is Lisp used in text parsing and processing tasks?
Tuomas P
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
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
> 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
>
> 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?
> 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
> 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
>
> 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>.
>
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
> 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
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
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
> 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
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
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
> 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
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
| 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
> 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
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
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
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
> 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
> 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
> 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
| 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
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
> 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
| 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
> 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
<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
[ 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
Christopher C. Stacy
Michael> That's gotta be Greenblatt.
???
Raymond Wiker
> Words such as 'do', 'manager', 'process' and 'stuff' are always useful
> additions if a name is looking too readable
You forgot "factory".
Espen Vestre
> 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
> * 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
> 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
> > * 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
> >>>>> On Thu, 14 Nov 2002 02:00:05 GMT, Michael Parker ("Michael") writes:
> Michael> That's gotta be Greenblatt.
>
> ???
Joe Marshall
> 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
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
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
> 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
| 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
> 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
>
> * 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
| 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
> 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
+---------------
| 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
> 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
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
> 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
I just looked at the course and it looks like a remarkably pleasant way
to learn AI and Lisp.
marc
Kalle Olavi Niemitalo
> * Use this code to iterate over a list.
> (dotimes (i (length lst))
> (do-something-to (elt lst i)))
Nice use of lst. ;-) One could slow that down a little more by
measuring the length on each iteration.
(do ((i 0 (1+ i)))
((= i (length lst)))
(do-something-to (elt lst i)))
(loop for i from 0
while (< i (length lst))
do (do-something-to (elt lst i)))
Is there a simpler way? These ones look too complex to be used
by mistake.
Gareth McCaughan
> 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
Very neat. That page doesn't say where to get the tool from;
it's at
http://www.cs.northwestern.edu/academics/courses/c25/programs/cs325.zip
I'm not sure that "could only be done in lisp" is right, though.
(It's certainly easier in Lisp than in any other language I can
think of.) There are similar tools for other languages, not written
in Lisp. Even <shudder> C++.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Alexander Schmolck
> 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
Actually, I vaguely remember the claim of one of my former lecturers to have
written something similar in fortran (analyzing fortran programs) for his phd
thesis, back in the days of punch cards. So maybe you really ought to say that
it can only be done in well matured programming languages (like lisp *or*
fortran). :)
alex
Knut Olav Bøhmer
<cut>
> (loop for i from 0
> while (< i (length lst))
> do (do-something-to (elt lst i)))
>
> Is there a simpler way? These ones look too complex to be used
> by mistake.
I don't know why I'm answering this, but here I go:
(loop for i in lst
do (massage i))
--
Knut Olav Böhmer
_ _
/ / (_)__ __ ____ __
/ /__/ / _ \/ // /\ \/ / ... The choice of a
/____/_/_//_/\.,_/ /_/\.\ GNU generation
An ideal world is left as an exercise to the reader. (Paul Graham)
Paul F. Dietz
>> (loop for i from 0
>> while (< i (length lst))
>> do (do-something-to (elt lst i)))
>>
>>Is there a simpler way? These ones look too complex to be used
>>by mistake.
>
>
> I don't know why I'm answering this, but here I go:
>
> (loop for i in lst
> do (massage i))
He knew that. He was looking for a simpler way to make
bad code, not the simpler way to do it right.
Oh, and this is simpler. :)
(mapc #'massage lst)
Paul
Rob Warnock
+---------------
| mul t0,t1 ; .B*3
+---------------
Should have been "imul", of course. (*blush*)
-Rob
Reference: <URL:http://pdp10.nocrew.org/docs/opcodes.html>
Paolo Amoroso
wrote:
> 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.
[...]
> * 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.
[...]
> * 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)))))
What's amazing is not much that students make mistakes like the ones
mentioned in this thread. I am more suprised by the fact that they do such
mistakes after being exposed to a usually large number of--hopefully--good
and idiomatic code samples.
How much attention do they pay to _reading_ those examples? Shouldn't the
"cut and paste" mindset be of some help here? Bad habits spread like
wildfire, but there's a sort of psychological barrier to copying good ones.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso
> 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
This is an interesting reading:
"FoOBaR - A Prehistoric Survivor"
António Menezes Leitão
Proceedings of ELUGM '99
Abstract: We describe an old and large AI system that crossed several
Lisp periods and dialects. The system is currently implemented in Common
Lisp but still represents an unique source of information regarding
implementation problems and solutions in older Lisp dialects and
implementations. Most of these solutions are techniques to sourmount
language limitations, to use language features in unforseen ways, or just
incorrect coding practices. This paper describes some of these problema
snd solutions, and their impact on readability, efficiency, and
maintenance.
Deon Garrett
>
> What's amazing is not much that students make mistakes like the ones
> mentioned in this thread. I am more suprised by the fact that they do such
> mistakes after being exposed to a usually large number of--hopefully--good
> and idiomatic code samples.
>
Aye, therein lies the rub. Ordinarily, students start off with the
standard Lisp beginner fare; reverse a list recursively and all that
stuff. In this course, the professor decided to try a little
experiment. He explained Lisp in some detail in the lectures, but
then left the students to study on their own. They were supposed to
read the Graham book (Ansi Common Lisp) and see me with questions.
All the assignments have been fairly substantial pieces of code, at
least considering their lack of experience. Of course, most didn't
read anything and have just been trying to muddle their way through
the semester. I actually thought this was a good idea. I've always
found the best way to learn a language was to write something real in
it. In hindsight, I think students probably need a little more
guidance in the process of learning Lisp.
Yes, they _should_ have been exposed to plenty of good examples, but
the reality is that many of them probably think mapcar is some sort of
joint venture between Honda and Rand McNally.
I'm being a little too critical here. About 25% of the class is
actually writing very good code. A couple of students have actually
learned the Lisp efficiency model. I guess that's probably the norm
in undergraduate education these days. You probably can't expect much
more than that to do truly good work.
Erik Naggum
| What's amazing is not much that students make mistakes like the ones
| mentioned in this thread. I am more suprised by the fact that they do such
| mistakes after being exposed to a usually large number of--hopefully--good
| and idiomatic code samples.
|
| How much attention do they pay to _reading_ those examples? Shouldn't
| the "cut and paste" mindset be of some help here? Bad habits spread like
| wildfire, but there's a sort of psychological barrier to copying good
| ones.
The problem is that some people can learn something only once. They are
only malleable while they are truly unexposed. Show them something, and
the impression it makes causes anything that could occupy the same space
later to be rejected. If they later learn that their first impression was
wrong, the result is only that they reject everything, which makes them
insecure and suspicious. To make matters worse, I believe this to be the
default programming mode of the brain and that it requires directed effort
-- also known as /thinking/ -- to override the default behavior.
Pascal Costanza
> The problem is that some people can learn something only once. They are
> only malleable while they are truly unexposed. Show them something, and
> the impression it makes causes anything that could occupy the same space
> later to be rejected. If they later learn that their first impression was
> wrong, the result is only that they reject everything, which makes them
> insecure and suspicious. To make matters worse, I believe this to be the
> default programming mode of the brain and that it requires directed effort
> -- also known as /thinking/ -- to override the default behavior.
I think you are talking about cognitive dissonance. See
http://tip.psychology.org/festinge.html
Pascal
--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
Erik Naggum
| I think you are talking about cognitive dissonance.
Well, cognitive dissonance is the effect of the cause I was talking about.
When cognitive dissonance occurs, the default coping strategy is to reject
rather than to think and analyze and embrace new input, but the key to the
ability to learn is the ability to update a slot that had been filled by
the first impression, or to internalize and integrate new and conflicting
information. Failure to do this will only produce repeated incidents of
cognitive dissonance.
Tim Daly, Jr.
tuo...@yahoo.com (Tuomas P) writes:
> 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?
>
For parsing, I would highly recommend bigloo:
http://www-sop.inria.fr/mimosa/personnel/Manuel.Serrano/bigloo/
It's not Common Lisp, but it's still great. It includes functionality
for lexing - (regular-grammar), and lalr parser generation
(lalr-grammar). Check it out, I'm really impressed.
-Tim