Re: [stack] language hierarchy

On Dec 4, 2007, at 7:41 PM, William Tanksley, Jr wrote:

>> This page might explain it a bit better:
>> http://en.wikipedia.org/wiki/Function-level_programming
>
> It does indeed! Thank you.
>
> And now I'm enlightened. You weren't merely making up your own
> hierarchy :-); you were citing well-established terms.

Aye. I should've been more clear.

>  I'm not sure that it's right to say that composition is
> the ONLY functional form; others may be permitted (for example, 'map'
> is a functional form).

In Joy, map isn't a functional form; it's just a normal higher order  
function that operates on the value level. The fact that ones of the  
values is a function doesn't make map any less value-level.

Composition in Joy isn't value-level; it's a function-level operation.  
(Of course, Joy also has a function named 'compose' that operates on  
values and is value-level.) FL had many of these functional forms; Joy  
has composition as the only functional form in terms of which programs  
are written. More on this later...

> It's also not destructive to have local non-concatenative
> syntax here and there, so long as there's some interesting subset of
> the language that IS concatenative.

Agreed. Like in the functional programming world where there are  
varying degrees of how functional something is -- Haskell is purely  
functional, ML is mostly functional, etc -- it would be the same here.

>> - A concatenative syntax isn't required, but it is the most obvious  
>> choice
>
> What other syntax choices are available, aside from the trivial choice
> of using a symbol to represent the composition operator? Is that the
> only difference between this definition of 'composable' and
> 'concatenative'?

It's the only thing I see as distinguishing concatenative from  
composable if you consider concatenative languages a subset of  
composable languages. As for other syntactic choices, yes, an explicit  
operator is one way. This might be useful in a language that's not  
purely composable. Graphical syntaxes also could exist. I can imagine  
only ones that are fairly useless at the moment however.

>> Joy would fit in this category. FL would not, as functions can be
>> manipulated in ways beyond composition. Forth should fit provided  
>> local
>> variables are eschewed. Haskell wouldn't.
>
> ...yet well-defined and "interesting" subsets of all those languages
> would be composable.

I don't think there's anything composable about Haskell, strictly  
speaking. The compose operator in Haskell is really just a function  
with infix syntax that operates on functions /as values/ via function  
application. This is something you can add to most any vaguely  
functional language:

	(define (compose f g) (lambda args (f (apply g args))))

To be more clear, in Joy, composition is the only functional form. In  
Haskell, /application/ is the primary functional form. In the program  
'f (g 5)', there's no apply function being called that deals with f or  
g as values. Again, you can have an 'apply' function that operates on  
the value level as in the above Scheme example, but that's something  
different. Interestingly, FL does not have a functional form for  
application as there are no arguments to be applying functions to.

As I'd not consider Haskell composable, I'd not consider it  
concatenative either.

- John