Re: [stack] stackless fixed-arity concatenative languages

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

> Well, to be clear, Cat and Fifth can't infer a good type for the
> correct version either. You end up with 'A b b (A b -> A) -> A'. It's

Sorry, I was talking about your new implementation -- you said that
one would handle it correctly.

> the same general problem where the first application gets in the way
> of the second. This is directly related to the fact that you're doing
> all your computation on a single stack and the second application (in
> this case) is allowed access to the entire state of the program at the
> limit. This is what I meant by it being a fundamental problem for a
> system like Fifth's when n-ary combinators are involved.

If it's a problem for "a system like Fifth" it's not a fundamental
problem with concatenative languages in general :-). Sorry I'm selfish
that way.

> With the newer (and not yet fully implemented) system, you can infer a
> good type with the clearer specification, but only because the type
> '$a [$B] -> $B $a $B' *is* the specification. It's somewhat concerning
> however that I need a system that will do whole program analysis if
> necessary in order to avoid making assumptions. Only more experience
> will tell if it's feasible in practice. I haven't been able to try it
> with anything but programs of a few lines yet.

Yes, whole-program can become bad... I imagine that HM's exponential
worst-case performance could manifest itself unpleasantly.

Like I said, I'd like to see a system that tied static
typing/inference, BDD, and DBC. Such a system could (in theory) limit
its static analysis to just the function, its contract, and its BDD
specifications, and then require a unique concrete type (no $ type
variables).

> - John

-Wm