Re: [stack] sweetening concatenative syntax

On Mar 5, 2008, at 9:34 PM, Stevan Apter wrote:

> ; map [jump] [each* rot => map <= swons] [pop] ifte ;
> ; each* => uncons <= tuck 2slip ;

So that, versus this:

f map = unlist:
   []
   [x xs -> (f x) (map xs f) cons]

It seems to me that the second version is objectively easier to  
understand. It's clear that 'map' destructures a list and it's clear  
how both possibilities (the null list and the non-null list) are  
handled. Even if we drop the prefix/indent syntax, it's still a good  
deal clearer:

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

Actually, I like that better.

At the very least, it seems that there's a strong argument for  
offering lambda expressions and a locals syntax.

It's less clear that the prefix syntax is worthwhile. In particular,  
point Dan made is valid:

> Also, what happens if a function is given too many arguments? The
> result is very counterintuitive, and a more useful translation would
> take into account type information.

I'd be strongly opposed to any translation that was not a purely  
syntactic preprocessing step as otherwise you truly are complicating  
the language. At the moment, my type system can't enforce that a given  
quotation isn't given "too many" arguments because this makes no  
sense; all functions operate on stacks. The type system can enforce  
that a given quotation will try to use no more than a given number of  
arguments when it is later evaluated, and this is critical for typing  
combinators like 'infra', but that isn't helpful here. It is therefore  
probably best to rule out prefix syntax.

- John