- pro - mailman3.common-lisp.net

[pro] Chains of multiple-value-bind...
by Pascal Costanza 26 Nov '10

26 Nov '10

Hi, I just hacked the following macro: (defmacro multiple-value-case (&body clauses) (when clauses (destructuring-bind (first &rest rest) clauses (cond ((member (first first) '(t otherwise)) (when clauses (warn "Dead code: ~S." clauses)) `(progn ,@(rest first))) (t (destructuring-bind ((&rest lambda-list) expression (guard) &rest body) first `(multiple-value-bind ,lambda-list ,expression (if ,guard (progn ,@body) (multiple-value-case ,@rest))))))))) Did anybody see anything similar before? Any suggestions for improvement? Thanks, Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

4 3

[pro] Professional uses of Common Lisp...
by Pascal Costanza 11 Nov '10

11 Nov '10

Hi, Dan recently did a survey of existing Common Lisp implementations, which IMO is a very valuable resource. Another valuable resource would be an updated list of current existing professional uses of Common Lisp. The ALU wiki has a list here: http://wiki.alu.org/Industry%20Application - but that is somewhat old by now, as far as I can tell. Any volunteers for doing a survey along those lines? ;) Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

4 3

Re: [pro] Dennis Kucinich
by Daniel Weinreb 29 Oct '10

29 Oct '10

Apologies, the auto-complete in Thunderbird seems to have screwed the address here. Sorry! Yakov Zaytsev wrote: > wtf > > On Fri, Oct 29, 2010 at 7:23 PM, Daniel Weinreb <dlw(a)itasoftware.com > <mailto:dlw@itasoftware.com>> wrote: > > Dennis Kucinich's race is very close. If you want him to win, > send $, see: > > http://kucinich.us/index.php?option=com_content&task=view&id=46&Itemid=58 > <http://kucinich.us/index.php?option=com_content&task=view&id=46&Itemid=58> > > _______________________________________________ > pro mailing list > pro(a)common-lisp.net <mailto:pro@common-lisp.net> > http://common-lisp.net/cgi-bin/mailman/listinfo/pro > >

1 0

[pro] Out of curiosity, ALU membership?
by Peter Seibel 29 Oct '10

29 Oct '10

I'd be interested to know how many people on this list are members of the ALU. If you are or are not and care to share, feel free to email me. And if you're on the board, maybe you could tell me for how long you've been on it. -Peter -- Peter Seibel http://www.codequarterly.com/

1 0

[pro] Dennis Kucinich
by Daniel Weinreb 29 Oct '10

29 Oct '10

Dennis Kucinich's race is very close. If you want him to win, send $, see: http://kucinich.us/index.php?option=com_content&task=view&id=46&Itemid=58

3 2

[pro] Polling CL implementors and maintainers
by Peter Seibel 05 Oct '10

05 Oct '10

Hi folks, I’m working on my talk for the upcoming ILC. If you are the implementor or maintainer of a Common Lisp system, I’d love to know if you were involved in the standardization of Common Lisp either in the pre-ANSI period or on the ANSI committee. If you could drop me an email saying whether you were or were not and what implementation you work on, that’d be a huge help. If you were, please let me know if it was pre-ANSI, ANSI, or both. -Peter -- Peter Seibel http://www.codequarterly.com/

1 0

[pro] The Best Examples of "Code is Data"
by Kazimir Majorinc 28 Sep '10

28 Sep '10

As first, good luck with this list! I'm in search for best examples of "code is data" paradigm in Common Lisp. For most CL-ers, it probably means "macros", but eval, backquote, anything that processes the code as data is of interest. As "best" I think on the most surprising, powerful, sophisticated examples, not necessarily of a pedagogical value. Imagine that someone invited you to write the presentation "Five best CL macros ... I seen" or "Five best CL macros ... I wrote." What would you chose and why? Kazimir Majorinc

26 60

Re: [pro] Fwd: The Best Examples of "Code is Data"
by Vladimir Sedach 28 Sep '10

28 Sep '10

Kazimir Majorinc: > formulas. So far so good. However, some essential operations on formulas > (substitution, unification, rules or inference ...) require analysis of > the formula. > > Similar analysis of the function could be done only by transforming it > back into formula with (caddr (function-lambda-expression Si)), and it > is not simpler, even if it work, what is not guaranteed according to > Hyperspec. This example is confusion about phase separation (http://axisofeval.blogspot.com/2010/07/whats-phase-separation-and-when-do-y…) but more relevantly it presents a false dichotomy for the solution space and perfectly demonstrates the power of macros. There is no need to choose between EVAL and lambdas - make the formula operators be macros and the formulas will know how to analyze (macro-expansion time) *and* evaluate (result of macro-expansion) themselves - the formula interpreter falls out "for free" from doing a COMPILE on a lambda that binds the formula free variables. As a bonus, now the code is factored such that all the analysis code is grouped with the definition of the relevant operators, instead of being scattered around inside an interpreter. A similar example came up in an ll1 mailing list discussion on macros vs closures (http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02060.html - recommended reading as there is also discussion of good macros), but using SQL query languages as the domain. CLSQL, for example, does it with macros, which enable all kinds of compile[macro-expansion]-time analysis and optimization. Smalltalkers do the same thing with closures and using #doesNotUnderstand: (which is sort of like re-binding APPLY): http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02096.html I wrote about how this technique might be used in Common Lisp: http://carcaddar.blogspot.com/2009/04/closure-oriented-metaprogramming-via.… I think the macro approach to queries is more succinct and powerful (you are no longer limited to function calling syntax for your query DSL). The query DSL is something that a lot of people seem to like - LINQ in .NET attempts to do the same thing, but a much higher price (an new syntax for expressing queries, a new protocol for query consumers (database interfaces), and a horribly complicated implementation). The other really powerful example pointed out in the ll1 discussion was SETF. I think SETF is one of the best examples of macros around. It takes the idea of accessors, and turns them into a generic idea of "places" that can be modified in the same way they are read. This extends the language with an entirely new domain concept that works transparently everywhere, with absolutely no changes needed to any of its other parts. There are ways to fake "places" with closures (ex: Oleg Kiselyov's "pointers as closures" trick, or the way dynamic variables work in SRFI 39), but they work by completely changing the accessor protocol, introducing a second protocol for updating places (funcall the closure with new value), and because the "directions" to the place are not reified they are not composable (ie - you can't do (setf (gethash foo (aref bar)) baz) with closures), and cannot be implemented efficiently. Now think about what it would take to do this in Java - you'd need a whole new DSL implemented on top of the Interpreter pattern, a Factory to help you produce the grammar of that DSL, all with a Strategy component so you can define new places. I bet it would be really pleasant to use as well. Vladimir

4 3

[pro] Anaphoric macros (Was: The Best Examples of "Code is Data")
by Daniel Gackle 28 Sep '10

28 Sep '10

Attila's experience matches mine: anaphoric macros are useful because they enhance readability. (I mean, of course, when they're used properly, but that's such a tiresome caveat to have to add and I'm hoping one benefit of this list is that we don't have to jump through *all* the usual hoops.) Given this experience I find it hard to fathom the critique of anaphoric macros that they are bad for readability. Plausible reasons for disagreement are (a) we've had different experiences; (b) we have different tastes; or (c) we're talking about different things. Perhaps the best approach in every case is to make our terms explicit, so at risk of overspecifying I'm going to be as explicit as I can. "Anaphoric macros" for me nearly always means AWHEN or AIF, very occasionally ACOND and that's about it. When I say these "improve readability" I mean that they make code shorter in an easily grokkable way. "Used properly" means "used in a small snippet": when their scope grows beyond the nearly trivial, their benefit -- concision -- tends to get diluted to the point of why bother. Worse, the meaning of IT gets exponentially harder to grok the further IT strays from ITs anaphoric introduction. Here are two simple examples chosen nearly at random from the Skysheet code (Skysheet is the web-based spreadsheet startup I'm working at): (awhen (search "Version/" str) (after-slash it)) (awhen (getf sh :col-deltas) (alist->hash it)) AWHEN makes these forms slightly more trivial than they would be without it. I like that: trivial is second only to non-existent as a good thing for code to be. Here are two more. These are about as complex as I'd ever like an anaphoric macro to get: (awhen (next-as-binary-op) (when (>= (precedence it) level) (consume) it)) (aif (implicit arg) (cond ((eq it :column) +abs-row+) ((eq it :row) +abs-col+) (t +abs-abs+)) (aim-rank (getf arg :aim))) (That COND would be better as a CASE, but it has to run in both CL and JS via Parenscript, and CASE doesn't map to an expression in the latter.) In all four examples I prefer AWHEN/AIF to an explicit binding because it makes the code shorter and more idiomatic. I guess you'll have to take my word for it that the concept temporarily denoted IT is in each case obvious from context and would not get any obviouser with an explicit name. A couple of general reflections. Readability is hard to talk about because it's so in the eye of the beholder. My own views on what's readable have changed a lot. They even vary per-program. In the end I find the definition is a cultural thing that has to get hammered out on a per-project basis by people who are working together (and needs a certain amount of re-hammering with each new person). Finally, I hesitate to post the above because anaphoric macros are kind of a bike-shedding topic: not that interesting but easy to have an opinion about, so they get argued about more than they deserve. But I think it's a useful exercise occasionally to get right down to the threading on the screws. Too often in abstract discussions about programming I find myself wondering what people really mean; this experience gets worse as the subject matter gets more meta. Perhaps anaphoric macros are worth talking about *because* they are so simple. They're a chance to practice talking concretely about abstraction. Dan Gackle On Mon, Sep 27, 2010 at 3:56 AM, Attila Lendvai <attila.lendvai(a)gmail.com>wrote: > > macros that are useful and should be allowed. It is just that > > anaphoric macros, despite all their cuteness, tax code readers > > unnecessarily hard and thus have not been adopted as acceptable > > practice in multi-programmer environments. > > > well, it's one opinion. > > there's at least one counter example in our team of 4. and i > personally do like reasonable usage of anaphoric macros, even when > done by my colleagues. and the reason is exactly that it *rises* code > readability for us. > > our practice includes special coloring for "it" and avoids any usage > which is not blatantly trivial. > > -- > attila > > PS: argh, i so much didn't want to join such a subjective > discussion... i need to meditate on this a bit more to successfully > resist next time. the first exercise will be to let go my opinion of > with-nesting... :) > > _______________________________________________ > pro mailing list > pro(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/pro >

1 0

[pro] Fwd: The Best Examples of "Code is Data"
by Raymond Wiker 25 Sep '10

25 Sep '10

---------- Forwarded message ---------- From: Raymond Wiker <rwiker(a)gmail.com> Date: Fri, Sep 24, 2010 at 2:51 PM Subject: Re: [pro] The Best Examples of "Code is Data" To: Kazimir Majorinc <kazimir(a)chem.pmf.hr> I do not think that this is a case where eval is needed, and it is not a case where eval is likely to be either the best or the simplest solution. Instead of using list-construction operations to construct a "function" to be eval'd, you can use the function-construction operator (lambda, that is). In addition to being more conventional (simply by not using eval), it also gives you a mechanism for passing parameters into your functions without resorting to specials. Two mechanisms, in fact - you can use ordinary parameters and closed-over variables. On Thu, Sep 23, 2010 at 9:53 PM, Kazimir Majorinc <kazimir(a)chem.pmf.hr> wrote: > OK, but both of you paid more attention to the additional niceties or > advantages, unspecified in the problem, than to confirm or reject the > claim that eval is the best solution for problem under specified > criteria "simpler is better." > > It looks to me as implicit claim "Yes, eval is the best solution of that > problem, but if the problem is developed further, other approaches (like > few mentioned) will (soon?) prevail." > > Is it right?

2 1