"Bruce McFarling" <agila61@[EMAIL PROTECTED]
> schrieb im Newsbeitrag
news:46265d52-578e-42dc-8731-c17dca1745c1@[EMAIL PROTECTED]
> On Apr 8, 2:01 am, "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
> online.de> 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.
Okay. Let me summarize how I interpret your (and Bernd's and Jonah's)
suggestions.
strong.fs is actually an implementation of StrongForth in Forth-94. After
loading strong.fs you can switch to the StrongForth system, which has its
own compiler and its own dictionary. The StrongForth compiler and
interpreter cannot directly access the Forth-94 dictionary, because the
words in this dictionary do not contain type information. However, it is
possible to define a new StrongForth word with type information etc. as an
alias (or wrapper) of a word defined in the Forth-94 dictionary. This
would
grant the StrongForth system access to Forth-94 libraries and word sets.
strong.fs would consist of two parts:
The first part will be 100% Forth-94 code. It will implement StrongForth's
kernel, plus a word that switches from the Forth-94 system to StrongForth.
At the end of the first part, this word is being executed.
The second part will run StrongForth. It will compile StrongForth
definitions as aliases (wrappers) of existing Forth-94 words, provided
these
words have unambiguous stack diagrams. Furthermore, additional pure
StrongForth words that have no counterpart in Forth-94 can be defined as
required to complete the StrongForth word sets. At the end of the second
part, the system could optionally switch back to the Forth-94 system.
It should be possible to switch between the two systems. Additional
Forth-94
libraries can be included by compiling them with the Forth-94 compiler. To
make them available in StrongForth, one has to switch to StrongForth and
compile an alias (wrapper) for each word in the library.
The important point is that two compilers and two dictionaries exist in
parallel. It is not possible to mix the two systems, e. g., by executing
or
compiling a StrongForth word with the Forth-94 compiler or vice versa. But
that's not necessary anyway. The main advantages are that StrongForth with
its type checking and overloading features can actually run on each
Forth-94
system, and that all existing Forth-94 libraries can easily be made
available to StrongForth.
This apporach sounds doable, so I will give it some more thoughts. The
implementation effort doesn't seem too high, because StrongForth's kernel
is
rather small.
Stephan
|
