Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

is Lisp used in text parsing and processing tasks?

47 views
Skip to first unread message

Tuomas P

unread,
Nov 12, 2002, 3:53:27 PM11/12/02
to
Hi!

Is Lisp being used in programs that do text processing of various
kind, such as parsing and manipulating an HTML file, parsing C code
(and reindenting it), etc.? Would Lisp be a good to choice if one is
to write such software?

Best wishes,
Tuomas
tuo...@yahoo.com

Barry Margolin

unread,
Nov 12, 2002, 3:56:01 PM11/12/02
to
In article <994828d9.02111...@posting.google.com>,

Tuomas P <tuo...@yahoo.com> wrote:
>Is Lisp being used in programs that do text processing of various
>kind, such as parsing and manipulating an HTML file, parsing C code
>(and reindenting it), etc.? Would Lisp be a good to choice if one is
>to write such software?

The indenting code in Emacs is all written in Lisp. There's also a web
browser integrated into Emacs, so it does HTML parsing in Lisp.

--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Dave Bakhash

unread,
Nov 12, 2002, 7:19:20 PM11/12/02
to
tuo...@yahoo.com (Tuomas P) writes:

> Is Lisp being used in programs that do text processing of various
> kind, such as parsing and manipulating an HTML file, parsing C code
> (and reindenting it), etc.? Would Lisp be a good to choice if one is
> to write such software?

As far as parsing the various formats out there, I don't think that CL
is necessarily stronger or weaker than other languages. It sometimes
helps to have built-in regular expressions, which CL doesn't have, but
which some vendors and implementations support. Even so, the Lisp
regexp packages don't tend to be as fast as those in C, and probably not
even as fast as they are in Perl and Python.

In general, I'd say that CL doesn't have the most powerful string
processing, though its list processing functions are very powerful.

Stream operations have also been improved in ACL (based on Simple
Streams), which might indirectly affect overall parsing performance,
though I don't know how much of an overall effect this will have on
parsing in general.

Zebu is an example of a parser generator implemented in CL. Of course,
if what you're parsing is S-expressions, then I doubt there's anything
better than CL, though this is seldom the case, unfortunately.

Other parser-related links can be found at:

http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/nlp/parsing/0.html

dave

Martti Halminen

unread,
Nov 12, 2002, 8:06:23 PM11/12/02
to
Dave Bakhash wrote:
>
> tuo...@yahoo.com (Tuomas P) writes:
>
> > Is Lisp being used in programs that do text processing of various
> > kind, such as parsing and manipulating an HTML file, parsing C code
> > (and reindenting it), etc.? Would Lisp be a good to choice if one is
> > to write such software?
<snip>

> Zebu is an example of a parser generator implemented in CL. Of course,
> if what you're parsing is S-expressions, then I doubt there's anything
> better than CL, though this is seldom the case, unfortunately.

While pure s-expressions aren't that common, many file formats are still
readable with CL READ and relatives with a little massaging
(filter out/replace some characters like #:,'`).
I once wrote a parser in CL for IFC (uses ISO 10303-21 format), which
clearly outperformed the previous implementation based on lex/yacc.

--

Matthew Danish

unread,
Nov 13, 2002, 2:38:32 AM11/13/02
to
On Tue, Nov 12, 2002 at 07:19:20PM -0500, Dave Bakhash wrote:
> tuo...@yahoo.com (Tuomas P) writes:
>
> > Is Lisp being used in programs that do text processing of various
> > kind, such as parsing and manipulating an HTML file, parsing C code
> > (and reindenting it), etc.? Would Lisp be a good to choice if one is
> > to write such software?
>
> As far as parsing the various formats out there, I don't think that CL
> is necessarily stronger or weaker than other languages. It sometimes
> helps to have built-in regular expressions, which CL doesn't have, but
> which some vendors and implementations support. Even so, the Lisp
> regexp packages don't tend to be as fast as those in C, and probably not
> even as fast as they are in Perl and Python.
>

The author of the REGEX package claims 5-20x speed improvement over the
GNU C regular expression library. I haven't verified his claim
personally but I've made available Debian packages (and the ASDF file
which can be used w/o Debian) for CL-REGEX, CL-AWK (CLAWK), and
CL-LEXER. See <http://www.mapcar.org/~mrd/debs/unstable/>, and the
author's homepage at <http://www.geocities.com/mparker762/clawk.html>.

--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

Andreas Hinze

unread,
Nov 13, 2002, 5:29:30 AM11/13/02
to
Matthew Danish wrote:
>
> The author of the REGEX package claims 5-20x speed improvement over the
> GNU C regular expression library. I haven't verified his claim
> personally but I've made available Debian packages (and the ASDF file
> which can be used w/o Debian) for CL-REGEX, CL-AWK (CLAWK), and
> CL-LEXER. See <http://www.mapcar.org/~mrd/debs/unstable/>, and the
> author's homepage at <http://www.geocities.com/mparker762/clawk.html>.
>
In the last distributions of CLAWK there is a speedtest.c program included.
So anyone who want to do can test the speed advantage of REGEX by himself.
I made these tests some times ago and found that REGEX indeed is much
faster than the linux regex library.

Best
AHz

Matt Curtin

unread,
Nov 13, 2002, 7:29:45 AM11/13/02
to
tuo...@yahoo.com (Tuomas P) writes:

> Is Lisp being used in programs that do text processing of various
> kind, such as parsing and manipulating an HTML file, parsing C code
> (and reindenting it), etc.? Would Lisp be a good to choice if one is
> to write such software?

We use ANSI Common Lisp for this very purpose (among other things)
here. We have several web robots that can parse various formats,
scoring and rating things that it downloads based on certain criteria,
and reporting their findings. To say we have several is actually a
lie; we have one robot engine and various frontends to the engine that
allows us to use basically the same robot code for sometimes very
different purposes.

Whether Lisp is a good choice for the job at hand will depend on your
requirements. If you are writing something that will perform quick
and dirty parsing, Lisp isn't going to offer you significant
advantages over some other languages that are well-suited for text
processing (e.g., Perl). Most Lisp implementations (including the
free CLISP) have a way to use regular expressions, so it isn't as
though Perl and friends will offer significant advantages over Common
Lisp, either. Issues like availability of other libraries that you
could use, portability, maintenance, operational considerations,
speed, etc., will need to be considered.

In our case, Lisp was a very good choice. The ability to patch a
running program without having to stop it is quite nice, and Lisp also
makes it very easy to save state so that the robot can simply pause
for a while during a system reboot...it just loads its memory image
and picks up right where it left off. We have also been able to
introduce new people to the code and have them understand, very
quickly, what is happening, and how they can perform their work on the
code.

(And on that point, let me add that I think that the concern about
difficulty in finding competent Lisp programmers is bunk. I don't
think that finding competent Lispers is inherently more difficult than
finding competent programmers for any other language. Competent
programmers require some looking around, period, irrespective of the
intended target language. The difference is that there aren't a lot
of incompetent "programmers" out there claiming to be able to write
Common Lisp code. End of rant.)

--
Matt Curtin Interhack Corp +1 614 545 HACK http://web.interhack.com/
Author, /Developing Trust: Online Privacy and Security/ (Apress, 2001)
Programming should be fun. Programs should be beautiful. --Paul Graham

Marco Antoniotti

unread,
Nov 13, 2002, 9:55:25 AM11/13/02
to

Martti Halminen <martti....@kolumbus.fi> writes:

...

> While pure s-expressions aren't that common, many file formats are still
> readable with CL READ and relatives with a little massaging
> (filter out/replace some characters like #:,'`).

Exactly. One standard trick on many ASCII based formats (e.g. rows of numbers)
is to just do

(read (format nil "(~A)" (remove-bad-characters line)))

Cheers

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Barry Margolin

unread,
Nov 13, 2002, 10:37:18 AM11/13/02
to
In article <86ptt9d...@rowlf.interhack.net>,

Matt Curtin <cmcu...@interhack.net> wrote:
>(And on that point, let me add that I think that the concern about
>difficulty in finding competent Lisp programmers is bunk. I don't
>think that finding competent Lispers is inherently more difficult than
>finding competent programmers for any other language. Competent
>programmers require some looking around, period, irrespective of the
>intended target language. The difference is that there aren't a lot
>of incompetent "programmers" out there claiming to be able to write
>Common Lisp code. End of rant.)

IMHO, very competent programmers are usually able to adapt to just about
any programming language or environment. They know general programming and
CS concepts, and have used a few different ones so they know the various
paradigms and idioms.

A programmer who can't learn new languages easily, while not necessarily
incompetent, is at best mediocre.

Raymond Wiker

unread,
Nov 13, 2002, 11:37:41 AM11/13/02
to
Barry Margolin <bar...@genuity.net> writes:

> IMHO, very competent programmers are usually able to adapt to just about
> any programming language or environment. They know general programming and
> CS concepts, and have used a few different ones so they know the various
> paradigms and idioms.

I would agree as far as programming languages are concerned,
but _not_ about environments. In particular, I think it should be
allowed to be "incompatible" with Microsoft Visual Studio without
necessarily being incompetent.

--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60

Try FAST Search: http://alltheweb.com/

Kenny Tilton

unread,
Nov 13, 2002, 12:32:12 PM11/13/02
to

Barry Margolin wrote:
> A programmer who can't learn new languages easily, while not necessarily
> incompetent, is at best mediocre.

Absolutely. I watched three people (me included) learn CL after I
adopted it for my little team. No problemo. Mind you, eight years later
I am still learning it, but I was productive almost immediately.

When our CEO worries about finding CLers, I tell him that if someone
cannot learn a new language in a week he does not want them anyway.
Especially since, as a start-up, we cannot afford dozens of developers
(which is probably /never/ a good idea).

He doesn't buy it, but his first business was and is tech recruiting and
he says the search he did for Lisp people produced by far the most
talented crop of applicants he's seen in twenty years of tech recruitng.

So he is happy.

--

kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd

Kenny Tilton

unread,
Nov 13, 2002, 1:08:49 PM11/13/02
to

Matt Curtin wrote:
> The difference is that there aren't a lot
> of incompetent "programmers" out there claiming to be able to write
> Common Lisp code.

Exactly. In fact, sick idea: I'd love to track down the worst programmer
who likes Lisp. Maybe hold an anti-contest. I bet they would not be very
bad. Hmmm, maybe I should look at the Lisp archives.

Then we get to argue over whether Lisp makes us write good code, or
whether only good coders like Lisp.

Kaz Kylheku

unread,
Nov 13, 2002, 1:37:43 PM11/13/02
to
tuo...@yahoo.com (Tuomas P) wrote in message news:<994828d9.02111...@posting.google.com>...

> Hi!
>
> Is Lisp being used in programs that do text processing of various
> kind, such as parsing and manipulating an HTML file, parsing C code
> (and reindenting it), etc.? Would Lisp be a good to choice if one is
> to write such software?

I would argue that there is nothing better. The hard thing in
processing languages is not the lexical analysis, or even the parsing;
these can be done quite easily even in languages like C. Where things
get hard is actually building the parse trees and transforming them;
and this is where Lisp really shines.

To make from-scratch lexing to run fast in Lisp, you will need a good
native compiler, and probably make liberal use of declarations to make
some of the run time type checking go away. In a tight loop that read
and branches on characters, you don't need the machine to be type
checking whether a value is in fact a character or not.

The built in lexical analyzer, called the Lisp reader, can be
customized to some extent; it's good to evaluate whether a given
language can be munged that way.

Barry Margolin

unread,
Nov 13, 2002, 1:53:55 PM11/13/02
to
In article <3DD28CE3...@nyc.rr.com>,

Kenny Tilton <kti...@nyc.rr.com> wrote:
>He doesn't buy it, but his first business was and is tech recruiting and
>he says the search he did for Lisp people produced by far the most
>talented crop of applicants he's seen in twenty years of tech recruitng.

I suspect that knowing more than just the current fad that's taught in the
trade schools is indicative of a more enthusiastic programmer, the type of
people that the term "hacker" used to refer to before it was coopted to
refer to crackers. The fact that someone goes out of their way to learn
and become proficient at relatively obscure languages like Lisp, Smalltalk,
SML, or Prolog suggests that they're likely to be more talented than the
norm. Good computer programming is an art, and this is indicative of the
right mind-set that's needed for excellence (by analogy: a great musician
can probably learn multiple instruments, and play them all decently,
although he may only be a virtuoso on his favorite).

Erik Naggum

unread,
Nov 13, 2002, 2:06:30 PM11/13/02
to
* Barry Margolin

| A programmer who can't learn new languages easily, while not necessarily
| incompetent, is at best mediocre.

Does this apply to other things? Is a furiously fast and accurate typist
on qwerty, if not necessarily incompetent, at best mediocre, if unable to
switch to a dvorak layout? Is an author of great intellectual prowess
and much acclaim, if not necessarily incompetent, at best mediocre, if
unable to switch to a very different language? How trustworthy is a
doctor of law or medicine who can easily change specialty? Would you
take your pet to a veterinarian who boasted that he could learn a new
animal easily?

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Michael Hudson

unread,
Nov 13, 2002, 2:04:40 PM11/13/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Matt Curtin wrote:
> > The difference is that there aren't a lot
> > of incompetent "programmers" out there claiming to be able to write
> > Common Lisp code.
>
> Exactly. In fact, sick idea: I'd love to track down the worst
> programmer who likes Lisp. Maybe hold an anti-contest. I bet they
> would not be very bad. Hmmm, maybe I should look at the Lisp archives.

That's not something I'd thought about. What would _really bad_
Common Lisp look like? You could get good mileage out of tagbody, I
guess, but I don't know what genuinely bad (as opposed to creatively
bad a la ioccc) code would use.

Cheers,
M.

--
Very clever implementation techniques are required to implement this
insanity correctly and usefully, not to mention that code written
with this feature used and abused east and west is exceptionally
exciting to debug. -- Erik Naggum on Algol-style "call-by-name"

Christopher C. Stacy

unread,
Nov 13, 2002, 2:15:49 PM11/13/02
to
>>>>> On Wed, 13 Nov 2002 19:04:40 GMT, Michael Hudson ("Michael") writes:

Michael> Kenny Tilton <kti...@nyc.rr.com> writes:
>> Matt Curtin wrote:
>> > The difference is that there aren't a lot
>> > of incompetent "programmers" out there claiming to be able to write
>> > Common Lisp code.
>>
>> Exactly. In fact, sick idea: I'd love to track down the worst
>> programmer who likes Lisp. Maybe hold an anti-contest. I bet they
>> would not be very bad. Hmmm, maybe I should look at the Lisp archives.

Michael> That's not something I'd thought about. What would _really bad_
Michael> Common Lisp look like? You could get good mileage out of tagbody, I
Michael> guess, but I don't know what genuinely bad (as opposed to creatively
Michael> bad a la ioccc) code would use.

There was a Lisp book out in the 1980s written by a fellow who
didn't know Lisp at all. I can't remember the name of it.

Paul Wallich

unread,
Nov 13, 2002, 2:21:35 PM11/13/02
to
In article <uheelf...@dtpq.com>,

cst...@dtpq.com (Christopher C. Stacy) wrote:

>>>>>> On Wed, 13 Nov 2002 19:04:40 GMT, Michael Hudson ("Michael") writes:
>
> Michael> Kenny Tilton <kti...@nyc.rr.com> writes:
> >> Matt Curtin wrote:
> >> > The difference is that there aren't a lot
> >> > of incompetent "programmers" out there claiming to be able to write
> >> > Common Lisp code.
> >>
> >> Exactly. In fact, sick idea: I'd love to track down the worst
> >> programmer who likes Lisp. Maybe hold an anti-contest. I bet they
> >> would not be very bad. Hmmm, maybe I should look at the Lisp archives.
>
> Michael> That's not something I'd thought about. What would _really bad_
> Michael> Common Lisp look like? You could get good mileage out of tagbody, I
> Michael> guess, but I don't know what genuinely bad (as opposed to creatively
> Michael> bad a la ioccc) code would use.

Tagbody would be one thing, endless use of setq would be another
(although perhaps just a sign of having come from another language
and not trusting Lisp to pass values around the usual way).

paul

Basile STARYNKEVITCH

unread,
Nov 13, 2002, 2:37:31 PM11/13/02
to
>>>>> "Kenny" == Kenny Tilton <kti...@nyc.rr.com> writes:

Kenny> Matt Curtin wrote:
>> The difference is that there aren't a lot of incompetent
>> "programmers" out there claiming to be able to write Common
>> Lisp code.

Kenny> Exactly. In fact, sick idea: I'd love to track down the
Kenny> worst programmer who likes Lisp. Maybe hold an
Kenny> anti-contest. I bet they would not be very bad. Hmmm, maybe
Kenny> I should look at the Lisp archives.

I would suggest that a big Lisp code which uses cons cells (instead of
structures, vectors, objects and hashtables) only might be usually be
bad. This means replacing the constant (and quick) access time of a
field (or an element in a vector) by scanning lists (which is
proportionnal to the list size).

But I don't claim to be a good Common Lisp coder (I seldom code in
Lisp, for many -but not all- tasks, I prefer Ocaml to CommonLisp).

Regards
--

Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
alias: basile<at>tunes<dot>org
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Joe Marshall

unread,
Nov 13, 2002, 2:59:38 PM11/13/02
to
Erik Naggum <er...@naggum.no> writes:

> Would you take your pet to a veterinarian who boasted that he
> could learn a new animal easily?

If there were no vet in the nearby area that specialized in the kind
of pet that I had, then I'd prefer one that felt comfortable with all
animals in the same family or order to one that felt that cats
differed so much from dogs as to be incomprehensible.

Joe Marshall

unread,
Nov 13, 2002, 3:34:45 PM11/13/02
to
Michael Hudson <m...@python.net> writes:

> What would _really bad_ Common Lisp look like?

I saw an example of flavors programming where they created a
`factorial' object. You sent it a `set-argument' message, then a
`compute' message, and finally a `get-result' message. It would
instantiate other instances of itself for the recursion.

> You could get good mileage out of tagbody, I guess, but I don't know
> what genuinely bad (as opposed to creatively bad a la ioccc) code
> would use.

How's this?

(defun p1boole: (x) ;boole transformer. x is a form whose car is boole.
;puts everything in terms of and, ior, xor. I.e. boole 1, 6, or
; 7, or else progn or prog2 for the trivial cases.
(prog (y) ;*** only works if boole has 3 or more args.
(cond ((and (cdr x) (cddr x) (cdddr x)))
(t (barf x "boole with less than 3 args." nonfatal) (go lose)) )
(or (numberp (setq y (cadr x)))
(return x)) ;variable boole - leave it alone
(setq y (assq y '( ;get characteristics of this boole from first arg, which must be fixnum.
(0 con 0)
(1)
(2 ca 1)
(3 spm)
(4 cm 1)
(5 spa)
(6)
(7)
(10 cr 7)
(11 cr 6)
(12 ca 3)
(13 ca 7)
(14 cr 5)
(15 cm 7)
(16 cr 1)
(17 con -1) )))
(and (null y) (barf x "first arg to boole must be a fixnum between 0 and 17" nonfatal) (go lose))
(or (setq y (cdr y))
(return x)) ;if an elementary boole (1, 6, or 7), just leave it.
(cond ((eq (car y) 'cr) ;complement result:
(return (list 'boole
6 ; by xoring with -1
(p1boole (cons 'boole
(cons (cadr y)
(cddr x) )))
-1)))
((eq (car y) 'con) ;result is a constant, so make progn to eval args then return constant value
(return (cons 'progn (append (cddr x) (list (cadr y))) )))
((eq (car y) 'spm) ;result is last arg
(return (cons 'progn (cddr x))))
((eq (car y) 'spa) ;result is 2nd arg
(return (cons 'prog2
(cons nil
(cddr x)))))
((eq (car y) 'ca) ;complement "accumulator"
(return (prog (z zz)
(setq z (caddr x) ;2nd arg
zz (cdddr x)) ;rest of args

loop (setq z (list 'boole ;complement result so far (z)
(cadr y) ;and apply boole to next arg
(list 'boole 6 z -1)
(car zz) ))
(cond ((setq zz (cdr zz))
(go loop))
((return z)) ) )))
((eq (car y) 'cm) ;complement "memory": all opnds except 2nd arg
(return (cons 'boole
(cons (cadr y)
(cons (caddr x)
(mapcar '(lambda (z)
(list 'boole 6 z -1))
(cdddr x) ))))) ))
lose (return ''nil)))

Duane Rettig

unread,
Nov 13, 2002, 4:00:00 PM11/13/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Matt Curtin wrote:
> > The difference is that there aren't a lot
> > of incompetent "programmers" out there claiming to be able to write
> > Common Lisp code.
>
> Exactly. In fact, sick idea: I'd love to track down the worst
> programmer who likes Lisp. Maybe hold an anti-contest. I bet they
> would not be very bad. Hmmm, maybe I should look at the Lisp archives.

What you're really talking about is an obfuscation contest. And
only the best Lisp programmers would be able to win such a contest
framed as looking for the worst Lisp code...

--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182

Erik Naggum

unread,
Nov 13, 2002, 4:18:28 PM11/13/02
to
* Michael Hudson

| What would _really bad_ Common Lisp look like?

It is posted here from time to time. Just use a `setq´ of free variables
that are not declared special, and you are half there with just one major
ugliness. Then think you are writing in Scheme and you have taken another
half out of the rest of the journey to worst-possible Common Lisp. And if
you really want to do a good approximation, think you are writing in C and
do your own allocation of all objects from a pre-allocated pool and crash
when you run out of space from that pool or any other error happens. Do
not use the exception system, but use reasonable return values for errors
(like -1 where it really is a valid value). Avoid multiple return values
and pass values back through "global" variables. Use Hungarian notation
and variable names in Polish, but do not declare types. Avoid hyphen, use
underscore /and/ StudlyCaps. Sprinkle whitespace, including line breaks,
after open and before close parens.

Kenny Tilton

unread,
Nov 13, 2002, 4:33:01 PM11/13/02
to

Duane Rettig wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>Matt Curtin wrote:
>> > The difference is that there aren't a lot
>>
>>>of incompetent "programmers" out there claiming to be able to write
>>>Common Lisp code.
>>
>>Exactly. In fact, sick idea: I'd love to track down the worst
>>programmer who likes Lisp. Maybe hold an anti-contest. I bet they
>>would not be very bad. Hmmm, maybe I should look at the Lisp archives.
>
>
> What you're really talking about is an obfuscation contest. And
> only the best Lisp programmers would be able to win such a contest
> framed as looking for the worst Lisp code...
>

No, no, no, the code has to be a genuine best effort. So we would need
anti-prizes. The winner has to pay the losers.

Maybe we have a new form of the Turing Test: can a good programmer
really produce code that would fool a judge into thinking they were
awful at it? They can't just produce obfuscated-code, wouldn't be
convincing.

Try placing three stones on a piece of paper so they appear to be
randomly located.

:)

Lars Magne Ingebrigtsen

unread,
Nov 13, 2002, 4:36:26 PM11/13/02
to
Michael Hudson <m...@python.net> writes:

> What would _really bad_ Common Lisp look like?

Well, I found myself writing this a few weeks ago:

(min max (max (min min min-max) fee))

And I feel I deserve some sort of recognition for that one.

--
(domestic pets only, the antidote for overdose, milk.)
la...@gnus.org * Lars Magne Ingebrigtsen

Erik Naggum

unread,
Nov 13, 2002, 4:44:48 PM11/13/02
to
* Joe Marshall

| If there were no vet in the nearby area that specialized in the kind of
| pet that I had, then I'd prefer one that felt comfortable with all
| animals in the same family or order to one that felt that cats differed
| so much from dogs as to be incomprehensible.

And then there are people who do not consider emergencies the proper
focus of all their planning, philosophies, and ethics.

Duane Rettig

unread,
Nov 13, 2002, 8:00:05 PM11/13/02
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Duane Rettig wrote:
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> >
>
> >>Matt Curtin wrote:
> >> > The difference is that there aren't a lot
> >>
> >>>of incompetent "programmers" out there claiming to be able to write
> >>>Common Lisp code.
> >>
> >>Exactly. In fact, sick idea: I'd love to track down the worst
> >>programmer who likes Lisp. Maybe hold an anti-contest. I bet they
> >>would not be very bad. Hmmm, maybe I should look at the Lisp archives.
> > What you're really talking about is an obfuscation contest. And
>
> > only the best Lisp programmers would be able to win such a contest
> > framed as looking for the worst Lisp code...
>
> >
>
>
> No, no, no, the code has to be a genuine best effort. So we would need
> anti-prizes. The winner has to pay the losers.

You'd get exactly zero participants in such a contest...

> Maybe we have a new form of the Turing Test: can a good programmer
> really produce code that would fool a judge into thinking they were
> awful at it? They can't just produce obfuscated-code, wouldn't be
> convincing.

You'd get exactly zero qualified judges for this...

> Try placing three stones on a piece of paper so they appear to be
> randomly located.

Now _this_ can be done...

> :)

:-)

sv0f

unread,
Nov 13, 2002, 8:03:49 PM11/13/02
to
In article <m3bs4tk...@quimbies.gnus.org>, Lars Magne Ingebrigtsen
<la...@gnus.org> wrote:

>Well, I found myself writing this a few weeks ago:
>
> (min max (max (min min min-max) fee))
>
>And I feel I deserve some sort of recognition for that one.

It's like morse code mated with beat poetry.

Daniel Barlow

unread,
Nov 13, 2002, 7:29:58 PM11/13/02
to
Erik Naggum <er...@naggum.no> writes:

[ lisp style suggestions deleted ]


> and pass values back through "global" variables. Use Hungarian notation
> and variable names in Polish, but do not declare types. Avoid hyphen, use
> underscore /and/ StudlyCaps. Sprinkle whitespace, including line breaks,
> after open and before close parens.

It's also important to adopt the kind of naming conventions for
functions and variables that would be familiar to C programmers
brought up in the "externally visible identifiers must be unique in
the first six characters" world. Eschew vowels, abbreviate wherever
possible, abbreviate some places where not possible, name
side-effecting functions for their return value, value-returning
functions for their side-effect, and functions that do both and have
no clear purpose at all by concatenating a random selection of words
associated with the general concept of the program's application area

Words such as 'do', 'manager', 'process' and 'stuff' are always useful
additions if a name is looking too readable

-dan

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

Michael Parker

unread,
Nov 13, 2002, 9:00:05 PM11/13/02
to
That's gotta be Greenblatt.

Christopher C. Stacy

unread,
Nov 13, 2002, 10:24:27 PM11/13/02
to
>>>>> On Thu, 14 Nov 2002 02:00:05 GMT, Michael Parker ("Michael") writes:
Michael> That's gotta be Greenblatt.

???

Raymond Wiker

unread,
Nov 14, 2002, 1:51:05 AM11/14/02
to
Daniel Barlow <d...@telent.net> writes:

> Words such as 'do', 'manager', 'process' and 'stuff' are always useful
> additions if a name is looking too readable

You forgot "factory".

Espen Vestre

unread,
Nov 14, 2002, 3:42:00 AM11/14/02
to
Erik Naggum <er...@naggum.no> writes:

> underscore /and/ StudlyCaps. Sprinkle whitespace, including line breaks,
> after open and before close parens.

and then: Top it off with a few counter-intuitive macros and reader
macros, and you can make it look like a basic programmer's first
encounter with Perl!
--
(espen)

Deon Garrett

unread,
Nov 14, 2002, 5:33:38 AM11/14/02
to
Erik Naggum <er...@naggum.no> writes:

> * Michael Hudson
> | What would _really bad_ Common Lisp look like?
>
> It is posted here from time to time. Just use a `setq´ of free variables
> that are not declared special, and you are half there with just one major
> ugliness. Then think you are writing in Scheme and you have taken another
> half out of the rest of the journey to worst-possible Common Lisp. And if
> you really want to do a good approximation, think you are writing in C and
> do your own allocation of all objects from a pre-allocated pool and crash
> when you run out of space from that pool or any other error happens. Do
> not use the exception system, but use reasonable return values for errors
> (like -1 where it really is a valid value). Avoid multiple return values
> and pass values back through "global" variables. Use Hungarian notation
> and variable names in Polish, but do not declare types. Avoid hyphen, use
> underscore /and/ StudlyCaps. Sprinkle whitespace, including line breaks,
> after open and before close parens.

I'm the TA for an intro to AI course, so I think I can add a few items to
Erik's list...if I can drop the assumption that the person knows what he's
doing.

* Don't put line breaks in....ever. I graded one assignment containing
a 393 character line. I'm not kidding.

* Pretend that and/or do not exist and write complex branching
logic using cond nested five levels deep.

* declare 10 local variables with default values in a let form, then
spend the next 10 lines assigning values to them with 10 different
setf's.

* Use this code to iterate over a list.
(dotimes (i (length lst))
(do-something-to (elt lst i)))

* Don't just mix underscore and StudlyCaps in a program. Truly awful
code requires going above and beyond. It requires mixing StudlyCaps,
nocaps, and various forms of WEIRDCaps into different references to
the same symbol. As in
(setf MyList (cons something MYLIST))

* And my current favorite: add 5 numbers with this beauty.
(+ 1 (+ 2 (+ 3 (+ 4 (+ 5)))))


I could probably add more. All these examples are from code I've seen since
Monday. Yes, I am slowly going insane. Someone please help me...or just
kill me.


- Deon

Nils Goesche

unread,
Nov 14, 2002, 8:15:25 AM11/14/02
to
Deon Garrett <gar...@cs.colostate.edu> writes:

> I'm the TA for an intro to AI course, so I think I can add a few
> items to Erik's list...if I can drop the assumption that the person
> knows what he's doing.
>
> * Don't put line breaks in....ever. I graded one assignment
> containing a 393 character line. I'm not kidding.

Hey, have some faith: Maybe he generated the code and just didn't
bother shoving it through the pretty printer because he was
assuming that you have some AI program doing the grading, anyway, and
would never actually look at it!

Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x0655CFA0

Martti Halminen

unread,
Nov 14, 2002, 8:12:56 AM11/14/02
to
Deon Garrett wrote:

> > * Michael Hudson
> > | What would _really bad_ Common Lisp look like?

> * declare 10 local variables with default values in a let form, then


> spend the next 10 lines assigning values to them with 10 different
> setf's.
>
> * Use this code to iterate over a list.
> (dotimes (i (length lst))
> (do-something-to (elt lst i)))

Had a colleague once who specialised in thousand-line functions doing 5
separate things, including several nested loops iterating over several
variables in various directions, and never used recursion. (Those few
times he noticed recursion might be cleaner he had to ask me to write
those pieces...)

--

Michael Parker

unread,
Nov 14, 2002, 9:15:14 AM11/14/02
to
cst...@dtpq.com (Christopher C. Stacy) wrote in message news:<u1y5o9...@dtpq.com>...

> >>>>> On Thu, 14 Nov 2002 02:00:05 GMT, Michael Parker ("Michael") writes:
> Michael> That's gotta be Greenblatt.
>
> ???

http://groups.google.com/groups?q=g:thl3617830644d&dq=&hl=en&lr=&ie=UTF-8&selm=0Yvl8.31678%2444.8950007%40typhoon.ne.ipsvc.net

Joe Marshall

unread,
Nov 14, 2002, 9:16:17 AM11/14/02
to
Michael Parker <michae...@earthlink.net> writes:

> That's gotta be Greenblatt.

Heh heh. I couldn't find anything with his explicit signature on it,
but I was looking for an example.

My first assignment as a `professional' Lisp hacker was to write a
microcode verifier for the LMI Lambda. RG handed me half a dozen
files written in such a perspicuous style, pointed me at the Lisp
machine microcode, and said `dive in'.

The doctors say that with therapy I could once again lead a normal and
productive life.

Kenny Tilton

unread,
Nov 14, 2002, 10:27:03 AM11/14/02
to

Deon Garrett wrote:
> Erik Naggum <er...@naggum.no> writes:
>
>
>>* Michael Hudson
>>| What would _really bad_ Common Lisp look like?
>>
>> It is posted here from time to time. Just use a `setq´ of free variables
>> that are not declared special, and you are half there with just one major

>> ugliness. Then ....


>
>
> I'm the TA for an intro to AI course, so I think I can add a few items to
> Erik's list...if I can drop the assumption that the person knows what he's
> doing.
>
> * Don't put line breaks in....ever. I graded one assignment containing
> a 393 character line. I'm not kidding.

They must have been going between PC and Mac, yes? Anyway...

>
> * Pretend that and/or do not exist and write complex branching
> logic using cond nested five levels deep.
>

OK, youse guys are having a lot of fun with my anti-contest, but you are
losing sight of the premise that everyone involved sincerely likes Lisp
and so would have had enough experience not to (+ 1 (+ 2 3)). Similarly,
for example, there would be no StudlyCaps because even a bad Lisp
programmer would have been hounded into conformity by a mob of
hyphen-zealots.

> I could probably add more. All these examples are from code I've seen since
> Monday. Yes, I am slowly going insane. Someone please help me...or just
> kill me.

We feel your pain. Have them pre-flight their homework here on cll; some
of us like to teach, the others need a way to keep their claws from
growing too long.

Hannah Schroeter

unread,
Nov 14, 2002, 11:38:25 AM11/14/02
to
Hello!

Raymond Wiker <Raymon...@fast.no> wrote:
>Daniel Barlow <d...@telent.net> writes:

>> Words such as 'do', 'manager', 'process' and 'stuff' are always useful
>> additions if a name is looking too readable

> You forgot "factory".

Perhaps also "thingy" (courtsey IIRC to perl).

Kind regards,

Hannah.

Henrik Motakef

unread,
Nov 14, 2002, 2:36:15 PM11/14/02
to
Daniel Barlow <d...@telent.net> writes:

> It's also important to adopt the kind of naming conventions for
> functions and variables that would be familiar to C programmers
> brought up in the "externally visible identifiers must be unique in
> the first six characters" world. Eschew vowels, abbreviate wherever

> possible, [...]

As opposed to conventions leading to clear names like cddddr, psetf,
ldp, fboundp, or rplacd?

scnr
Henrik

Erik Naggum

unread,
Nov 14, 2002, 3:41:25 PM11/14/02
to
* Henrik Motakef

| As opposed to conventions leading to clear names like cddddr, psetf,
| ldp, fboundp, or rplacd?

All crystal clear to me, except for `ldp´.

Petter Gustad

unread,
Nov 14, 2002, 3:56:51 PM11/14/02
to
tuo...@yahoo.com (Tuomas P) writes:


> Is Lisp being used in programs that do text processing of various
> kind, such as parsing and manipulating an HTML file, parsing C code
> (and reindenting it), etc.? Would Lisp be a good to choice if one is
> to write such software?

Yes - since you have functions like read and the reader macros as well
as powerful macros.


Some time ago I was complaining about parser generating tools like
ANTLR lack of CLOS support (it generates code for C/C++ and Java).

Then I took a quick look at Meta. I briefly read the paper by
Baker(1). I thought it looked interesting and asked the author for the
source code so I could study it in more detail. He kindly replied that
all the code was in the paper. It was only a couple dozen lines long!
I would recommend looking at this paper (and don't assume parser
generators to be huge programs like I did)

Meta is simple and elegant. I have just played with it to parse simple
numbers etc, but have anybody used it to write parsers and translators
for a full programming language?

Petter

1) http://home.pipeline.com/~hbaker1/Prag-Parse.ps.Z

--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter

Martti Halminen

unread,
Nov 14, 2002, 4:41:09 PM11/14/02
to
Erik Naggum wrote:
>
> * Henrik Motakef
> | As opposed to conventions leading to clear names like cddddr, psetf,
> | ldp, fboundp, or rplacd?
>
> All crystal clear to me, except for `ldp´.

The original poster possibly meant ldb, which I believe was directly
borrowed from PDP-10 assembler.

--

Erik Naggum

unread,
Nov 14, 2002, 5:33:26 PM11/14/02
to
* Henrik Motakef
| As opposed to conventions leading to clear names like cddddr, psetf,
| ldp, fboundp, or rplacd?

* Erik Naggum


| All crystal clear to me, except for `ldp´.

* Martti Halminen


| The original poster possibly meant ldb, which I believe was directly
| borrowed from PDP-10 assembler.

Yes, `dpb´ and `ldb´ are PDP-10 instructions, all right. I wish more
low-level instructions like this were available to Common Lisp
programmers. E.g., byte-swapping instructions and rotates.

However, you seem to have missed the potential for a humorous bent on
this. Complaining about cryptic names is one thing, but getting them
wrong when you do is inherently funny, at least in my book.

Steven E. Harris

unread,
Nov 14, 2002, 6:31:51 PM11/14/02
to
Daniel Barlow <d...@telent.net> writes:

> Words such as 'do', 'manager', 'process' and 'stuff' are always
> useful additions if a name is looking too readable

You should see some of the code I work with here. If you can think of
a concept, it has a "manager" associated with it. It won't be long
until we birth a ManagerManager.

--
Steven E. Harris :: seha...@raytheon.com
Raytheon :: http://www.raytheon.com

Rob Warnock

unread,
Nov 15, 2002, 12:07:57 AM11/15/02
to
Petter Gustad <newsma...@gustad.com> wrote:
+---------------

| Meta is simple and elegant. I have just played with it to parse simple
| numbers etc, but have anybody used it to write parsers and translators
| for a full programming language?
+---------------

Way back ~1970 there was a PDP-10 program named "Meta II" that
was a standalone Meta processor. I used it to write a dead stupid
BLISS compiler over a single weekend! Now, granted, my compiler
emitted *dumb* PDP-10 assembler code[1], but it implemented most
of the core language. It didn't hurt that BLISS is roughly LL(1)
[if not LL(0)!], which nicely matches Meta's recursive-descent style.

Meta is cool.


-Rob

[1] The code generator I wrote didn't bother with register management,
assuming a simple stack VM, so that the code for "A = .A + .B * 3"
turned into this horrid mess: (*blush*)

movei t0,A ; get A's address
push p,t0 ; save for later
movei t0,A ; get A's address, *again*! (oops)
move t0,(t0) ; get .A (contents of A)
push p,t0 ; save for later
movei t0,B ; same song & dance for B
move t0,(t0)
push p,t0
movei t0,3 ; get 3
pop p,t1 ; get .B back
mul t0,t1 ; .B*3
pop p,t1 ; get .A back
add t0,t1
pop p,t1 ; get A back [note: *address* of A]
storem t0,(t1) ; done

But of course, none of that was Meta's fault. ;-} ;-}

-----
Rob Warnock, PP-ASEL-IA <rp...@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Raymond Wiker

unread,
Nov 15, 2002, 4:37:10 AM11/15/02
to
Steven E. Harris <seha...@raytheon.com> writes:

> Daniel Barlow <d...@telent.net> writes:
>
> > Words such as 'do', 'manager', 'process' and 'stuff' are always
> > useful additions if a name is looking too readable
>
> You should see some of the code I work with here. If you can think of
> a concept, it has a "manager" associated with it. It won't be long
> until we birth a ManagerManager.

Or a FactoryFactory, or a FactoryFactorySingleton. Hopefully
not a SingletonFactory, though...

Larry Hunter

unread,
Nov 15, 2002, 1:43:41 PM11/15/02
to

I could probably add more. All these examples are from code I've
seen since Monday. Yes, I am slowly going insane. Someone please
help me...or just kill me.

The best idea I have seen for escaping this hell could only be done in
lisp. Chris Riesbeck has written a lisp homework parser that checks
for hundreds of stylistic and semantic errors that he never wants to
see. Some of it only works for particular problems (generally taken
from Graham's CL book exercises), but others are generic. Students
have to get the programs to pass his autochecker before submitting it
for his review. Source code is available...

http://www.cs.nwu.edu/academics/courses/c25/exercises/critic.html

--

Lawrence Hunter, Ph.D.
Director, Center for Computational Pharmacology
Associate Professor of Pharmacology, PMB & Computer Science

phone +1 303 315 1094 UCHSC, Campus Box C236
fax +1 303 315 1098 School of Medicine rm 2817b
cell +1 303 324 0355 4200 E. 9th Ave.
email: Larry....@uchsc.edu Denver, CO 80262
PGP key on public keyservers http://compbio.uchsc.edu/hunter

Marc Spitzer

unread,
Nov 15, 2002, 2:35:22 PM11/15/02