Fw: the unary combinator
stevan apter — 2003-05-21 13:18:01
i have a question about the unary combinator.
unary apply its program argument to the stack, returns
one item from that operation, and then removes exactly
one item from the stack. for programs which return
more than one result, only the last of those is saved
to the stack:
10 20 30 [[1 2][3 4]] [uncons] unary
10 20 30 [[3 4]]
i'm not sure how to phrase my question. i suppose it
boils down to whether this is good behavior for a primitive,
returning just part of a result. (or perhaps not, since
x / y loses information too.)
the programmer who uses unary (and similar combinators) had
better know how many results its program argument will return:
if just one, he'll get the whole result; if more, he'll get
just the last part.
Nick Forde — 2003-05-21 15:21:53
stevan apter writes:
>
> i have a question about the unary combinator.
>
> unary apply its program argument to the stack, returns
> one item from that operation, and then removes exactly
> one item from the stack. for programs which return
> more than one result, only the last of those is saved
> to the stack:
>
> 10 20 30 [[1 2][3 4]] [uncons] unary
> 10 20 30 [[3 4]]
>
> i'm not sure how to phrase my question. i suppose it
> boils down to whether this is good behavior for a primitive,
> returning just part of a result. (or perhaps not, since
> x / y loses information too.)
>
> the programmer who uses unary (and similar combinators) had
> better know how many results its program argument will return:
> if just one, he'll get the whole result; if more, he'll get
> just the last part.
This has caught me out before and is one of the situations I mentioned
earlier where I find stack manipulation tricky. When a combinator
doesn't quite do what I expected I use the following function and
strategically place '_' characters through my code.
DEFINE _ == "stack = " putchars stack dup reverse put unstack "\n" putchars.
I suppose the interpreter could raise an error when situations such as
this arise and it is about to throw away data. Although I think this
would prove to be unnecessarily restrictive.
Regards,
Nick.