<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 6:18 AM Marco Antoniotti <<a href="mailto:marco.antoniotti@unimib.it">marco.antoniotti@unimib.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>... I forgot.<br><br></div>Let's get the CLtL2 "Environment" API back in the "extended" spec.</div><div><br></div><div>Which brings me to the following statement.  The issue here is to <b>extend </b>the spec; not to cut pieces out of it.<br></div><div><br></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div></div></div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 12:07 PM Marco Antoniotti <<a href="mailto:marco.antoniotti@unimib.it" target="_blank">marco.antoniotti@unimib.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Jean-Claude</div><div><br></div><div>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".</div><div><br></div><div>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).<br><br></div><div>First of all there are several issues with CL which need to be clarified.</div><div><ul><li>Some time ago, I started looking at reviewing the condition hierarchy.  The motivation being the fact that<br><span style="font-family:monospace">(read-from-string "I-AM-NOT-A-PACKAGE::FOO")</span><br>yields different conditions in different implementations.  This is just an example: there are many, many more.</li></ul></div></div></blockquote></div></blockquote><div><br></div><div>You have to hit directly on it to see what could be wrong with it. I cannot do much about other implementations though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><ul><li>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<br><span style="font-family:monospace">(defclass foo (a1 a2 ... an)<br>   (... slots...)<br>   ...<br>   (:sealed t))</span><br>should actually do?</li></ul></div></div></blockquote></div></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><ul><li>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.</li></ul></div></div></blockquote></div></blockquote><div>Looks like a "also nice to have". <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><ul><li>Can we have a common and Common Lispy network interface?<br></li></ul></div></div></blockquote></div></blockquote><div>Such a nice candidate for a (standard?) library.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><ul><li></li><li>Did I mention<br><span style="font-family:monospace">(pathname-device some-pathname)</span><br>?<br></li></ul></div></div></blockquote></div></blockquote><div>Specifically pathname-device alone or the whole pathname business? <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><ul><li></li></ul></div><div>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</div></div></blockquote></div></blockquote><div><br></div><div>Thank you very much for all this.</div><div><br></div><div>Regards,</div><div><br></div><div>Jean-Claude</div><div><br></div><div><br></div></div></div>