Path: news.daimi.aau.dk!news.uni-c.dk!sunic!uunet!imagen!rpal.rockwell.com!news.Stanford.EDU!nntp.Stanford.EDU!rogoff From: rogoff@sccm.Stanford.EDU (Brian Rogoff) Newsgroups: comp.lang.beta Subject: Re: Value patterns in BETA? Date: 6 Feb 95 13:01:59 Organization: /u/rogoff/.organization Lines: 111 Distribution: comp Message-ID: References: <3gsak5$j5b@engnews2.Eng.Sun.COM> Reply-To: rogoff@sccm.stanford.edu NNTP-Posting-Host: sccm.stanford.edu In-reply-to: olm@Eng.Sun.COM's message of 3 Feb 1995 04:15:01 GMT In article <3gsak5$j5b@engnews2.Eng.Sun.COM> olm@Eng.Sun.COM (Ole Lehrmann Madsen) writes: 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. I'll look there. Thanks for answering my rather rudely phrased question so politely. In fact, you also brought up another question that I had about BETA, that is userdefined binary operators... . . . discussion of static vs reference objects deleted . . . 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.) Let me rephrase my question. In the case that I have declared a "Complex" pattern as a static object, do I pay any penalty at all, i.e., some sort of type tag in each Complex object? If so, is there any way for me to avoid paying this penalty. What I'd really like to do is have a Complex object which, if it consisted of 8 byte reals, would only take up 16 bytes of space. I think that in Ada 95 the "tagged" keyword conveys the idea of what I am looking for; the ability to create untagged Complex types which may be "generic" but cannot be inherited from. I asked about this some time ago, and I was told that there is indeed a tag in Mjolner BETA. Is this the case? 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. That wasn't part of my original question, but your prescience is amazing because I was wondering about that too! I agree that real overloading may be kind of heavy for BETA, but how about some kind of Eiffel 3 style ability to declare new binary operators without ad-hoc polymorphism? I don't see how this would be that complicated, and community standards could be used to adopt "reasonable" operators for common applications. I hope such a facility would not be that heavily used outside of mathematical applications. In any case, this is *far* less important to me than the ability to make highly efficient numeric classes (and hence efficient matrix classes, etc...) 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. I guess the best way to get improvements would be to buy copies of Mjolner BETA and then insist on better performance as a paying customer ;-) 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 -- Brian