Tunes activity, LLL
Sat, 4 Mar 95 2:26:32 MET
> Fare wrote:-
> > * Relaunch talks about the LLL
> > I suggest we use our own FORTH dialect as a LLL.
> > Why not start with the ANS FORTH specifications, or Postscript,
> > then modify it when we find the semantics do not fit the project ?
> Yaargh. I **really believe** that _any_ language you create must take
> a few good ideas and explore the development of these from the bottom
> up, rather than being the bastardization of someone else's ideas.
I fully agree; however, I also believe we need make prototypes before we
finally arrive to the final model.
> I am sure that I do not know enough about the above specs to comment
> with any degree of accuracy. Do you have the specs in a file
> that you can email to the group, or where can we FTP them?
If you mean about FORTH, well, I'll add some pointer in the next release
for the Tunes WWW pages. Basically, try
If it's about the TUNES project, well, there haven't been much discussion
since Mike left us. The latest thing he proposed was a virtual stack
processor with a lot of extra stacks and registers. My counter-proposition
was having a minimalistic machine, with just a local stack, a heap, and a
"continuation" object. We're still looking for someone to take over the LLL
project. Any taker ?
Now, if it's about where to find the stuff I constantly write about
the TUNES project, I've just added it in my .sig !
> > Begin coding the GC in LLL.
> > Begin implementing the LLL in asm using techniques like eForth,
> > that we can refine later.
> No point, if we don't know what we are doing and where we are heading!
> Last time I tried making a few tentative suggestions, someone who
> doesn't know the difference between an interpreter and a compiler
> poured piss all over them.
Yes, he was rude, and we had no means to write down your proposition in
any document; it should be reviewed in the LLL project.
(btw, the mailing-list digesting hasn't advanced a lot lately - Chris ?
Rainer ? me ?):
Now, again, we must propose and implement prototypes before we can
find a "perfect" model: it won't become obvious by magic !
> > Why wait for the HLL ? Everything is ok, as soon as we write it in
> > a modular way, and are ready to modify it to fit further requirements.
> Bullshit. Modular crap is still crap. Also, you are making too much
> fuss about HLL vs LLL. The HLL should fit logically and seamlessly
> onto the LLL, and will not do so if the two are designed at different
> times by different people.
If you have any criticisms, they'll be more useful if you argue them publicly.
Now, I admit the HLL should be implemented as an extension to the LLL;
I myself always said that there were no clear limit to be between a HLL and
a LLL if both were powerful enough. But HLL and LLL *start* from different
point of view: the HLL strives to define abstractions that are conceptually
easier to manipulate from the human point of view, while the LLL starts from
the actual CPU up. Both join, and deeply interact, as do all the subprojects
in TUNES: our project has some deep unity. I do think the HLL and LLL deserve
to be different projects; now, if you find a better organization in subprojects
I'm open to any suggestion (didn't we say that the project should be democratic
whenever possible ?)
> > > * Open a subproject about object migration.
> > * Reviewing existing languages and existing systems on top of which to
> > implement Tunes, and what techniques are involved.
> Excellent ideas.
Perhaps you can send contributions, or even become maintainer, then ? ;-)
This also applies to you all Tunes readers.
As for those interested in reviewing other projects, Lots* of unreviewed
pointers lie in the TUNES WWW page (see "Other related projects"); more are
ever to come. If we find a maintainer/enough contributions, it'll earn a
subproject of its own !
Well, thanks JVS for your joyous feedback !
Any feedback welcome, all !
-- , , _ v ~ ^ --
-- Fare -- firstname.lastname@example.org -- Francois-Rene Rideau -- +)ang-Vu Ban --
-- ' / . --
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System
WWW URL: http://acacia.ens.fr:8080/home/rideau/Tunes/
IRC: on undernet (e.g. /server us.undernet.org) channel #Tunes
FTP SITE: ftp://frmap711.mathp7.jussieu.fr/pub/scratch/rideau/Tunes/
contains full (~300K) distribution, regular patches (~30K) to upgrade,
and the full (~1400K) mailing list archive for MOOSE & TUNES.
Get any by mail and/or subscribe to patches by sending me mail.