Justin <zallambo <at> yahoo.com> wrote:
>"William Tanksley, Jr" <wtanksleyjr <at> ...> wrote:
>> John Carter <john.carter <at> ...> wrote:
>> > Justin <zallambo <at> ...> 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. [...] What's wrong with that?

I didn't mean to imply that "syntactic sugar" should never be used,
sorry. I meant that it's entirely inappropriate in the use to which I
was replying. A concatenative language is, by definition, a language
in which syntactic concatenation is the primary means of expressing
composition. If there are other means (and there need not be), they
are the syntactic sugar;concatenation is not.

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

There's no profound reason why it needs to; my friend wrote a very
simple code generator that used registers for the top stack items.
However, using something other than a stack means that the behavior of
the language is different; your operational semantics would be
different.

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

Something else. (Forth also has both.)

Factor also has the cleave/spread combinators. From
http://factor-language.blogspot.com/2008/03/inheritance-tuple-reshaping-cleavers.html:

"These combinators help structure your data flow by grouping parts of
computations into one-to-many, many-to-many and many-to-one designs."
... "For example, I recently converted our serialization library to
use these combinators. The result is extremely straightforward: there
is almost no stack manipulation, except for the occasional dup and
drop, but it doesn't use named locals either. Thanks to the cleave
combinators, all values just happen to be in the right place at the
right time, and everything composes together very nicely, like lego
bricks."

-Wm