pro June 2011

pro@common-lisp.net

30 participants
15 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro June 2011