What is your goal for the lll?

Captain Napalm spc@armigeron.com
Sat, 27 Apr 1996 05:10:35 -0400 (EDT)


  This is what I get for going into crunch mode - way behind.  Anyway ... 

A long long time ago on a network far far away, Nathan Hawkins thus said:
> 
> Anyway, by this time, I had discovered Forth, and had been thinking about 
> ways to use Forth in the core of my own project.

  Well, I've been doing pretty much the same.  I started an OS project on
Monday, December 3, 1990 at 10:38 pm EDT (ah, the joys of having a notebook)
and currently have about 160 pages of notes, four implimentations of a
language I came up with (the latest, stable version I sent to Nathan) and a
definite opinion as to where I would want an OS to go.

  That, and while I like Forth (and the system started out with Forth in
mind), I don't like Forth at the same time.

  Actually, I like Forth on a theoretical level, not on the actual
implimentation level, so I have no desire to really keep compatibility with
Forth (79, 83, Fig or ANS).

> The conclusion I had 
> come to was that Forth mostly needs better modularity. I wanted (and still 
> do) to drasticly extend the vocabulary concept into a hierarchical 
> directory style structure. (Some of you may have seen a my thread on this in 
> comp.lang.forth.) And I'd like to make my own Forth-like language 
> capable of being ported to most =>32-bit processors. This shouldn't be 
> too hard.
> 
  An idea might be to forgo an ANS version and go with a Forth-like
language, then add an ANS layer to it (like QNX has added a POSIX layer). 
My current language design (which I haven't had much time to work on lately)
has a vastly new structure beneath it, and adding an ANS layer to this
shouldn't be a problem.

> So what I want is something I can still use as a Forth-based 
> human-writable/readable language with the following principal features:
> 
> 1. portability
> 2. efficiency

  The first two are almost mutually exclusive 8-)

> 3. modularity
> 4. extensibility

  And these two go pretty much hand in hand.

> 5. interactivity
> 
> Modularity would mean the ability to load a package of words into memory 
> and unload them when finished with them. Forth has never really had a 
> good means of separating programs and libraries from the rest of it and 
> each other. Nowadays, this is a liability, which I would like to eliminate.
> 
  Might want to take a look at Java then.  I've noticed (since I've been
working with nothing BUT Java for the past two months) that only those parts
of an applet are transferred that are actually used (almost like demand
paging).  But once loaded, they (I assume) stay loaded.

  -spc (Not to say that I like Java any more than Forth - if anything, I'd
	rather be doing Forth ... )