Subject: Re: Q: parsing strings From: Erik Naggum <firstname.lastname@example.org> Date: 2000/10/10 Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * Dirk Zoller <firstname.lastname@example.org> | Well, probably due to my lack of experience with Lisp, I don't see | any problems. I'd say, what I've posted earlier are the beginnings | of a nice solution. You responded "why so ambitious" to someone's argument that you can't do it all. If you have the beginnings, where is it going, if you don't want others to be so ambitious? | The only drawback is that the Lisp code to fiddle around with each | character of both format string and input string is probably pretty | inefficient (unless heavily pumped up with type declarations). | Therefore this should be in the System implementation, were it could | be done in C or whatever chosen by the system maker. Wrong conclusion. Therefore the Common Lisp implementation should be improved to the point where such things are fast enough to be written in a good language. In practice, they are. Doing parsing in C is insane. C is unsuited to process textual input. (One might also argue that Common Lisp is unsuited to process binary input.) Perl is the answer to the needs of the C programmers. And if this doesn't scare you, you're too much of a cynic for your own good. | The C-programmer (although she could) typically doesn't write her | own scanf(), so why should the Lisp programmer? Both the amount of | work and the benefits seem similar to me in both worlds. One | provides such a solution, the other doesn't. Strange. I wasn't aware that C programmers were female¹, but C programmers don't write their own necessary tools because they have something that almost fits the bill, for a relaxed understanding of "fits", and so they never quite get it right, especially when the discover that to get it entirely right requires massive support from tools not at their disposal. Hence the gargantuan libraris of C++ and Java, which both do a much better approximation to "fit" than C ever could hope for, except they are also _massively_ expensive to learn to use well and very cumbersome and verbose in practice to boot. Incidentally, tools such as yacc and lex are very good, but they are much, much slower than anyone who contemplates using them could even conceive that they would be. It's C, so it must be fast, right? Well, they're C allright, and _therefore_ slow, because C doesn't have the necessary machinery to process textual input efficiently, so those who wanted it made half-assed attempts and were satisfied with them prematurely, like the immigrants who stop improving their English as soon as they are no longer actively bothered by repeating themselves to those who don't understand him, or find others who can understand their inferior language skills and pronunciation. I find that Lisp's very nature makes writing parsers easy and very straight-forward. Much easier than doing them in C with all sorts of inferior tools that don't quite cut it. Like scanf, regexps, ... #:Erik ------- ¹ I am, however, aware of the silly, annoying trend among some people who don't appreciate the history of the English language to think that "he" and "man" refers to the _male_. They don't. The male in English doesn't have his own pronouns and sex²-specific terms the way the female does. And so now you want to take everything away from the males? To what end is this productive and constructive? ² Yes, it's "sex", not "gender", too. -- If this is not what you expected, please alter your expectations.