World: r3wp
[!REBOL3-OLD1]
older newer | first last |
Maxim 15-Dec-2006 [1726] | ready, aim, fire that pretty much covers the dialect |
Henrik 15-Dec-2006 [1727] | and reload? |
sqlab 18-Dec-2006 [1728] | and lock and unlock.) |
Henrik 20-Dec-2006 [1729] | Ladislav, it wasn't until you wrote those two small examples, that I finally understood what APPLY is about. :-) |
CharlesS 20-Dec-2006 [1730] | what examples |
Henrik 20-Dec-2006 [1731] | charles, see the R3 blog on the APPLY function at the bottom of comments |
CharlesS 20-Dec-2006 [1732x2] | What advantages does HASH have over regular blocks, I can access a regular block like a dictionary anyway |
right ? | |
Henrik 20-Dec-2006 [1734] | it's very fast |
Maxim 20-Dec-2006 [1735x2] | speed.... MUCH faster on lookup |
IIRC slower on insert | |
Henrik 20-Dec-2006 [1737x3] | I think the normal procedure is to manipulate your block like you normally would and then convert it to hash! when you want to do lookups |
I posted something on the APPLY thing on empty argument blocks, which I think should produce an error. This made me think of whether there is a very easy way to tell how many arguments a function requires? | |
ah, first :+ == [value1 value ] | |
JaimeVargas 20-Dec-2006 [1740x2] | variable arg dispatching breaks a major premise of rebol dispatch mechanism. |
Henrick. In scheme/lisp. apply :+ [] ;== 0 whichs is a very sensible result. | |
Henrik 20-Dec-2006 [1742] | well, is it then not necessary to set up different rules for what it should output for different functions? |
JaimeVargas 20-Dec-2006 [1743x2] | I am not sure what you mean. Another example is: apply :* [] ;== 1 |
Scheme gives out this results because 0 and 1 are *neutral* numbers regarding addition and multiplaction. That is the result is unaltered by those values respectevely. | |
Henrik 20-Dec-2006 [1745] | these are arithmetic operations. what about other kinds? |
JaimeVargas 20-Dec-2006 [1746] | Rebol functions can't accept a variable number of arguments with the exception of refinements. So the issue is becomes important. APPLY is kind of incompatible to the principle that * every function has a fixed number of arguments*. |
Izkata 20-Dec-2006 [1747] | They can if you take advantage of the unset! datatype... But it's not pretty and more confusing than it's worth |
Henrik 20-Dec-2006 [1748] | I just think it would be more straight forward with natives for performing arithmetics on blocks. It's more predictable. |
Maxim 20-Dec-2006 [1749] | predictable? |
Henrik 20-Dec-2006 [1750] | apply :* [] ;== 1 isn't predictable within REBOL terms, I think |
JaimeVargas 20-Dec-2006 [1751x2] | APPLY just means run this function with the block content as args. So: APPLY :+ [1 2 3 4] is equivalent to DO [+ 1 2 3 4] ;; using scheme semantics |
If we stick with this definition an no varargs for functions then APPLY :+ [1 2 3 4] is impossible it actually should throw an error because the native '+ requires two arguments. | |
Maxim 20-Dec-2006 [1753] | yes Jaime that is how I see it in REBOL too... so in rebol the last two args would be ignored if we use the current understanding |
JaimeVargas 20-Dec-2006 [1754] | In which case APPLY with math ops is kind of lame compared to scheme. |
Maxim 20-Dec-2006 [1755x2] | how does scheme understand to continue grabbing values? because its not hitting an action? |
or because it servers args within an argument () ? | |
JaimeVargas 20-Dec-2006 [1757x3] | I APPLY was simply implemented as the DO translation; you will get tons of side effects. Because, APPLY :+ [1 2 3 4] implented as DO [+ 1 2 3 4] ;== 4 (NOT 10 wich is the expected result). |
Because in Scheme you can have function with variable number of arguments thanks to the parenthetical notation. (APPLY + '(1 2 3 4)) ;== (+ 1 2 3 4) and '+ is coded to handle variable arguments. | |
In scheme the parenthesis tell the function where the expression ends. In rebol the number of arguments tell the function where the expression ends. This is a very fundamental difference and the tradoff made when dropping parenthesis or any kind of expression delimiter. | |
Maxim 20-Dec-2006 [1760x2] | exactly. |
but we can just implement our functions with a single block argument if we wish... then its a moot point... no? | |
JaimeVargas 20-Dec-2006 [1762x2] | No. Because now you need to be passing blocks everyware. And doing composing for symbol to value replacement everyware. |
For example: 1 + 2 becomes + [1 2], and then how you handle + [a b]. You need a prebinde code. Basically that reitroduces parens. | |
Maxim 20-Dec-2006 [1764x5] | yes obviously, actually calling reduce all the time. |
I've often wondered if I missed variable args, and it seems I don't miss them that mutch. they seem less needed in rebol. | |
but refinements are hard to reapply. | |
which is why I then use blocks as above. | |
I guess it could be nice if the burden of calling reduce where on the function itself. | |
JaimeVargas 20-Dec-2006 [1769] | I actually like the ability of having variable args. It is very handy. |
Maxim 20-Dec-2006 [1770x3] | in the example of a function which accepts one variable length block, it could cause the prebind (reduce) itself as a pre-entry operation. |
in this case it would allow a parens-like calling method, but we'd use blocks and the caller would not need to reduce the value explicitely. | |
obviously, the function args spec would have to be expanded a little. | |
JaimeVargas 20-Dec-2006 [1773x3] | (apply * (map + item-order-list item-price-list)) for example (apply * (map + '(1 2 4) '(100 50 25))) ;== 300 That is my one line scheme code for totalizing an order. |
But if function pre-bind blocks or pre-reduce, you lose CODE-AS-DATA, beside making function evaluation slower. | |
I used such technique in my toy implementation for supporting multimethod . (Found in rebol.org) | |
older newer | first last |