Re: [stack] sweetening concatenative syntax

On Mar 7, 2008, at 11:19 AM, 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.

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

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

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

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

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

- John