Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[RWEBOL] HOF and system exploration

 [1/26] from: jan:skibinski:sympatico:ca at: 23-Oct-2002 12:23


Hi All, First, a bit of statistics to show how useful the HOF (Higher Order Functions) are for system exploration. Then a bit on 'signature function. [Some of the idioms shown below might of general use.] {How many words are defined in my system?} length? first system/words ; == 2318 {How many words have any value?} length? filter :value? (map :to-lit-word first system/words) ; == 645 . {So what are the other words for? A garbage or contents of definition?} {Set 'x to be the block of all literal meaningfull words} x: filter :value? (map :to-lit-word first system/words) {Convert from lit-words to regular words} x: map :to-word x {How many of those are any functions: native, op, function, action?} is-any-function?: func [x][any-function? get x] length? filter :is-any-function? x ;== 457 {How many of those are mezzanine functions?} is-function?: func [x][function? get x] length? filter :is-function? x ;== 211 {Get only the mezzanine functions} x: filter :is-function? x {Get a block of argument counts for mezzanine functions} args: map :nargs reduce (map :to-get-word x) ; [1 0 1 1 0 1 2 1 3 1 2 1 2 1 2 2 1 1 2 ....] {Get the maximum of the block of args} maximum-of args ; == [5 5 4 4 3 3 ....] {OOPS! Unexpected answer!} {Sort the args in ascending order} sort/reverse args ; == [5 5 4 4 3 3 3 ...] {Yeah, that's what the 'maximum-of appears to be doing!} {Group the functions according to number of arguments} x0: filter (func[u] [0 == nargs (get u)]) x x1: filter (func[u] [1 == nargs (get u)]) x x2: filter (func[u] [2 == nargs (get u)]) x x3: filter (func[u] [3 == nargs (get u)]) x x4: filter (func[u] [4 == nargs (get u)]) x x5: filter (func[u] [5 == nargs (get u)]) x {List the count of arguments in each group and total} map :length? reduce [x0 x1 x2 x3 x4 x5 x] ; == [35 125 34 11 2 2 209] {Now set the 6 lists of function signatures} s: copy [] foreach k [x0 x1 x2 x3 x4 x5] [append/only s (map :signature get k)] {So what is the signature for?} {For simplicity, let us assume this alias ordered! = [number! char! date! money! time!] is legal. Soe here are just two examples:} signature even? ; == [even? [ordered!] [any!]] {Which means: function 'even has a type from ordered! to any!} {Typing can be improved a bit by declaring the result, as in this "improved" version:} signature even?' ; == [even?' [ordered!] [logic!]] ======================================================= Why is a concept of signature important? Many reasons. One example that immediately comes to mind is that the function 'filter use in many examples above: filter :some-function series works only with a proper subset of functions of this specific signature: [some-function: [any-type!] [logic!]] The filter would barf on anything else!! If anyone is interested I can post the 'signature function - together with somehow modified and well tested 'map and 'filter functions. Jan

 [2/26] from: jan:skibinski:sympatico:ca at: 23-Oct-2002 12:30


Sorry for mistyped title. Jan

 [3/26] from: rotenca:telvia:it at: 23-Oct-2002 20:13


Hi Jan Skibinski
> {So what are the other words for? A garbage or contents of definition?}
When a word is loaded also as a simple value, it is added to the global context. Why? I do not know. But i know that using un-loaded words can trig a crash error under some conditions. find mold first system/words "foo"; == none load "[foo]"; == [foo] last first system/words; == foo This generates an un-loaded word: find mold first system/words "foo2"; == none to-block "foo2" ;== [foo2] last first system/words; == foo --- Ciao Romano

 [4/26] from: rebol:optushome:au at: 24-Oct-2002 6:08


Ladislav's continually evolving highfun.r A set of higher order functions: Accum, Apply, Curry, Curryfirst, Composition, Filter, Map, Mapper, Nargs and Refined. http://www.rebolforces.com/~ladislav/ Cheers, Allen K

 [5/26] from: jan:skibinski:sympatico:ca at: 23-Oct-2002 16:11


Allen, I know and appreciate Ladislav's efforts. Andrew Martin, Joel Neely have also produced few nice gems. And possibly others as well. I always give due credits in scripts. In addition to the HOFs you mentioned there are other HOFs worthy to consider: fold family, zip, unzip, flip, combinators, list [block] comprehension, etc., etc. Nothing really new, but fun to use in Rebol :-). I already implemented some of them, took a shot at currying by re-writing, etc. All the rest in due time. For a moment I play with 'signature stuff to decide on usefulness or lack of it - as far as rebol is concerned. Jan Allen Kamp wrote:

 [6/26] from: jan:skibinski:sympatico:ca at: 23-Oct-2002 18:35


An anonymouse writer wrote personally to me,
> Please do post the three functions to the list or if it is > too much work to clean them up I'd love a copy just > the way they are. >
So I posted the signature.r to www.reboltech.com/library/scripts Includes the examples from the original post - both commented and uncommented for quick evaluation in one shot. Aside from reading my lengthy comment about signatures try and look carefully at output of: signature filter help filter signature map help map Best, Jan -- Attached file included as plaintext by Listar -- X-Mozilla-Status2: 00000000 Message-ID: <[3DB72147--91022B30--sympatico--ca]> Date: Wed, 23 Oct 2002 18:23:03 -0400 From: Jan Skibinski <[jan--skibinski--sympatico--ca]> Reply-To: [jan--skibinski--sympatico--ca] X-Mailer: Mozilla 4.73 [en]C-SYMPA (Windows NT 5.0; U) X-Accept-Language: en,pl,fr-CA MIME-Version: 1.0 To: Rod Gaither <[rgaither--triad--rr--com]> Subject: Re: [REBOL] [RWEBOL] HOF and system exploration References: <[9132C624-E6B5-11D6-912D-00039387DE76--triad--rr--com]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rod Gaither wrote:
> Please do post the three functions to the list or if it is > too much work to clean them up I'd love a copy just > the way they are. >
Posted to www.reboltech.com/library/scripts/signature.r Includes the examples from the original post - both commented and uncommented for quick evaluation in one shot. Aside from reading my lengthy comment about signatures try and look carefully at output of: signature filter help filter signature map help map Best, Jan

 [7/26] from: lmecir:mbox:vol:cz at: 26-Oct-2002 7:29


Hi Jan, ----- Original Message ----- From: "Jan Skibinski"
> there are other HOFs worthy > to consider: fold family, zip, unzip, flip, combinators, list
<<quoted lines omitted: 3>>
> I already implemented some of them, took a shot at currying > by re-writing, etc. All the rest in due time.
The following combinators were discussed on the list: U: func [f][f :f] Y: func [g][ U func [f][g func [x] reduce [:f :first reduce [:f] 'get/any first ['x]]] ] -L

 [8/26] from: lmecir:mbox:vol:cz at: 25-Oct-2002 8:43


Hi Jan, <<Jan wrote>> I propose to always define and use a special word 'result, along with its type in a function definition, as in: some-function: func [ x [..!] ..... /local result [logic!] ....... <</Jan>> RT wanted to use something like: some-function: func [ x [...!] ..... return: [logic!] ....... , but they didn't implement it yet. You can find that in the implementation of the HELP function. -L

 [9/26] from: lmecir:mbox:vol:cz at: 25-Oct-2002 9:02


Hi Jan, argument counts aren't strict in Rebol. Did you read http://www.rebolforces.com/~ladislav/argstake.html ? -L

 [10/26] from: jan:skibinski:sympatico:ca at: 25-Oct-2002 14:21


Ladislav Mecir wrote:
> Hi Jan, > > argument counts aren't strict in Rebol. Did you read > http://www.rebolforces.com/~ladislav/argstake.html ? >
Hi Ladislav,
> argument counts aren't strict in Rebol. Did you read > http://www.rebolforces.com/~ladislav/argstake.html ?
Sorry for the long answer but I think I owe it to you. I re-read the cited file just a while ago. I do not understand the business with 'unset yet, so I'll put this problem aside for a moment. A question of of refinements just complicates the picture but it is also tractable, so I'll let it be too. I would also put aside the case with :-, since Rebol seems to confuse itself sometimes by having a choice to interprete :- either as the unary operator 'negate or the binary operator 'subtract. I came across such examples too. But if you substitute :- by explicit 'subtract in your tests then everything is OK. But what disturbs me in your article is the last point you are making about a variable number of arguments which some functions, such as 'make and 'do, seem to take. I have examined your tests regarding the 'do function: args-taken? :do reduce [:- 1 2] ; == 3 args-taken? :do reduce [:make function! [] []] ; == 4 and came up with a conclusion that your tests here are not properly chosen for the current version of your 'args-taken? function. You would either need to redesign that function or use it with great care. For a start, I would expect the result = 1 in either case, -- not 3 and 4, as shown above. By definition, the 'do function expects ONE argument only, which is either a block of expressions, or a single expression silently packaged inside a block. If you modify the first test above as follows: x: reduce [:+ 1 2] ; I replaced :- by :+ to avoid unary/binary confusion == [op 1 2] args-taken? :do [x 99 sine 4] == 1 then you end up with the argument count == 1, as expected and also delivered by 'nargs: nargs :do == 1 Your 'args-taken? seems to check at runtime whether a function being tested (here the 'do function) accepts more arguments than officially described by 'help, or computed by 'nargs. So when 'args-taken? is supplied with a correct number of arguments - plus possible extra garbage - it uses the 'do/next to operate only on those arguments which are needed. But it fails if the number of arguments is underspecified. Since 'args-taken? depends on the framework you provide in the highfun.r I took a liberty to simplify it, to clearly understand what's going on here. arg-count?: func [ {How many arguments a function takes?} f [any-function! word! path!] args [block!] /local test ][ test: to-block :f foreach k args [ append/only test to paren! reduce [:k] ] test: do/next test print mold test (length? args) - (length? second test) ] For the debugging purpose I also print the output from the 'do/next executed inside that function. Running it on the same example as before arg-count? :do [x 99 sine 4] [3 [(99) (sine) (4)]] == 1 clearly shows where the 'do/next stopped executing. The result from 'arg-count? is 1 - as expected. Just to confirm, here is another test: arg-count? :+ [1 2 sine 4] [3 [(sine) (4)]] == 2 Take care, Jan

 [11/26] from: lmecir:mbox:vol:cz at: 26-Oct-2002 11:36


Hi, ----- Original Message ----- From: "Jan Skibinski"
> I would also put aside the case with :-, since Rebol seems > to confuse itself sometimes by having a choice to interprete > :- either as the unary operator 'negate or the binary operator > 'subtract.
... but this is one of the cases supporting my POV...
> I came across such examples too. But if you > substitute :- by explicit 'subtract in your tests then > everything is OK.
Yes, SUBTRACT behaves differently.
> what disturbs me in your article is the last point > you are making about a variable number of arguments > which some functions, such as 'make and 'do, seem to take.
...
> I have examined your tests regarding the 'do function: > > args-taken? :do reduce [:- 1 2] ; == 3 > args-taken? :do reduce [:make function! [] []] ; == 4
...
> For a start, I would expect the result = 1 in either case, > -- not 3 and 4, as shown above.
That is what everyone would expect, but as our great Czech Jara da Cimrman (a comedy character) said: You can protest or disagree, but this is all you can do about it :-)
> By definition, the 'do function expects ONE argument only, which > is either a block of expressions, or a single expression > silently packaged inside a block.
This is not by definition for me, this is by "description". I wanted to know what the truth is. The definition of DO in't directly accessible to me. Moreover, you can "package" as many expressions as you want into a block. (This may expose a "definitional" problem: how many expressions are in: [5 + 4 9 - 4] ? A possible answer is, that you see two expressions having results 9 and 5, or, you may say, that the last result is 5, which is the result of the code seen as one expression only. My POV is, that the above code consists of two expressions, which can be verified, if we use REDUCE [5 + 4 9 - 4] instead of DO [5 + 4 9 - 4].)
> If you modify the first test above as follows: > x: reduce [:+ 1 2] ; I replaced :- by :+ to avoid unary/binary
<<quoted lines omitted: 6>>
> nargs :do > == 1
DO took just one argument in this case. I didn't tell, that there weren't cases, when DO could take just one argument. Your modification wasn't just an operator replacement, you changed the type of the first argument supplied to DO! Even without replacing the operator you would get the same answer, because DO takes just one argument, if the first argument is a BLOCK! type value. x: reduce [:- 1 2] args-taken? :do [x 99 sine 4] ; == 1 Because you don't trust me with DO (a complicated case), you can try the MAKE example, which is simpler: first, let's use a simple example, when MAKE takes two arguments: make first [word] first [word] ; == word Let's transform the example to the form suitable for ARGS-TAKEN?: args-taken? :make [word word] ; == 2 No surprise here. Now a different example, where the first argument of MAKE is different: type? make function! [] [] ; == function! I am pretty sure, that MAKE "consumed" three arguments (one datatype and two blocks), which is the count correctly returned by ARGS-TAKEN?: args-taken? :make reduce [function! [] []] ; == 3 To show you the complications with DO, here is a simple task: Define a functional (let's call it SIMILAR) taking an ANY-FUNCTION! F, which can take one normally evaluated ANY-TYPE! argument. The result of SIMILAR should be a FUNCTION! value that yields equal results as the argument function F would yield. One possible solution is: similar: func [f [any-function!]] [func [arg [any-type!]] compose [(:f) get/any 'arg]] Now try to "correct" SIMILAR to work when it obtains DO as its argument :-) Cheers -L

 [12/26] from: jan:skibinski:sympatico:ca at: 26-Oct-2002 8:50


Hi Ladislav, A quick note related to this fragment of your last email..
> To show you the complications with DO, here is a simple task: > Define a functional (let's call it SIMILAR) taking an ANY-FUNCTION! F, which
<<quoted lines omitted: 4>>
> get/any 'arg]] > Now try to "correct" SIMILAR to work when it obtains DO as its argument :-)
I do not understand the task you posed. As far as I can see there is nothing to "correct" in your 'similar. Works like a charm for me, even with 'do: lado: similar :do
>> lado sine 90
== 1
>> lado [5 sine 90]
== 1 Jan

 [13/26] from: lmecir:mbox:vol:cz at: 26-Oct-2002 15:06


Hi Jan,
> I do not understand the task you posed. As far as I can see there is
nothing
> to "correct" in your 'similar. Works like a charm for me, even with 'do: > > lado: similar :do > >> lado sine 90 > == 1 > >> lado [5 sine 90] > == 1
try this: do :+ 1 2 lado :+ 1 2 -L

 [14/26] from: g:santilli:tiscalinet:it at: 26-Oct-2002 16:06


Hi Jan, On Saturday, October 26, 2002, 2:50:36 PM, you wrote: JS> I do not understand the task you posed. As far as I can see there is nothing JS> to "correct" in your 'similar. Works like a charm for me, even with 'do: JS> lado: similar :do JS> >> lado sine 90 JS> == 1 JS> >> lado [5 sine 90] JS> == 1 You didn't seem to have tried all the possibilities. :-) Why don't you try with: lado :sine lado :sine 90 and contrast it with: do :sine do :sine 90 Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [15/26] from: jan:skibinski:sympatico:ca at: 26-Oct-2002 15:30


Hi Gabriele and Ladislav:
>From Gabriele: > You didn't seem to have tried all the possibilities. :-) Why don't
<<quoted lines omitted: 4>>
> do :sine > do :sine 90
..and from Ladislav:
> try this: > do :+ 1 2 > lado :+ 1 2
========================================== But lado + 1 2 == 3 or plus: :+ lado plus 1 2 == 3 or sin: :sine lado sin 90 == 1 =========================================== Involved in our tests of 'do and 'lado is one extra complexity layer that involves silent convertion of command line into block of expressions, I think. So why don't we simplify the tests by supplying the 'do with a block of expression(s) instead?
>> e1: [+ 1 2] >> do e1
== 3
>> lado e1
== 3 So far so good! Now, let us substitute "+" by ":+":
>> e2: [:+ 1 2]
== [:+ 1 2]
>> do e2
== 2
>> lado e2
== 2 Neither 'do nor 'lado recognized that the intend here was to get the value of '+ and then to apply it to the rest of the expression. My interpretation of this is that both evaluate ":+" but do not bind it to anything, and then continue evaluating first 1 then 2. Let's see:
>> e3: do/next e2
== [op [1 2]]
>> e3/2: 1
== [op 1]
>> append e3 2
== [op 1 2] Now let's repeat the test using this precalculated 'op:
>> do e3
== 3
>> lado e3
== 3 We can of course make a variation of the functional 'similar, which replaces all 'get-words by 'words and then produces a version of 'lado that works with expressions containing :+, etc. Here is a quick example (with constraint on the arg type): lado2: func [ arg [block!] /local t ][ t: map :no-colon arg native t]
>> lado2 [:+ 1 2]
== 3 But that's beside the point. All the above tests could be run using the string versions, rather than the block versions of the example expressions, such as ":+ 1 2". The outcome would be exatly the same as for the previous tests. To summarize: I do not think there is a problem with the 'similar functional, nor with the functions it generates - and that includes clones of the 'do function. But there is some extra functionality of 'do which interacts with the toplevel environment and which confuses the issue. I am refering to the core manual, which describes in passing how the command lines are being embedded in a block before being processed by 'do. Best wishes, Jan

 [16/26] from: g:santilli:tiscalinet:it at: 26-Oct-2002 22:24


Hi Jan, On Saturday, October 26, 2002, 9:30:44 PM, you wrote: JS> But JS> lado + 1 2 JS> == 3 You don't get the point. Here you are passing the value "3" as argument for DO. Me and Ladislav are passing a function value to DO. This is what make the difference. JS> Involved in our tests of 'do and 'lado is one extra complexity layer that JS> involves silent convertion of command line into block of expressions, JS> I think. There's no conversion. You are passing a value to DO; in such a case, DO behaves like if the function was present directly in the place where DO was present; it can do this because it is native and it plays with the interpreter itself. You can't do something like that in a user defined function. (You can't do a "silent conversion" either, so Ladislav's point still holds anyway.) JS> So why don't we simplify the tests by supplying the 'do with JS> a block of expression(s) instead? That's not a simplification. You are changing the example so that the behavior we are showing does not happen. JS> But that's beside the point. That simply has nothing to do with our example. SIMILAR does not work for all functions, because it does not work for DO and MAKE, and we showed you an example where it didn't work. You just showed us examples where it works --- but that is meaningless. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [17/26] from: jan:skibinski:sympatico:ca at: 26-Oct-2002 17:45


Hi Gabriele,
> You don't get the point. Here you are passing the value "3" as > argument for DO. Me and Ladislav are passing a function value to > DO. This is what make the difference.
Thanks for the stern lecture. :-) It's all in the name of learning so I do not mind if I look stupid from time to time. Jan

 [18/26] from: g:santilli:tiscalinet:it at: 27-Oct-2002 1:57


Hi Jan, On Saturday, October 26, 2002, 11:45:57 PM, you wrote: JS> It's all in the name of learning so I do not mind if I look JS> stupid from time to time. I didn't mean to sound rude. :-) Sorry for that. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [19/26] from: jan:skibinski:sympatico:ca at: 27-Oct-2002 7:54


Ladislav, Gabriele: Attached are some good examples, which I hope you will find satisfactory! I discovered pleasent trick with parens! I know now why the orginal 'similar was failing. I'll leave explanation for later. Here is just a quick view of the results. I just posted the script %hof-accu.r in the util section. (High Order Funcctions - Apply/Closure/Curry/Uncurry, HOF-ACCU). You will find the discussion there. Few bugs and shortcuts need to be fixed. Refinements are not treated yet. Best regards, Jan ======================================================== Two samples of code ('apply and 'closure) are at the bottom. 1. APPLY :: [any-function!][block!][any-type!] 2. CLOSURE :: [any-function!][paren!] 3. CURRY :: [paren!][integer!][paren!] 4. UNCURRY :: [paren!][block!][paren!] 5. SIGNATURE :: [word!][block!] 6. SIGNATURE' :: [any-function! paren!][block] ----------------------------------------------- Using APPLY: apply :do [:+ 1 2] == 3 apply (func[x y][x * y + 10]) [2 3] == 16 -------------------------------------- CLOSURE and CURRYING: [Now you can see the code of SIMILAR-like function] g: closure :do :g == (native) g: uncurry :g [:+ 1 2] == (native :+ 1 2) Now that we have uncurried the g function let us execute it: g == 3 And again.... g == 3 Voila! Here you go! --------------------------------------- PLAYING WITH CURRY/UNCURRY Some dummy test function f of this signature: f :: [[money!] [date!] [integer!] [logic!]] Making closure, fully curried: g: closure :f signature' :g == [[money!] [date!] [integer!] [logic!]] signature' (first :g) ; of function embedded f == [[money!] [date!] [integer!] [logic!]] And now uncurrying one by one g: uncurry :g [$100] signature' :g == [[date!] [integer!] [logic!]] g: uncurry :g [now/date 10] signature' :g == [[logic!]] Now the closure can be fully evaluated by calling it by name: g == false ; some dummy result --------------------------------------------- Finally, here are two functions from %hof-accu.r apply: func [ "Apply function :f to a block of its args" f [any-function!] args [block!] /local result [any-type!] xs ][ xs: copy args insert xs :f result: to-paren xs result ] closure: func [ {Generate closure for function :f with no arguments. Such closure corresponds to the fully curried function.} f [any-function!] /local result [paren!] xs ][ xs: to-block :f result: to-paren xs :result ]

 [20/26] from: rotenca:telvia:it at: 27-Oct-2002 15:54


Hi Jan
> CLOSURE and CURRYING: > [Now you can see the code of SIMILAR-like function]
<<quoted lines omitted: 11>>
> == 3 > Voila! Here you go!
This aggressive evaluation is no more supported in the new betas. See: http://www.rebol.com/docs/core25n.html#sect4.2. --- Ciao Romano

 [21/26] from: jan:skibinski:sympatico:ca at: 27-Oct-2002 14:55


Hi Romano and All, Thank you for this info. I used to run my experiments on core 2.5.0.3.1 and view 1.2.1.3.1. I just downloaded 2.5.3.31 and 1.2.8.3.1 for windows. If these are not the latest betas please let me know, if you can. What a waste of time in the past few days! It seems that other participants were affected as well. All the talk about evaluation of "similar", etc. did not have much sense since event this starter expression x: do :+ 1 2 has not survived to 2.5.3 version.: version 2.5.0 :: x = =3; type? x == integer! version 2.5.3 :: x== error; type? x == error; type? :x == op! And then there is completely different bahaviour for parens, etc. Please disregard my hof-accu.r script until further notice. Thanks Romano Paolo Tenca wrote:

 [22/26] from: lmecir:mbox:vol:cz at: 27-Oct-2002 21:13


Hi Jan, I am afraid that your APPLY doesn't work well, if you supply functions as arguments. (My APPLY is in http://rebolforces.com/~ladislav/higfun.r and it handles a lot of other interesting things, like named arguments e.g.) Moreover, there are other complications, like functions with unevaluated/fetched arguments (which I have chosen not to support with my APPLY). It doesn't look like your CLOSURE corresponds with the usual meaning of that word ... My SIMILAR functional works for any unary function, it cannot be "corrected" or fixed, because it isn't broken. The only "trouble" with it is, that it works only with unary functions and that is why it cannot handle DO, because DO simply isn't a unary function (at least not always), which is something you left unnoticed until now. There's one more thing I can suggest to you. Try to curry DO, and take into account, that DO can take any function as its first argument, not just a number or a block. Take care, -L

 [23/26] from: lmecir:mbox:vol:cz at: 27-Oct-2002 21:24


Hi Jan, Romano, the behaviour looks like a 2.5.3 bug IMO and that is why I am reporting it to the feedback. x: do :+ 1 2 version 2.5.0 :: type? :x == integer! version 2.5.3 :: type? :x == op! Regards Ladislav

 [24/26] from: jan:skibinski:sympatico:ca at: 27-Oct-2002 16:03


Hi Ladislav, Thank you for the feedback.
> I am afraid that your APPLY doesn't work well, if you supply functions as > arguments. (My APPLY is in http://rebolforces.com/~ladislav/higfun.r and it > handles a lot of other interesting things, like named arguments e.g.) > Moreover, there are other complications, like functions with > unevaluated/fetched arguments (which I have chosen not to support with my > APPLY).
I know that. I am not tring to compete :). It's all in the name of exploration, not to deliver a stable and a powerful library.As you must know I am a newcomer to Rebol: I am quite often confused by unexpected language behaviour and I have already learned that nothing in it can be taken for granted. For better or for worse.. The %hof-accu.r is a result of my last night work and I realize that it has many limitations. As it is my usual way, I try to list all shortcomings I am aware of (didn't I mentioned lack of support for the refinements?) of whatever I produce. The hof-accu was written in a terrible rush, since I wanted to share what I thought to be a neat solution.
> It doesn't look like your CLOSURE corresponds with the usual meaning of that > word ..
I realize that, but it is a curry behaviour not the implementation of thunks, or whatever which I was after. I have also another version which is based on re-writing. Well, partial re-writing, since Rebol is imperative and one therefore cannot assume too much about equivalencies of expressions.
> My SIMILAR functional works for any unary function, it cannot be "corrected" > or fixed, because it isn't broken. The only "trouble" with it is, that it > works only with unary functions and that is why it cannot handle DO, because > DO simply isn't a unary function (at least not always), which is something > you left unnoticed until now.
I understood that the problem posed was not to fix your 'similar but to find the solution.
> There's one more thing I can suggest to you. Try to curry DO, and take into > account, that DO can take any function as its first argument, not just a > number or a block.
I am not sure what I suppose to do with all of that in view of my latest 'discovery'. Mind you, I did not scan all the messages in the archive yet. :-), so I was not aware of such important differences until Romano let me know about it. I just received your next message:
> the behaviour looks like a 2.5.3 bug IMO and that is why I am reporting it > to the feedback. > > x: do :+ 1 2 > version 2.5.0 :: type? :x == integer! > version 2.5.3 :: type? :x == op!
and I am not sure which version should I use for further work. Any recommendations for core and view? Best wishes, Jan

 [25/26] from: rotenca:telvia:it at: 28-Oct-2002 1:56


Hi Jan,
> What a waste of time in the past few days! It seems that other > participants > were affected as well.
Experimenting is the best way to learn Rebol.
> All the talk about evaluation of "similar", etc. > did not have much sense since event this starter expression > x: do :+ 1 2 > has not survived to 2.5.3 version.: > > version 2.5.0 :: x = =3; type? x == integer! > version 2.5.3 :: x== error; type? x == error; type? :x == op!
Uh, it seems to me you have discovered an unknown bug! I do not think that less agressive evaluation should mean this. BTW, the behaviour is very strange:
>> do :+ 1
** Script Error: ?op? expected value2 argument of type: number pair char money date t ime tuple ** Near: do :+ 1 This means that the + is evaluated and ask two args, but the return value is a wrong op!, instead of an integer! The same happens also if the op value is inside a block. It sems to happen only with op! not with function/action values. These op! are a real patch in Rebol. You should send a message to RT feedback. --- Ciao Romano

 [26/26] from: lmecir:mbox:vol:cz at: 28-Oct-2002 8:49


Hi Jan, ----- Original Message ----- From: "Jan Skibinski"
> I am not tring to compete :).
I understand, but the handling of functions supplied as arguments is pretty important and you should give it a thought to learn something important, IMO. Your CURRY implementation looks like not being accessible to me (yet)?
> I understood that the problem posed was not to fix your 'similar but > to find the solution.
Not exactly. I don't think that there is a solution. I think, that you can find out something about Rebol.
> and I am not sure which version should I use for further work. Any > recommendations for core and view?
If you want to try the latest Rebol interpreter, it looks like 2.5.2 would be better for experimenting with evaluation, because the 2.5.3's behaviour can be safely expected to change. Best regards -L

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted