Re: [stack] sweetening concatenative syntax

<[email protected]> wrote:
>  > But you can't measure the readability of a language NOTATION in
>  > comparison to a different notation by converting the first one into
>  > the second. By that standard Brainf**k and Haskell have the same
>  > readability (they can both be converted to x86 machine code).

>  I didn't think I was doing that. I don't mean to suggest that lambda
>  expressions are superior to pointfree code because they can be converted
>  to pointfree code and therefore are just as readable if not more so. There
>  are certainly cases where lambda expressions are less readable. We got
>  confused somewhere back there...

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?

>  >>  This is incorrect. "Linear" means that *values* have at most one
>  >>  reference to them. It has nothing to do really with how often a given
>  >>  variable shows up the source code. Take a look at Henry Baker's Linear
>  >>  Lisp. It certainly has lambdas, but it is also certainly linear. There
>  >>  are also languages like Clean that enforce linearity through the type
>  >>  system.

>  > I'm trying to find where linear lisp or Clean's uniqueness types allow
>  > multiple uses of the same variable. I'm not finding that; it appears
>  > to me that the opposite of what you claim is true: those languages
>  > claim to be linear BECAUSE they enforce only one use of each variable.

>  > What am I missing?

>  Here's a function from Baker's "The Forth Shall Be First":
>    (defun abs (x)
>      (if-minusp x (- x) x))
>  Here, 'x' appears more than once in the source code, yet it is still
>  linear.

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

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

> The only claim I was making is that variables can appear more than
>  once and the language can still be linear.

You actually claimed that your implementation was linear, which it's not.

I would concede that variables can appear twice, if the variable can
only possibly be encountered once (for example, in both branches of an
'if').

>  What Linear Lisp disallows is implicit copying. For example, to write
>  "square", you need to do something like this:
>    (defun square (x)
>      (let* ((x x-prime (dup x)))  ; use Dylan syntax [Shalit92].
>        (* x x-prime)))
>  The difference between Linear Lisp and Fifth is that Fifth essentially
>  just inserts the 'dup' expressions for you. Dan has suggested that perhaps
>  there should be an option to disallow this behavior so that copying is
>  explicit. I'm not sure this is necessary provided that there is a clear
>  and simple set of rules for when copying will occur as I've laid out.

I look forward to reading more about Fifth. I agree with you that
linearity is interesting, and that the rules you hint at should make
linear coding with variables a little easier. I don't see how your
rules can improve over established techniques like SSA.

>  >> Likewise, you can have non-linear languages that do not have
>  >> variables. Look at Joy for example.
>  > Joy appears to be linear. What am I missing?

>  Joy is not linear because Joy allows values to have multiple references to
>  them.

Touche'. Thank you, I definitely have to entirely concede that point.
Well played :-).

>  In short, enforcing that values are singly referenced is the definition of
>  linearity. Use-once variables are a means to achieve this that requires
>  explicit copying. However, you can also have a linear language by
>  automatically inserting the necessary copying which is what Fifth does.

Actually, this sounds like it should be pretty cool.

>  - John

-Wm