... I forgot.
Let's get the CLtL2 "Environment" API back in the "extended" spec.
Which brings me to the following statement. The issue here is to extend the spec; not to cut pieces out of it.
CLtL2 "Environment" API is second from the top of my list of things to do. But I am of the opinion that this API needs one or two corrections before being good enough for primetime. But currently I need first to finish my C99-complete FFI thing.
Jean-Claude
the point is that CLOS is not a "library", although it was certainly possible to implement it that way.. It is an integral part of CL "as is".
I see that the discussion has gone ahead, but here is my 2 cents. I don't have much time to work on it due to my day job (and other - retrocomputing - distractions).
First of all there are several issues with CL which need to be clarified.
- Some time ago, I started looking at reviewing the condition hierarchy. The motivation being the fact that
(read-from-string "I-AM-NOT-A-PACKAGE::FOO")
yields different conditions in different implementations. This is just an example: there are many, many more.
You have to hit directly on it to see what could be wrong with it. I cannot do much about other implementations though.
- If your really want to help a "smart enough compiler" to produce fast code, what about writing up a precise explanation, wrt the current CL standard of what an extension like
(defclass foo (a1 a2 ... an)
(... slots...)
...
(:sealed t))
should actually do?
I tried myself at this one quite a while back and got a very big headache. If I recall correctly my working conclusion was that this :sealed option of cl:defclass was targeting the wrong thing. The CPL of the class was the real key instead and I could not see how to nail that one. But that has been quite a while ago so I could be fabulating here.
- I still would like to be able to write an interval arithmetic package in Common Lisp (yes; I may have hooked up a student to finish the grunt work of producing an initial spec that could be discussed in detail.
Looks like a "also nice to have".
- Can we have a common and Common Lispy network interface?
Such a nice candidate for a (standard?) library.
- Did I mention
(pathname-device some-pathname)
?
Specifically pathname-device alone or the whole pathname business?
The list can go on. But what I have in mind are all clarifications and extension to the CL spec as is. Not that there aren't libraries out there that do some or most of what I have in mind, but that's' the way things are right now
Thank you very much for all this.
Regards,
Jean-Claude