Re: [stack] sweetening concatenative syntax

John Nowak <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
On Mar 5, 2008, at 9:14 AM, Daniel Ehrenberg wrote:

> Sure, there are lots of translations that we could make efficiently
> and accurately with concatenative languages, but I'm not sure if all
> of these are essential or beneficial to the nature of the languages.
> They make things more complicated and they remove all of the nice
> properties of concatenativity, which is useful in building software
> because it helps you factor code.

I'm not convinced concatenativity offers a huge advantage in  
factoring. It's easy to write code in such a way that useful chunks  
can't be pulled out. It's also difficult to find useful abstractions  
unless you have some experience. For example, I'd guess the novice  
programmer looking to add two lists together wouldn't accidently write  
zip-with.

I think how factorable a language is primarily depends on its  
usefulness in building abstractions rather than any particular syntax.  
Languages with first class functions offer factorability that language  
like Forth don't offer. Haskell's type classes over a level of safe  
and structured factorability that's inaccessible to Joy. ML's functors  
offer a means of factoring I often miss when using Haskell. Types  
offer a way of verifying my abstractions in a way I miss when using  
Scheme. Scheme offers macros as a means of factoring that I miss when  
using Haskell. Et cetera.

If a syntax that is non-concatenative makes it any easier to use any  
of the other means of factoring, then it seems to me it's worth  
considering.

- John
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.