Re: [stack] sweetening concatenative syntax

>  I. Lambda Expressions
>  II. Local Function Variables

Sure, these two seem reasonable seems reasonable. Factor and Cat
support these. The only thing I have to say is, they shouldn't be used
too often or for everything, since they can make code unnecessarily
more verbose and less factorable.

>  III. Prefix Notation
>  Prefix notation may seem like a curiosity at first, perhaps existing
>  only to lure over those familiar with prefix notation. However, I'd
>  argue that prefix notation makes certain code objectively easier to
>  read. This is especially the case when dealing with deconstructors
>  like 'if' or 'unlist' as the higher order function of primary interest
>  is "announced" earlier in the definition. In the following example,
>  both functions are equivalent:
>
>  f map = [] [x xs -> x f i xs f map cons] unlist
>
>  f map =
>  (unlist []
>  [x xs -> x f i xs f map cons])
>
>  (Perhaps this is not the best example. Substitute a better one with
>  nested ifs.)
>
>  Prefix notation also has the benefit that you can express "nested"
>  code (as above) in a way that allows editors to automatically intent
>  properly. This is not at all the case with purely postfix code where
>  type information and perhaps some heuristics would need to be involved
>  to produce acceptable indentation.
>
>  Here's a rewriting of map using *only* prefix notation in a way that
>  most any Scheme or Haskell programmer would find comfortable:
>
>  f map =
>  (unlist []
>  [x xs -> (cons (f x) (map xs f))])
>
Now this I have a very hard time understanding the motivation for.
Sure, when you're just learning concatenative languages, it can be a
little weird that "if" comes after the quotations, but humans don't
read completely linearly in normal circumstances, and it doesn't take
too much effort to look to the end. In a case where you have to look a
page ahead, I'd say the fault lies with the author of the code writing
things unreadably, rather than the language being unreadable. Also,
what happens if a function is given too many arguments? The result is
very counterintuitive, and a more useful translation would take into
account type information.

>  IV. Indentation
>
>  f map = unlist:
>  []
>  [x xs -> cons: (f x) (map xs f)]

I don't completely get it. This example doesn't take advantage of
indentation, it only uses modified prefix syntax. I guess the
indentation can make a difference if you have multiple arguments
following the word, and then something else after that that's not an
argument?

Sure, there are lots of translations that we could make efficiently
and accurately with concatenative languages, but I'm not sure if all
of these are essential or beneficial to the nature of the languages.
They make things more complicated and they remove all of the nice
properties of concatenativity, which is useful in building software
because it helps you factor code. We could easily create a translation
from Scheme to a concatenative language, but that doesn't mean that
we'd want to do all of our concatenative programming on a Scheme skin.