Re: Why would anyone want opacity?

[Matthias Blume <blume@CS.Princeton.EDU>]

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