some HLL comments

[Jecel Mattos de Assumpcao Jr.]

On Mon, 6 Mar 95 18:03:21 MET Francois-Rene Rideau wrote:
>    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.

Like you said, this is just a numbering convention. Then please decide
what Alpha version 0.X will have and what will only be implemented in
1.0.

> > [ open stack ( Forth ) or framed stack ( C ) model? ]
>    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.

I don't think this is possible. You can't link Forth to C directly, or
Pascal to LISP. You need to generate adaptors, but these cannot handle
all of the differences between the models. Some manual patching is needed
in all of the systems I ever saw. Picking one method as native will
reduce the number of adaptors you have to build from n/2*(n-1) to n-1.

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

How would the annotation translate into LLL terms? Library calls?

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

Good idea, but let's leave translating Spice as an excercise for the
user ;-)

-- Jecel