Re: [stack] Concatenative Research

John Carter <[email protected]> wrote:
> Justin <[email protected]> wrote:
>> http://dl.dropbox.com/u/17328602/concat/index.html
> "Concatenative" refers to the syntactic sugar (glucose?, alcohol?) of

Definitely syntactic splicing factor U2AF.

> choosing a syntax in which function composition is represented by string
> concatenation.

That's what I think of, yes -- minus the word "sugar". Not all syntax
is "syntactic sugar". A language might be defined as "the mapping of
syntax onto semantics"; thus, language design is concerned with
defining syntax, semantics, and the mapping between them. Words like
"syntax sugar" encourage a disregard for one of those crucial three
components of language design.

> The neatness of concatenative program fragments often arises from a
> carefully pre-chosen alignment of the output values of the previous function
> with the input requirements of the next.
> Where it doesn't align neatly, we need a bunch of stack manipulating "fluff"
> that adds nothing to computation.

> What may be interesting and useful would be to return to typed variables
> (named values variety) and something like a SQL "natural join".

That is indeed an interesting thought.

I should note that ANS Forth (for example) says that there may be an
additional stack on which floating point numbers reside. Floating
point operators access only the FP stack. Perhaps, therefore, part of
the solution might involve defining multiple stacks for items with
different types, and for items involved in different architectural
purposes.

> By making the rules for doing this explicit, you should be able to create a
> concatenative language that doesn't involve the notion of a stack, nor are
> the program fragments cluttered with irrelavent variable name references or
> stack manipulation "fluff".

Possibly true. I'd love to see this explored; it does seem that the
"stack" is not _necessary_ to the idea of a concatenative language.

> I would argue that any language where the function definitions are cluttered
> with stack manipulations OR variable references has NOT yet met the full
> promise of concatenative languages.

I know what you mean. Forth, Joy, and Factor are all capable of being
written without clutter; but it's widely admitted that it's easier to
do in Factor than it is in Forth. Surely there's more progress to be
made beyond what Factor's done already!

> John Carter

-Wm