Re: [stack] stackless fixed-arity concatenative languages

John Nowak <[email protected]> wrote:
>> A definition that matches the
>> semantics of 'bi@' in Factor is 'dup [ dip ] dip call', or '[ dip ]
>> keep call'.

> Last thought on this for tonight. I wanted to note that 'dup dip dip'
> is actually just plain wrong if you want to use it for quotations with
> arities beyond 1->1. For example, here's the Factor version of 'bi@'
> at work with a quotation of arity 1->2, 'dup':

Ah, that does make sense.

> Not so good. Anyway, if we use the /correct/ version of 'bi@' from
> Factor, my new system-in-progress can give it this rather nice looking
> type that very clearly shows what it does:
>    $a [$B] -> $B $a $B

> Maybe the trick to making n-ary combinators understandable is a more
> powerful system, not a more restricted one.

Hmm. I certainly like that idea. That's what I meant by asking whether
the problem was fundamental -- it appears that it wasn't; our problem
was due to a foggy specification of bi@ that caused us to accept an
incorrect implementation. We can't fix foggy specifications :-), but
at least this problem isn't caused by some fundamental property of
concatenative languages.

Nonetheless, it seems obvious that some programs will have equivocal
typings (two or more entirely different type inferences which imply
different capabilities) and only one of those typings will be intended
by the author. Equally obviously, requiring handwritten type
signatures is not a general solution (unless we require type
signatures on ALL methods as does Scala).

One idea might be to tie the inferencing system into a
design-by-contract and behavior-driven-development system. DBC
expresses universal properties (i.e. for-all properties), while BDD in
this sense expresses particular examples (i.e. there-exists
properties). If the inference system had direct access to both types
of specification, it could make better decisions and print clearer
error messages (and even, perhaps, eventually make guesses that the
programmer needs to write a given type of test in order to clarify the
types his program is using). Both types of specification are, of
course, valuable in their own right, so this seems like it could be a
win-win solution.

> - John

-Wm