Testing the waters.

[Chris Bitmead uid(x22068)]

>Now if there are ready and willing developers that want Common Lisp
>because they've got big apps they want to easily adapt to LispOS, that
>is an actual argument for going with Common Lisp (especially if they
>are prepared to share these apps).  Lemee see what do I care about,
>maybe Maxima, sorta kinda CLX, Garnet but not really... umm.. 
>err.. uh..

I'll repeat again, that I'll go with the majority rule on the Lisp vs
Scheme issue.

However, let me say this. The primary objective of this project is to
build something which is the Right Thing (tm). Compatibility very much
takes a second place as far as importance. If this were not the case,
we might choose to stay with C++ on NT.

Now IMHO, Scheme with a suitably powerful set of libraries and object
system, is the Right Thing (tm). I don't say this because the language
is small. I say this despite the language being small.

I think Scheme is the Right Thing because...
- It evaluates the operator position of a procedure call in the same
way as an operand. I find lisp quoting and funcall confusing and less
clean. It actually irritates me quite a bit.
- It has call/cc and lisp does not.

So, my preference is to use Scheme since we're sacrificing
compatibility with almost everything anyhow. Those existing CL
programs which can be forced to work on LispOS probably aren't written
to properly take advantage of what LispOS and POS has to offer
anyway. If forcing what's out there already to work is a major
consideration, then getting C programs to work is probably more
important.

I suspect that using more than one language on LispOS is not going to
work too well, so if Lisp is the designated language then I suspect
that everyone should use that language.