World: r3wp

And the third possibility (which maybe not is very REBOLish):
f: closure [x /local a: 2 * pi] [(sine/radians x) / a]

Ladislav, will rebcode be part of REBOL3? Do you know?

I do not know, but think so

Is the idea, that the second closure block will only be parsed one 
time? (and therefore be fast)

yes

Rebcode is mentioned on the roadmap doc

Ok, functions with many constants will be much faster with this extra 
block then, right?

faster, yes, much faster - maybe not

Where is your opinion against? With or without the extra block?

my opinion is not strong, therefore I am asking

hehe :)

the main point against it is the more complicated syntax, which could 
be used for static initialization, that may be even more useful sometimes

I have a feeling, that it'll be a little too much to write (like 
with function), and therefore I'll probably wont use it much.

too much to write: actually not, let's compare:

If the idea with closure is, that programmers having trouble with 
func (and feel going into using bind is difficult), then the more 
complicated syntax will also not be good, as you say.

f: closure [/local e] [e: exp 1 print e]
g: closure [/local e] [e: exp 1] [print e]

hm it doesn't look right to me. I think, because I'm not used to 
function (which also has 3 blocks). I would read it, as the second 
block is the function, and then I'll be confused, when seeing yet 
another block.

Wasn't closure called indefinite extend in rebol 1.0?

extent

You need to ask someone familar with function (and not just func).

>> length? "function [] [a] []"
== 18
>> length? "func [/local a] []"
== 18

Ladislav - I will read it tomorrow, as now I go to sleep - travelling 
to Prague tomorrow, so I better get some sleep ... but I do remember 
there were other goodies, which even I understood. Not sure now, 
if it was 'default ... I need to go via your materials once again 
...

default: no need to guess there, it will be called differently but 
*implemented* in Rebol3

Yes, the same amount to type. So it's not precisely true, that it's 
the amount, but also the more complicated syntax = more difficult 
to read.

ha, cool ... thanks :-) So in overall - what about some of your other 
enhancements? Any changes to parse? binding? object cloning? map? 
You know - your rebol pages contain lots of stuff - http://www.fm.vslib.cz/~ladislav/rebol/

Ladislav - what it was about with | or some other kind of assignment? 
IIRC it was rejected - just curious ...

What is the speed of this compared to using closure (with the extra 
block):
o: context [a: 2 * pi f: closure [x] [(sine/radians x) / a]]
And then call it by: o/f 1

I am not sure about object cloning, otherwise lots of things *will* 
be improved (parse, closures, function attributes to mention just 
a few)

My idea is, if a function has lots of constants, programmers may 
just put them in an object?

So the function doesn't have to initialize them every time.

Geomol: my guess is, that if you wrote: context [a: 1 / 2 / pi set 
'f closure [x] [a * sine/radians x]], you wouldn't be slower than 
the initialization block can be while retaining the "static nature" 
of the defined variables, that can be even changed when wanted

Isn't the conclusion then, that closure doesn't need the extra block? 
It's possible to have the speed without, and the extra block will 
complicate the syntax.

I gotta sleep too. Working day tomorrow.

good night to you and everybody

night!

I think not having the extra block is better, and concise.

which orca-site? trac (but timeline says nothing), campfire or altme?

sorry, wrong group..

I wonder how much closures will be used. For some apps, probably 
a lot. But we do pretty well everything with FUNCs right now. Therefore 
I suggest CLOSURE to take three block arguments, as it will not be 
used as much in general.

(and if it does turn out to be used a lot, then that would justify 
adding a separate function, taking two blocks (probably called CLOS).

Common Lisp Object System? :-)

;-)

Closures: I never understood why we have FUNC and FUNCTION. I always 
use FUNC with /local, which seems very natural for me. So why not 
add something like: FUNC [a /static x /local b c d] ?

Than I see what every word is about. Otherwise I have to remember 
the semantics from the position of the blocks within a function definition.

Nice one! Ladislav, does it makes sense to add /static to FUNC, or 
does CLOSURE do something more?

Actually, CLOSURE does not have anything in common with STATIC, it 
is "more dynamic", than FUNC in a sense

(it looks like this confusion is my mistake - maybe I shouldn't have 
mentioned the STATIC variant?)

Why we have FUNC and FUNCTION: FUNCTION is older than FUNC, it is 
a "relic" from the Rebol1 days (some of my code survived the generation 
 change because I used FUNCTION)

the /static variant looks like unacceptable (incompatibility issues)

Anton: your argument looks to me as yet another reason why *not* 
have additional initialization block :-)