Small is Beautiful?
I have a problem with the sheer size of Common Lisp,
people say "life is to short to learn German" I'm
beginning to think this might be true of CL. For
example CLtL2 is 1,070 pages.
I suspect a subset of CL (something the size of Scheme)
would be well received in educational circles. From an
compiler/interpreter implementation view-point, a smaller
CL would be cheaper to build, and presumably cheaper to buy.
Lisp systems could be branded as "Common Lisp-Lite Conformant".
From an application development point of view, a CL-Lite
would be fine, since CL-Lite apps could be ported onto
more expensive Common Lisp systems later.
What do you-all think?
Has any work been done to define a standard subset of CL?
I live in hope,
Bill
--
Bill Birch | ·······@uk03.bull.co.uk
Bull Info. Sys. Ltd. | Bull Tel: 773 4770
Maxted Road, | Bull Mail: HM14 UK03
Hemel Hempstead, | Tel: +44 442 884770
HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
Aviate, Navigate, Communicate...
In article <······················@uk03.bull.co.uk> ······@hemel.bull.co.uk (Bill Birch) writes:
Small is Beautiful?
I have a problem with the sheer size of Common Lisp,
people say "life is to short to learn German" I'm
beginning to think this might be true of CL. For
example CLtL2 is 1,070 pages.
I have some trouble with this argument. To torture your analogy a
bit, I know someone who, while relatively uneducated and not
particularly bright, speaks German fluently. How? He was stationed
in Germany in the army, and married a German woman. No doubt he
picked up those parts of German that were useful to his immediate goal
(hitting it off with the local ladies) and the rest followed.
Common Lisp can be approached in the same way. There's no need to
digest all of CLtL2 like a boa-constrictor to program in Common Lisp.
Trying to learn Common Lisp from CLtL2 is terrible idea unless you
already know some other lisp dialect. Other books, like Norvig's
"Paradigms of AI Programming: Case Studies in Common Lisp" and,
surprisingly, "The Art of the Metaobject Protocol" by Kiczales et al.
are much better texts.
Once you become fluent enough to express yourself in Common Lisp you
can consult CLtL2 to resolve that any lingering doubt that "there must
be a built-in function that does what I want to do."
I suspect a subset of CL (something the size of Scheme)
would be well received in educational circles. From an
compiler/interpreter implementation view-point, a smaller
CL would be cheaper to build, and presumably cheaper to buy.
Lisp systems could be branded as "Common Lisp-Lite Conformant".
The implementation arguments have some merit. There are free
implementations, such as AKCL and CMU Common Lisp. Commercial
implementations that cost big bucks come with a lot of extra stuff
such as fancy debuggers, editors, programming tools, and extensive
class libraries for such things as creating user interfaces.
From an application development point of view, a CL-Lite
would be fine, since CL-Lite apps could be ported onto
more expensive Common Lisp systems later.
What do you-all think?
Has any work been done to define a standard subset of CL?
There are a couple of problems with subsets. The semantics of the
language make it hard to exclude anything because any function can be
called via eval. In the 4 years that I have been involved with the
ANSI Common Lisp committee subsets have come up again and again.
There hasn't been any consensus on what would be desirable subsets or
even if subsets are a good idea at all (from a standards viewpoint).
I live in hope,
If small Lisps are a great idea, then Dylan has a lot of promise.
This new language was designed by Apple to have "relatively modest
memory footprint". It has one of the best features of Common Lisp, a
generic function based object system.
--
Tim Moore ·····@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
- Rush
·····@cs.utah.edu (Tim Moore) writes:
>In article <······················@uk03.bull.co.uk> ······@hemel.bull.co.uk (Bill Birch) writes:
>Common Lisp can be approached in the same way. There's no need to
>digest all of CLtL2 like a boa-constrictor to program in Common Lisp.
>Trying to learn Common Lisp from CLtL2 is terrible idea unless you
>already know some other lisp dialect. Other books, like Norvig's
>"Paradigms of AI Programming: Case Studies in Common Lisp" and,
>surprisingly, "The Art of the Metaobject Protocol" by Kiczales et al.
>are much better texts.
Check out "Common Lisp: An Interactive Approach" by Stuart Shapiro. IT is
a VERY good book to get started in lisp with. (The author happens to be my
AI prof here at UB.) This book in conjunction with CLTL2 will enable you
to start programming in CL without any previous knowledge of functional
languages whatsoever (although some background in recursive techniques is
very helpful).
--
David Thomas Dudek / ········@ubvms.bitnet \ __ _ The Cybard
State University / ·····@sun.acsu.buffalo.edu \ / `-' ) ,,,
of New York / "If music be the food of love, \ | | ()|||||||[:::}
@ Buffalo / play on!" - Wm. Shakespeare \ `__.-._) '''
From: Hallvard Tretteberg
Subject: What is useful in CL, was Common Lisp Lite?
Date:
Message-ID: <HAL.93Mar12090118@monsun.si.no>
In article <···················@defmacro.cs.utah.edu> ·····@cs.utah.edu (Tim Moore) writes:
Once you become fluent enough to express yourself in Common Lisp you
can consult CLtL2 to resolve that any lingering doubt that "there must
be a built-in function that does what I want to do."
While learning (myself) CL I often felt that "there must be an elegant
way of formulating this". And after looking in CLtL2 I most often
found I was right. It was typically some useful argument to sequence
function like :key to reduce, or more obscure things like the :default
keyword in make-pathname. The nice thing was that the intuitive
feeling that things are easy in CL was supported by practical
experience. And to be that useful, it "has to be" big.
I've often wondered whether I would like CL to be smaller, and found
that I never want to trade the features for a smaller memory
footprint. Another point is that I like a language that always has
more to offer than you've already found out. It inspires you to learn
more, although you don't have to.
Just for fun I went through CLtL2 to find what parts I did (n't) use
(in my current project). The list is below. Of course i isn't
accurate, but it should give an impression that almost every aspect of
the language is useful and usable. ~ before a chapter name denotes
that the items for the chapter are the things I don't use, makes the
list smaller. While paging through the book I also found a new thing
that I wanted to use.
2. ~Datatypes: Floating point and complex numbers, bit-vectors,
hash tables, readtables, random state.
3. ~Scope and extent:
4. ~Type specifiers: Type upgrading.
5. ~Program structure: &aux variables (I don't like them).
6. ~Predicates: equalp
7. ~Control structure: define setf forms (I usually define setf
functions with defun or defmethod), symbol-macrolet, tagbody,
prog (I've found progv useful).
8. ~Macros: &environment related stuff, compiler-macros.
9. ~Type declarations: Function type declarations.
10. ~Symbols:
11. Packages: defpackage, in-package, find-package and intern. Import
and export.
12. Numbers: Only integer arithmetic, logical operations.
13. ~Characters:
14. ~Sequences: Sort and merge.
15. ~Lists: Fourth, fifth and onwards,
16. Hashtables:
17. Arrays: Only use vectors.
18. ~Strings:
19. ~Structures: :read-only slot options :-), defstruct options except
:include.
20. The evaluator: eval
21. ~Streams: Stream creators, special stream types (But I've
implemented my own with CLOS.)
22. ~Input/Output: Very advanced format directives.
23. ~File System Interface: Make load form.
24. ~Errors:
25. Miscellaneous features: compile-file, time functions, identity.
26. Loop:
27. ~Pretty-printing:
28. ~CLOS: method-combination, the metaobject protocol, with-accessors
and -slots.
29. Conditions: define-condition, handler-bind, restart-case.
--
Hallvard Traetteberg
Dept. of Knowledge Based Systems
SINTEF SI (Center for Industrial Research)
Box 124 Blindern, 0314 Oslo 3
NORWAY
Tlf: +47 22 06 79 83 or +47 22 06 73 00
Fax: +47 22 06 73 50
Email: ···················@si.sintef.no