June 2011 - pro - mailman3.common-lisp.net

[pro] "fhash"
by Daniel Weinreb 30 Jun '11

30 Jun '11

Friends, I wrote a little package for "fash hash tables", which provide an abstraction that is analogous to that of Common Lisp hash tables, but is faster for tables with few elements, and only slightly inferior for tables with many elements. I did this because performance analysis showed that our system was spending too much time in hash table operations, and using the new package helped. 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 so on. However, before I open-source it, I was to make sure it's "right". It recently occurred to me that the package name "fhash" has problems. Here are pros and cons of changing it that I can see. Pro: I's not a hash table in the small-cardinality case; it's a linear lookup. So the name is not actually accurate. Pro: Calling such a data structure a "hash table", even as Common Lisp does, is an abstraction violation. Whether it works by hashing is an implementation detail. The Java collection library calls this a Map. Python calls it a dictionary. Clojure calls it a map. Those are both better names. Con: Common Lisp already uses the name "hash table", so it would be easier for existing Common Lisp programmers to see the analogy. Advice? Thanks! Thanks! -- Dan

8 13

[pro] library configuration
by Hans Hübner 29 Jun '11

29 Jun '11

I made a moderation error, so I'm forwarding this message manually. -Hans ---------- Forwarded message ---------- From: Tamas Papp <tkpapp(a)gmail.com> To: pro(a)common-lisp.net Date: Tue, 28 Jun 2011 12:26:24 +0000 (UTC) Subject: library configuration 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

6 8

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

28 Jun '11

Hi I have the following problem (here below in CCL and LW) CCL: marcoxa$ ccl AM I BEING LOADED? Welcome to Clozure Common Lisp Version 1.5-r13651 (DarwinX8632)! ? (ignore-errors (read)) foo::bar NIL #<CCL::SIMPLE-READER-ERROR #xC48489E> ? LWM: CL-USER 1 > (ignore-errors (read)) foo: NIL #<CONDITIONS:PACKAGE-NOT-FOUND-READER 21BA3B93> CL-USER 2 > Other Lisps behave similarly. I.e. they don't agree on the type of the error that they need to generate. 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. Doesn't anybody think that it would be a good thing to have a CDR suggesting an agreed upon extension of the CL standard ERROR/CONDITION hierarchy? 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.

5 5

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