r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Ladislav
5-Apr-2006
[76x4]
make-f-returning: func [x] [does [x]]
f-returning-ok: make-f-returning "ok"
f-returning-ok ; == "ok"
f-returning-wrong: make-f-returning "wrong"
f-returning-wrong ; == "wrong"
f-returning-ok ; == "wrong"
make-g-returning: closure [x] [does [x]]
g-returning-ok: make-g-returning "ok"
g-returning-ok ; == "ok"
g-returning-wrong: make-g-returning "wrong"
g-returning-wrong ; == "wrong"
g-returning-ok ; == "ok"
what do you say to this?
the alternative to the initialization block is to not use it and 
initialize everything to NONE like in the FUNC case
Geomol
5-Apr-2006
[80x2]
ok, I see the difference. And I guess, it's benefitial, because using 
bind can be difficult.

And your question is, if closure should have a third block with "cheap" 
initializations?
Like in your:
 c: closure [/local a] [a: 0] [a: a + 1]
Ladislav
5-Apr-2006
[82]
the question is, if users want to have the additional (actually second) 
block for the initialization purposes of do not mind to have everything 
initialized to NONE
Geomol
5-Apr-2006
[83x3]
Damn hard question! :-)
It mayl be easier to say, when I've done 10 programs using closure. 
But I'll think about it.
may
Ladislav
5-Apr-2006
[86]
you do not have to know anything about closure, you may imagine the 
same question for FUNC case: would you appreciate to be able to specify 
the initial values for locals?
Geomol
5-Apr-2006
[87x3]
Before I answer that..

I use FUNC all the time. I almost never use FUNCTION. I guess, because 
I have to write more with FUNCTION.
I also started to use HAS and DOES, when I found those.
CLOSURE may come in the group with FUNCTION, if it get 3 blocks as 
arguments, so I may not use it.
Could it be possible to make the initial assignments in the first 
(and only) argument block?
Ladislav
5-Apr-2006
[90]
the only disadvantage of initialization I came to is the more complicated 
interface to CLOSURE needing always one more block to specify
Geomol
5-Apr-2006
[91]
I think, that's a very good point! REBOL programmers don't like to 
write much.
Ladislav
5-Apr-2006
[92]
it may be possible to put the initializations into the first block 
but that would cost some syntax complications and differencess too...
Geomol
5-Apr-2006
[93x2]
yeah
Could we have 2 versions of closure, like we have func and function? 
One where init = NONE and one with the extra block?
Ladislav
5-Apr-2006
[95]
probably yes, although Carl always hesitates to include unwanted 
features
Geomol
5-Apr-2006
[96x4]
I can understand that.
Let's see another example with the extra block:
f: closure [x /local a]Ê[a: 2 * pi] [(sine/radians x) / a]

without:
f: closure [x /local a] [a: 2 * pi (sine/radians x) / a]


Is it something like this, you're thinking about? And will the first 
be faster than the second?
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?
Ladislav
5-Apr-2006
[100]
I do not know, but think so
Geomol
5-Apr-2006
[101]
Is the idea, that the second closure block will only be parsed one 
time? (and therefore be fast)
Ladislav
5-Apr-2006
[102]
yes
Allen
5-Apr-2006
[103]
Rebcode is mentioned on the roadmap doc
Geomol
5-Apr-2006
[104]
Ok, functions with many constants will be much faster with this extra 
block then, right?
Ladislav
5-Apr-2006
[105]
faster, yes, much faster - maybe not
Geomol
5-Apr-2006
[106]
Where is your opinion against? With or without the extra block?
Ladislav
5-Apr-2006
[107]
my opinion is not strong, therefore I am asking
Geomol
5-Apr-2006
[108]
hehe :)
Ladislav
5-Apr-2006
[109]
the main point against it is the more complicated syntax, which could 
be used for static initialization, that may be even more useful sometimes
Geomol
5-Apr-2006
[110]
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.
Ladislav
5-Apr-2006
[111]
too much to write: actually not, let's compare:
Geomol
5-Apr-2006
[112]
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.
Ladislav
5-Apr-2006
[113]
f: closure [/local e] [e: exp 1 print e]
g: closure [/local e] [e: exp 1] [print e]
Geomol
5-Apr-2006
[114]
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.
Pekr
5-Apr-2006
[115x2]
Wasn't closure called indefinite extend in rebol 1.0?
extent
Geomol
5-Apr-2006
[117]
You need to ask someone familar with function (and not just func).
Ladislav
5-Apr-2006
[118]
>> length? "function [] [a] []"
== 18
>> length? "func [/local a] []"
== 18
Pekr
5-Apr-2006
[119]
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 
...
Ladislav
5-Apr-2006
[120]
default: no need to guess there, it will be called differently but 
*implemented* in Rebol3
Geomol
5-Apr-2006
[121]
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.
Pekr
5-Apr-2006
[122x2]
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 ...
Geomol
5-Apr-2006
[124]
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
Ladislav
5-Apr-2006
[125]
I am not sure about object cloning, otherwise lots of things *will* 
be improved (parse, closures, function attributes to mention just 
a few)