Re: [stack] sweetening concatenative syntax

John Nowak <[email protected]> wrote:
>  William Tanksley, Jr wrote:
>  >> Small point: You forgot the initial swap to put the list on top of
>  >> the stack. The type system would've saved you of course.
>  > I didn't forget it; I was imitating your lambda code, in which the
>  > list is already on top of the stack. Isn't that what "xs -> f i"
>  > implies? So is your lambda code also wrong?

>  No, it's correct. The list wasn't already on the top of the stack, the
>  function was. By binding the function to 'f', we remove it from the
>  stack, causing the list to be on top. This is why the call to 'unlist'
>  makes sense.

The *function*?? I'm confused. The function can't possibly be at the
top of the stack. Here's your code (slightly bugfixed).

>    f map = [pop nil]
>            [xs -> f i xs f map cons]
>          unlist

As far as I can see, 'unlist' doesn't pass any function around; it
doesn't know about a function. Your 'f map' notation appears to be
creating a named lambda with a parameter named 'f'; that is the
function and it gets passed around, but if 'map' wasn't defined as a
lambda the function would be _under_ the 'x' and 'xs' parameters that
'unlist' creates for the second quotation to consume.

Right? What am I missing?

>  > This is moving the goalposts. When you posted the challenge you didn't
>  > mention anything about programming time;
> > I didn't time my coding, and I didn't know that was the goal, so I've
>  > got no way to compete here.

>  I was just relaying my personal experience. There was no timed
>  challenge.

I didn't take offense -- sorry for the ambiguity (I seem to be vague a
lot). But you DID challenge us to implement this algorithm in a
"purely concatenative form", and you claimed that your version with
lambdas was "objectively easier to understand". Nothing about it
taking 15 seconds to program.

I think I've met your challenge, and am at least entitled to claim the
your "objectively easier" claim is incorrect.

>  > Not that speed competition would be fair -- I've never seen your
>  > 'unlist' API anyhow, and now it appears you're doing something tricky
>  > or incorrect in your example code (by putting the list on top).

>  I posted the type and explained it. I showed how you can use it to
>  write head/tail/null?/uncons. I'm not sure what else I can do. At the
>  very least, I did say that, "What 'unlist' does is take three
> arguments. The first is a list."

I wasn't complaining about bad documents in that paragraph -- I'm just
pointing out that I can't write a 15-second program in a brand new
API, even one that's fully documented. So I admit that my version took
longer than 15 seconds to write.

> >> It took me over a minute to write the pointfree
>  >> version. (Perhaps I just need more practice.) I also think the
>  >> pointful version is easier to read, although we can certainly
>  >> disagree.

>  > Perhaps you find it easier, but there's objective reason why it
>  > shouldn't be easier. The point-free version is linear

>  They're both linear, at least where "linear" refers to how objects are
>  referenced.

'f' is referred to twice; that's nonlinear.

> If you mean that it reads left to right as a strict means
>  of sequencing, then no, it isn't linear. I'm not sure that's
>  necessarily something that makes something easier to read however.
>  Certainly mathematicians have been inventing notations that read in
>  many different ways for quite awhile.

Left to right IS easier than jumpy. That's a simple and clear rule. It
doesn't mean that jumpy is bad; sometimes you need jumpy. But it's
objectively more complex.

>  > IMO anytime you play with 'dip' you introduce reading difficulty.
>  Maybe it's a matter of taste then. I find 'dip' a lot easier to keep
>  in my head than shuffles.

I think that's reasonable. (Wow, agreement!) When considering shuffles
versus dips, keep in mind that dip essentially *both* performs a
shuffle and an execution. Shuffles are technically simpler (because
they _only_ rearrange), but of course there's only one thing 'dip' can
do, while there's a lot of things shuffles can do. In other words, I
do have sympathy for your argument, and I concede that it's
subjective.

>  >> Perhaps this series of errors is just another argument for lambda
>  >> expressions and types. :) Considering the multitude of errors, I'd
>  >> say it's a pretty strong one...

>  > Considering that all your lambda implementations had the same errors,
>  > I don't see how that applies.

>  They did not have any errors, although it seems to me that the errors
>  in our pointfree code were due to translating the lambda-based
>  versions and getting it wrong. In particular, the lambda version
>  didn't need to pop the function because binding it to 'f' removed it
>  from the stack. When doing the translation, we both forgot to pop it
>  explicitly.

I do concede that your lambda probably wasn't wrong; it looks right to
me. What seems wrong to me is your recent claim that in the stack
version, the function is on top of the stack rather than car and cdr.

>  - John

-Wm