Re: [stack] sweetening concatenative syntax

----- Original Message ----- 
From: "John Nowak" <[email protected]>
To: <[email protected]>
Sent: Thursday, March 06, 2008 6:38 PM
Subject: Re: [stack] sweetening concatenative syntax


> 
> On Mar 6, 2008, at 6:12 PM, Stevan Apter wrote:
> 
>> forget about the partial application case.  what i want in my toolkit
>> is a single combinator 'map' which takes an n-ary function and applies
>> it to each of a list of length-n lists.
> 
> Ah, I think maybe there's some confusion here over what we mean by  
> "list". (Yes, really!) In Joy, lists, stacks, and functions are all  
> magically the same thing. I assume it's similar in XY as well. In  
> Fifth, lists, stacks, and functions are all different things. This is  
> just one more example of the endless complication that types introduce.

this is the sort of thing that makes me type-averse.  i understand that
proponents of types have their reasons, but i can't help thinking that it's
one of those things that language-designers like more than language-users.
one of the beauties of joy is that quotations are lists are programs, and
in some variants, are stacks.

is there really no way to reconcile typing with this elegant simplification?

> 
> The 'mapx' function I gave before took a list of lists and a function  
> of type 'a b -> b'. In other words, the function is restricted to  
> taking only two arguments as is standard for the 'fold' combinator.
> 
> It sounds to me like what you're describing is a function that takes a  
> list of *stacks* and applies an n-ary function to each stack in the  
> list. This is doable, where 'map' below is the "normal" map you'd find  
> in a language like ML, Haskell, or Fifth:
> 
>    mapx :: {(Stack A)} [A -> B] -> {(Stack B)}
>    mapx = quote [infra] compose map
> 
> There are some limitations. In particular, all stacks in the list need  
> to be of the same type. Due to how row variables in stack types must  
> get instantiated (the row variables are stripped out), all stacks must  
> have the same number of elements and elements in corresponding  
> positions in each stack must be of the same type.
> 
> This limitation probably isn't too onerous in practice as I can't  
> imagine the use case for mapping over a list of elements of various  
> types. Note that when I say all elements must be the same type, I  
> don't mean that they must all be ints or that they must all be  
> strings. You can always introduce sum types for handling any  
> combination of types you want. The only requirement is that you  
> explicitly wrap up all types into the sum type with the appropriate  
> constructors. A sum type deconstructor ensures that you handle all  
> possible cases when you translate back to the "raw" types.
> 
> - John
>