Re: [stack] sweetening concatenative syntax

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
>  > Sure it does! The referential transparency alone is worth the price of
>  > admission -- the famous "extract method" refactoring (considered by
>  > many to be the first indication of "true" refactoring support in a
>  > tool) is merely a cut-and-paste in any editor.

>  Indeed, although this partially breaks down in the presence of
>  modules.

I don't see why... Unless you're also talking about moving the
resulting function out of the current module, which isn't something I
intended to imply. In fact, is that what you're talking about? It
can't be, because in general that's impossible (the function might
refer to some stuff that's private to the original module).

So I definitely don't know what you mean.

> Types also complicate things. For example, you can't factor
>  out the 'dup i' in '[swap] dup i' unless your system has higher-rank
>  polymorphism or equi-recursive types.

Well, technically if your typesystem was "concatenative" you could
factor it out. If your typesystem isn't concatenative, then the
resulting language is no longer strictly concatenative, although it
may indeed appear concatenative, or it may be concatenative but
require some kind of type annotation which isn't concatenative.

I can't criticise anyone for failing to have a concatenative type
system, since I don't know what such a thing would look like --
_except_ in the special case where all types are declared (as in
StrongForth). Clearly that's not an optimal case. It seems to me that
it _should_ be possible to construct a truly concatenative type
system, but again, I don't know what it would look like.

>  > Yes, we don't have a concatenative Haskell yet -- but give us time.
>  I'm working on it!

Yes indeed, as is Chris -- and your work is very interesting.

>  - John

-Wm