another frustrating learner question, CLOS
in [Lisp]
|
Prev: Anybody mind to translate this Felleisen quote from German to English
Next: Macros and anonymous functions
From: Mario S. Mommer on 3 Mar 2010 12:00 Tim Bradshaw <tfb(a)tfeb.org> writes: > On 2010-03-02 14:34:56 +0000, Giovanni Gigante said: >> Btw, I've never understood the traditional "Larry is a linguist" >> argument. I think that ambiguities are a source of richness and fun >> in human language, but not in computer ones (for most definitions of >> "fun"). > > I wasn't actually thinking about that. What I meant was that > mastering a natural language requires people to deal with all sorts of > weird idiosyncratic rules and guidelines because natural languages are > like that. And it turns out that human beings are *really good* at > this, which isn't surprising of course, because natural languages are, > well, natural. > > But somehow, for some people, any programming language which allows > some of the variation you see in natural languages is not acceptable. > Except it's more complicated than that, since basically all > programming languages allow this kind of variation (Common Lisp being > a fine example of this). I think the truth is that people will use > this kind of syntactic variation as a way to be rude about a language > that they have already decided they do not like, for whatever reason. I think you are trivializing the issue. Syntax is a vehicle for representing information, and a baroque language just offers more opportunities for misunderstanding (from both sides), and also presents a steeper learning curve. > It's just syntax people, get over it. Well, consider APL, then. Even those who like APL warn about it's write-only properties. Without additional care (i.e. investing additional resources) you run the risk of writing code that is be difficult to understand later (and then costs you a lot more resources). Just syntax, you know? A more reasonable syntax costs you less upfront, and presents a smaller risk. That, IIUC, is the argument against perl, and against linguistic irrelgularites like those that also plage C++, btw. You pay for all those iregularities and quirks, and obtain less than nothing in return. What's the point?
From: Pillsy on 3 Mar 2010 12:03 On Mar 3, 11:26 am, Ron Garret <rNOSPA...(a)flownet.com> wrote: > In article <hml542$4m...(a)news.eternal-september.org>, > refun <re...(a)nospam.gmx.com> wrote: [...] > > The standard allows implementing FORMATTER as a simple FORMAT call, so it's > > not reliable to do this in all implementations, but those that implement a > > real FORMATTER allow you to get useful information about the workings of > > format strings. > There are other ways to lose as well. For example if your > implementation compiles everything: What does your CL compiling everything have to do with whether MACROEXPAND works, or the FORMATTER macro expands into something other than a straight FORMAT call? > Welcome to Clozure Common Lisp Version 1.5-dev-r13442M-trunk > (DarwinX8664)! > ? (formatter "~A") > #<Anonymous Function #x3020014AC60F> > ? (function-lambda-expression *) > NIL > NIL > NIL > ?
From: Pillsy on 3 Mar 2010 12:10 On Mar 3, 3:03 am, refun <re...(a)nospam.gmx.com> wrote: > In article <rNOSPAMon-5BA109.08521402032...(a)news.albasani.net>, > rNOSPA...(a)flownet.com says... > > I have already conceded that Common Lisp sucks. But even Common Lisp is > > less sucky than other languages in this regard because it is always > > possible to use READ-FROM-STRING, GET-MACRO-CHARACTER, and MACROEXPAND > > to get an explanation of what is going on in terms of something that you > > can type into a search engine or do a meta-point on. (Except format > > strings of course. Format strings are irredeemably sucky.) > Actually, format strings can be as transparent/lispy as normal macros and > reader macros in implementations that support compiled format strings (SBCL is > one example). The same is true of regexes. CL-PPCRE has a function that will parse a regex into a nice, sexp-based form, and allows you to write regexes in that format as well. It has some other advantages, as well---for instance, it's a much less error-prone way of programmatically generating regexes, for much the same reason that Lisp macros are a win over straight text substitution. Cheers, Pillsy
From: Ron Garret on 3 Mar 2010 12:13 In article <5981237a-3762-417f-8295-f358e1326f48(a)t23g2000yqt.googlegroups.com>, Pillsy <pillsbury(a)gmail.com> wrote: > On Mar 3, 11:26 am, Ron Garret <rNOSPA...(a)flownet.com> wrote: > > In article <hml542$4m...(a)news.eternal-september.org>, > > refun <re...(a)nospam.gmx.com> wrote: > [...] > > > The standard allows implementing FORMATTER as a simple FORMAT call, so > > > it's > > > not reliable to do this in all implementations, but those that implement > > > a > > > real FORMATTER allow you to get useful information about the workings of > > > format strings. > > > There are other ways to lose as well. For example if your > > implementation compiles everything: > > What does your CL compiling everything have to do with whether > MACROEXPAND works, or the FORMATTER macro expands into something other > than a straight FORMAT call? Sorry, brain wedgie. ? (macroexpand '(formatter "~{~A~}")) #'(LAMBDA (CCL::S &REST CCL::ARGS) (CCL::DO-SUB-FORMAT-0 CCL::S "~{~A~}" CCL::ARGS)) T CCL::DO-SUB-FORMAT-0 is a function, not a macro. rg
From: Thomas A. Russ on 3 Mar 2010 12:27
Ron Garret <rNOSPAMon(a)flownet.com> writes: > > There are other ways to lose as well. For example if your > implementation compiles everything: > > Welcome to Clozure Common Lisp Version 1.5-dev-r13442M-trunk > (DarwinX8664)! > ? (formatter "~A") > #<Anonymous Function #x3020014AC60F> > ? (function-lambda-expression *) > NIL > NIL > NIL > ? Of course one can manage to still win with (setq ccl:*save-definitions* t) first. But that still doesn't guarantee that the code produced by FORMATTER is all that illuminating: ? (setq ccl:*save-definitions* t) T ? (formatter "~A") #<Anonymous Function #x8B721C6> ? (function-lambda-expression *) (LAMBDA (CCL::S &REST CCL::ARGS) (CCL::DO-SUB-FORMAT-0 CCL::S "~A" CCL::ARGS)) NIL NIL -- Thomas A. Russ, USC/Information Sciences Institute |