Re: Why would anyone want opacity?

[Shriram Krishnamurthi <shriram@cs.rice.edu>]

Matthias Blume wrote:

> 
> From: "Michael R. Blair" <ziggy@martigny.ai.mit.edu>
> Subject: Re: Why would anyone want opacity?
> Date: Fri, 10 May 96 16:34:30 EDT
> 
> > [1] Will Clinger wants to use the exception system to extend generic
> > arithmetic.  For example, + is not defined on vectors. Will might choose a
> > vector representation of `surreal numbers' or he might want to implement
> > complex or rational numbers in a Scheme that currently does not have them,
> > again using vectors as a data type representation.
> > 
> > He might use the exception system to accomplish this.  So he would now
> > accept expressions like:
> > 
> >   (+ '#(1 2) '#(23 42))
> > 
> > ...which your static type checking would presumably reject.  In fact, the
> > whole point of using the exception system to extend generic arithmetic is
> > that the _run-time_type_error_ signalling mechanism can be run-time
> > extended.
> 
> This can all be done with sum types.  Or with overloading.  But then:
> why generic arithmetic?  I know, it's kinda cute.  But is it worth it?
> Don't we know most of the time in advance that a given variable will
> always hold a small integer?  Or a real?  Is the trouble of
> automatically injecting into and projecting from a universal number
> type (with the associated run-time checks) really worth it?
> 
> If you want to write a piece of code in ML where you want to leave the
> number type and the primitive operations over those numbers open, then
> you write it as a functor.  That's what the ML module system is all
> about.  And then you can even drop in your favorite generic arithmetic
> package when you so desire.
> 
> > [2] Andy Berlin's master's thesis provided a partial evaluator for
> > arithmetic Scheme code by `advise'-ing the standard arithmetic primitives
> > to generate and propagate `symbolic values'--- that is, he effectively
> > used SET! to reassign things like `+' to accept symbolic values (pairs).
> > 
> > In a static type checking system like ML, this would presumably be verboten
> > since, in such a system, one cannot SET! a variable (like +) to anything
> > that is not type-equal to its default type (number x number -> number).
> 
> First, aren't we somehow confusing the notions of rebinding and
> assignment here?  In ML assignment to (op +) is indeed verboten,
> because (op +) is not a ref cell.  It should be that way in Scheme as
> well, which is something I am also arguing in favor of for a while
> now.
> 
> Furthermore, what you want to do here can easily be done by, again,
> using a functor.  The argument of the functor is a structure defining
> `int' and its operations.  For ordinary integers you apply this
> functor to the `Int' structure from ML's initial basis.  For symbolic
> calculations you apply it to your custom SymbolicInt structure.
> 
> > Would you forbid these programs being written this way?  Then you would
> > take away an ability Will and Andy currently have.
> 
> Well, yes.  The program cannot be written in exactly the same style,
> unless you transliterate all your Scheme code to ML code with explicit
> injections and projections.  But ML gives you a much cleaner way of
> doing what you want, with the added benefit of compile-time type
> checking.
> 
> So I wouldn't consider this taking anything away.  But new rules are
> new rules, and sometimes one has to change an old habit or two in
> order to comply.
> 
> -Matthias