What is the best way to process this list
in [Lisp]
|
From: Ron Garret on 7 Jan 2010 14:11 In article <m3aawp7s18.fsf(a)moon.robolove.meer.net>, Madhu <enometh(a)meer.net> wrote: > * mdj <4e7b1ccf-3154-4ffa-b855-a4ce05aaa647(a)22g2000yqr.googlegroups.com> : > Wrote on Thu, 7 Jan 2010 06:43:38 -0800 (PST): > > | On Jan 8, 12:29 am, Madhu <enom...(a)meer.net> wrote: > |> * mdj <369f86a8-5b3f-47b3-83c1-93756be22...(a)r5g2000yqb.googlegroups.com> : > |> Wrote on Thu, 7 Jan 2010 06:21:01 -0800 (PST): > |> > |> | On Jan 7, 11:50 pm, Madhu <enom...(a)meer.net> wrote: > |> | > |> |> Where did I "lapse into `Indian pigeon English'" ? Can you > |> |> provide a citation? > |> | > |> | On Jan 7, 3:32 pm, Madhu <enom...(a)meer.net> wrote: > |> | > |> |> Again you fell for the Ron's trick. Last time it was on the > |> |> meaning of "interesting". Now it is on the meaning of "Layout". > |> > |> And what is the flaw here? maybe you can read "based on" for "on" > | > | "the Ron's" > > Indeed. Sorry, I should've capitilized the `The' > > pls read: ``Again you fell for The Ron's trick.' It's spelled "Da bomb". rg
From: Christophe Rhodes on 7 Jan 2010 15:49 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. > DEFSTRUCT and DEFCLASS are the *only* two constructs in CL that let you > do this, by the way. Don't forget DEFINE-CONDITION. > But there is another way of thinking about the types defined by > DEFSTRUCT, and that is not as an associative map, but rather a set of > symbolic labels layered on top of a SEQUENCE (which is also not a real > type in CL, but rather just the union of lists and vectors). SEQUENCE is not just the union of lists and vectors. > DEFSTRUCT explicitly supports [this] view with its TYPE option. When > you define a new structure type with a TYPE argument, you *force* > DEFSTRUCT to behave in this low-level way. But of course you don't then get the "high-level" type-definition behaviour; if you don't use the :type argument, you do. So... > It is therefore not unreasonable to suppose that the designers > intention was that thinking about structures defined by defstruct as > associative maps is simply wrong, that defstruct is unambiguously a > low-level construct (notwithstanding its flirtation with the > high-level concept of defining new types), and that the above example > should be expected to return 2. ....it might not be unreasonable, but I don't think it would be unreasonable to suppose the opposite, either. > The reason that (foo-c >>foo) returns an error has nothing to do with > any of this, it has to do with the fact that length-checking of > sequences is built in to Lisp's fundamental low-level data model. It > has nothing do with which view of DEFSTRUCT one chooses to subscribe to. I don't think this is true either, even given your assumptions: if Lisp's fundamental low-level data model is of conses, then the operators which act on conses (e.g. nth, nthcdr) are not required to check the length of their argument: only that they are not acting on arguments of the wrong type. So for DEFSTRUCT-as-abstraction-over-conses, Thomas' (foo-c >>foo) would return NIL; for DEFSTRUCT-as-abstraction-over-1d-array, it would have completely unspecified behaviour -- at least, I couldn't find any requirement anywhere that specifically array operators are required to do any bounds checking at all. It is only if you assume DEFSTRUCT-as-abstraction-over-sequence, and specifically SEQUENCE independently of which concrete representation the implementation is choosing to use, that you would expect an unconditional error for (foo-c >>foo) Christophe
From: Ron Garret on 7 Jan 2010 16:48 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. > > DEFSTRUCT and DEFCLASS are the *only* two constructs in CL that let you > > do this, by the way. > > Don't forget DEFINE-CONDITION. Oh, right. I usually think of that as a thin layer on top of defclass, but I guess it doesn't have to be (and in SBCL it actually isn't). > > But there is another way of thinking about the types defined by > > DEFSTRUCT, and that is not as an associative map, but rather a set of > > symbolic labels layered on top of a SEQUENCE (which is also not a real > > type in CL, but rather just the union of lists and vectors). > > 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? > > DEFSTRUCT explicitly supports [this] view with its TYPE option. When > > you define a new structure type with a TYPE argument, you *force* > > DEFSTRUCT to behave in this low-level way. > > But of course you don't then get the "high-level" type-definition > behaviour; if you don't use the :type argument, you do. So... Like I said, there are two ways to look at DEFSTRUCT without a TYPE argument. One is as a thin layer on top of essentially the same functionality as is provided *with* a TYPE argument, and the other is as a completely different thing altogether operating at a different level of abstraction. A reasonable person could subscribe to either view. > > It is therefore not unreasonable to suppose that the designers > > intention was that thinking about structures defined by defstruct as > > associative maps is simply wrong, that defstruct is unambiguously a > > low-level construct (notwithstanding its flirtation with the > > high-level concept of defining new types), and that the above example > > should be expected to return 2. > > ...it might not be unreasonable, but I don't think it would be > unreasonable to suppose the opposite, either. Of course. > > The reason that (foo-c >>foo) returns an error has nothing to do with > > any of this, it has to do with the fact that length-checking of > > sequences is built in to Lisp's fundamental low-level data model. It > > has nothing do with which view of DEFSTRUCT one chooses to subscribe to. > > I don't think this is true either, even given your assumptions: if > Lisp's fundamental low-level data model is of conses, then the operators > which act on conses (e.g. nth, nthcdr) are not required to check the > length of their argument: only that they are not acting on arguments of > the wrong type. So for DEFSTRUCT-as-abstraction-over-conses, Thomas' > (foo-c >>foo) would return NIL; for > DEFSTRUCT-as-abstraction-over-1d-array, it would have completely > unspecified behaviour -- at least, I couldn't find any requirement > anywhere that specifically array operators are required to do any bounds > checking at all. It is only if you assume > DEFSTRUCT-as-abstraction-over-sequence, and specifically SEQUENCE > independently of which concrete representation the implementation is > choosing to use, that you would expect an unconditional error for > (foo-c >>foo) Yes, that's right. (foo-c >>foo) could reasonably return NIL. rg
From: Raffael Cavallaro on 7 Jan 2010 18:13 On 2010-01-07 16:48:21 -0500, Ron Garret <rNOSPAMon(a)flownet.com> said: > I'm not saying everyone subscribes to this, but many (I would go so far > as to say an overwhelming majority) do. I think this depends to a large extent on how one came to lisp, and how long ago one came to lisp. For example, I came to common lisp by way of Dylan. As a result, CLOS was one of the very first things about common lisp that I learned precisely because Dylan is a dialect of lisp where the clos-like object system permeates the entire langauge as part of the core design. OTOH, if one came to lisp in the 70s or 80s, then one would be much more comfortable with the ULFE way. (i.e., Use Lists For Everything). I had only a passing acquaintance with lisp in the 70s, so I was not indoctrinated, as it were, in ULFE culture. > Lisp pedagogy certainly leans > heavily in this direction. This is certainly true of many authors (Paul Graham for example), and it's something that I always found frustrating about the existing texts. Indeed, the one text I'm aware of that explictly represents itself as being object oriented, Stephen Slade's _Object-Oriented Common Lisp_, doesn't get to generic functions until more than 400 pages into the book, and doesn't begin to cover CLOS proper until almost 500 pages in! FWIW, I avoid using lists as a data structure. When not using CLOS (often because existing interfaces require one to do so), I've almost always used arrays (for speed of access to large data sets) or hash-tables, not lists. And I pretty much always ended up reworking the home-brew hash-table solution to a clos one. Now, recognizing that I'm likely to end up there anyway, I just start with a clos-based model. -- Raffael Cavallaro
From: Pillsy on 7 Jan 2010 19:24
On Jan 7, 4:48 pm, Ron Garret <rNOSPA...(a)flownet.com> wrote: > In article <87wrzt3akf....(a)cantab.net>, > Christophe Rhodes <cs...(a)cantab.net> wrote: [...] > > 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"? /Practical Common Lisp/ introduces alists and plists the chapter before CLOS, and several chapters after hash tables. Also, unlike some of the other books I've read on CL (like Norvig's), once CLOS shows up it's used pretty pervasively. These days, I'm betting /PCL/ introduces a lot of people to Lisp. It was my first encounter with the language outside extremely rudimentary Emacs stuff. Cheers, Pillsy [...] |