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
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.
> 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
> 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.
--
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."
Best
AHz
> 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
...
> 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'.
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.
> 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/
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
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.
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.
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).
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.
> 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"
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.
>>>>>> 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
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
> 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.
> 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)))
> 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
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.
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.
:)
> 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
And then there are people who do not consider emergencies the proper
focus of all their planning, philosophies, and ethics.
> 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...
> :)
:-)
>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.
[ 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
???
> Words such as 'do', 'manager', 'process' and 'stuff' are always useful
> additions if a name is looking too readable
You forgot "factory".
> 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)
> * 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
> 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
> > * 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...)
--
> 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.
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.
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.
> 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
All crystal clear to me, except for `ldp´.
> 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
The original poster possibly meant ldb, which I believe was directly
borrowed from PDP-10 assembler.
--
* 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.
> 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
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
> 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...
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