[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