LLL Re:many [far30]

[Michael David WINIKOFF]

> 
> ">>" is [far30]
> ">" is Michael's Apr 30 reply
> 
> If we have an OO late binding mechanism (=dynamic, run-time, object link),
> which is I think basic for an OO system (what's an OO system if there's no
> such thing ?), it will not be that easy at all including these mechanism
> in the compiler; and there won't be anymore usable code/data portability.
> Thus, from one platform to the other, you'll have to exchange some ASCII
> text, as with unix, and recompile it, but keeping sources for further
> exchange (which explains why unix eats so much disk space).

I don't think this is why Unix is large.

I still think that you can provide late binding by packing object code
into objects with info on methods.

CF. Libraries on the Amiga and devices on (nearly) any OS.

> > 
> > This varies. Yes, parsing and lexing take time but linking also takes a fair
> > amount of time.
> > 
> Yes, but there's no way to escape it. At least, _user_ compile time will have
> been sped up by a two to five factor.

Avoid compiling at run time. Simple.

I think a problem here is that I'm thinking in terms of conventional compilation
whereas you're thining in terms of libraries/late binding.

To me the packaging of objects to enable late binding should be independant of
the compilation technology.


> > 
> > Besides, most of the compilation you do will be during development when you
> > HAVE to do the first step source->LLL, sure you save on the LLL->executable
> > and I think interpreting LLL will help in making a good debugger but you're
> > not saving on lexing/parsing -- rather on linking.
>  Yes, but only the author will have to compile, not the user; moreover,
> including info in LLL keeping track of what code corresponds to what source
> part will allow partial compile; finally, if the parsed format is standard
> (=commented unoptimized LLL), we can build parse-on-the-fly structured
> editors. If you ever used something like GFA Basic on the Atari or the Amiga,
> you'll know that structured editors are far more functional than linear text
> editors; and GFA is limited by its Basic structure, whereas if we build our
> HLL, we we're not, and we can improve the principle.

Yuck! LLL is by definition low level.
Structured editors are not all good -- when editing strucured programs you 
often go through stages where the program isn't valid syntactically.

You're contradicting yourself -- if only the author needs to compile then
why should LLL keep track of what code corresponds to what source? And doesn't
this keeping track involve keeping the source around?

>  I conceive the system as a huge structured relational code&data base. Of
> course, ASCII source IS a possible and sometimes useful representation of it,
> but it certainly isn't the only, and neither the best, nor the quicker, nor
> the easiest to read/understand/modify for the human, nor the only portable
> one. Let's just not be bound by the ASCII limitations of unix(tm).

To the contrary. What I am proposing is that we accept compiled object code
which is essentially machine code with some packaging as a standard.

This is important -- companies don't want to distribute source code ...

> > 
> > You don't need LLL for this. It can be done with the object code.
> Yes, but LLL is portable, whereas object code is not. But signature is not
> an essential point.

POrtabiity at the object code isn't useful. 
You can get the same effect through source code portability which leaves
you with a simpler kernel.

Let me emphasize one VERY important point:

	PUTTING  FUNCTIONALITY INTO THE KERNEL IS NOT FREE

	EACH BIT OF FUNCTIONALITY THAT IS ADDED TO THE KERNEL HAS A DETRIMENTAL
	EFFECT ON THE SPEED AND RELIABILITY OF THE SYSTEM.
> >
> Well, you know, this is only a particularization of the general problem of
> distributed systems, i.e. keeping track of "copies" of different versions
> of objects. If we have a distributed system, this will only be an
> application of our more general solution (what will it be ?) to the one
> big problem.

ANother point -- are we trying to build a distributed system?

It seems to me that these are still an open research area.
We want to avoid anything associated with research if we want to have a running
system.

> >
> If Moose is made portable, assembling won't be done b4 distribution, except
> possibly for time-critical and/or unportable drivers.

I've answered this above -- this is not a good way of achieving portability.
Furthermore assembley b4 distribution is actually desirable.

>  Did you never have to write some application where the user had to/could
> input functions and/or expressions ? (curve drawing programs and/or
> small spreadsheet app, etc ?). Sometimes, you like it to be powerful, even
> if the kernel is simple and you can't afford building something complex.
> Then, a STANDARD LLL and/or semi-HLL (i.e. standard local entries to the
> HLL compiler) can be more than just useful. Saves time, money, increases
> power, allows easy inter-app high-level communication.

Sorry. I don't see the connection.
Please expand.

> 

Michael -- about to log off and get some sleep.
PS. I'm busy this week so I;d like to appologise in advance for not replying.

--------------------------------------------------------------------------------
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.