pro

pro@common-lisp.net

1 participants
346 discussions

[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

[pro] conditioning on *print-readably*
by Tamas K Papp 07 Jun '11

07 Jun '11

Hi, I am working with some structures that have quite a few elements but for most of the time are easier to interpret using a one-line summary. I would like to achieve the following: when *print-readably*, have the structure printed the usual way, eg #S(...). Otherwise use my custom unreadable summary. Eg (simplified example code): (defstruct foo a b) (defmethod print-object ((foo foo) stream) (if *print-readably* (...what-to-do-here?...) ; ?? (print-unreadable-object (foo stream :type t) (format stream "my way of printing foo with A=~A and B=~A" (foo-a foo) (foo-b foo))))) but I don't know how to call CL's built-in way of printing the structure readably in the IF clause above. Tamas

2 1

[pro] Lisp 2's and function values.
by Matthew D. Swank 04 Jun '11

04 Jun '11

I have implemented a small fexpr interpreter in Common Lisp based on Kernel http://web.cs.wpi.edu/~jshutt/kernel.html. Right now it's a Lisp 1, but I am considering trying to make it a more idiomatic extension of Common Lisp by making it a Lisp 2. Part of the Lisp 2-ness of the Common Lisp evaluator is that the car of a form must name a function, macro, or special form. This name is either a symbol bound in the function name space, or a lambda expression. However, Kernel just requires the car evaluate to a combiner (this is what Kernel calls a generic operator). Obviously, in a Lisp 2, a symbol would evaluate to the value bound to it in the function name space. However, consider the following: ((returns-a-function) arg arg ...) Would it be reasonable to allow this as a legal form as well? I'm not arguing Common Lisp should work this way, but I seems to make sense in the context of a Kernel like evaluator. Matt

8 16

[pro] Parallel random number generation...
by Pascal Costanza 26 May '11

26 May '11

There was recently a discussion about random number generation in Common Lisp. Here is an article that may be interesting: http://www.multicoreinfo.com/2011/05/rand/ Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

1 0

[pro] Professional Reports
by Nico de Jager 25 May '11

25 May '11

I am looking for tips to create professional multi-page reports, invoices, etc, preferably producing standalone files like PDFs that can be emailed. Automatic page calculation would be great, and I'd like to include generated and static images (e.g. graphs and logos). The solution does not have to be open source, although most of my applications are web based for which I do prefer GNU Linux as a hosting platform (I am a LispWorks user and have both Linux and Windows licenses). I know about cl-pdf and cl-typesetting, although I have only had a fleeting glance at them. Maybe there is an easy WYSIWYG layout editor that a list member can recommend among the hordes that Google spits out. How do list members typically solve this (boring) problem with their CL applications? Regards. Nico

8 8

[pro] need a lisp tempfile library
by Mark H. David 24 May '11

24 May '11

I think it would be nice to have a library for creating tempfiles. There's this nice writeup of one in Python for inspiration: http://docs.python.org/library/tempfile.html Is there one for Lisp?

4 3

← Newer
1
...
24
25
26
27
28
29
30
...
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro