The question is whether one plans (or at least wants to allow) to
reuse code written for standard Scheme. IEEE Scheme already requires
() to be taken as true in conditional contexts (if etc.), and thus
obviously it has to be different. R5RS (whenever it may arrive ;-)
is supposedly going to join IEEE Scheme in that respect. Therefore,
I'd really like Guile to be an extended Scheme, and its Emacs-Lisp
compatibility mode should provide special means for transition.
I suggest a special object emacs-nil, and suitably modified condition
tests (i.e. it satisfies null? and is seen by if and friends as a
false value, though not eq? to #f or ()). Then explicity encourage
writing portable Scheme code, and declare emacs-nil to die several
releases later (i.e. it's only intended as a porting aid for the
existing Emacs-Lisp sources). In addition, provide conversion tools
and style warnings for common patterns which should be changed,
and include optional (selectable at run-time) warnings when some
non-Emacs builtin procedures encounter emacs-nil. It's more work
at the start, but for the future, we should try to establish Scheme
(including also Guile, but regardless of a particular implementation)
on the "language market", rather than create more divisions than
absolutely necessary. If this strategy should happen to be the sole
hindrance for an early release of Guile, declare the current identity
of (), #f and emacs-nil as deprecated feature, which is going to change
in a later release (and give some rough estimate until when one should
have made one's bad code portable, and then really change it).
-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>