What is the best way to process this list
in [Lisp]
|
From: Tamas K Papp on 8 Jan 2010 04:40 On Fri, 08 Jan 2010 00:46:21 -0800, Ron Garret wrote: > In article <7qo7kfF9e3U1(a)mid.individual.net>, > Tamas K Papp <tkpapp(a)gmail.com> wrote: > >> On Thu, 07 Jan 2010 13:48:21 -0800, Ron Garret wrote: >> >> > In article <87wrzt3akf.fsf(a)cantab.net>, >> > Christophe Rhodes <csr21(a)cantab.net> wrote: >> > >> >> Ron Garret <rNOSPAMon(a)flownet.com> writes: >> >> >> >> > On the other hand, Lisp has a strong cultural bias against >> >> > creating *new* abstractions, preferring instead to pun mainly on >> >> > cons cells. >> >> >> >> This is not representative of the Lisp culture that I think of >> >> myself as a part of. >> > >> > I'm not saying everyone subscribes to this, but many (I would go so >> > far as to say an overwhelming majority) do. Lisp pedagogy certainly >> > leans heavily in this direction. Is there even one Lisp book out >> > there that doesn't introduce ALists and/or PLists early on and saves >> > CLOS as an "advanced topic"? And then, of course, there is SICP >> > which takes this to an extreme and is highly regarded in certain >> > circles. >> >> I think that there are two communities here. One is what I would call >> "academic" (with apologies to people who are in academia but clearly >> don't belong to this group), the other "practical". The academic group >> mainly uses Lisp-like languages for teaching, and "clever" >> manipulations of lists, preferably using recursion, is held in high >> regard. Macros are not emphasized, if mentioned at all. The "Little >> Schemer" is a perfect example of this community. >> >> The practical camp uses Lisp as practical programming language, solving >> actual problems. They care about programming in the large, >> performance, and robustness, and exploit syntactic abstraction with >> macros to a large extent. >> >> It is an unfortunate historical accident that Lisp education is almost >> exclusively in the hands of the academic group. The majority of >> students who encounter Lisp in college think that it is a DSL for >> recursive list manipulation, and treat it as little more than a >> impractical curiosity. Given the way they are taught Lisp, they are >> probably right. Sometimes I think that Lisp as a practical language >> would benefit enormously if it was scrapped from college curriculums. >> >> Tamas > > Just for the record, when I wrote "Lisp has a strong cultural bias > against creating *new* abstractions" what I had in mind was new abstract > data types, not macros. But since you bring it up... > > Even the practical camp has a somewhat schizophrenic attitude towards > macros. On the one hand, macros are often touted as the cool feature > that makes Lisp superior to other languages. On the other hand, > reactions to specific macros are often strongly negative. "Leave macro > writing to the experts" is an often-heard refrain, and even macros > written by experts are more often than not very badly received (e.g. > John Foderaro's IF* macro, or more recently, Pascal Costanza's filtered > functions). The LOOP macro has a dedicated band of detractors who > regularly urge people not to use it because it isn't "Lispy" enough > (whatever that could possibly mean). The *idea* of macros seems to be > much more enthusiastically embraced than actual macros. Well, this is usenet. If you came up with a pill that cures cancer, some people would immediately complain that it is not the right color. But I hear what you are saying. My response would be to divide the practical camp into open-minded and anal-retentive subcamps (yes, I know, those labels are a bit loaded). The open minded people know that macros are a great tool for DSLs, and if you give me a construct that I don't find useful, it may be that I haven't yet encountered the particular situation in which it comes handy. And maybe I never will, because I am working in a different problem domain, or using a different, equally viable style. But that doesn't make the macro per se useless or harmful. I will refrain from characterizing the anal-retentive subcamp, lest it cause a flamefest. OTOH, a flamefest about macros could be more interesting than a thread with 100+ simple minded insults from you-know- who. Tamas
From: Madhu on 8 Jan 2010 05:39 * Tamas K Papp <7qobuqF2rqU1(a)mid.individual.net> : Wrote on 8 Jan 2010 09:24:42 GMT: | On Fri, 08 Jan 2010 00:48:48 -0800, mdj wrote: | |> I'm also not above directly representing an algorithm I picked up in |> pseudo code from from say, TAOCP using TAGBODY. Often, I won't bother |> making it "lispy" as long as it works fine and is efficient. I |> suspect some 'camps' would consider this 'naughty', but I prefer |> pragmatism to idealism myself. | | Then you are a man after my own heart --- a lot of my numerical code | that I have implemented based on journal articles is done using | TAGBODY. I think that TAGBODY is an underappreciated gem --- for some | algorithms, it _is_ the cleanest choice. Especially when writing FORTRAN in Lisp. -- Madhu
From: Madhu on 8 Jan 2010 05:48 * Tamas K Papp <7qocs9F8j4U1(a)mid.individual.net> : Wrote on 8 Jan 2010 09:40:25 GMT: | But I hear what you are saying. My response would be to divide the | practical camp into open-minded and anal-retentive subcamps (yes, I | know, those labels are a bit loaded). | | The open minded people know that macros are a great tool for DSLs, and | if you give me a construct that I don't find useful, it may be that I | haven't yet encountered the particular situation in which it comes | handy. And maybe I never will, because I am working in a different | problem domain, or using a different, equally viable style. But that | doesn't make the macro per se useless or harmful. Let me guess. You belong to the open-minded group. | I will refrain from characterizing the anal-retentive subcamp, lest it | cause a flamefest. OTOH, a flamefest about macros could be more | interesting than a thread with 100+ simple minded insults from | you-know- who. Maybe you are referring to me! FTR I've stopped insulting Matt with those `simple minded insults' now that I come to realize that his engaging me --- trolling me to insult him --- is not out of spite but because of a pathological mental condition. Insults like "idiot" are rude, when the target is indeed a retard. They need sympathy and not more anger. -- Madhu
From: Christophe Rhodes on 8 Jan 2010 06:44 Ron Garret <rNOSPAMon(a)flownet.com> writes: > In article <87wrzt3akf.fsf(a)cantab.net>, > Christophe Rhodes <csr21(a)cantab.net> wrote: > >> Ron Garret <rNOSPAMon(a)flownet.com> writes: >> >> > On the other hand, Lisp has a strong cultural bias against creating >> > *new* abstractions, preferring instead to pun mainly on cons cells. >> >> This is not representative of the Lisp culture that I think of myself as >> a part of. > > I'm not saying everyone subscribes to this, but many (I would go so far > as to say an overwhelming majority) do. Many who are within the "Lisp culture"? Or an overwhelming majority of those whose only experience with Lisp is a one-term course in a CS degree? For what it's worth, the collection of anecdotes that make up my personal experience is diametrically opposed to the view that you hold: no Lisper that I know, whose code I work with, whose stories I hear, prefers mainly to pun on cons cells rather than creating new abstractions. > Lisp pedagogy certainly leans heavily in this direction. Is there > even one Lisp book out there that doesn't introduce ALists and/or > PLists early on and saves CLOS as an "advanced topic"? Keene, S. (1989) Object-Oriented Programming in Common Lisp Kizcales, G. et al. (1991) The Art of the Metaobject Protocol Levine, N. (forthcoming) Lisp Outside the Box >> SEQUENCE is not just the union of lists and vectors. > > Really? How do you make a sequence that isn't either a list or a vector? By calling an appropriate constructor, either user-defined or provided by your implementation. For one approach, see the work I presented at ILC'07: "User-extensible sequences in Common Lisp". But the point is that the CL standard explicitly says that LIST and VECTOR do not necessarily form an exhaustive partition of SEQUENCE. Christophe
From: Nicolas Neuss on 8 Jan 2010 07:12
Ron Garret <rNOSPAMon(a)flownet.com> writes: > This is not really Peter's fault, by the way. Lisp pedagogy is > hobbled by the fact that Common Lisp has built-in support for > particular implementations of associative maps, but not for abstract > associative maps. This, BTW, is consistent with another point of view > that has a significant constituency within the Lisp community, to wit, > that CL is a language for experts and the fact that it does not cater > to beginners is a feature, not a bug. I would be interested in who is claiming such a thing. Quite the opposite, I think that most of us think 1. CL is a language for everyone with good taste. 2. It does cater to beginners at least as much as the very popular languages C or Java, and surely much more than C++. (Also the difference in accessibility to Scheme or Python is not large, IMO.) 3. Where it does not, there are either important reasons, or you can easily adapt it to your needs. Nicolas |