Re: Type checking (was: The strengths of FORTH)

On Apr 8, 3:22 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
> wrote:
> > "Bernd Paysan" <bernd.pay...@[EMAIL PROTECTED]
> schrieb
> > ...
>
> > > Having a library for StrongForth would probably reduce some comments
> > > from non-Forthers like Q: "you don't have typechecking" A: "require
> > > strong.fs"
>
> > That would really be nice, but I'm afraid it's not doable. As Michael
> > wrote, StrongForth is "inherently unstandard". Strong static type
> > checking works only if the compiler has precise information about the
> > stack effect of each word. In StrongForth, this information is
> > included in the dictionary. But it would be difficult to add this
> > information to a system that does not provide it from the start.
>
> Each word would become a CREATE DOES> word which stores that
> information.
>

Not exactly. StrongForth finds a (name,stack-effect) pair. So we can
put strongForth words into a wordlist, but we can find only names. The
solution is that each word becomes a vocabulary of stack effects:
after a name is found, the name searches for the entry whose stack
effect matches (the top of) the current stack state.

By the way, this will be the rare case that removal of FORTH-WORDLIST
from the search order has a good reason.

> > Even if this was possible, how to deal with a
> > non-typechecking library that is included after "strong.fs"?
>
> Put the strongforth in a wordlist, take it out of the search order when
> you don't use it.

I think, one will be able to import non-typechecking words after
specifying their stack effects. Finally, this can be done for CODE
definitions, why not to do it for typeless Forth?

>
> > Furthermore, some words like ?DUP and FIND are simply incompatible
> > with strong static type checking, because their stack effects are not
> > known at compile time.

In fact, ?DUP has the stack effect ( x -- x/xx ), and
IF can be described as ( x/xx -- x ; no jump ) ( x/xx -- ; jump )
so ?DUP IF would work...

Another awful ANS Forth data type is ( xn ... x1 n ), but it also can
be resolved.
IIRC, pointers are parametrized with the data type they point to;
the same thing may be dome for { x }*n.

> It looks like a lot of effort but so far I don't see any gotchas that
> would keep it from working.

I think, a bit less labor than for a Forth system from scratch,
comparable to that for a Forth Assembler or a bit more. (Test suites
and docs not counted).