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