some HLL comments

> I haven't been able to read the very latest versions of the WWW
> pages as the local server insists on giving me cached ( old ) versions
> of the pages :-(
On netscape, the "reload" icon should flush this cache;
but I'd recommend you have a local copy of the whole Tunes distribution,
and then use the GNU patch utility to update it.
Patch 0.0.0.9 is just out !


> I think that the requirements are too ambitious. The multiple syntax
> thing, the pledge to run on obsolete hardware, etc... You will find
> that 20% of your goals will take up 80% of your effort without
> proportional gains. Find out what you can live without and leave it
> for version 2.0.
   I'd rather stick to have everything in version 1.0,
but I agree ALPHA versions 0.x won't need have everything.
Actually, it's just a problem of version numbering policy:
we all agree (I think) that we must begin implementing incomplete
prototypes before version 1.0 is out.


> It is not clear to me whether Tunes uses an open stack or a framed
> stack model. The example you gave had both FORTH and C semantics. They
> are *not* compatible. It is very hard to distribute computation in
> the FORTH model because you can't do remote proceedure call kind of
> things. You can't know how many arguments a proceedure will take
> except by running it! Of course, C is not very simple either ( printf )
> but it is more static.
   I think our HLL should be high-level enough to make such considerations
obsolete, and its implementation versatile enough to allow linking to
lower-level routines using either model. To the HLL, all routines will
have a fixed number of argument, but the way the arguments are passed is
function-dependent: according to the implementation, it could be done
through dictionary modification, LISP-like cons-list parameter, pushing
on an array-like stack, using registers (with various callee-saved and
caller-saved conventions), etc. ". rest" or "&rest" parameters, passing
parameters through dictionary, using implicit parameters, importing
a parameter's structure in the dictionary, would be standard techniques
to allow any kind of parameter passing.
   To me, distribution would be done at the HLL using parallel evaluators
for function evaluation (functions would then have to be annotated to
show how parallelization is possible); the LLL would still reflect the
sequential von Neuman machine architecture of today's CPUs. That's still an
opinion, though. Arguments pro/con welcome.


> About C compatibility - this is an illusion, but you saw this. People
> talk to me about running C but forget that there is malloc/dealloc or
> Mac/Windows memory management, stdio or X widgets or ...., parallelism
> through PVM or Linda or "by hand" over tcp/ip or....
> C + Posix as you seem to indicate is a reasonable target.
I think we should rather allow interactive programmable translation of
C into our HLL. We'd then "manually" translate, and would produce scripts
as we do, that we'd then refine, generalize, multiplex, clean, and merge
into a single package, as we do...


--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- 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.