Moose Requirements & LLL followup [djg21]

[Michael David WINIKOFF]

> 
> Quoting two messages from Michael David WINIKOFF
> 
> >Mouse?
> 
> Mouse is optional and therefore not REQUIRED.

I'd suggest that it's pretty pointless to have people using a GUI without
a mouse.

I know it can be done but I see nothing wrong with insisting that people have
Mice. This isn't the 80's anymore :-)

> 
> Actually, this is a way of saying serial line without preventing it
> from also allowing network connections, or bi-directional use of a
> parellel port.

Fair 'nuff.

> 
> --------------------------------------------------
> 
> >>
> >> David Garfield Said:
> That was not me, that was Dan Odom.  Watch the quotes!

:-)

> 
> For the sake of the above mentioned commerial applications and
> shareware developers, we need to have a distribution method other than
> source.  For the sake of portability we should have some method of
> distribution other than system-specific binary.  This leaves us with

Not neccessarily. 
Firstly I'd argue that portability AT THAT LEVEL is not an important goal.
You can easily achieve portability by recompiling.
What counts is SOURCE CODE PORTABILITY.
The only reason you'd want binary portability is for process migration which
is irrelevant as WE ARE NOT DEVELOPING A DISTRIBUTED OS.

There's nothing stopping us from defining an LLL and writtig an interpreter, and
encouraging people to use it.

What I object to is placing a compiler in the system and having the system 
responsible for run-time compilation and caching of code.

There are simpler ways to achieve portability which remain out of the
system level.

> an interpreter of some sort, ant thus we get LLL.  But I still feel
> that it is not to be used for most/all of the standard distributions.
> I will point out (again?) that this can be done any time up till when
> there is a general public distribution.  After that it is too late.
> You also can't aford to change the LLL once you do have a general
> public distribution.  If you do, you get other portability problems.
> 
> As for the comment someone had about disadvantages of putting
> something like this in the kernel, you have to put it somewhere fairly
> common.  Perhaps the interpreter winds up being a second meta-class?

Fine. /bin/LLL-interpreter (or the equivalent).

> Anybody want to discuss meta-classes?  Should we support meta-classes?
> This might solve the upgrade problems, and even allow any developer
> that felt the need to design a new interpreter.

What's a meta-class? 

> 
> David
> 

Michael