What is your goal for the lll?

[Nathan Hawkins]

On Sat, 27 Apr 1996, Captain Napalm wrote:

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

I have started OS design _lot's_ of different times. And I have a box 
full of notes, most of which I can't read at all. Oh well.

As for your language, I screwed up the shell archive somehow, and haven't 
found the time to fix it, so I haven't had a chance to look at it. :-(
If you have an ftp location, or can get it to gzip well, could you try to 
get it to me again?

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

I like some implementations better than others... I particularly _don't_ 
like any of the ones I've tried for Linux. Mine were all slightly 
incompatible, things like doing the "user" variables as TO variables, 
compiling input (like in the thread currently going on in c.l.f), stuff 
like that. I also like things to be as simple as possible, which some 
systems don't...

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

That would be fine, as long as it's possible to do an ANS layer in a more 
or less transparent way. (That is, don't implement in a way that's 
totally incompatible.)

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

True, but some hacks are possible, since you can write code that is 
conditionally compiled, and at compile time detect things like integer 
size. ANS Forth adds words to do this sort of thing. I'd do something 
like that, and try and make it a little easier.

> > 3. modularity
> > 4. extensibility
> 
>   And these two go pretty much hand in hand.

They _should_! But Forth has great extensibility, but poor modularity. 
(See below.)

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

I looked very briefly, but wasn't keen on it. Too much like C++, and I 
try to avoid that. I've even been getting sick of C, lately.

But this functionality added to Forth would be a huge step towards both 
the goals of the Tunes project, and my own OS project, since I could then 
write an OS solely in that language, and hopefully share packages between 
the two systems.
Possibly even set things up so that my system can host Tunes and/or vice 
versa. This would be done by having both systems use the LLL, and let the 
HLL and the rest of Tunes be simply libraries and runtime environment as 
far as Radix (my system) is concerned. That is at least as practical as 
the OTOP project, and almost certainly more so, since I'm likely to 
design my system to allow it, whereas Posix is already fixed in stone...

But that's all speculation, and a long way from the present. Still, it 
would be nice.

*utsl*