Re: [stack] impure concatenativity: let without translation

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
>  > 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.

>  I don't see why macros would complicate the type checker. Perhaps you
>  were suggesting that macros complicate concatenativity.

I was replying to your message, in which you appear to be talking
specifically about the problems of making the type checker emit
reasonable error messages in the presence of a sophisticated macro
system. Did you mean something else?

>  >> 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.

>  What I'm suggesting is code like this, where 'foo' is a function that
>  takes an argument 'x' and returns a function with 'x' closed over:
>     x foo = [bar x quux]

Okay, got it. You want dynamic code assembly. Forth (for example) does
this by driving the compiler, which is available at runtime. Joy uses
lists and interprets them. Either way, same basic idea: you need a
word that incorporates a value as a literal and a word that
incorporates a value as a function call into an ongoing definition.

Your "compositing functions" is my "incorporates a value as a function call".

>  > See http://factor-language.blogspot.com/2007/08/compiled-curry.html
>  > for the obvious way to do partial application in Factor.
>  The obvious way to implement partial application is in terms of quote
>  and compose:
>     pa = [quote] dip compose

You're right; I apologize. I meant the obvious way to make it
reasonably fast, not the obvious way to do it.

>  The Factor example seems to only avoid this when the function created
>  via partial application is not returned from the context in which it
>  was created.

I don't see why this is a limitation.

>  > 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.

>  This is a good point, although I see this as more of a problem to be
>  solved via education and community conventions than anything else
>  really.

You're totally right. I see part of the purpose of this group as
finding what those conventions are, or at least might be. I admit that
I take that purpose too seriously; there's also another purpose of
this group, to find and explore uses of concatenative languages (which
definitely includes useful things like math syntax and lambda syntax).

Stevan makes a good point -- as fun as theory is, we need written
code, and even an application written by a newbie who had to lean on
the crutch of local variables almost the entire time is probably more
likely to contain something unique than something written by an old
Forther who's set in his ways.

With that said, it makes sense to learn from the programmers of the
old stack languages. There are two rules they use that seem
appropriate: avoid syntax-changing macros, and avoid local variables.
The interesting lesson for ME to take from these are that in both
cases, the language provides facilities for these; the instruction to
"avoid" them is just a recommendation, not a rule.

>  > (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.)

>  Sometimes though, you just need something to work as quickly as
>  possible. If your language requires that you sit down and ponder how
>  to translate something like the quadratic formula, you have a problem.

Then every language short of Mathematica or MathCAD has "a problem" --
the quadratic formula isn't an obvious translation even in a lambda
notation, and it's one of the simpler practical formulas.

We're dealing with largely imperative languages here; they're always
going to be clearer when expressing algorithms than they are when
expressing formulas. This is one reason I find the idea of a math
sublanguage attractive, because it adds something that the main
language simply does not possess.

>  > Concatenative languages are in their infancy.

>  This is a very, very good point. I'm experimenting with one particular
>  aspect of concatenative languages; that is, placing them into a typed
>  context. Alternatively, I'm experimenting with effect systems and type
>  systems in a concatenative context if you'd prefer to put it that way.

Either way, your work is very interesting. I don't know what an
"effect system" is, by the way.

>  There's so much that I'm necessarily ignoring to be able to focus on
>  these things. I'm still very interested in the purely concatenative
>  approach as a way of writing simple, concise programs in a highly
>  simplified language. The language I'm working on is not that language;
>  I'm trying to convince myself to focus on just one for the moment.

That's a very good point. Your field contains enough to explore
anyhow; no need to add yet more unknowns.

>  - John

-Wm