Path: news.daimi.aau.dk!news.uni-c.dk!sunic!uunet!usc!cs.utexas.edu!uwm.edu!lll-winken.llnl.gov!koriel!male.EBay.Sun.COM!engnews2.Eng.Sun.COM!olm
From: olm@Eng.Sun.COM (Ole Lehrmann Madsen)
Newsgroups: comp.lang.beta
Subject: Re: Value patterns in BETA?
Date: 3 Feb 1995 04:15:01 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
Lines: 128
Distribution: comp
Message-ID: <3gsak5$j5b@engnews2.Eng.Sun.COM>
References: <ROGOFF.95Jan31183456@sccm.Stanford.EDU>
NNTP-Posting-Host: det.eng.sun.com
X-Newsreader: NN version 6.5.0 #21 (NOV)

rogoff@sccm.Stanford.EDU (Brian Rogoff) writes:

>Hi,
>	In Sather I can create value classes whose instances are not 
>heap allocated objects, a real win for scientific programming. Is there 
>a way to do this for BETA, so that Complex and Interval patterns (for 
>example) can be added? I don't think it can be done, from what I've 
>read. If that is the case, I was wondering if some of the BETA wizards 
>who dwell here could explain their omission. Was numerics deemed an 
>unworthy domain in which to use BETA?

I think there are a couple of issues in your question. It is not easy
to give a short answer, but I shall try.  More details may be found in
the BETA book.

In BETA instance of a class pattern may be either heap-allocated or
allocated as a static part of e.g. a procedure pattern.
Unlike Eiffel and Sather (correct me if I am wrong!), this is not
a property of the class pattern.

Example:

Consider a class pattern

	point: (# x,y: @integer #);

and a procedure pattern

	foo: (#  p1: ^ point;
		 p2: @ point
	     do ...; &point[] -> p1[]; ....
             #)

'p1' is a reference denoting an instance of 'point'.
'p1' may refer an instance being dynamicaly (heap) allocated as in

	&point[] -> p1[];

'p2' is a static-object (or part-object), and is generated as part of
the activation-record for 'foo'. Since 'foo' is a pattern, the
activation-record is just another object, and 'p2' is inlined as part
of this object.
	
'p1' may also be set to refer to the (static) 'p2'-object using:

	p2[] -> p1[]

It is not possible to have:

	p1[ -> p2[]

since 'p2' is a static instance. 

With the above constructs you may allocate static instances and pass
references around to objects no matter where they are allocated.

If you want to assign values of objects you have to declare an
enter/exit part of the class pattern as in:

	point: (# x,y: @integer
	       enter(x,y)
	       exit(x,y)
	       #)

If 'point' is declared in this way, it is possible to write
imperatives like

	p1 -> p2;

This means (essentially) the same as

	p1.x -> p2.x; p2.y -> p2.y

(If point has a do-part, then more will happen, but this will not be
explained her. Also enter/exit can be more general than shown here.)

Note that it does not matter whether the objects are dynamic allocated
or static allocated.

It is thus possible to use a value-oriented style by using part
objects and value-assignment as in

	bar: (# p1,p2,p3: @ point
	     do (0,0)->p1;
		p1->p2;
		p2->p3
	     #)]

The objects p1,p2,p3 are allocated statically and assignment (and
equality) is not implemented as reference assignment (equality).

The question about whether or not Complex and Interval patterns can be
added depends on what you mean. It is of course possible to define
operations allowing imperatives like

	p1 -> p2.add -> p3

but if you mean operator overloading like

	p1 + p2 -> p3

then this is not possible. BETA does not have operator loading. So far
we have not found it worth while the complications it will add to the
language. I admit that for numeric classes it may be useful.

This then leads to the question on 'Was numerics deemed an unworthy
domain in which to use BETA?"! Absolutely not! We hope that BETA also will
be useful to do numerics. The first releases of the BETA compiler
had poor support for reals, but this has improved with the latest release
and we are constantly working on improving it. I am, however, not sure
if you find the current support to be sufficient. The problems that you
might find could be:

	- too inefficient for numeric calculations.
	
	- only one numeric pattern (real) which represents
	  a double-floating point number.

We have got little feedback on the use of numerics so far. We would
certainly welcome more feedback. Due to limited resources it is
difficult to promise when better support will be available. However,
good suggestions are always welcome.

Sincerely

Ole Lehrmann Madsen