From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!134.222.94.5!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: newline and concatenate. length of a lisp function. References: <6b4aa54a.0107250550.4f81dec6@posting.google.com> <3205061214248143@naggum.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3205086696355384@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jul 2001 21:51:37 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 996097897 193.71.66.49 (Wed, 25 Jul 2001 23:51:37 MET DST) NNTP-Posting-Date: Wed, 25 Jul 2001 23:51:37 MET DST Xref: archiver1.google.com comp.lang.lisp:13541 * "Coby Beck" > While admittedly I don't quite know *everything* (but plan to by 2002).... > > I can not for the life of me imagine _any_ good reason to have one function > of such length! Or any class of problem that would require that.... Come back when you have tried to figure out how best to parse SGML and XML. Since you have not been very kind to me, let me assure that you _need_ to know thees things and should not consider the pain you suffer to be a good indication to stop. So go be good at XML! :) Essentially, state machines are best implemented in huge tagbody's. Trying to break them up into little "modular" pieces causes much more code and much less efficiency. Also, each state, labeled by a tag, _is_ a little module, but the way it has been expressed is different from the function-level modularization that is hailed as universally better by people who lack experience from real life. #:Erik -- There is nothing in this message that under normal circumstances should cause Barry Margolin to announce his moral superiority over others, but one never knows how he needs to behave to maintain his belief in it.