Path: news.daimi.aau.dk!olevi
From: olevi@daimi.aau.dk (Ole Villumsen)
Newsgroups: comp.lang.beta
Subject: Re: Value patterns in BETA?
Date: 21 Feb 1995 09:30:26 GMT
Organization: DAIMI, Computer Science Dept. at Aarhus University
Lines: 102
Message-ID: <3icbri$je3@belfort.daimi.aau.dk>
References: <ROGOFF.95Jan31183456@sccm.Stanford.EDU> <3gsak5$j5b@engnews2.Eng.Sun.COM> 	<ROGOFF.95Feb6130159@sccm.Stanford.EDU> 	<3hnskr$13m@belfort.daimi.aau.dk> <ROGOFF.95Feb14131212@Lanczos.Stanford.EDU>
NNTP-Posting-Host: angers.daimi.aau.dk

The article that Brian Rogoff <rogoff@Lanczos.Stanford.EDU> posted on
the 14th, showed up on our newsserver on the 20th. But my reply is still
valid :-)

I believe one point can be drawn from the discussion we've had (partly by
email): Beta needs genericity among the basic data types (integer, char,
Boolean and real), for instance in the form of a common superclass
"basicType" or "untagged". I'll return to this later.

>   >In article <3gsak5$j5b@engnews2.Eng.Sun.COM> olm@Eng.Sun.COM (Ole Lehrmann M
>adsen) writes:
>
>   >       p1 -> p2.add -> p3
>   >   but if you mean operator overloading like
>
>   >       p1 + p2 -> p3

From my follow-up:

>   I'd prefer  (p1,p2) -> add -> p3 , which is possible in BETA.
>
>That's fine, as long as all of the basic numeric patterns use the same names.

Sorry: no overloading in Beta. If you want to use the same name with many
types, just use p1 -> p2.add -> p3.

>In an e-mail message Ole writes, in response to my query about whether
>the small space overhead occurs once per "Matrix of MyComplex" or for
>every "MyComplex" in the Matrix:
>
>   But I'll have to disappoint you: the penalty comes with *each object*. I
>   think it's 16 bytes or so - I never understood why it had to be so much;
>   but I could be wrong about the amount. No way I know of to "untag" patterns
>   or objects, except hand-build the data structure using only basic types.
>   There is no penalty with those (integer, real, boolean, char). I'll
...
>That is too much. A "Matrix of MyComplex" is 3 times as big as it needs to
>be (assuming 2 4 byte floats for the complex and a tagless reresentation).
>
>I am willing to surrender some flexibility and extensibility for speed and
>space. I believe that it is possible to have at least some amount of genericity,
>i.e., to be able to write a generic NumericMatrix, and not have to have
>tags if I am willing to surrender the ability to do OO dispatch on the type.

There is (currently??) no way to disable extension in BETA. That means,
if I declare a Matrix of MyComplex, BETA would assume that the Matrix
could also contain subpatterns of MyComplex, so it would need to store
the tag with each element in the Matrix.

So what you'd have to give up would be the genericity (parameterised
types). You *can* go:

MyComplex: (# re,im: @real; enter (re,im) exit (re,im) #);

MatrixOfMyComplex:
  (# height,width:< integerValue; (* size is user specifiable *)
     complexSize: (# exit 2 #); (* a MyComplex consists of 2 reals *)
     private: [height*width*complexSize] @ real; (* all the data, no penalty *)

     put: (# ... #); (* method to insert a MyComplex at position (i,j) *)

     get: (# ... #); (* returns the (i,j)th element (MyComplex) *)
  #);

As you can see, this matrix construct is not readily reuseable for
matrices with other element types than MyComplex. If you can specify in
advance that a matrix element is always some number of reals, I can come
closer still. But what you'd really like to do would be:

MatrixOfNumeric: (* generic matrix type with ignorable space overhead *)
  (# buildingBlockType:< basicType; (* further bind this to integer or real *)
     height,width:< integerValue;
     elementSize:< integerValue;
     (* number of buildingBlockType per Matrix element *)
     private: [height*width*elementSize] @ buildingBlockType;
     (* all the data, no penalty *)

     put:< (# ... #); (* method to insert an element at position (i,j) *)

     get:< (# ... #); (* returns the (i,j)th matrix element *)
  #);

MatrixOfMyComplex: MatrixOfNumeric
  (# buildingBlockType:: real;
     elementSize:: (# do 2 -> value #); (* a MyComplex consists of 2 reals *)
     put:: ...; get:: ...;
  #);

I've thought before we ought to have genericity on the basic types (real,
integer, char, Boolean), maybe in the form of a common superclass
"basicType" (or "untagged"). It could be convenient in many situations,
and help save a lot of space in the above example.

It may not be trivial to implement. At least, the compiler would have to
check that basicType is not used directly for creating instances, since
that would be meaningless. (A general way to indicate that a class is
abstract and cannot be used for creating unspecialised instances,
would be another nice feature in BETA.)

Ole V.
--
Ole Villumsen, Department of Computer Science, Aarhus University, Denmark