Re: [stack] sweetening concatenative syntax

> I'm one of the confused. You said your lambda code was objectively
> superior and challenged me to write concatenative code. I did, and
> then produced objective measures for my code's acceptability (function
> count, token count, linearity, and smooth left-to-right reading). You
> *apparently* responded by claiming that those somehow applied to your
> notation too because your notation could be translated to mine.
>
> If that's not what you meant, cool; but what DID you mean?

I meant that it could be reasoned about as easily as the pointfree version
as there would be a well-defined translation. That's what I meant by
saying you get the best of both worlds; the worlds were "simple
concatenative semantics" and "lexically scope variables".

> Read Baker's discussion -- he admits that this is a special case with
> "relaxed" rules. It's admittedly not "strictly" linear (his words).

I obviously have to re-read it! It's been awhile.

> Your code doesn't even meet that special case; it's nonlinear in 'f',
> which appears twice sequentially.

In the program that results from my code, all values are referenced once
(due to implicit copying). Values can be mutated without visible side
effects. No garbage collection is needed. In seems that it offers all of
the same benefits as Baker's Linear Lisp, does it not?

If it does offer the same benefits, then why is not linear? Is it because
all copying is not explicit? If that's the case, do macros make a language
non-linear because they can compile down to code that calls dup? If macros
do not make a language non-linear, then why do lambda expressions make it
non-linear if lambda expressions are just macros?

It seems to me that you're saying the addition of macros makes a language
non-linear. Perhaps Baker was simply not precise enough in his definition?
Perhaps I'm way off somehow?

- John