Re: [stack] sweetening concatenative syntax

ack.  it's been so long since i looked at this stuff that i'd
forgotten that 'map' in f/g and XY is an extension of the standard
definition:  given a list of k-length lists, it applies a n-ary
function n>=k to each element of the list.  so e.g.

    [[1 2][3 4][5 6]][+]map -> [3 7 11]

if n>k, then e.g. f "projects":

    [[1][3 4][5 6 7]][+ *][map] -> [[1 + *][7 *] 18]

i knew it looked more complex than it had to be!  anyway, i'd
be curious how you would write this combinator (call it 'mapx').

----- Original Message ----- 
From: "John Nowak" <[email protected]>
To: <[email protected]>
Sent: Wednesday, March 05, 2008 10:12 PM
Subject: 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
>