[REBOL] Re: [RWEBOL] HOF and system exploration
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
> 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
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
