[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on Dylan

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
arbitrary value.

(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: mayer@wrc.xerox.com
800 Phillips Road, 0128-29E             XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580                 Facsimile: (716) 265-7133