Re: [stack] language hierarchy

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
> > 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.

Hmm... Right. And much the same, there are benefits and drawbacks to
impurity... Perhaps one way of saying it is that impure programs can
tersely express some things for which pure ones need more verbosity,
while pure programs can be reasoned about using a simpler logic.
That's just experience speaking, no hard theory.

I do like your definitions now. Chris, any opinion?

> >> - 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.

Hmm. Okay, I think I get it. Review: composable means that function
composition is available and capable of forming interesting programs.
Concatenative means that function composition is the default operation
(performed by merely concatenating functions).

> >> 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.

Perhaps, but the language supports that composition on such a
fundamental level that it's hard to identify it as NOT part of its
syntax. A number of different subsets of Haskell can be constructed
that form a composable language -- for example, consider a stack
monad. At least if I'm reading your definition of 'composable'
correctly.

Of course, Haskell as a whole isn't composable, or at least isn't
purely composed. It's just that it has all of the syntactic power
needed to construct purely composed programs.

> This is something you can add to most any vaguely
> functional language:
>         (define (compose f g) (lambda args (f (apply g args))))

Sure; and if you can define that as infix, your language has
superficial support for composability. If you can define it as the
default operation for concatenation, your language has superficial
support for concatenativity. Making that support more than superficial
will require being able to define the datatype on which the functions
are operating, and the basis set of functions themselves.

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

I'd consider it composable (if I understand the word correctly) -- it
has sufficient expressive power to be warped that way -- but not
purely composable. To the best of my understanding, it's not at all
concatenative.

I think your definition is adequate, so let's go forward with it.

> - John

-Wm