Subject: Re: Q: parsing strings
From: Erik Naggum <>
Date: 2000/10/10
Newsgroups: comp.lang.lisp
Message-ID: <>

* Dirk Zoller <>
| 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, ...

¹ 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.