Re: variata

[David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>]

My thanks to Jonathan for his comprehensive reply to my questions
about his `variata'.

(1) I have no argument with your analysis of (COND) vs. (COND (ELSE))...

>			[...]  So I want to give you the two
>choices:
>   (a) (COND) and (COND (ELSE foo)) are both necessarily legal (compatible
>         with RRRS since it's more liberal).
>   (b) (COND) and (COND (ELSE foo)) are both not necessarily legal
>         (incompatible with RRRS in a way which I wouldn't expect people
>	 to be too bothered about).
>but not the choice (status quo):
>   (c) (COND (ELSE foo)) is legal but (COND) isn't.
>You've almost convinced me that (b) is the better choice than (a).  I
>really don't care as much as the volume of my words would indicate, so
>advise me.

I actually prefer choice (a)--I wasn't advocating anything like (b)
earlier, just asking for the rationale.  I dislike (b) because I often
code something like (COND (ELSE ...)) when I know I'm going to fill in
the other cases later but I want to get the COND in there to remind me
(and to get the indentation for the ELSE right).

>I guess no one read my BNF carefully, or this would have been discussed
>earlier.

Guilty!

(2) I also have no argument with (BEGIN) being not-OK.  But it seems
intuitive to me that if (COND) is OK with no obvious semantics, then
(BEGIN) might mean the same thing.  Your explanation for (COND) is
that it's easier to specify, not that it's particularly meaningful.
Given that we agree that (COND) is OK, it seems that (BEGIN) should be
OK.  Do those who object to that also object to (COND)?

I'm not inclined to make life difficult for you on such a minor point,
so do what you think best.

(3) No disagreement on using EQV? for CASE.  I had thought you were
suggesting that we change the definition to use EQUAL?.

(4) I accept your rationale for (EQV? "" "") and (EQV? #() #()).

(5) If you consider (MAKE-VECTOR 0 <exp>) valid, then presumably you
consider (LAMBDA (X Y) X) to be valid also, along with other
expressions that aren't *provably* wrong but might be.  If I argue
this one the debate will go on indefinitely until everyone agrees to
add more declarations to their systems, so I'll drop it!  Of course, I
agree with the word "valid", I'm just discussing whether a development
environment for Scheme may issue warning messages about such things.

(6) If we say that two objects are EQV? if there is no predicate that
can distinguish them, then a requirement in RRRRRRS that two objects
are EQV? effectively prohibits an implementation from including such a
predicate as an extension.  The only example that comes to mind is
trivial, so maybe this comment is too, but here it is:

	(let ((x (make-vector 0 3))
	      (y (make-vector 0 4)))
	  (eqv? x y))

Since these are both empty vectors, am I *prohibited* from adding a
predicate that determines what fill character a vector was created
with?  Are there any non-trivial examples of this?

(7) I agree that Scheme will need a different reader than Common LISP.
However, if a Common LISP routine calls a Scheme routine with "" as an
argument, will it be EQV? to a constant "" in the Scheme routine?
It's just one more pitfall of trying to mix languages, and not
necessarily one we can hope to solve unilaterally.

(8) I see no compelling reason to ``insert apologies and references to
Common LISP'' unless you are trying hard to give full rationales for
everything you do.  In fact, I'd prefer just a simple mention in the
introduction to the effect that there are no ``gratuitous''
differences with Common LISP---that any you find were put there after
due deliberation!  If that's not true, then I (for one) think it ought
to be, since we agreed on that at Brandeis.

(We can argue on RRRS-AUTHORS whether something is ``gratuitous,'' but
I see no reason to expose all that in the RRRRRRRRRRS.)

(9) And to end on a positive note:

>    >What about (let ((x (list 'a))) (eq? x (reverse x))) ?
>
>    I feel strongly that REVERSE should always copy (unless its argument
>    is the empty list), since it is easier to remember that rule than that
>    it does so only when there's more than one element in the list.
>    Pragmatically, I often do something like (APPEND! (REVERSE X) Y), and
>    wouldn't want to side effect the original list in X if it had exactly
>    one element.  (Note that this works correctly when X is the empty
>    list, so this is a pretty unusual boundary condition.)
>
>I agree.  (Except note that it doesn't copy empty lists....)

Of course.  The ``this'' in ``Note that this works correctly when X is
the empty list, so this is a pretty unusual boundary condition''
refers to the action of APPEND!, not REVERSE.

-----

To summarize:

 -- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp))
 are valid.

 -- I feel that (BEGIN) should have the same meaning as (COND), but I
won't push the point.

 -- We agree on using EQV? for CASE.

 -- We agree that (EQV? "" "") and (EQV? #() #()) are true, but I worry
about confusion when I mix Scheme and Common LISP programs.

 -- I like warning messages for things like (MAKE-VECTOR 0 exp) more
than you do.  We can probably agree to provide declarations so you
won't refuse to buy my system!

 -- I'm concerned that defining certain objects to be EQV? prohibits
language extensions that might be able to distinguish them on the
basis of the context at their creation, but I haven't come up with a
non-trivial example.

 -- I'm not apologetic about trying to avoid ``gratuitous''
differences with Common LISP, but I don't want to burden the
description of Scheme with constant references to it either.

 -- We agree on REVERSE.

Sorry for yet another long message, but I'm finding this interchange
very useful and I hope others do too.  I don't see anything of
sufficient importance to hold up the latest revision, so please don't
drop the ball on my account!

Regards,
David Bartley
-------