[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
R^4RS Authors Comments on Dylan
This message summarizes the work of the task force appointed by the
Authors of the Revised^N Report on the Programming Language Scheme
(RNRS Authors) to study compatibility with Dylan.
It is clear that the Dylan design effort has incorporated many of
the most important lessons learned in the design and implementation
of Scheme (as well as other languages). They have designed an
admirable language, and the Scheme community can learn some lessons
from the process. The languages have different goals, and will for
good reason need to remain distinct. Nonetheless, we find a small
number of points where each language could still benefit from work
by the other.
Items for consideration by the Scheme community:
o Dylan has a well thought out exception system. While the exact
solution may not suit Scheme, any gratuitous differences should be
avoided. Since we have a subgroup designing an exception system for
inclusion in R5RS, we should ask them to study Dylan's sytem
o Dylan's use of generic functions, derived directly from CLOS, fit
into the language in a particularly elegant manner. If the Scheme
community does decide to adopt a modest object system, we should
study Dylan's subset of CLOS to make an informed choice between this
approach and the more traditional object-dispatch mechanism.
o Scheme might benefit from adopting a subset of the collection and
sequence operations from Dylan. In particular, the ability to
iterate over diverse sequences would be a valuable addition to
Scheme, and compatible with similar generic operations on numbers
already provided in the language.
o It is not possible to make a (reasonable) portable implementation of
Dylan in Scheme without the addition of some form of weak pointer
object. The Scheme community should consider the addition of at
least one such mechanism as part of the language core (weak-cons,
populations, and weak hash tables are more or less interchangeable).
Oddly enough, Dylan hasn't made any particular mechanism visible to
users, although the mechanism must exist internally. Perhaps this
mechanism should be coupled with the finalization proposal that has
been deferred to R6RS.
o While the details of Dylan's module system aren't available, the
fact that the outermost lexical environment is specified as a module
boundary is particularly interesting. It allows a compiler to
detect unbound variables at compilation time. Since modules are a
perpetual question for the Scheme community, we might want to
consider this issue (as well as the eventual Dylan module system)
during the design process.
o Not surprisingly, Dylan has followed the lead of CommonLisp in its
handling of multiple return values. While Scheme, in R5RS, will
include multiple values, they are not required to have the
"dropping" semantics of CommonLisp. [Actually, the current Dylan
manual is unclear on this, but private correspondance indicates that
this was unintentional.]
Items for consideration by Dylan designers:
o We understand (from David Moon) that the Dylan book inadvertantly
omitted the requirement that all Dylan implementations be properly
tail-recursive. We regard this as a critical requirement.
o We urge the Dylan community to reconsider the restriction on the use
of escape procedures which prevents them from being used as Scheme's
first-class continuations. The extra power available by relaxing
the restriction is significant, and the implementation cost appears
to be small. The use of full first-class continuations is likely to
simplify the exception system, as well, and this will become an
unnecessary additional source of incompatibility. This, in
particular, is an area where we'd welcome an opportunity to work
with the Dylan team to resolve the issue. This appears to be the
only item that prevents a straightforward translation of Scheme
programs into Dylan or the creation of a Scheme environment within
Dylan -- both of which are of extreme interest to the Scheme
o The restriction of variable names (in DEFINE-CLASS, etc.) and
GETTER: and SETTER: (in slot descriptions) to module variables seems
unmotivated. As currently specified, it allows a user write-only
access to the outermost lexical scope in cases where a lexical
variable shadows a module binding. The language would be
significantly simpler if this notion were removed and a completely
lexical implementation (familiar to users of C, C++, BCPL, ALGOL,
FORTRAN, and SCHEME). It is hard to understand what motivates this
particular design decision.
o Dylan follows a representation-based number system (similar to
CommonLisp). But the specification is sufficiently weak that it is
impossible to tell how it relates to the Scheme notion of
exact/inexact numbers. While it would be unreasonable of us to ask
Dylan to reconsider this particular decision, it would be
instructive to both languages to see whether the eventual
specification of the Dylan number system can be simultaneously
compatible with both notions, perhaps by providing EXACT?, INEXACT?,
INEXACT->EXACT, and EXACT->INEXACT procedures and the associated
contagion rules. In addition, Dylan doesn't provide analogs of the
Scheme procedures NUMBER->STRING and STRING->NUMBER (with their
associated invariance relation) -- this seems a logical extension to
the Dylan AS generic function.
o Without quarreling with Dylan's decision on the SETTER notation, we
prefer the value-based implementation found in T over the name-based
implementation in Dylan. In particular, the ability to bind (SETTER
T) as a lexical variable seems unusual and (frankly) unpleasant.
o Dylan's position on the order of argument evaluation (left-to-right
for arguments, but unordered with respect to the operator) seems
particularly strange, since it has the drawbacks of the Scheme
(unordered) decision without its performance advantages.