- pro - mailman3.common-lisp.net

[pro] LISP technology at Cisco
by Daniel Weinreb 08 Jul '11

08 Jul '11

This is a video about "LISP Technology at Cisco". http://www.youtube.com/watch?v=JIiBMZ86jZo&feature=player_embedded (It has nothing to do with Lisp, either.) :) -- Dan

4 3

[pro] why :key arguments?
by Tamas Papp 05 Jul '11

05 Jul '11

Why do some CL library functions have :key arguments? I am asking because I am working on some statistics functions, and the design choice came up. Specifically, I can write functions like (defun quantiles (sequence quantiles &key (key #'identity)) ...) but it is a bit cumbersome. I can make my code simpler by relying on calls like (quantiles (map 'vector key vector) quantiles) but this conses a bit more. Not a major concern at the moment, but if it ever becomes one, I could just define a compiler macro to take care of forms like this and transform to something like (quantile-with-keys vector quantiles key) I also thought of defining something like (defgeneric map1 (function object) (:method (function (list list)) (mapcar function list)) ...) for the sole purpose of mapping objects to similar objects (eg lists to lists, arrays to arrays, etc) and allow it to be optimized away (like above) by compiler macros. I would appreciate advice on this. I am especially interested in the reason why some CL functions have :key arguments: is it because of efficiency, backward-compatibility/history, or something else? Thanks, Tamas

10 20

[pro] Generated symbols
by Kazimir Majorinc 04 Jul '11

04 Jul '11

I need comprehensive review of use of generated symbols (make-symbol, copy-symbol, gensym... ) in CL. The books I have (both Grahams, Siebel, barely mention these operators, except for use of gensym in macros. What are other typical or interesting uses of these? -- Kazimir Majorinc

3 2

[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