[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Matthias Blume <blume@cs.Princeton.EDU>*Subject*: Re: Why would anyone want opacity?*From*: Shriram Krishnamurthi <shriram@cs.rice.edu>*Date*: Sat, 11 May 1996 03:36:23 -0500 (CDT)*Cc*: ziggy@martigny.ai.mit.edu, rrrs-authors@martigny.ai.mit.edu*In-Reply-To*: <199605102215.SAA29584@zayin.CS.Princeton.EDU>*References*: <199605102034.QAA19760@fs.CS.Princeton.EDU><199605102215.SAA29584@zayin.CS.Princeton.EDU>*Reply-To*: 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

**References**:**Re: Why would anyone want opacity?***From:*Matthias Blume <blume@CS.Princeton.EDU>

- Prev by Date:
**Revised straw proposal for heuristic info** - Next by Date:
**Re: Why would anyone want opacity?** - Prev by thread:
**Why would anyone want opacity?** - Next by thread:
**Re: Why would anyone want opacity?** - Index(es):