Testing the waters.

[Chris Bitmead uid(x22068)]

>Chris Bitmead:
>;; You won't get portability from LispOS to other versions of CL in any
>;; case, because you won't have the POS ported to the other version of
>;; CL. And POSes are always very tightly integrated with the virtual
>;; machine and garbage collector, and application code.
>
>I sure hope you don't apply that reasoning to your own applications -
>ever heard of modular design? 

A can only assume you have never used an object database.

>You don't need a degree in software
>engineering to separate out platform-dependent code from
>platform-independent code. 

What if every piece of Lisp code in the entire system continues to
work if you either..
- Pass it a pointer to memory
- Pass it a pointer to an object not in memory, but instead is in the POS.

How do you separate out the code which works with the POS? You can't,
because all code can work with the POS.

>If LispOS is based on CL, application level
>code should be VERY portable between LispOS and other CLs. 

Not if you assume the existance of a POS, and the "other" CL does not
support a POS. (Some CLs do support them BTW, so there is some degree
of portability, but it's not in the CL standard I don't think).

>Only the
>levels that interface with the OS will be non-portable.  

You are thinking in conventional paradigms. Now you have to learn to
think outside the square. It's hard to explain how a POS simplifys
everything if you have never used one.

>This is the
>same deal in ANY programming environment. 

Try sometime making a C++ application work with both Oracle and an
ODBMS. Good luck! Many dead carcasses lie on that trail. (Most of them
on the Oracle trail BTW).

>I write applications right
>now that have one common source base that will compile on Solaris,
>HP-UX, AIX, Windows NT, and Linux, and a small set of
>platform-dependent code.

Good for you. Have you got any that work with ObjectStore, Versant,
Oracle, Sybase and flat files? I didn't think so.

>Chris Bitmead:
>;; You may get your existing CL lisp programs working on LispOS, but they
>;; won't do things the LispOS way, so they fall into the general category
>;; of how to get legacy applications working on LispOS.
>
>The same reasoning above applies here too. It's insane to create a
>Lisp-based OS and then lump all existing LISP programs in the legacy
>bin. Can you see that?

That depends on how you view the legacy bin. The legacy bin has got
many useful, essential and interesting things in it. I like the legacy
bin. I use the legacy bin. It's still the legacy bin tho'.