Re: [stack] Concatenative Research

"Justin" <[email protected]> Mon, 31 Jan 2011 05:10:59 -0000
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
--- In [email protected], "William Tanksley, Jr" <wtanksleyjr@...> wrote:
>
> John Carter <john.carter@...> wrote:
> > Justin <zallambo@...> wrote:
>
> 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.

I don't understand what you mean. Syntactic sugar is syntax that can be easily explained in terms of other syntax. It says, "rather than give you a mapping from 'for loop' syntax to semantics, I'm going to give you a mapping from 'for loop' syntax to 'while loop' syntax, and then you can use the mapping from 'while loop' syntax to semantics". What's wrong with that?

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

Indeed, my operational semantics does not involve a stack.

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

Why would you say that is? I know it allows both stack manipulation and variables; is this a potent combination, or is something else at work?