From: jmiller@crl.DEC.COM Newsgroups: comp.lang.scheme Subject: R^4RS Authors Comments on Dylan Message-ID: <9208132109.AA16509@peanut.crl.dec.com> Date: 13 Aug 92 21:09:18 GMT Lines: 112 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. Executive Summary: 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 carefully. 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 community. 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.