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: Zach Beane on 1 Mar 2010 13:46 ccc31807 <cartercc(a)gmail.com> writes: > On Mar 1, 12:14 pm, Ron Garret <rNOSPA...(a)flownet.com> wrote: >> It detects valid email addresses. > > Which is over-kill for a common problem. > > Personally, I use something like /[\w.-]+@[\w]+\.[\w]{2,4}/ > which matches as follows: > - at least one alphanumeric character, dot, or dash > - exactly one "@" > - at least one alphanumeric character > - exactly one "." > - from two to four alphanumeric characters > and fits into the category of "good enough" This is a terrible pattern for email addresses. What would you do if you found a false negative or false positive? Would you patch it up to be good enough again (until the next problem), or would you try to get it right? Zach
From: Tamas K Papp on 1 Mar 2010 13:21 On Mon, 01 Mar 2010 19:03:24 +0100, Giovanni Gigante wrote: >> Which one would you rather try to debug? > > > None!!! > > Anyway, I don't understand what you're trying to prove. It is certainly > possible to write a regexp compiler that transform some kind of wordy > array-and-hashrefs perl structure into a regexp, but the fact that no > one uses such a tool (and not just in Perl) seem to indicate that the > traditional form of the unix regexp, which perl extends, is probably a > good compromise for most of the cases [1]. The RFC-822 case certainly is > not a typical example. > > But if the real point is that regexp are "Not Lispy Enough", then of > course I wholeheartedly agree. :-) I don't think that the issue is wordyness or lispyness. I would assume that when you can represent regexes as S-expressions, it is easier to construct them using functions (and maybe macros). So my answer to "which one would you rather try to debug": I would prefer to debug a program which constructs monster regexps in a clear, structured way, abstracting away the repetitive patterns. Of course one may construct regexps using their "standard" string representation, but I would imagine that is rather cumbersome, so I don't expect that it is done frequently (if at all). Tamas
From: Thomas A. Russ on 1 Mar 2010 12:08 ccc31807 <cartercc(a)gmail.com> writes: > On Feb 25, 9:31��am, Zach Beane <x...(a)xach.com> wrote: > > > You accumulated state in your system that interfered with its normal > > operation, and you fixed it by restarting from a clean state. .... > > Yeah, it took me about three microseconds to figure this out. That's > not the answer, and it's certainly not the question, but at least I > learned that this is a problem you can have, which isn't a problem in > my normal working environments. Well, that's because the lisp environment, particularly with the slime+emacs setup that you have works fundamentally differently than other programming environments that you may be used to from, say, Java or C/C++. In the Java/C world, each time you run the program, you are essentially starting up with a completely new state. In Common Lisp, you are engaged in a continual interaction with the system. That system stores state, and that state can then affect future computations. That state, however, is also why you can do incremental development and testing of parts of your program. Since you don't start all over from scratch, you can load parts of a program, do some testing, add some additional parts and continue to use what you have already loaded. It's just that sometimes, particularly during development, you can end up with things in your environment that you don't necessarily want. If really weird things start happening, then saving your work and killing the lisp environment may be the most useful way to proceed. -- Thomas A. Russ, USC/Information Sciences Institute
From: Ron Garret on 1 Mar 2010 14:17 In article <4b8c016f$0$1129$4fafbaef(a)reader3.news.tin.it>, Giovanni Gigante <giov(a)cidoc.iuav.it> wrote: > > Which one would you rather try to debug? > > > None!!! > > Anyway, I don't understand what you're trying to prove. I'm not trying to prove anything. I'm just trying to explain why I don't like Perl. And it's not really regexps per se, it's the general syntactic and semantic ugliness of it. It's not just regexps that are write-only, it's the whole freakin' language. The syntax of the language is perversely complex. It consists of almost nothing but random rules that have no rhyme, reason or regularity to them. Different letters and punctuation marks have different semantic relevance depending on the context. For example the following three lines: print a/b/c; print q/r/s; print x/y/z; do three completely different things, none of which involve computing a quotient. And this is just a single example of a long, long, long list of syntactic and semantic insanity. The worst part is that the design of Perl makes it nearly impossible to figure out what a piece of code does unless you're already intimately familiar with the language. Consider the above three lines of code, and suppose you didn't know what they did. How would you find out? What would you look up? rg
From: Pascal Costanza on 1 Mar 2010 14:44
On 01/03/2010 18:44, Slobodan Blazeski wrote: > On Feb 25, 7:47 pm, piscesboy<oraclmas...(a)gmail.com> wrote: >> On Feb 25, 11:45 am, ccc31807<carte...(a)gmail.com> wrote: >> >> >> >>> On Feb 25, 11:34 am, Zach Beane<x...(a)xach.com> wrote: >> >>>>> I make my living as a Perl programmer, munging data. Perl doesn't have >>>>> an interactive environment like the Lisp REPL. However, the cycle of >>>>> writing, testing, and running code is almost identical. >> >>>> Not in my experience. >> >>> Maybe that's a function of working habits rather than languages or >>> programming environments. I have developed a habit of write-switch- >>> run, and this is true with Perl, C, Java, and Lisp (although Java is >>> different in that I customarily write test cases for classes before I >>> write the class so I am not strictly running the code directly.) >> >>>> I sometimes see Perl environments corrupted by unexpected PATH or >>>> PERLLIB environment variables, leading to running an unexpected version >>>> of Perl or an unexpected version of a module. >> >>> I have been fortunate to control every machine that I have developed >>> on, so I've never had this particular problem, but with Java, yes, you >>> have to fiddle with the environment, e.g., CLASSPATH. >> >>> CC. >> >> Tangentially on the OP, >> >> Since I am learning Lisp and CLOS in particular, what would be the >> best, most direct route to doing so? The least painful method? Also >> the cheapest method? One that doesn't involve enrolling in school or >> taking classes? >> >> There's lots of resources out there in the form of online tutorials, >> code examples, etc for learning CLOS syntax, etc, but is there some >> simple resource available that conveniently catalogs functions and >> classes, their parameters, their uses, which packages they belong to >> etc...? >> >> I've been programming in Lisp for several months now, in depth, and I >> still have a hard time tracking down function names, class names, >> etc...through apropos, describe, and the various other documentation >> functions built into the REPL (I currently have clisp and ccl >> installed along with SLIME), and it is a real pain to track down >> functions that often have incomplete or sparse documentation if it >> exists. >> >> Often, it is through simple trial and error that I find functions for >> which I spent the last few hair pulling days that already exist in the >> existing Lisp packages, negating a lot of my work moot. It would be >> nice if the documenation and usage of all functions and classes in the >> standard user package and CLOS were documented mainly so I don't waste >> time writing something that already exists in a package. >> >> Forgive me if this is already the case, and if it is then point me in >> that direction. > > Nick Levine Fundamentals of CLOS is a good tutorial > http://www.ravenbrook.com/doc/2003/07/15/clos-fundamentals/ but you > won't need much CLOS anyway. Unless your name is Pascal Constanza of > course. It's Costanza, not Constanza. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ |