From ... From: Erik Naggum Subject: Re: I don't understand Lisp Date: 1998/09/24 Message-ID: <3115659533092322@naggum.no>#1/1 X-Deja-AN: 394506786 References: <35fb182d.86050524@news.newsguy.com> <3115018001706846@naggu m.no> <1998Sep18.123342.10768@srs.gov> <36063374.1EEF2B1C@bt-sys.spamblock.bt.co.uk> <3115371273457872@naggum.no> <3607F45F.B3199A6C@bt-sys.spamblock.bt.co.uk> <3115539566299174@naggum.no> <36093818.F32DDB3@bt-sys.spamblock.bt.co.uk> <3115568738543631@naggum.no> <86iuiec5c6.fsf@coulee.tdb.com> <3115618937722449@naggum.no> <86iuidjywp.fsf@coulee.tdb.com> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * Russell Senior | The applications I am finding for this tend to use the same delimiter | throughout the parent sequence. ... Since in my primary application 50 | or 100 or more subsequences might be returned, using that type of calling | interface was going to be impractical for me. this is quite interesting. I used it to hack apart ISO 8601 date and time specifications (later writing a much more general parser for that purpose), the "standard" Unix colon-separated lines, etc, where there were obvious binding requirements for the return values, and fairly short and simple argument lists. different needs produce different interfaces, meaning it's going to be exceedingly hard to get the interface right. this, too, could explain why what appears to be simple operations become less simple in Lisp because the _general_ case is bigger in Lisp than in other languages/tools. | On the return, I am less well-educated about the relative merits of | multiple-value returns compared to list of values, so I chose the one I | was more familiar with. I tend to use multiple values when I expect a list to be hacked apart as soon as it is returned, and even more so when one value is more important than the others, and thus more likely to be used by itself. | Hmm. I think your delete idea is an interesting solution that I hadn't | considered, but this specific suggestion would violate the sequence | abstraction in that the function would then only work on strings. good point, but then we should be specializing on lists, too, since they have fairly different performance profiles from vectors/strings... | Perhaps (= (length subsequence) 0) would be a more general and workable | predicate. that would be the same as (eq start end) before extracting the subseq, and EQ is OK since we deal with fixnums. the COLLECT clause could then be unless (and compact (eq start end)) do (push (subseq string start end) substrings) this would be an inexpensive test. | Anyway, I want to thank you for posting your function. you're welcome. I hadn't expected this reception, to be honest. perhaps there is hope for sharing Lisp code, after all. :) #:Erik