What If Python Replaced Elisp?

[Kragen Sitaker]

In article <slrn8cikie.evl.kc5tja at garnet.armored.net>,
Samuel A. Falvo II <kc5tja at garnet.armored.net> wrote:
>In article <Om9y4.1424$oN5.381668 at tw11.nn.bcandid.com>, Kragen Sitaker wrote:
>>It's a problem that Lisp compilers and the SELF compiler have wrestled
>>with for a long time.  It's not insoluble, but it's not like writing a
>>FORTH compiler.
>
>What about FORTH compilers?  I don't see how Forth fits into this discussion
>at all.  Forth is an extremely static language, for all its dynamic
>features.  +, for example, will *only* produce meaningful results when fed
>integers.  As a result, it doesn't even make sense to perform type
>inferencing with Forth.  :)

Well, + can produce meaningful results when fed a pointer and an
integer, too, but of course pointers are integers.  In fact,
everything's an integer.  :)

As Aahz pointed out, I meant that FORTH compilers are at the other end
of the spectrum in difficulty.  I hope most of my code is easier to
understand than that sentence evidently was.

It's probably possible to perform some type inferencing on FORTH
programs; I'd think the major difficulty would come from people putting
variable numbers of items on the stack in creative ways.  The rest of
the dataflow should be pretty straightforwardly traceable.

"Type inferencing" might include types like integer, high half of
doubleword, low half of doubleword, floating-point number, pointer to
character, pointer to character followed by ten other characters,
pointer to a pointer followed by an integer, etc.  Conversions between
these types would sometimes be difficult to check.  :)
-- 
<kragen at pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)