From ... From: Erik Naggum Subject: Re: Better Dylan syntax? Date: 1997/09/07 Message-ID: <3082654357249434@naggum.no>#1/1 X-Deja-AN: 270549846 References: <862035xpyn.fsf@g.pet.cam.ac.uk> <5unec0$j8j@tools.bbnplanet.com> <86wwkvn5ol.fsf@g.pet.cam.ac.uk> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.dylan,comp.lang.lisp * Paul Prescod | It's a little redundant to write a parser anyhow. Maybe it would be | better if the compiler's parser were provided as a library that you could | use from your favourite macro language. This is, for example, how people | typically work with SGML -- through an API or pre-parsed "pablum" | form. It seems to work, but people still complain that parsing SGML is | too hard so obviously they want to write their own parsers for whatever | reason (habit?). there is no agreement on what an SGML document "means", and widely varying ideas about what should and should not be _unavailable_ after the parsing has completed. this means people _will_ want to handle the raw text form of SGML as opposed to some arbitrarily chosen non-textual form. there is some consensus in the SGML community that two SGML documents are the same only if their textual forms are bitwise identical. there are many attempts to use _comments_ for various half-witted purposes, and comments are typically ignored in the parsed forms. etc. had SGML defined a "read syntax" and talked about objects at a post-parse level, SGML would have been a lot more interesting. in SGML today, every whitespace is sacred, every inferred delimiter must be marked as not present in the text, etc. you just can't handle this mess intelligently by defining a _single_ "API", and you will always find people who are smarter than the last guy who defined a "complete API". it's sad, really. #\Erik -- 404 You're better off without that file. Trust me.