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

On Apr 8, 2:01 am, "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
> wrote:
> "Bernd Paysan" <bernd.pay...@[EMAIL PROTECTED]
> schrieb im
Newsbeitragnews:guupc5-i8q.ln1@[EMAIL PROTECTED]
> ...
>
> > 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.

Yes, strong.fs would probably need a data file for the specific
implementation is is loading into. But if five or six implementations
covers 90%+ of installations, that's not a big obstacle.

"What can be written in vanilla portable Forth-94" is an interesting
intellectual exercise, but "what can be written in portable Forth-94
with a manageable portability harness" is a more sensible exercise if
the aim is to produce a useful library.

> Even if this was possible, how to deal with a
> non-typechecking library that is included after "strong.fs"?

I think that this could not be done by including any words in FORTH-
WORDLIST other than the word to launch into the StrongForth namespace.

IOW, yt would require building a "StrongForth" wordlist and then
making it the bottom wordlist in the stack when "StrongForth" is
executed, and when "Forth" is executed inside StrongForth, it does not
ADD Forth to the StrongForth wordlist stack ... it *replaces*
StrongForth.

If a non-type-checking library is called, it has to have words in it
that can have type-checked outputs, given type-checked inputs,
otherwise its not a useful library for working from inside the
StrongForth namespace. So it would require a prelude file that would
load the non-type-checking library, then import into StrongForth the
desired word with the type-checking binding.

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

?DUP and FIND would not be in the StrongForth namespace.

> And finally, "strong.fs" couldn't take advantage of
> overloading, because this feature introduces hundreds of additional
> incompatibilities by changing the names of many words.

Again, the documentation of strong.fs would not claim that a Forth-94
system existed after

REQUIRE strong.fs
StrongForth

A strongly-typed Forth-94 *cannot be done*. So if someone insists on a
"strongly-typed Forth", they are not losing anything they are not
prepared to lose in having to work with a non-Forth-94 system. If 85%
compatible as as close as it can get, offer them an 85% compatible
strongly typed language written for widely available Forth-94
implementations.