Re: [stack] Concatenative Research

John Nowak <[email protected]> wrote:
> John Carter wrote:
>> ie. In a very strong sense, parameter names and parameter order is fluff and
>> irrelevant to the actual computation being performed!
> You could have functions of multiple arguments take records instead. That does
> away with your parameter names (as you can use field accessors internally)
> and therefore all substitution, renaming, and the usual lambda dance. It also
> does away with your argument ordering.

Done the easy way this results in one record per complex function;
done the complex way it results in a sophisticated structural
hierarchy in your API. Neither one is inherently bad (it seems to me),
it just has different costs and benefits. Of course, for a language to
claim to support this it should provide some syntactic support beyond
simply allowing it :-).

Factor has some very simple support for this style, but the resulting
code takes more room than stack manipulations. OTOH, it's almost
certainly clearer what's going on for those parts of the API that use
it (because they have complex inputs and outputs).

Some other ideas occur to me, but this feels like the wrong place for
brainstorming details like that.

> That said, I take issue with the charge that these names are all just fluff.

I have to completely agree. Less strongly, "parameter names and
parameter order" cannot both be fluff at the same time.

> Pointfree languages are generally bad at using a single value at multiple
> places within a computation. Variables make this much easier.

A better term is "less powerful" rather than "bad". I don't say that
out of a mere political correctness; the idea of power can be
formalized to show its good and bad sides. Informally, variable names
allow the programmer to teleport data around. The new power tempts the
programmer to increase the scope available for its use, making
functions tend to be larger (since modern languages are lexically
scoped).

Once you start down that path, forever will it dominate your destiny.
Consume you it will. (Yoda is, after all, the patron saint of stack
programmers.)

And, more seriously, I do recognize that power is good. But next you
give an example where power is bad:

> Pointfree languages are also generally *very* bad at refactoring.
> This may seem like a strange charge when you have languages
> with names like "Factor", but it's true.

You're basically right -- higher-order point-free functional languages
are in general harder to refector, because they tend to have a lot of
broad syntactic structure. The less powerful lower-order concatenative
languages like Forth tend to be easier to refactor, although they have
their own problems abundantly.

> - jn

-Wm