NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/scheme/2027

Internet Message Format | 1992-08-13 | 6.3 KB

Path: sparky!uunet!olivea!decwrl!deccrl!bloom-beacon!INTERNET!dont-send-mail-to-path-lines
From: [e-mail]
Newsgroups: comp.lang.scheme
Subject: R^4RS Authors Comments on Dylan
Message-ID: <[e-mail]>
Date: 13 Aug 92 21:09:18 GMT
Sender: [e-mail] (Mr Background)
Organization: The Internet
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.