World: r3wp

It has support for tasks, but the method for tasking on a low level 
is supposedly not the correct one, given that R3 could be running 
on an OS kernel without threads.

I repost here: task is a discovery for me. I am interested to know 
if  it will be developed. It might be an important feature for R3.

oops, now I posted the response in the wrong group. :-)

ok, saw it, thanks

oops, I did it again:


The problem is that OS kernels do it differently, depending on their 
capabilities, so the current threading model used to create tasks 
may have to go.

yes, its a real challenge ...

Fortunately Carl has a little bit of experience with multitasking, 
so I'm sure a good model will come up. :-)

Of course ! He certainly will find a clever approach !

Graham, is it important to take into account leap years in your solution?

No, just accurate within a couple of days.

What is it that prevents this from working:

a: reduce [make object! [
        t: 3
        g: 5
    ] make object! [
        h: 12
        u: 15
    ]]

c: 2

a/:c/h
== 12 ; good

d: 'a/:c

d/h
== error!


It would be so wonderful to use only paths here instead of relying 
on GET IN GET IN GET IN...

Notice that I use a lit-path. I don't want evaluation to occur until 
the final moment.

>> p: 'a/b/c/d
== a/b/c/d
>> pick p 2
== b
>> p/2 
== b
>> p/c
== d
>> select p 'c
== d

Well, that's the inverse of what I would like to see: Path building 
using refinements only.

You can do it with file!:

a: %/c

a/somewhere
== %/c/somewhere

>> b: a/somewhere/else
== %/c/somewhere/else
>> b/subdir
== %/c/somewhere/else/subdir

etc...

When you write

d: 'a/:c


d become a path! datatype, and it's not connected to your block, 
a, in any way. If you wanna expand the path, you can do something 
like:

>> join d 'h
== a/:c/h

Is that what you wanna happen?

You can evaluate it with:

>> do join d 'h
== 12

It seems path! doesn't work like file! but more like block!, which 
is also what Gabriele pointed out, I think.

>> d/a
== :c


And that is also, why d/h fails. h is not found in the d path anywhere.

well, that's actually better, because I can put several refinements 
on top of a path!, which is really what I want:

>> a: 'b/c
== b/c
>> join a 'e/d
== b/c/e/d

but that final bit about using refinements alone would be cool

ok, I didn't get the block connection there, but I see it now.

It is a bit confusing, also because both path! and file! are series, 
so it's easy to think, they should work the same.

>> series? d
== true
>> series? %/a/b/c
== true

A question: can it be justified, that file! is a series?

>> a: %/c
== %/c
>> first a
== #"/"
>> a/1
== %/c/1


Is file! a pseudo-series? What exactly defines a series? It's some 
sort of a sequence of values, that can be picked individually. And 
series can be sorted, right? So the methods (or functions), that 
can be performed on the datatype defines its type. What defines a 
series in REBOL?

hehe I was writting up the EXACT same reply than geomol pointing 
out block and how to use do join x y ... had to for an exam at the 
dentist... I come back and geomol beat me to it  ;-)

each series type handles path actions how it wants to.

files append to themselves, blocks do lookup, strings return chars.


to be a series, in has to support insert, copy, first  which is why 
tuple isn't a serie.

in = it

Henrik, in R3 use get-paths instead:
>> a: reduce [func [] [print "hello"]] c: 1
>> a/:c
hello
>> print mold :a/:c
make function! [[][print "hello"]]


Get-paths solve your problem of delayed evaluation without using 
GET IN. Your example would be d: :a/:c insteac of 'a/:c.

Geomol: "What defines a series in REBOL?"


A series has contents, sequence and persistent position. The characters 
that make up a file (contents) are in a specific order (sequence) 
and you can do an offset reference to a later offset in the filename 
(position). If you do FIRST %a it will return #"a" every time (persistent 
position). Being a series doesn't mean that it is sortable, though 
many are. Being sortable means also having the contents be comparable, 
and the series be modifiable.


We were careful to make sure that things that aren't really series-like 
were removed from the series! typeset in R3. R2 is less consistent 
in this regard, so you have some types attempting to act series-like, 
poorly - pots being the worst example.


Some of the functions that act on series also act (differently) on 
non-series, but not all.

pots?

ports (stupid keyboard)

I thought that to qualify to be a series, a type also needed to support 
insertion, not only indexing and content.


cause your above definition qualifies tuple! to be a series, but 
they aren't.

Tuples don't have position.

Give me a sec, I'll list out the relevant functions...

hehe, yeah.... doh!  ;-)

(above related to tuple position comment)

Position: HEAD, TAIL, HEAD?, TAIL?, AT, SKIP, NEXT, BACK

Contents: PICK, POKE (for modifiable series), ordinals (FIRST, ..., 
LAST)

Sequence: PICK and POKE can use numbers (used to implement ordinals)

Persistent position and sequence: All of the above are repeatable, 
with no position change side effect.

and INDEX?   ;-)

Right, as a position function.

LENGTH? too. Note that in R3 an image! counts as a series, though 
it has 2 different position measures.

Bitsets, tuples, objects and maps don't have position. Objects and 
maps don't have sequence either (at least not in theory).

Ports in R3 (or open/direct or command ports in R2) don't have persistent 
position and sequence, or reference position. This makes them streams, 
not series.

yes basically, they are always at position 0 and looking at the data, 
implies you remove it, so ports are like quantum series  ;-)

The reference position vs inherent position distinction is important. 
That is why the position functions are seeking procedures for ports, 
while they are pure reference-returning functions for series.

It'd still be nice to have an interface that in some ways behaved 
like R2 ports (I think of it as adapter!) that allow the above series 
functions to operate on customised, abstracted series.  Perhaps I'm 
overlooking a simpler way of addressing the problems I have in mind.

It seems (by my reading) R3 ports have evolved toward more closely 
modelling streams of data as opposed to pools.

BrianH, I don't understand your get-path example. How can I use it 
to build more paths? You have to remember that I'm not interested 
in having a default path which then is altered. I want to build then 
by joining several paths together, just like file! does.

Well, paths are like blocks, not like filenames. You can't make them 
act like filenames without breaking them *in every other way*. You 
can build path just fine with JOIN and APPEND, you can fully evaluate 
them with DO, and you can partially evaluate them with get-paths 
without ever needing to use GET IN. Functionally, there is no problem 
with R3's current behavior except bugs 396, 861, 1236, 1339, and 
maybe 746 and 803.

We can safely assume that you are talking about R3 when proposing 
that behavior be changed, since R2 is in compatibility mode.

Anyone know a simple way to transform a block of sub-blocks into 
a single block while retaining the original type? I have [ [1] [2] 
[3]] and I'd like [ 1 2 3]. I can do with with form and parse but 
it  then I get ["1" "2" "3"].