World: r3wp
[!REBOL3-OLD1]
older newer | first last |
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) |
Geomol 5-Apr-2006 [126x2] | 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. | |
Ladislav 5-Apr-2006 [128] | 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 |
Geomol 5-Apr-2006 [129x2] | 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. | |
Ladislav 5-Apr-2006 [131] | good night to you and everybody |
Geomol 5-Apr-2006 [132] | night! |
JaimeVargas 5-Apr-2006 [133] | I think not having the extra block is better, and concise. |
Volker 5-Apr-2006 [134x2] | which orca-site? trac (but timeline says nothing), campfire or altme? |
sorry, wrong group.. | |
Anton 6-Apr-2006 [136x2] | 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). | |
Kaj 6-Apr-2006 [138] | Common Lisp Object System? :-) |
Anton 6-Apr-2006 [139] | ;-) |
Robert 6-Apr-2006 [140x2] | 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. | |
older newer | first last |