- pro - mailman3.common-lisp.net

Re: [pro] Some error/condition standardization anyone?
by Marco Antoniotti 28 Jun '11

28 Jun '11

On Jun 28, 2011, at 02:48 , Daniel Weinreb wrote: > > I'd love to see this standardized. Should we put in the work to come > up with a proposal before checking with the implementors to > see whether they're interested in implementing whatever > we come up with? There might be compatibility issues, > too. It would have to be a pretty big proposal to cover > even the basic cases... -- Dan I agree that this should be worked on cooperatively. I do not know if this should be a "big" proposal. My feeling is that the people interested (I am one) should come up with a preliminary outline with an initial goal of being the least intrusive possible into an implementation guts. Cheers -- MA > > Jun 27, 2011 03:16:26 PM, antoniotti.marco(a)disco.unimib.it wrote: > > =========================================== > > > On Jun 27, 2011, at 19:26 , Steve Haflich wrote: > >>> Marco Antoniotti wrote: >>> >>>> Now, this is a specific case for me: having a consistent >>>> READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS >>>> error signaled would simplify some code writing. >> >> I agree with the sentiment, what is the specific proposal may need more work. > > Of course... this is jut one example. There may be other cases, plus unexplored ones: FILE-ERROR is rather underspecified, so are PARSE-ERROR and PROGRAM-ERROR. I'd like to see a discussion started.... > >> Would you want this same condition to be signaled for this form? >> >> (defpackage :foo >> (:use :not-yet-loaded)) >> >> That's an error, but not a reader error the way reading not-yet-loaded:bar would be. Still, it would be nice if these shared a common superclass because what the application might want to do to handle would be the same. > > These would both be PACKAGE-ERRORs, but different > >> Unfortunately, the condition system does not portably support multiple inheritance. > > Yes, I'll grant you that and see where you are going. This is another CDR: The Condition system should use the CLOS algorithm to determine/use/offer multiple inheritance derived properties. > > Cheers > > -- > Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 > DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it > Viale Sarca 336 > I-20126 Milan (MI) ITALY > > Please note that I am not checking my Spam-box anymore. > Please do not forward this email without asking me first. > > > > > > > _______________________________________________ > pro mailing list > pro(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

2 1

[pro] library configuration
by Tamas Papp 28 Jun '11

28 Jun '11

Hi, A user of my LLA library asked for more flexibility in specifying which foreign library to load. For example, BLAS/LAPACK come in so many variants that it is impossible to cover them with the :or feature of cffi:define-foreign-library, especially because users have their own preferences when more than one is available. I am looking for a portable way to specify configuration for a library before/during loading with ASDF2. It would be sufficient if the user could specify an ALIST (or something similar) somewhere and I could read/ use it when the library is loaded. Does ASDF2 have a "standard" mechanism for library config files (eg where they are, how to handle them etc), or should I use something else? I thought of using *features*, but I need actual values instead of merely checking for the presence of symbols. Any suggestions are welcome. Thanks, Tamas

1 0

Re: [pro] Some error/condition standardization anyone?
by Steve Haflich 27 Jun '11

27 Jun '11

> Marco Antoniotti wrote: > > > Now, this is a specific case for me: having a consistent > > READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS > > error signaled would simplify some code writing. I agree with the sentiment, what is the specific proposal may need more work. Would you want this same condition to be signaled for this form? (defpackage :foo (:use :not-yet-loaded)) That's an error, but not a reader error the way reading not-yet-loaded:bar would be. Still, it would be nice if these shared a common superclass because what the application might want to do to handle would be the same. Unfortunately, the condition system does not portably support multiple inheritance.

2 1

[pro] European Common Lisp Meeting 2011: registration is open
by Arthur Lemmens 23 Jun '11

23 Jun '11

Hi everybody, Registration for the European Common Lisp Meeting 2011 is now finally open. Please go to the ECLM website at http://weitz.de/eclm2011/ and follow the instructions there if you want to register. We're hoping to see at least as many participants as in the last years in order not to go bankrupt... Also, should you encounter any technical problems (we hope not), please don't hesitate to contact us. And of course feel free to blog about this or advertise it on other mailing lists. Thanks, Edi & Arthur

1 0

Re: [pro] "fhash"
by Steve Haflich 14 Jun '11

14 Jun '11

If a fhash provided exactly the same API as a hashtable (which it could) then it is a hashtable, and this improved performance for small numbers of entries ought be a feature of any modern quality implementation. The only reason it needs a different name is that if the implementation doesn't provide it, there is no portable way to modify the implementation's implementation. BTW, the implementation probably could do a better job than portable user code at reducing the slight reduced performance for large fhash. Lisp has called these things hash tables ever since they were invented -- do we need two names for the same thing? If so, I've got a problem with this "cons" thingus. Or perhaps I'm just feeling grumpy tonite. A more serious future issue is that as CL slowly moves towards SMP one of the hairy implementation issues is providing efficient hash tables that are hazard free. It is really hard to do this in user code without huge efficiency loss. So fhash might be restricted to uses that cannot be shared between threads, unless it's performance improvement were provided by the native implementation.

6 6

[pro] Fwd: "fhash"
by Ala'a Mohammad 14 Jun '11

14 Jun '11

[Daniel, excuse me for the double post] ---------- Forwarded message ---------- From: Ala'a Mohammad <amalawi(a)gmail.com> Date: Tue, Jun 14, 2011 at 11:29 AM Subject: Re: [pro] "fhash" To: Daniel Weinreb <dlw(a)google.com> On Mon, Jun 13, 2011 at 11:18 PM, Daniel Weinreb <dlw(a)google.com> wrote: >... > I have recently been cleaning this up, one reason being that I'd like > to open source it. The function names used to be things like getfhash > and mapfhash. Now they are like fhash:get and fhash:map-elements and > ... > Here are pros and cons of changing it that I can see. > ... > Con: Common Lisp already uses the name "hash table", so it would be > easier for existing Common Lisp programmers to see the analogy. I can see this as a Con only if you will use the same API as hash-table. However, the fhash library uses different APIs (get, map-elements) instead of (gethash, maphash). This means the benefit of knowing/familiarity-with CL hash-table will not help/aid while using fhash (guessing the API), since I have to lookup (or learn) the new API wording. - Ala'a

1 0

[pro] About &aux
by Daniel Weinreb 13 Jun '11

13 Jun '11

I, myself, really dislike &aux. It has been so long since I have seen it that I have forgotten that it even exists. We never use it; and I should add that to our style guide. I don't even like (let (a b c) ...) since I prefer to think of "let" in the Scheme sense of "I am naming the result of a computation." In fact, I added a macro to our library that is like "let" but does not allow the variable to be modified. (It's not portable; it uses a CCL-specific feature.) Unfortunately, we do not use it in practice, since it's so important for code style to be consistent and it would be very hard to change all our sources to do this, since it's hard to know from looking at code whether the "let" variable ever changes, and we have like 700MLOC of code in QRes. I wish Common Lisp had always had such a feature. I'm not saying there's no place for let followed by side effects. It's just not the way I usually think of it. Also, putting things in the parameter list that aren't parameters just feels weird. I do not think my own opinions are by any means "right". These are just my biases and preferences. -- Dan

9 10

Re: [pro] BOA constructor and supplied-p argument
by Pascal Costanza 12 Jun '11

12 Jun '11

On 11 Jun 2011, at 21:25, Daniel Weinreb wrote: > I don't like (let (a b c) ...) any more than I do &aux. I suppose > it's because I'm trying to think "functionally", with "let" > as much as possible being "compute this value > and give it a name" rather than "declare this > variable so I can start side-effecting it. In general, I agree about (let (a b c) ...), but there are situations where it's hard to avoid. > I wish there were an idiomatic way to have a let > where the variable cannot be set later. I do > have a macro for this in our library, but I > don't use it since it's not part of our general > programming style and consistency of > style is so important. There is, actually: (flet ((a () 5)) ;; now (a) can only be read, but not assigned to ...) I don't think this is as bad as it may seem at first sight, especially making this look like a variable again is easy: (flet ((a () 5)) (symbol-macrolet ((a (a))) ...)) > I'm not saying there's no place for let followed > by side effects. It's just not the way I usually > think of it. Right. > Also, putting things in the parameter list that aren't > parameters just feels weird. ...but they are parameters, just not parameters passed by the client code explicitly. ;) > If I were designing Lisp again, I would also consider > not having &rest at all, and instead pass in "maps", > i.e. like alists, so that it would be easier to pass on > these arguments to other functions without > having to deal with "apply". > > A lot of the original motivation of &rest was to > avoid consing. In the original implementation, > the list values of &rest parameters were > stack-consed, and you were supposed to > be careful not to retain them beyond the > scope of the function, a trap for the unwary, > which could have very bad consequences. The fact that &rest can avoid consing is a major win in performance-critical code. Any alternative design that doesn't support this in some way can lead to problems here. I'm a bit less happy by now about the separation of required arguments and keyword arguments. Python makes the use of keywords optional for the same arguments, and I think that's actually better. I think this can in principle be implemented very efficiently. > And I would get rid of the supplied-p business, > which REALLY makes it hard to pass values > on to other functions. Function composition > should not be hard to do. Agreed. > But it's way to late to redesign Common Lisp. No need to be pessimistic. We're still way ahead of everybody else. ;) Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

2 1

Re: [pro] BOA constructor and supplied-p argument
by Nick Levine 11 Jun '11

11 Jun '11

Actually, looking through my code base, I find I've used &aux half a dozen times in the last ten years. Always in a BOA constructor. - n

4 3

[pro] BOA constructor and supplied-p argument
by Tamas K Papp 10 Jun '11

10 Jun '11

Hi, I tried to save a supplied-p parameter from a BOA constructor like this: (defstruct (delayed-iseq (:constructor iseq (start-or-end &optional (end 0 end?) (by 1) strict-direction?))) "Delayed index sequence evaluation." start-or-end end end? by strict-direction?) but SBCL complained that end? was not used. After rereading the CLHS page for defstruct, I am still not 100% sure why this is. My intepretation is that END? is an argument like any other, but probably I am not getting something. Anyhow, instead I used (defstruct delayed-iseq "Delayed index sequence evaluation." start-or-end end end? by strict-direction?) (defun iseq (start-or-end &optional (end 0 end?) (by 1) strict-direction?) (make-delayed-iseq :start-or-end start-or-end :end end :end? end? :by by :strict-direction? strict-direction?)) Is there a way to do it in a single defstruct definition? Best, Tamas PS.: (eq end nil) is different from when it is not supplied, hence the need to save end?.

4 3