EuLisp

[Marc Wachowitz]

Since EuLisp has been mentioned as an alternative base for LispOS, here
are a few thoughts about necessary extensions at the "language level" -
as far as one can differentiate that from mere libraries at all. (Btw,
does anyone have insider information whether there's still any language
development going on? From here it looks like the project is stuck at
definition 0.99, which is kind of sad given the promising foundation.)

The macro facility is almost useless. Once could either introduce an
explicit way of referencing a top-level binding from another module
independently from what's what in the scope (at module top-level or
nested) where the macro is used, or one could add a _sufficiently_
_powerful_ macro facility (like the SYNTAX-CASE proposed for Scheme)
taking care of scoping - including across module boundaries. It would
also be good to have something similar to Common Lisp's EVAL-WHEN
to allow non-trivial work during compile-time macro expansion (separate
from the run-time environment). This part of the semantics appears to
be very weakly specified - perhaps even intentionally, but for low-level
work and efficiency one should be able to tell explicity when something
should happen. Even more ambitious would be to make some compile time
information explicitly available to the macro (similar to &env in Common
Lisp). Whichever choice is made, it's important not to cripple macros to
the extend that they'd be merely a somewhat more elaborate variant of C
preprocessor macros, but to retain their strength as a CASE tool, which
makes them significantly more powerful in Lisp than in other languages.

Bignums need to be part of the language, to make mixed fixnum/bignum
arithmetic work right (e.g. fixnum + fixnum may yield a bignum) and
efficiently for the various numerical facilities. Providing access to
fixnum-only primitives with overflow indication would also be helpful,
but not sufficient for proper integration into the language.

Some form of low-level declarations at least for integer types and for
vectors/arrays (including bit-manipulation) is necessary for efficiency;
function types for calls to unknown functions would also be useful. Let's
learn from Common Lisp in that area, both about what would be worth
having, and about what may complicate the language without a real need
(the complexity of CL's type expressions is probably too much for EL, but
we should include enough to enable numeric code performing competetively
with excellent Fortran implementations, even if not every system might
implement it that well).

Character comparison must be defined - even though the result may be
non-portable across implementations, beyond what's currently defined.
Alternatively, one might also just require Unicode internally, and
implement IO via non-Unicode representations as raw numeric interfaces.
The latter would probably hurt those wishing to interface legacy code
(including running on a different OS, in the WWW etc.), and care should
be taken not to isolate the system through using something which was
intended to prevent isolation.

For those wanting a "Lisp-machine" like working environmet, there needs
to be a specification about redefintions etc., given that EuLisp does
define some bindings as constant. One might think of adding a kind of
open/closed specifier for a module, where "constant" bindings in open
modules could still be redefined in the development mode/environment,
while still disallowing arbitrary assignment. Instead of specifying it
in the module, this property could also be defined in various other
ways, even gradually - up to leaving everything "open" when you don't
care about the related loss of efficiency (e.g. inlining effectively
means closing the inlined code, unless you require the system to keep
track of and recompile all those dependencies, which would also create
some overhead for low-level code, and may not be good for delivery in
a client-server system, where the client is meant to be "thin").

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>