Re: Why would anyone want opacity?

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

From: david carlton <carlton@math.mit.edu>
Subject: Re: Why would anyone want opacity?
Date: Mon, 13 May 1996 17:26:23 -0400 (EDT)

> On Mon, 13 May 1996 15:02:07 -0400, Matthias Blume <blume@CS.Princeton.EDU> said:
> 
> > [ example of why one sometimes needs generic arithmetic deleted ]
> 
> > Of course there are times when one needs such things.  My objection
> > is to making generic numbers the *default*.  Most of the numbers in
> > my programs are small integers, and I expect this to be true even in
> > heavy generic math packages.  We can safely assume that loop
> > indices, array subscripts, etc., are not quaternions most of the
> > time.  And most of the numbers (at least in my programs) are loop
> > indices of some sort.
> 
> Different styles, I guess - I prefer to use lists to do my looping, so
> it's not so much of an issue.

Well, not everybody writes heavy math code.  I, for example, almost
never do.  In fact, the last time I wrote large amounts of Scheme code
was when I was working on VSCM's compiler.  Small integers come up all
over the place -- for various offsets, indices, ...

> > If you really need to use a generic Number type it would be better to
> > define a signature for the corresponding algebraic structure (pun
> > intended) and abstract your code over this structure.
> 
> Better for whom?  My code was easy to write, expresses what I mean,
> and works fast enough for what I want it to do.  I don't see what the
> problem is that signatures are supposed to solve.

Scheme, with its numeric type tower, makes some fairly restricting
assumptions of what kind of algebraic structure I am working with.
For example, the number 2 is basically considered an element of the
field of complex numbers.  What if I really had the -1 from Z3
(integers mod 3) in mind?  I can imagine Galois fields to be a very
useful thing, but Scheme only caters to one kind of possible
applications.

On the other hand, if I abstract over the actual field by making it
the argument of an ML functor I can make my code work with *any* kind
of field that is either available already, or that I choose to
implement when necessary.

> So in Scheme you're likely to be able to use bignums, but aren't
> absolutely guaranteed to be able to, whereas in ML you certainly (or
> almost certainly?) can't, and this is an advantage for ML?  I think
> I'm missing something here.  In both languages you can roll your own
> bignums, in both languages it's probably a pain to do so, but at least
> in Scheme you probably won't have to.

Most certainly someone has already done it for ML, so you can use it
from a library.

> Given that rolling my own
> bignum package isn't my idea of fun, Scheme seems like a clear win to
> me.

I don't understand this line of argumentation.  Providing
implementations for more algebraic structures is really a library
issue.  In both languages you are at the mercy of the implementor (of
either the compiler or the library).  Rolling your own bignum package
in Scheme seems to be quite complicated -- especially if you want to
hook it into the language as the report suggests (by completely and
transparently replacing ordinary integers with it).  The parameterized
module approach seems like a real win to me here.  There is only one
thing you loose -- the illusion that all numbers are ideal complex
numbers by default.

-Matthias