[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on Dylan
- To: firstname.lastname@example.org
- Subject: Comments on Dylan
- From: Jim Mayer <email@example.com>
- Date: Mon, 2 Nov 1992 12:53:19 PST
I just finished reading the Dylan book, and thought I would share some
thoughts I had about the language.
In general, I was very happy with what I saw. Most of the programming I do
can be broadly categorized as "systems" programming in Common Lisp. I
enjoy using Common Lisp and CLOS, but have been frustrated by the
resource requirements of the implementations available to me. I
would love to be able to write small, "unix" like, tools in Lisp
(currently I drop into "C" to do this sort of thing).
Here are some comments and some changes I would like to see in Dylan:
(1) Comment: I couldn't figure out how different comparison operations
were to be associated with hash tables.
(2) Unimportant comment: how about using #!fu instead of (setter fu).
If (setter fu) is just syntax, they why not use a syntaxy (?!?) form?
(2) Change: Add support for tables indexed by more than one key. One
could call these "multi-dimensional" tables by analogy with vectors
and arrays. Ideally, each "dimension" could be associated with a
different hash function.
Multi-dimensional hash tables are extremely useful for modeling
relations and for "memoizing" functions. The alternative of providing
a sequence of keys requires a structure walking "=" table to be used
(which is very slow compared to "id" tables), and requires a sequence
to be allocated for each query.
(3) Addition: Consider allowing hash tables to take arbitrary comparison
and hash generation functions. Also, consider whether or not the
"id-hash" could be exposed without overly limiting the range of
possible implementations. For example, one could put the following
restrictions on the use of hash values:
(a) The result of id-hash may change at any time, so hash
functions are not free to cache the results of calling
(b) A table may "rehash" itself at any time, and user defined
hash functions may be called arbitrarily.
(c) The results of a hash function may only be combined by
means of the "combine-hash" function.
(4) Addition: Add support for weak pointers and collections
(particularly deques And tables). Weak data structures are very
useful for implementing caching schemes.
(5) Addition: Add support for finalization, while stressing that its
"proper" role is for supporting automatic collection of objects
outside the scope of normal storage management (such as file
(6) Comment: YES vote for a threads package as an optional library.
(7) Addition: add a denotation for classes and generic functions.
Classes and generic functions would then be at the same "level" as
numbers and methods (both of which have denotations).
(8) Addition: Currently the only way to create a read-only variable is
to use "define-class" or "define-generic-function". There ought to be
a "define-readonly" that creates a read-only variable with an
(9) Addition: support the ability to declare that a given condition
evaluates to a TRUE value at all points within a lexical scope. For
(bind (((x integer) 0))
(proclaim-function (method () (<= 0 x 5)))
or (for a nicer syntax)
(bind (((x integer) 0))
(proclaim (<= 0 x 5))
This asserts that "x" lies within the range [0..5] at all points
within its scope. This information can be checked, assumed, or
ignored by a compiler (just like type declarations in common lisp).
I prefer this approach to introducing a large type system because the
"proclaim" construct does not introduce a new sublanguage (such as the
common lisp type system). It also avoids the complexity of talking
about "abstract" and "representation" types that common lisp gets
-- Jim Mayer
Phone: (716) 422-9407
Webster Research Center Intelnet phone: 8*222-9407
Xerox Corporation Internet Email: firstname.lastname@example.org
800 Phillips Road, 0128-29E XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580 Facsimile: (716) 265-7133