Re: [stack] sweetening concatenative syntax

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
>  > John Nowak <[email protected]> wrote:
> >> Lambdas don't have anything to do with
>  >> it; they just let you write it in a way that makes it look more like
>  >> pattern matching. You can write it without variables if you prefer.
>  >> You can even write it with just one variable which is actually nicer:

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

>  > Okay, so the challenge is to write that entirely without variables
>  > (i.e. without the benefit of lambdas). Let's try.

>  You must've missed my response to you earlier where I gave this
>  translation:

>     map = swap
>           []
>           [rot dup 2dip swap map cons]
>         unlist

No, I saw it -- actually, I saw one with a '2keep', so perhaps I
missed the one you're showing. There are 2 reasons I wrote my own: 1.
I wanted to accept your challenge; 2. I don't like words with numbers
in them (2keep? I don't know what that does).

>  > map = [] [ bury over i rot map cons ] unlist

>  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?

Anyhow, that makes my version look like this:
map = [drop null] [ swap bury over i rot map cons ] unlist
Or, using a shuffle:
map = [drop null] [ fsx--sfxf i rot map cons ] unlist

>  > Arguably no worse than yours; the body of my definition contains six
>  > words, matching yours if we don't count your lambda and its variable
>  > (beating it otherwise).

>  This seems like a poor way of measuring how easy it is to read and
>  write code. At least in my case, I know I wrote the pointful version
>  in about 15 seconds.

This is moving the goalposts. When you posted the challenge you didn't
mention anything about programming time; all you did was post a few
different variants, and then you posted one that you said was "better"
(the one with only a single lambda variable). The only difference I
see is that the single-variable one is shorter, so I assumed shortness
was your criteria.

I didn't time my coding, and I didn't know that was the goal, so I've
got no way to compete here.

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).

> 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 and has fewer
symbols. (Your point-free version -- the '2dip' one -- is okay, but
IMO anytime you play with 'dip' you introduce reading difficulty.)

> 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. The specification was unclear, we both
misunderstood, and produced correct programs for the wrong API.

>  - John

-Wm