home *** CD-ROM | disk | FTP | other *** search
- x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 12 Jan 1993 17:59:45 EST
- Date: Tue, 12 Jan 1993 14:59:04 PST
- Message-ID: <9301122259.AA01049@thalidomide.lucid>
- X-Windows: Power tools for power fools.
- From: jwz@lucid.com (Jamie Zawinski)
- Sender: jwz%thalidomide@lucid.com
- Subject: Re: Solution to buff-menu.el bug
- References: <9301112333.AA23712@thalidomide.lucid>
- <9301122117.AA07645@thymus.synaptics>
- Newsgroups: alt.lucid-emacs.bug
- Path: sparky!uunet!wendy-fate.uu.net!bug-lucid-emacs
- Lines: 24
-
- I would like to see someone rewrite cl.el as several packages. One for the
- really small stuff like `when', `unless', and `pop'; one for the hairier
- control structures like `do'; one for `setf'; one for `defstruct'; etc.
-
- The multiple-values stuff should be expunged. The &key stuff should be
- expunged. So should most of the rest of it. Implementing Common Lisp in
- emacs-lisp is a fundamentally bad idea (not to mention doomed to failure.)
- Implementing certain CL constructs which emacs-lisp has no trivially easy
- way of simulating (like setf) has some merit.
-
- Trying to implement a cl-compatible defstruct (constructors, etc) is a bad
- idea. You don't really need all that hair, and it is not a good fit with
- emacs-lisp.
-
- I don't think starting from the existing cl.el is a good idea, because that
- code (pardon my bluntness) really really sucks.
-
- If someone wants to take a stab at this they should become intimately familiar
- with the byte compiler, hve a firm grasp on the differences between compile
- time, macroexpand time, load time, and run time, and should know how not to
- clutter up a namespace. (I'm sure Daveg could handle it, but I just thought
- that this needed to be said.)
-
- -- Jamie
-