Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!news.princeton.edu!blume
From: blume@dynamic.cs.princeton.edu (Matthias Blume)
Subject: Re: three R4RS/IEEE questions
In-Reply-To: bakul@netcom.com's message of Thu, 15 Dec 1994 22:32:09 GMT
Message-ID: <BLUME.94Dec16103623@dynamic.cs.princeton.edu>
Originator: news@hedgehog.Princeton.EDU
Sender: news@Princeton.EDU (USENET News System)
Nntp-Posting-Host: dynamic.cs.princeton.edu
Organization: Princeton University
References: <LORD.94Dec7141015@x1.cygnus.com> <3cl5rd$9u5@apple.com>
	<LORD.94Dec14223917@cygnus.com> <bakulD0vILL.6sD@netcom.com>
Date: Fri, 16 Dec 1994 15:36:23 GMT
Lines: 66

In article <bakulD0vILL.6sD@netcom.com> bakul@netcom.com (Bakul Shah) writes:

   I am sorry but I just do not understand how a `Standard' can say
   _anything_ about objects that are not specified in it.  [...]

Of course, it is a truism to say that a standard cannot say anything
about things it doesn't say anything about.  But this is not the case.
R4RS (and IEEE P1172, I suppose) talk about conforming
*implementations* and the conditions under which an implementation is
conforming.

First of all, they define what has to be implemented (which types,
which procedures) and how these things have to behave.  One could stop
here and say: ``Everybody who offers anything beyond that does not
implement a confoming Scheme system.''

Given the absence of many of the important things which make a
programming language worthwhile using in real applications this
wouldn't be practical.  Therefore, R4RS opens the door for extensions.
At this point -- if a standard wants to be of any value at all -- it
needs to make sure that certain invariants hold: invariants the
programmer can rely on no matter which system with what extensions is
being used.  While the standard cannot specify the concrete properties
of non-standard extensions it *can* impose constraints.  Extensions
which do not adhere to those constraints render the whole
implementation in its entirety non-conforming.

Why do we need constraints?  Let's take the example of a ``sequence''
type which satisfies both list? and vector? predicates.  Such a type
is useful only if I can use it in place of lists and in place of
vectors anytime and everywhere.

Now let's suppose I have this function in standard-Scheme, which
takes a list *or* a vector as its argument and returns the sum of
the elements if it is a list and the product if it is a vector.
I am not going to show you the code, however.  In standard Scheme the
behavior of this procedure is well defined.

Any of the following implementations would be correct:

A: (define (sp x)
     (cond ((list? x) (apply + x))
	   ((vector? x) (apply * (vector->list x)))
	   (else 'error)))

B: (define (sp x)
     (cond ((vector? x) (apply * (vector->list x)))
	   ((list? x) (apply + x))
	   (else 'error)))

C: (define (sp x)
     (if (list? x)
         (if (vector? x) (fire-the-nukes!) (apply + x))
         (if (vector? x) (apply * (vector->list x)) 'error)))

Obviously, without looking at the concrete code it is not possible to
know how the function behaves on such `peculiar' non-standard objects.
Under the wrong circumstances this can be very dangerous!

In summary, our non-standard list-and-vector-at-the-same-time objects
cannot successfully pose as lists (or as vectors), because some
programs want to discriminate between these to types and expect
non-overlapping domains.

--
-Matthias
