Subject: Re: I don't understand Lisp From: Erik Naggum <firstname.lastname@example.org> Date: 1998/09/21 Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * Kent M Pitman <firstname.lastname@example.org> | I'm gonna side with Donald on this one. The absence of regular | expressions is a shame. a _shame_? I don't consider regular expressions _that_ much of a must. (I installed them in ACL 4.3, and it comes builtin with ACL 5.0, but I haven't had occasion to use it, quite unlike in Emacs Lisp, where I have to, and don't like the absence of everything that makes me have to.) on the contrary, since their presence seem to supplant better solutions, like parsers that convert strings into data structures you can work with more intelligently, I find them akin to the mythological sirens whose luring songs called ships into dangerous waters. | I think the absence of them in CL is mostly an accident of history | because of when CL was coming together, not a willful rejection of a good | idea. Regexps hadn't caught on clearly enough by 1988 when we froze the | standard for there to be implementations which were sporting them. would it be a workable solution if the vendors cooperated on the functional interface today? it doesn't appear to be for lack of fast and good implementations, at least not as far as strings are concerned. | I do also sometimes wish for the LispM's string-search-set and | string-search-not-set. hm. I found a veritable plethora of string functions in the Genera 7.2 manual set (which Michael Cracauer kindly sent me some time ago), most of them seeming to _scream_ for far more general solutions (not counting regexps as such a solution). it occurs to me that SEARCH should be sufficient with some moderately simple functions, as in (search (set <member>...) <string> :test #'in-set-p) where SET and IN-SET-P could cooperate on optimizing performance, perhaps even at compile time. I just don't want to limit this to strings, only. likewise, regular expressions that worked on sequences of all kinds with any type of contents would be _much_ more attractive to me. regular expressions on strings is just that: a special case for _strings_, and the pattern matching languages involved should be far more generally applicable, in my opinion. it seems "un-Lispy" to me to make something work only for strings when there is wider applicability. #:Erik -- ATTENTION, all abducting aliens! you DON'T need to RETURN them!