Re: [stack] impure concatenativity: let without translation

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
>  > John Nowak <[email protected]> wrote:

>  >> translate it to. Basic operations like 'swap' are defined in terms of
>  >> 'lambda', not the other way around.

>  > I have proposed using stackshuffles instead of stack operators.
>  > Lambdas take that a little too far, though; a stack operator or a
>  > stack shuffle works in at worst constant time; a lambda may never
>  > terminate, and it's impossible in principle to tell.

>  Indeed. Of course lambdas can do a lot more than just shuffle.

Right; they can additionally do anything the rest of  the language can
do. Only the rest of the language doesn't need them in order to do it.

>  >> The result is significantly better error reporting,

>  > Only when you have a macro language laid on top of the base language
>  > and the macro language has inadequate error reporting.

>  Yes, we might imagine some wonderful macro system that has all sorts
>  of hooks into the type checker and can inform it in various ways to
>  allow it to somehow present code as it was written, preserving
>  variable names and so on, when giving type errors. I don't think this
>  is really possible in practice though without some massively
>  complicated system and a truly heroic series of macros. Ultimately, I
>  think it's a necessity for the type checker to be able to deal with
>  let/lambda/etc if you're going to offer them.

I admit that it's entirely unproven whether an inferential static type
checker can work at all in a concatenative language, let alone one
with macros. The ones we have now are not concatenative (or are only
partially concatenative), and it makes good theoretical sense that
this should be so.

A non-inferential typechecker would be able to do better, but I don't
see how such a thing would work with macros. Plus, inference is SUCH a
good thing.

>  >> and a more efficient implementation (as you
>  >> don't have to quote values and compose quotations together at runtime
>  >> to create closures -- the implementor can choose whichever approach
>  >> is best).

>  > I do agree that composing quotations shouldn't be necessary; but
>  > indeed, it never was considered as such until Joy came along. More
>  > power to Joy, but it's still only a convenience to be SOMETIMES used,
>  > not a requirement.

>  Compositing quotations is equivalent to composing functions. I see
>  this as a necessity. In either case, I don't see how you can create
>  closures without quoting values and composing functions.

What do you mean "closures"? In my book, a closure is a function which
refers to lexically available variables outside its local scope. A
purely concatenative language does not have variables, and so does not
have closures in that sense.

I think you're referring to partially applied functions, which are
useful when one wishes to specialize a function. Forth is able to do
that, albeit messily, without quotations or their concatenation.
There's a lot you can't easily do in Forth; Factor is in many ways a
remediation of that. See
http://factor-language.blogspot.com/2007/08/compiled-curry.html for
the obvious way to do partial application in Factor.

>  >> Yes, you lose some interesting theoretical properties by defining the
>  >> language as such. I don't think any of these are of practical
>  >> concern,
>  >> although if you can think of any, I'd be interesting in hearing them.
>  >> It seems all of the (minor) additional complexity would be born by
>  >> the implementor.

>  > You lose the ability to refactor a function using only cut-and-paste.

>  You lose this the moment you introduce macros anyway.

No, you only lose it over syntax macros, not expansion macros.

> In either case,
>  you only lose it if you use variables. If you don't use them, you're
>  right where you were.

I concede this, of course.

>  > You lose the ability to reason about a program in chunks as small as
>  > you want (that is, in a concatenative language if you see a phrase
>  > whose meaning you don't grasp you can work with that phrase in
>  > isolation, and you can be sure that the phrase in context means the
>  > exact same thing).

>  This ignores the possibility that lambdas might allow you to write
>  code that doesn't put you in those situations as often to begin with.

Well, actually, rather than ignoring it, it dismisses the possibility
with a tired wave of its hand. Metaphorically speaking. Seriously,
code has to be read carefully to be understood. Nothing will fix that.
There is no algorithm that will cause code to be understood.

I do concede and admit that having more tools is more practical than
having fewer tools, so including locals and lexical scoping is better
than not doing so; the problem isn't the locals, but the fact that
most programmers are trained in nothing but them, and use them as
crutches for their own lack of understanding rather than as poles to
vault over problems that are truly helped by them. (Problems such as
the infamous quadratic formula. I'm preparing an alternate, purely
concatenative approach to that, one which is not as pretty but has
interesting features to it.)

>  Variables are again only optional. Yes, you're stuck with them when
>  looking at someone else's code, but no language is going to prevent
>  programmers from writing terrible, confusing messes. I'm not a big fan
>  of denying programmers powerful tools on the grounds that others might
>  abuse them (not that that's what you were suggesting necessarily).

I concede that this is a large factor in my worry, and I concede that
I share your attitude in general.

I want to make it clear that there are many techniques that result in
clear, simple concatenative code, and using locals is a distraction
from them. Concatenative languages are in their infancy.

>  - John

-Wm