World: r3wp

on OSX, it would be nice to have native access to file metadata (what 
"mdls filename" return from the terminal in Tiger) with something 
like info?/all or info?/meta or info?/metadata returning an object 
with the metadata.

Ladislav, yes, I don't think we need the feature :)

Ladislav, I don't have time to think it all to the end, but an advise: 
Keep it simple!


I know, it's a very hard goal to reach, because we don't want to 
cut off possibilities. If it's possible for someone new to the language 
to use a feature like "function-local return" right away with expected 
result, and still the advanced programmer can use the feature in 
a way maybe not obvious at first, but that makes good sense, then 
it might be perfect.


But don't make the advanced programmer happy, if it'll make things 
difficult for the newbie.


recursive usage of the function that may request a return from different 
instances of the recursion

 sounds complicated at first. I think, you're right. We probably don't 
 need such a feature. If the code (C source) become simpler by including 
 the feature in recursion, then you might consider it though.

it seems to be the other way around - adding this feature may complicate 
and slow down the interpreter as it looks. Otherwise my observations 
are, that Carl is taking care to keep REBOL simple. (beginners don't 
need to use functions with local return at all)

hmm, mid May, I wonder if some eeeeearly alpha 3.0 Core is already 
starting to emerge on Carl's harddrive :-)

Ladislav, then it's easy. Leave the feature out, as you suggested! 
:-)

petr, sure it's running on Carl's computer. it has probably been 
for a while. it'll be more interesting when it starts working outside 
of his computer too ;)

gabriele, looking forward to the behind-the-scenes DVD! :-)

lol, we should ask carl to keep a video camera in is studio maybe 
;)

that would be good. 4 hours of video, watching Carl typing on his 
keyboard.

Someone send Carl a webcam, please! ;-)

Oh, he already has a webcam!!! Here's a snapshot from it: http://www.bronzelady.com/ARMANI/fantasia.jpg

if those were the methods of development, I would not have any trust 
in a REBOL3 release :-)

then again, Arthur C. Clarke said "Any sufficiently advanced technology 
is indisinguishable from magic." What if wizards like Gandalf or 
witches really are people from a distant future? :-)

hehe You make me think of the sci-fi novel "Hyperion" by Dan Simmons. 
In that nano-technology has advanced, so you can have little invisible 
robots in the air around you doing "magical" stuff. Read it, if you 
haven't! One of the best. Same idea in the online role-playing game 
"Anarchy Online". Lots of fun!

Michael Crichton reused the idea in "Prey"

In that novel, the nano-bots couid only be destroyed in the final 
chapter by a bunch of peasants with flaming torches.

Hang on, no: it was a bunch of techies with thermic lances. But they 
didn't use REBOL to program the little critters.

Ladislav, Doesn't RETURN/FROM promotes 



spaghetti coding ?

;What do i miss?
f: func [
    /local g
] [
    catch/name [
        g: func [n] [
            if n = 0 [
                return 0
            ] 
            if n = 1 [
                throw/name 1 'return-from-f
            ]
        ] 
        g 0 
        g 1 
        g 0
    ] 'return-from-f
] 
probe f

Jaime: spaghetti coding always possible, this is to enable control 
functions which need such features

Volker: I probably didn't say it clear. Your are right, that  the 
example can be implemented using Catch/Throw. What I wanted to say 
is something else:

Throw/Catch can be implemented using local return functions. Local 
return functions cannot be implemented using Catch/Throw.

Hmm, spaghetti coding: when I think about it, this is a step in that 
direction, yes.

Regarding the example Volker wrote: yes, it is a way how to do similar 
things, but it differs - Catch/Throw ignore contexts, so the behaviour 
is not equivalent, although it looks so

Contexts are a good point. Spagetti: oi agree. Hard to see there 
is a hidden return when looking in 'f. But maybe 'catch could use 
contexts, or would that be overkill? Or, catch, explicit 'equal? 
and rethrow otherwise? (or was it 'same? have to look on the ML ;)

Ladislav: could you give an example of a controlfunction where it 
would be useful ? Now I know what it means, but don't have an example 
in mind, when/how I would use it. Nevertheless, I'm always for having 
concepts in the language which make things possible, which otherwise 
would be hard to achieve (or just by doing some tricks with other 
language constructs - note! doesn't necessarily mean the catch example 
- can't judge this). If a normal user won't be affected and it's 
ok with Carl and the implementation - why not having it?

Guessing: in recursion one typically goes into a function, guess 
a few ifs deep, does some work and returns. 
 either n > 0 [do-work exit][recurse n - 1]

If that is long, one ants to split that in multiple functions, indirect 
recursion
  f: func[n][  some-checks-or-return  g-checks n]
  g: func[n][either n > 0 [do-work exit/from f][f n - 1]
And that is not possible, one can only exit 'g itself.

guess -> goes

ants -> wants

coffee -> mouth .. (urgent!) *sigh*

'g-checks and 'g are the same, typo.

example of a control function where it would be useful: control functions 
usually have to ignore non-local returns (rethrow them or whatever 
we call the behaviour), because they are meant for different purposes. 
If we want/need to use return in a control function, we have to use 
a specific (local) return to discern it from non-local returns

so the purpose of local return in a control function may be the same 
as the purpose of ordinary return in ordinary functions

What we currently flag with func[[throw]] ?

I understand control-function as  'forall and friends.

Volker: yes, to both questions. It is possible that users find other 
applications for functions with local return, though.

But wasn

anyway, this is a design stage, so the things may change as I understood

sorry - was in send on return mode


but wasn't in one of Ladislavs articles already something about these 
two types of return ? this is about the same then ... just looked 
different to me

yes, this means we will have some features I described available 
natively

so the question or discussion is mainly about these two distinct 
types of return and not something else .... because to me it looks 
(outside of this use), also quite disturbing or weird if people start 
to leave a nested functions suddenly to somewhere maybe not immediately 
visible

ok

MAybe some hinting in the control-func? How about a 'catch which 
knows its function-name? and throw/to res 'func-name? Would still 
be short. Although if he have
 a -> b -> c 
and c return to a, 'b must call in that way too.

How is this control func thing solved with macros in lisp - I'm just 
curious but whould have to look that up, does somebody know this 
out the mind immediately ? (is it different because kind of preprocessed 
before actually used)

I think that different interpreters/compilers of Lisp use different 
solutions.

Well. Lisp has only maybe two control mechanisms, one is tail-recursion, 
and the second call-with-current-cotinuation (kind of goto but with 
the context stack maitain). You can build any other control mechanisme 
from loops to preemptive-threading with this two constructs.

The macros are just a way to do syntactic-enhancement. In a sense 
they are just templates to basic constructs.  But this templates 
are quite 'smart'

I've been wondering about an extension to EXTRACT as I haven't been 
able to find this particular functionality anywhere else. If it exists, 
then I'm wrong and you can ignore this.


I would like to propose adding a /size refinement to set the number 
of values extracted at each point. This would make it very easy to 
split a string in equal-sized chunks. It could also be used to retrieve 
equal sized parts of a set of database records. Combining this with 
/index, I think this could be very useful.

Here's how I would like it to work:

>> block: [1 2 3 4 5 6 7 8 9]
>> extract block 2
== [1 3 5 7 9]
>> extract block 4
== [1 5 9]
>> extract/index block 2 2
== [2 4 6 8 none]

The refinement at work:

>> extract/size block 4 2
== [[1 2] [5 6] [9 none]]
>> num: to-string 123456789
== "123456789"
>> extract num 3
== [#"1" #"4" #"7"]
>> extract/size num 3 1
== ["1" "4" "7"]
>> extract/size num 3 2
== ["12" "45" "78"]
>> extract/size num 3 3
== ["123" "456" "789"]
>> extract/size num 3 5
== ["12345" "45678" "789"]
>> extract/size/index num 3 5 2
== ["23456" "56789" "89"]
>> extract/size num 3 12
== ["123456789"]

/size would always return a block of series.

Looks like it could be useful Henrik. I might call the refinement 
/part, to match other funcs. For the case of splitting a series into 
equal-sized pieces, or a fixed number of pieces, here's what I use:

split: func [  ; subdivide, chunk, segment  ?

        {See: CLOS pg. 937. Not that mine works the same, but that was
        the inspiration.}
        series [series!]

        size   [integer!] "The size of the chunks (last chunk may be shorter)"

        /into  "split into a set number of chunks (last chunk may be longer 
        than others)."
        /local ct cur-piece result
    ][

        ct: either into [size] [round/down divide length? series size]
        if into [size: to-integer divide length? series size]
        result: copy []
        if zero? size [return result]
        parse series [
            ct [

                copy cur-piece size skip (append/only result cur-piece) mark:
            ]
        ]
        if any [into  not zero? remainder length? series size] [
            cur-piece: copy mark
            either into
                [append last result cur-piece]
                [append/only result cur-piece]
        ]
        result
    ]

>> b: [1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4]
== [1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4]
>> chunk b 4
== [[1 1 1 1] [2 2 2 2] [3 3 3 3] [4 4 4 4]]
>> chunk b 2
== [[1 1] [1 1] [2 2] [2 2] [3 3] [3 3] [4 4] [4 4]]
>> chunk/into b 2
== [[1 1 1 1 2 2 2 2] [3 3 3 3 4 4 4 4]]