[imp-hackers] cl-ext:exit

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Thu Jun 25 09:24:14 UTC 2009


Hi everybody. I am also one of those that remained silent, but mostly
because I forgot I had subscribed and ignored whether there was other
people in the list already.

I must say that I am all for a de-facto standardization not only of
things which do not belong in the ANSI specification, but also of
undefined or ill defined behavior. Just to say a few examples...

* Naming of features, which may collide between different platforms or
which might be agreed upon if the imply the same things (for instance
floating point operations, as shown below)

* Real life program facilities, such as quitting with an error code,
exit cleanup handlers, command line arguments, launching programs and
the like. These are things that mostly exist but have never been
agreed upon.

* New paradigms that are being developed, such as native
multithreading, with all the changes that it involves: launching,
stopping, interrogating processes, special variable bindings,...

* AMOP extensions that could be implemented without much fuss. For
instance, locking of slots to fixed positions for fast access.

* As I said before, undefined or ill defined behavior. For instance
the behavior of a compiler under different values of OPTIMIZE: when
are type declarations assumed, when are they used for unboxing values
in an unchecked way, when does the compiler produce type checks, etc.
Or another field is handling of compiler conditions: how should the
user bind its default handlers, intercept errors, collect them, etc.

* ANSI extensions, such as IEEE floating point numbers: NaNs,
infinities, etc. This is requested by major users of open Common Lisp
implementations (Maxima, OpenAxiom), who should be major forces behind
driving users to CL.

* Pedantic ANSI modes and features to enable it (like gcc's -ansi and
so on), so that SBCL for once emits a warning when it finds a LOOP
statement with the wrong ordering of clauses ;-)

I can understand that well developed implementations may feel
reluctant to change, but even for relatively "newcomers", such as ECL,
it becomes a nightmare to take implementation choices when the sea of
lisps has users that are used to completely different strategies, APIs
and behaviors. For instance, right now we have to make changes on the
way users can access compiler conditions, but on the other hand there
are huge improvements to come in the field of interrupt handling.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com




More information about the implementation-hackers mailing list