From gomes@ICSI.Berkeley.EDU Fri Sep 27 10:42:24 PDT 1996 Article: 3070 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Parameterized routines? Date: 27 Sep 1996 17:42:04 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 103 Message-ID: <52h3lc$29v@agate.berkeley.edu> References: <52g52t$2qk@lmfpub.lmf.ericsson.se> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <52g52t$2qk@lmfpub.lmf.ericsson.se>, Ari Huttunen wrote: >The new Sather library seems to contain generic algorithms somewhat like >those in C++ standard template library. Using those seems a little cumbersome, >though. You are supposed to write: > > a_sorter: A_SORT{FLT,ARRAY{FLT}}; > a: ARRAY{FLT} := |1.0,2.0,3.0,1.0|; > a_sorter.sort(a); > >It would perhaps be possible to introduce parameterized routines in the Sather >language which would help with the burden. These parameterized routines would work >similarly to template member functions in the new draft C++ standard. In effect >the routine parameters would be automatically inferred from the declared >parameters actually offered to the routine. > >I imagine you could write the above as: > a: ARRAY{FLT} := |1.0,2.0,3.0,1.0|; > A_SORT::sort(a); >The definition of class A_SORT would be unparameterized and the >routine itself would be parameterized as follows. (Currently these parameters >appear in the definition of A_SORT.) > > sort{ATP<$ARR{ETP}}(a:ATP) is > -- Default sorting uses quicksort and sorts the whole array > quicksort(a,0,a.size-1) > end; > This requires two things: - the "backwards" type inference of the type parameter from the routine arg - the inference of the type of ETP from the type of the array. It does not seem to really require parametrized routines - you could imagine the same thing with parametrized classes, as they stand. Whenever you have a :: call on parametrized class, provided all the parameters occur somewhere as arguments to the class, the type of the class could be inferred. However, it does not work when any of the parameters are implicitly used in the routine body, but don't occur as the type of one of the arguments. I personally like the notion of being able to infer some type parameters from others, but I don't think it can work. Consider something like the following: class A_SORT{ETP < $NUMBER{ETP}}{ATP < $ARRAY{ETP}} is implicit list explicit list The problem is that a given class may be under multiple parameterizations of array, such that the routines can co-exist by overloading. class FOO < $ARRAY{INT},$ARRAY{FLT} is end; In this case, in A_SORT{FOO}, it is not possible to infer what ETP is. There are some short-cuts around the verboseness... a) You need not declare the sorter a: ARRAY{FLT} := |1.0,2.0,3.0,1.0|; A_SORT{FLT,ARRAY{FLT}}::sort(a); b) Declaring an "include" class with a bunch of these algorithm classes as variables. partial class SORT_INCL{T < $NUMBER{T}} is array_sorter:A_SORT{T,ARRAY{T}}; flist_sorter:A_SORT{T,FLIST{T}}; general_sorter:A_SORT{T,$ARR{T}}; array_sorter.sort(a); A little cumbersome, and would need to be extended for new container classes. c) Creating the common dispatched version of the class class A_SORT{T} is include A_SORT{T,$ARR{T}}; end; A_SORT{FLT}::sort(a); This would be less efficient, of course. d) Creating multiple versions for the special cases ARRAY_SORTER{T} is include A_SORT{T,ARRAY{T}}; end; FLIST_SORTER{T} is include A_SORT{T,FLIST{T}}; end' etc. which is not too bad... e) Providing creator routines in the array class class ARRAY{T} is ... sorter:A_SORT{T,SAME}; permuter:A_PERMUTE{T,SAME}; end; This has two problems - 1) there is now a strong coupling between the container and the algorithm class and (2) it forces a lot of stuff to be parsed in every compile, regardless of whether it is used (though no code is generated). The one feature that I would have really liked to have is the ability to declare methods to be "shared" meaning that they can/should be called on void. Shared methods/variables then correspond exactly to the notion of "class" variables in languages like smalltalk. These are the possibilities that I considered. I would consider adding (d) to the library - it seems quite reasonable, though the naming could get out of hand. Any other suggestions are welcome! ben From erik.schnetter@student.uni-tuebingen.de Fri Oct 4 12:04:03 PDT 1996 Article: 3079 of comp.lang.sather Path: agate!spool.mu.edu!howland.erols.net!news.mathworks.com!fu-berlin.de!news.belwue.de!newsserv.zdv.uni-tuebingen.de!hp11.zdv.uni-tuebingen.de!erik.schnetter From: Erik Schnetter Newsgroups: comp.lang.sather Subject: Re: Reading "raw" FLTD Date: Fri, 4 Oct 1996 13:37:45 +0200 Organization: InterNetNews at ZDV Uni-Tuebingen Lines: 70 Message-ID: NNTP-Posting-Host: @hp11.zdv.uni-tuebingen.de Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: zxmsv01@hp11.zdv.uni-tuebingen.de In-Reply-To: <52u4sh$1d0_001@topaz.gemprint.com> On 2 Oct 1996, Bruce Guenter wrote: > Greetings. I have a "how-to" question of a technical nature for anyone who > can answer. > > I am trying to read a pre-existing file format that happens to have several > fields which contain IEEE double precision (ie 64-bit) numbers. How can I > read these into a (field of a) Sather object that I can manipulate and write > back? I can deal with the remainder of the file/string manipulation stuff, > but this I can't. FLT and FLTD have a routine called "get_representation": you get the sign, mantissa, and exponent from a floating point number. This should handle the Sather->File stuff. The opposite routine is unfortunately missing, or at least I couldn't find it. A quick hack to your problem is a short C routine: -- in Sather: external class CONVERSION is str_to_flt (s: STR): FLT; end; /* in C: */ float str_to_flt (char* s) { return *(float*)s; } Or if you are daring and/or need the performance: -- in Sather, without C: str_to_flt (s: STR): FLT pre s.length=4 is f: FLT; SYS::inlined_C ("#f = *(float*)&(#s->arr_part);"); return f; end; Some comments: Be aware of high endian and little endian machines. Swap the characters in your string if necessary. (The built in routine "get_representation" is endian aware.) Due to changes between Sather 1.1 and Sather 1.0.8 the C function might have to be called "CONVERSION_str_to_flt". It would probably be cleaner to use C_FLT instead of FLT in the external class, and then convert this to FLT later. I think that there is a bug in the Sather 1.1 compiler. When supplying the C file containing the "str_to_flt" routine, I had to say "conversion.o". Saying "conversion.c" didn't work, the generated Makefile was wrong. Nevertheless, the file was compiled automatically. Accessing the string with "arr_part" is not defined in the language, it's just the way the compiler currently does it. It might change in the future. The "real" way of doing it is to add "set_representation" routines to FLT and FLTD. -erik ----- Erik Schnetter, erik.schnetter@student.uni-tuebingen.de From gomes@ICSI.Berkeley.EDU Tue Oct 15 16:35:27 PDT 1996 Article: 3086 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: adding to base objects Date: 15 Oct 1996 21:43:43 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 33 Message-ID: <5410if$45t@agate.berkeley.edu> References: <53tt3l$jcg@tierra.santafe.edu> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <53tt3l$jcg@tierra.santafe.edu>, Bill Macready wrote: > >I have been teaching myself Sather over the past few days and really >like the language. I have perhaps a simple question. I would like to >add new methods to some of the base classes (specifically INT and >ARRAY). I don't want to subclass them. What is the preferred way to >do this? A first question is - what kinds of methods? If these are methods that would be generally useful, if you send them to me, I'd be happy to add them to the standard library. Of course, the standard requirements hold - test out any classes you submit by modifying your own installation of the library and provide test classes for anything you submit. Also, make sure that these methods really do need to be *in* ARRAY or INT i.e. if possible, place them in an "algorithm" class that acts on arrays or integers, just like the GRAPH_ALG classes - the next version of the library will factor out some more functionality into such algorithm classes. If these modifications are purely for your personal use, you could just modify the versions in your installation of the Library. If you cannot/would rather not modify your installation, there is a "not-guaranteed-to-work" way of replacing individual library *files* (note - files, not classes). Just copy the whole file in which the class occurs, modify it and include it among your own source files. The compiler will encounter your own code before it parses the library files. ben From davids@ICSI.Berkeley.EDU Tue Oct 15 16:35:59 PDT 1996 Article: 3085 of comp.lang.sather Path: agate!davids From: davids@ICSI.Berkeley.EDU (David Petrie Stoutamire) Newsgroups: comp.lang.sather Subject: Re: Sather garbage collector Date: 15 Oct 1996 17:16:29 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 34 Message-ID: <540gtd$q3j@agate.berkeley.edu> References: <53v8lj$ouj@cis.clark.edu> NNTP-Posting-Host: icsib18.icsi.berkeley.edu In article <53v8lj$ouj@cis.clark.edu>, Stoian Pavlov wrote: >I've read in a README somwhere in Sather distribution that it'd be >nice if Sather had a custom garbage collector. >Since I wasn't successfull in porting Boehm's GC on Motorola M88K, >I'm very interested in such a thing. Has anyone done it? >Or, is there any work in progress in that direction? I have a custom GC running as part of my thesis work, and it will become part of the Sather distribution when I am comfortable with releasing it. Like any collector, it has some operating system specific code. In my opinion, the Boehm collector is quite well-written and portable, given the fundamentally non-portable problem it addresses. The essential difficulty is in identifying the root set (ie. registers, stack and dynamic library areas). This operating system and HW dependency isn't obviated by having a custom GC collector. The advantage of a custom collector is in performance, not portability. With that in mind, I decided to not try to supplant the Boehm collector as the default, portable memory management facility of Sather, merely make my GC available. However, my collector will be the only option for distributed pSather garbage collection, since the Boehm collector can't span address spaces. Hans has been very responsive to bug reports and performance issues in the past, so I encourage anyone having trouble with his collector to contact him, after you've tried everything you can think of yourself. - Dave -- David Stoutamire http://www.icsi.berkeley.edu/~davids From gomes@ICSI.Berkeley.EDU Tue Oct 15 16:36:25 PDT 1996 Article: 3081 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: How to exec external command? Date: 12 Oct 1996 08:10:25 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 17 Message-ID: <53njph$4ho@agate.berkeley.edu> References: <537h4c$rdd@nh1.u-aizu.ac.jp> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <537h4c$rdd@nh1.u-aizu.ac.jp>, Yasuhiro Abe wrote: >Hello. > >I want to know how to execute external program >(xeyes, xbiff, etc) from sather program. >I'm looking for a class worked similar system() in C. >Please tell me the way. > Use the routine UNIX::system("xeyes"); It is simply a wrapper function in Sather. In general, you can write such wrapper functions by using external classes. See the spec or manual for more details... ben From gomes@ICSI.Berkeley.EDU Tue Oct 15 16:36:30 PDT 1996 Article: 3082 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Inference of type parameters Date: 14 Oct 1996 00:25:54 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 68 Message-ID: <53s1ai$pib@agate.berkeley.edu> NNTP-Posting-Host: samosa.icsi.berkeley.edu A few days back Ari brought up the idea of using type inference to infer some of the type parameters in a parametrized class - I believe I know a way to do it (in the examples below, I'm just using the graph classes as a generic example - the classes don't necessarily correspond exactly to the library versions). As Ari pointed out,it would be nice to be able to say GRAPH_ALG{MY_GRAPH}::do_foo rather than GRAPH_ALG{NODE_TYPE,EDGE_TYPE,MY_GRAPH}::do_foo Very often, the type of the component parameters can be inferred from the typebound i.e. in class GRAPH_ALG{NTP,ETP,GTP<$GRAPH{NTP,ETP}} it should be possible to infer the type of NTP and ETP for any given parametrization. However, a problem can arise because a single graph class can subtype multiple times from the same abstract type. MY_GRAPH < $GRAPH{MYNODE,MYEDGE},$GRAPH{MYOTHERNODE,MYOTHEREDGE} In this case, it would not be possible to infer whether NTP should be MYNODE or MYOTHERNODE - both are valid. This situation can occur in complicated ways that are not immediately evident, but break compositionality. However, note that this problem does not arise whenever the parameter type is used as a return type in one of the methods of the abstraction. i.e. if there is some method class $GRAPH{NTP,ETP} is node!:NTP; edge!:ETP; end; it is not possible to subtype from multiple versions of $GRAPH, since the different versions of node! and edge! could not overload (they only differ in their return type). Using this fact, we can solve the problem as follows. Introduce a typeof() operator to indicate the "inferred" types as shown below: GRAPH_ALG{GTP<$GRAPH{NTP,ETP}}{NTP=typeof(GTP::node!),ETP=typeof(GTP::edge!)} The use of the typeof operator ensures that *there is at least one method with the appropriate type as the return value*, which is the condition required to make the type inference unambiguous. Other languages make use of similar operators, but I'm not sure if they do it for exactly the same reasons. This seems to greatly ameliorate the problem of the size of the names of parametrized classes, without affecting the semantics. ben p.s. The other way to reduce the number of parameters is to make use of dispatching: class GRAPH_ALG{NTP,ETP} is GRAPH_ALG{NTP,ETP,$GRAPH{NTP,ETP} end; However, this does not reduce the number of parameters as much and can be significantly less efficient. From spi@lio.fmi.uni-sofia.bg Wed Oct 16 16:58:32 PDT 1996 Article: 3084 of comp.lang.sather Path: agate!biosci!news.Stanford.EDU!nntp-hub2.barrnet.net!cpk-news-hub1.bbnplanet.com!www.nntp.primenet.com!nntp.primenet.com!enews.sgi.com!arclight.uoregon.edu!news-peer.gsl.net!news.gsl.net!news.mathworks.com!uunet!in1.uu.net!netnews.nwnet.net!news.clark.edu!lio.fmi.uni-sofia.bg!spi From: spi@lio.fmi.uni-sofia.bg (Stoian Pavlov) Newsgroups: comp.lang.sather Subject: Sather garbage collector Date: 15 Oct 1996 05:49:39 GMT Organization: Sofia University Lines: 10 Message-ID: <53v8lj$ouj@cis.clark.edu> NNTP-Posting-Host: lio.fmi.uni-sofia.bg X-Newsreader: TIN [version 1.2 PL2] I've read in a README somwhere in Sather distribution that it'd be nice if Sather had a custom garbage collector. Since I wasn't successfull in porting Boehm's GC on Motorola M88K, I'm very interested in such a thing. Has anyone done it? Or, is there any work in progress in that direction? Thanks. -velco From davids@ICSI.Berkeley.EDU Wed Oct 16 16:58:37 PDT 1996 Article: 3085 of comp.lang.sather Path: agate!davids From: davids@ICSI.Berkeley.EDU (David Petrie Stoutamire) Newsgroups: comp.lang.sather Subject: Re: Sather garbage collector Date: 15 Oct 1996 17:16:29 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 34 Message-ID: <540gtd$q3j@agate.berkeley.edu> References: <53v8lj$ouj@cis.clark.edu> NNTP-Posting-Host: icsib18.icsi.berkeley.edu In article <53v8lj$ouj@cis.clark.edu>, Stoian Pavlov wrote: >I've read in a README somwhere in Sather distribution that it'd be >nice if Sather had a custom garbage collector. >Since I wasn't successfull in porting Boehm's GC on Motorola M88K, >I'm very interested in such a thing. Has anyone done it? >Or, is there any work in progress in that direction? I have a custom GC running as part of my thesis work, and it will become part of the Sather distribution when I am comfortable with releasing it. Like any collector, it has some operating system specific code. In my opinion, the Boehm collector is quite well-written and portable, given the fundamentally non-portable problem it addresses. The essential difficulty is in identifying the root set (ie. registers, stack and dynamic library areas). This operating system and HW dependency isn't obviated by having a custom GC collector. The advantage of a custom collector is in performance, not portability. With that in mind, I decided to not try to supplant the Boehm collector as the default, portable memory management facility of Sather, merely make my GC available. However, my collector will be the only option for distributed pSather garbage collection, since the Boehm collector can't span address spaces. Hans has been very responsive to bug reports and performance issues in the past, so I encourage anyone having trouble with his collector to contact him, after you've tried everything you can think of yourself. - Dave -- David Stoutamire http://www.icsi.berkeley.edu/~davids From jouko.holopainen@xnet.otm.fi Wed Oct 16 16:58:43 PDT 1996 Article: 3088 of comp.lang.sather Path: agate!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!nntp.inet.fi!news.funet.fi!news.otol.fi!news.netppl.fi!not-for-mail From: Jouko Holopainen Newsgroups: comp.lang.sather Subject: Re: Sather garbage collector Date: Wed, 16 Oct 1996 16:33:40 +0300 Organization: X-Net Oy Lines: 36 Message-ID: <3264E433.262E@xnet.otm.fi> References: <53v8lj$ouj@cis.clark.edu> <540gtd$q3j@agate.berkeley.edu> Reply-To: jouko.holopainen@xnet.otm.fi NNTP-Posting-Host: 194.136.175.156 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (Win95; I) David Petrie Stoutamire wrote: > In my opinion, the Boehm collector is quite well-written and portable, > given the fundamentally non-portable problem it addresses. The essential > difficulty is in identifying the root set (ie. registers, stack and > dynamic library areas). This operating system and HW dependency isn't > obviated by having a custom GC collector. Biggest problem (IMO) with Boehm GC is that it is not deterministic. Besides, I think that if a language is designed to have GC, it should have real (cooperative) GC. > The advantage of a custom collector is in performance, not portability. Boehm GC assumes knowledge of memory map etc. Not very portable I think. A simple GC done with e.g. reference counts is much more portable and robust. I am not enough language expert to judge if this kind of GC is possible with Sather. (If not, why bother to have any GC at all?) > With that in mind, I decided to not try to supplant the Boehm collector as > the default, portable memory management facility of Sather, merely make my > GC available. However, my collector will be the only option for > distributed pSather garbage collection, since the Boehm collector can't > span address spaces. Could we get a glimpse of it's implementation details? > - Dave -- Jouko Holopainen X-Net Oy http://www.otm.fi/xnet/ Teknologiantie 4 FIN-90570 Oulu FINLAND Tel: +358 8 551 5693 jouko.holopainen@xnet.otm.fi From davids@ICSI.Berkeley.EDU Wed Oct 16 17:02:23 PDT 1996 Article: 3089 of comp.lang.sather Path: agate!davids From: davids@ICSI.Berkeley.EDU (David Petrie Stoutamire) Newsgroups: comp.lang.sather Subject: Re: Sather garbage collector Date: 16 Oct 1996 17:00:43 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 81 Message-ID: <5434br$2ql@agate.berkeley.edu> References: <53v8lj$ouj@cis.clark.edu> <540gtd$q3j@agate.berkeley.edu> <3264E433.262E@xnet.otm.fi> NNTP-Posting-Host: icsib18.icsi.berkeley.edu In article <3264E433.262E@xnet.otm.fi>, Jouko Holopainen wrote: >Biggest problem (IMO) with Boehm GC is that it is not deterministic. >... >Boehm GC assumes knowledge of memory map etc. Not very portable I think. I was scratching my head, trying to figure out how you thought a GC could be written that was deterministic, that *didn't* know about the stack etc., until I read: >A simple GC done with e.g. reference counts is much more portable and >robust. >I am not enough language expert to judge if this kind of GC is possible >with >Sather. (If not, why bother to have any GC at all?) Now I see the why there is a misunderstanding. I consider reference counting to be just barely garbage collection. It has severe problems. The first is that it doesn't collect cycles. Second, it blows space in every object for the count and destroys reference locality of a program. In addition to the code needed for updating the counts, every pointer assignment touches both objects involved, which is a horror on a modern memory hierarchy. Picture, for example, a parallel cache coherent machine in which every write flushes the cache block on all other processors. I don't have to access the same data to make the system crawl, all I have to do is pass pointers around to the same object. There are certainly advantages to reference counting; the big one is that you get immediate reclamation without any garbage collect pause, and it can be done purely locally. Reference counting should be viewed as a technique to complement other garbage collection. For example, I considered making the compiler emit reference counting code for objects that the type system could prove do not form cycles. I haven't done it, though, mainly because a good reference count implementation requires effort to avoid updating the counts for register and stack variable assignments whenever possible for efficiency. I do believe that reference counting looks promising for distributed machines, where a full GC is done locally and reference counting is used between nodes because it doesn't require ever stopping the world. I just don't think reference counting is sufficient all by itself. I don't consider the reference counting done in C++ programs through smart pointers acceptable, because it's the worst of all worlds. The programer needs to understand how it works to cooperate in their own memory management. It is in user code, so the compiler can't do the optimizations I describe above. It's arcane, because it relies on transparent overloading of operators. It silently fails to collect cycles. It takes additional space and time, breaks for multithreaded codes without expensive synchronization, and can change the asymptotic behavior on cache-coherent machines. Yuck! >Could we get a glimpse of it's implementation details? It's a distributed stop-the-world mark-sweep collector, with bells and whistles for locality. Small objects are bin allocated and large objects come from a splay tree. Attention is paid to keeping everything aligned to cache blocks and pages. The extra bits for recording where objects begin, which ones have pointers, and what's been marked are kept in a separate bit-table for good locality during GC - objects are never referenced when they don't contain any pointers. After marking, coalescing is done with a sweep through the compact bit tables. The root set is found conservatively but the heap is traversed precisely. Finalization occurs exactly once per object with no guaranteed order, but reclamation of finalized objects doesn't happen until dangling pointers >from other objects waiting to be finalized are no longer possible. I'm not attempting to do incremental or generational collection because it's a lot of work and the payoff is unclear on a distributed system. The locality payoff is expected to be in for the user code in between GC, and I can analyze this separately from the efficiency of the GC. (Of course, an incremental/generational collector changes the tradeoffs but I'd like to prove my point with something simple. My thesis isn't directly about GC, it's about allowing programmers to express locality in a portable and natural way.) - Dave -- David Stoutamire http://www.icsi.berkeley.edu/~davids From bolstad@blad.rtpnc.epa.gov Wed Oct 16 17:03:10 PDT 1996 Article: 3091 of comp.lang.sather Path: agate!newsgate.cuhk.edu.hk!news.uoregon.edu!hunter.premier.net!www.nntp.primenet.com!nntp.primenet.com!cpk-news-hub1.bbnplanet.com!newsfeed.internetmci.com!aanews.merit.net!trixie.rtpnc.epa.gov!usenet From: Mark Bolstad Newsgroups: comp.lang.sather Subject: Re: Sather garbage collector Date: 16 Oct 1996 10:11:48 -0400 Organization: United States Environmental Protection Agency Lines: 74 Message-ID: <5cd8yj578b.fsf@blad.rtpnc.epa.gov> References: <53v8lj$ouj@cis.clark.edu> <540gtd$q3j@agate.berkeley.edu> NNTP-Posting-Host: blad.rtpnc.epa.gov X-Newsreader: Gnus v5.3/Emacs 19.34 Here is what I'd like to see in Sather, specifically regarding the GC. I want to have one development environment (Sather on an SGI), and when I'm ready for distribution to spit out totally stand alone C that I can then compile on any other platform. Maybe this is a compiler option, "-portable", that generates the C and packages up the source for the Boehm collector into a stand-alone directory complete with Makefile. I'm targeting Unix platforms for my application, specifically the following platforms: SGI, Sun, Dec, HP, Cray-C90, Cray T3D. I'm working on a distributed application based on MPI that will (hopefully) use pSather for threaded computation on MP platforms with MPI passing messages between platforms. Speaking of pSather, has it been implemented for IRIX 6.2? This version (the latest) supports POSIX threads which I believe that pSather is based on. There are a specific set of patches required to upgrade the "pushed" 6.2 to run POSIX threads. 2nd issue: What you are saying is that any GC requires OS & H/W dependancies. Is this true? Is there a way for the Boehm collector to generate independant C if it can't determine the machine type? I guess these issues are best addressed by Hans, but I'm interested in other responses. Mark davids@ICSI.Berkeley.EDU (David Petrie Stoutamire) writes: > > In article <53v8lj$ouj@cis.clark.edu>, > Stoian Pavlov wrote: > >I've read in a README somwhere in Sather distribution that it'd be > >nice if Sather had a custom garbage collector. > >Since I wasn't successfull in porting Boehm's GC on Motorola M88K, > >I'm very interested in such a thing. Has anyone done it? > >Or, is there any work in progress in that direction? > > I have a custom GC running as part of my thesis work, and it will become > part of the Sather distribution when I am comfortable with releasing it. > Like any collector, it has some operating system specific code. > > In my opinion, the Boehm collector is quite well-written and portable, > given the fundamentally non-portable problem it addresses. The essential > difficulty is in identifying the root set (ie. registers, stack and > dynamic library areas). This operating system and HW dependency isn't > obviated by having a custom GC collector. > > The advantage of a custom collector is in performance, not portability. > With that in mind, I decided to not try to supplant the Boehm collector as > the default, portable memory management facility of Sather, merely make my > GC available. However, my collector will be the only option for > distributed pSather garbage collection, since the Boehm collector can't > span address spaces. > > Hans has been very responsive to bug reports and performance issues in the > past, so I encourage anyone having trouble with his collector to contact > him, after you've tried everything you can think of yourself. > > - Dave > > -- > David Stoutamire > http://www.icsi.berkeley.edu/~davids -- -- Mark Bolstad Visualization Specialist Martin Marietta Technical Services bolstad@vislab.epa.gov (919)-541-3604 From bguenter@gemprint.com Wed Oct 16 17:06:00 PDT 1996 Article: 3090 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!nntp.portal.ca!news.bc.net!rover.ucs.ualberta.ca!mongol.sasknet.sk.ca!io.innovplace.saskatoon.sk.ca!topaz From: bguenter@gemprint.com (Bruce Guenter) Newsgroups: comp.lang.sather Subject: Sather 1.1 compiler for Win95/NT Date: 16 Oct 1996 15:27:04 GMT Organization: Gemprint Lines: 10 Message-ID: <542ntm$1r0_001@topaz.gemprint.com> NNTP-Posting-Host: topaz.gemprint.com X-Newsreader: News Xpress Version 1.0 Beta #4 Greetings. Is anybody (other than myself) working on building a working compiler for the above platforms? I have gotten as far as building a working executable, but I can't get it to execute without aborting with signal 11. Can anybody help? -- Bruce Guenter, Software Developer, Gemprint Phone(work): (306)934-3511 Fax: (306)249-5128 E-Mail: bguenter@gemprint.com WWW: http://www.qcc.sk.ca/~bguenter From gomes@ICSI.Berkeley.EDU Thu Oct 17 19:26:01 PDT 1996 Article: 3094 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Inference of type parameters Date: 17 Oct 1996 21:54:19 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 22 Message-ID: <5469ub$iu2@agate.berkeley.edu> References: <53s1ai$pib@agate.berkeley.edu> <5403e1$gon@lmfpub.lmf.ericsson.se> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <5403e1$gon@lmfpub.lmf.ericsson.se>, Ari Huttunen wrote: >Would it be possible to use this construct to define new variables >like in the example below? I believe Eiffel has this sort of thing but >uses different syntax. > > tmp:typeof(arr.elt!); > Sure, if the language had such a construct, I don't see why not. Though I have mixed feelings about type inference in general. The biggest use of type inference is in getting around parametrized class names that are yards long. Just having type inference in the class parameters should help that problem a lot. Type inference is great for writing code, but it can make reading code harder. I try to use type inference sparingly in my own code. ben From wgm@santafe.santafe.edu Fri Oct 18 16:50:33 PDT 1996 Article: 3097 of comp.lang.sather Path: agate!biosci!news.Stanford.EDU!nntp-hub2.barrnet.net!cam-news-hub1.bbnplanet.com!news.mathworks.com!uunet!in3.uu.net!news.sandia.gov!tesuque.cs.sandia.gov!SantaFe!santafe!wgm From: wgm@santafe.santafe.edu (Bill Macready) Newsgroups: comp.lang.sather Subject: fortran+sather=? Date: 18 Oct 1996 01:13:28 GMT Organization: The Santa Fe Institute Lines: 30 Message-ID: <546ljo$qd2@tierra.santafe.edu> NNTP-Posting-Host: santafe.santafe.edu I am trying to use the fortran interface in Sather and have run into a problem. I want to call a fortran subroutine which minimizes a function. The fortran function in turn calls a function with signature F_ROUT{F_INTEGER,F_ARRAY{F_DOUBLE},F_DOUBLE,F_ARRAY{F_DOUBE}} which takes as argument the dimension of the input point, the input point, the value of the function at the input point and the gradient of the function at the input point. Here is an example function that I want to test the minimization: cost(n:F_INTEGER, x:F_ARRAY{F_DOUBLE}, f:F_DOUBLE, g:F_ARRAY{F_DOUBLE}) is sum ::= 0.0d; loop i:INT := 0.upto!(n.int-1); sum := sum + x[i]*x[i]; g[i] := #F_DOUBLE(2.0d)* x[i]; end; f := #F_DOUBLE(sum); end; The problem is that there seems to be no way of getting at the components of the F_ARRAY. What does one do?? Thanks for any help, Bill -- Santa Fe Institute wgm@santafe.edu 1399 Hyde Park Road, Santa Fe, New Mexico, 87505 (505)984-8800 From davids@ICSI.Berkeley.EDU Wed Oct 30 12:01:51 PST 1996 Article: 3126 of comp.lang.sather Path: agate!davids From: davids@ICSI.Berkeley.EDU (David Petrie Stoutamire) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Subject: Re: Eiffel and Java Date: 30 Oct 1996 19:58:28 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 58 Message-ID: <558c14$kv1@agate.berkeley.edu> References: <550sm2$sn1@buggy.news.easynet.net> NNTP-Posting-Host: icsib18.icsi.berkeley.edu Xref: agate comp.lang.eiffel:16144 comp.lang.ada:53136 comp.lang.sather:3126 In article , Don Harrison wrote: >Vincent WEBER writes: > >:Sather's contravariant mecanism seem very interesting too, has stronger and >:safer theorical bases... > >Why does Sather use contravariance (apart from the safety issue). You would >expect more specific actions to require more specific parameters. Safety is the primary reason (we claim reason enough!), but it also eliminates runtime checks. (One can still program in a covariant style by placing runtime checks explicitly in the code, but contravariance forces their overhead to be made explicit.) >: Sather also allow sepation between code inclusion and >:subtyping. Is it cleaner, or just more complicated that the universal >:inheritance mecanism ? any comment ?) > >What is the purpose of separating interface and implementation inheritance? >When would you need to inherit an implementation without needing it's interface >as well (and vice versa)? This turns out to be very useful. Sather 1 strictly separates interfaces >from implementations; abstract classes ("interfaces") can't have code in them at all. So entirely different mechanisms are at work for code inclusion and subtyping. For example, there is an abstraction in the Sather 1 library called $SET{T} that has methods like "has(element:T):BOOL". One can build a new implementation of sets which conforms to this interface without using any code from it; and that's pretty much what you want, since the implementations may have little in common. If you want some code shared between them, you build a partial class with that code and include from it in both implementations. This way, a third implementation could be built that doesn't use the shared implementation and it doesn't bother anyone. Sather-K makes slightly different choices, allowing code in abstract classes but still allowing code inclusion without subtyping. I view Sather-K inheritance as the natural consequence of merging Sather 1 abstract and partial classes into a single construct. Something similar is possible in Java, where there can be interfaces with no code (and hence no code inclusion from them). Our experience is that the differences between these languages don't affect the code building experience much, but the separation is really missed as soon as one is forced to go back to a language like C++. More information on Sather is available at: http://www.icsi.berkeley.edu/~sather - Dave -- David Stoutamire http://www.icsi.berkeley.edu/~davids From fjh@mundook.cs.mu.OZ.AU Thu Oct 31 14:24:03 PST 1996 Article: 3128 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!munnari.OZ.AU!cs.mu.OZ.AU!mundook.cs.mu.OZ.AU!fjh From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Subject: Re: Eiffel and Java Date: 30 Oct 1996 17:12:06 GMT Organization: Comp Sci, University of Melbourne Lines: 91 Message-ID: <558296$aqk@mulga.cs.mu.OZ.AU> References: <55562c$nkd@mulga.cs.mu.OZ.AU> NNTP-Posting-Host: mundook.cs.mu.oz.au Xref: agate comp.lang.eiffel:16148 comp.lang.ada:53148 comp.lang.sather:3128 comp.lang.java.advocacy:2441 donh@syd.csa.com.au (Don Harrison) writes: >Fergus Henderson writes: > >:donh@syd.csa.com.au (Don Harrison) writes: >: >:>What is the purpose of separating interface and implementation inheritance? >: >:Suppose I have two existing library classes (perhaps supplied by different >:vendors) which have some commonality, but don't inherit from a common >:base class. In Sather, one can simply create a new interface and >:declare these classes to be instances of this interface, without >:modifying the existing code. > >Sorry. Don't follow. Can you give an example? >Isn't this creating a superclass rather than separating interface and >implementation inheritance? Yes, that is creating a superclass. However, I think it would be impossible to provide this feature in a language like C++ where interface and implementation inheritence are combined. The following is from Stephen Omohundro's article about Sather in Dr. Dobb's: ====================================================================== Separate Implementation and Type Inheritance In most object-oriented languages inheritance both defines the subtype relation and causes the descendant to use an implementation provided by the ancestor. These are quite different notions and confounding them often causes semantic problems. For example, one reason why Eiffel's type system is not statically checkable is that it mandates "covariant" conformance for routine argument types (Meyer, 1992). This means that a routine in a descendant must have argument types which are subtypes of the corresponding argument types in the ancestor. Because of this choice, the compiler cannot ensure argument expressions conform to the argument type of the called routine at compile time. In Sather, inheritance from abstract classes defines subtyping while inheritance >from other classes is used solely for implementation inheritance. This allows Sather to use the statically type-safe contravariant rule for routine argument conformance. ====================================================================== The following is from Benedict A. Gomes' Sather tutorial. ====================================================================== What is the rationale behind supertyping clauses, and how are they used ? You define supertypes of already existing types. The supertype can only contain routines that are found in the subtype i.e. it cannot extend the interface of the subtype. type $IS_EMPTY{T} > FLIST{T}, FSET{T} is is_empty: BOOL; end; The need for supertyping clauses arises from our definitition of type-bounds in parametrized types. Any instantiation of the parameters of a parametrized type must be a subtype of those typebounds. You may, however, wish to create a parametrized type which is instantiated with existing library code which is not already under the typebound you want. For instance, suppose you want to create a class FOO, whose parameters must support both is_eq and is_lt. One way to do this is as follows: class BAR{T} is -- Library class that you can't modify is_eq(o: T): BOOL; is_lt(o: T): BOOL; end; type $MY_BOUND{T} > BAR{T} is is_eq(o: T): BOOL; is_lt(o: T): BOOL; end; class FOO{T < $MY_BOUND{T}} is some_routine is -- uses the is_eq and is_lt routines on objects of type T a,b,c: T; if (a < b or b = c) then .. end; end; end; Thus, supertyping provides a convenient method of parametrizing containers, so that they can be instantiated using existing classes. ====================================================================== -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From mernst@x4u2.desy.de Fri Nov 1 12:32:09 PST 1996 Article: 3133 of comp.lang.sather Path: agate!howland.erols.net!feed1.news.erols.com!uunet!in2.uu.net!Gamma.RU!srcc!Radio-MSU.net!dscomsa.desy.de!x4u2!mernst From: mernst@x4u2.desy.de (Matthias Ernst) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Subject: Re: Eiffel and Java Followup-To: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Date: 1 Nov 1996 12:51:44 GMT Organization: DESY Lines: 61 Message-ID: <55crp0$qn9@dscomsa.desy.de> References: <550sm2$sn1@buggy.news.easynet.net> NNTP-Posting-Host: x4u2.desy.de X-Newsreader: TIN [version 1.2 PL2] Xref: agate comp.lang.eiffel:16180 comp.lang.ada:53225 comp.lang.sather:3133 Don Harrison (donh@syd.csa.com.au) wrote: : Why does Sather use contravariance (apart from the safety issue). You would : expect more specific actions to require more specific parameters. : : Sather also allow sepation between code inclusion and : :subtyping. Is it cleaner, or just more complicated that the universal : :inheritance mecanism ? any comment ?) : What is the purpose of separating interface and implementation inheritance? : When would you need to inherit an implementation without needing it's interface : as well (and vice versa)? All languages that unify inheritance and subtyping enforce that once you inherit from a class you build a subtype. There are several examples (mostly with binary methods and the type Self, SAME, like Current or whatever) that show that it may be the implementation you are interested in but you can't guarantee subtype relationship. Say: class Comparable is "<="(other: Self): Bool is abstract; ">="(other: Self): Bool is other <= self end; ">"(other: Self): Bool is ~(self <= other) end; "<"(other: Self): Bool is other > self end; end; You are likely interested to inherit from this class and only implement "<=" but as we all know subtyping is impossible because of the contravariant position of the Self parameters. When you look at the examples that claim for covariance you will see that many are not interested in subtyping, i.e. subsumption, but gather advantage only from code reuse. There are already many publications about this topic, you may want to search for 'binary methods', 'inheritance is not subtyping', 'type matching', 'F-bounded subtyping' and so on. Look for Kim Bruce, Cardelli, Castagna and many more. As far as I understand it correctly, it is about what Eiffel's new typechecking rules with respect to 'polymorphic catcalls' express: 'If it serves your purpose you may, while inheriting, change parameters or variable types or access rules in an incompatible (i.e. subtype breaking) way. But if you try to use subsumption I (the typechecker) will catch you, requiring programm data flow analysis.' Sather says: 'You may change what you want when inheriting since for subsumption you must separately obey the subtype relation that I can check locally.' which I like better. One should not forget that Sather's rules also have disadvantages. Because of the freedom you have it's nearly impossible to check routines once in the superclass and then inherit them unchecked. The Sather compiler must recheck every inherited routine in the context of its new class. -- Matthias From wclodius@lanl.gov Fri Nov 1 12:32:47 PST 1996 Article: 3134 of comp.lang.sather Path: agate!howland.erols.net!newsfeed.internetmci.com!ncar!newshost.lanl.gov!usenet From: William Clodius Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Subject: Re: Eiffel and Java Date: Fri, 01 Nov 1996 10:45:45 -0700 Organization: Los Alamos National Lab Lines: 25 Message-ID: <327A3749.41C6@lanl.gov> References: <550sm2$sn1@buggy.news.easynet.net> <55crp0$qn9@dscomsa.desy.de> NNTP-Posting-Host: hotspec.lanl.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0S (X11; I; IRIX 6.2 IP22) Xref: agate comp.lang.eiffel:16183 comp.lang.ada:53228 comp.lang.sather:3134 Matthias Ernst wrote: > > All languages that unify inheritance and subtyping enforce that once you > inherit from a class you build a subtype. There are several examples (mostly > with binary methods and the type Self, SAME, like Current or whatever) that > show that it may be the implementation you are interested in but you can't > guarantee subtype relationship. > The above restriction is true only if you maintain single dispatch, as in most object oriented languages. However, I suspect that most programmers would find that the work required to maintain full sub-typing relations with multiple dispatch to be more effort than is justifiable and the result would be semantically error prone even if nominal type consistency is maintained. Most related objects should not satisfy the subtype/supertype relationship, and making them satisfy such a relationship can result in code that does not enforce encapsulation. Local type consistency, see for example the work on Cecil, may be more useful -- William B. Clodius Phone: (505)-665-9370 Los Alamos National Laboratory Email: wclodius@lanl.gov Los Alamos, NM 87545 From gomes@ICSI.Berkeley.EDU Fri Nov 1 12:46:11 PST 1996 Article: 3138 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Subject: Re: Eiffel and Java Date: 1 Nov 1996 20:45:39 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 24 Message-ID: <55dnhj$5sg@agate.berkeley.edu> References: <550sm2$sn1@buggy.news.easynet.net> <55crp0$qn9@dscomsa.desy.de> NNTP-Posting-Host: samosa.icsi.berkeley.edu Xref: agate comp.lang.eiffel:16190 comp.lang.ada:53236 comp.lang.sather:3138 In article <55crp0$qn9@dscomsa.desy.de>, Matthias Ernst wrote: > >One should not forget that Sather's rules also have disadvantages. Because >of the freedom you have it's nearly impossible to check routines once in the >superclass and then inherit them unchecked. The Sather compiler must recheck >every inherited routine in the context of its new class. > Though Sather does not do this, it would be easy at the language level to define a form of code inclusion that avoids this problem - there have been proposals to this effect- by providing the sort of encapsulated code inclusion that you get in Java. Since code inclusion is essentially a syntactic operation, new forms of code inclusion do not really impact other aspects of the language - they can be viewed as different kinds of macro operators. IMHO, this encapsulated form of code inclusion should actually be the default, though the current, looser version should still be possible. ben From donh@syd.csa.com.au Sun Nov 3 14:44:05 PST 1996 Article: 3154 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.sather Path: agate!howland.erols.net!www.nntp.primenet.com!nntp.primenet.com!news.cais.net!in1.nntp.cais.net!news.vbc.net!vbcnet-west!news.mira.net.au!news.netspace.net.au!news.mel.connect.com.au!news.syd.connect.com.au!syd.csa.com.au!news From: donh@syd.csa.com.au (Don Harrison) Subject: Eiffel and Sather X-Nntp-Posting-Host: dev11 Message-ID: Sender: news@syd.csa.com.au Reply-To: donh@syd.csa.com.au Organization: CSC Australia, Sydney References: <558c14$kv1@agate.berkeley.edu> Date: Fri, 1 Nov 1996 06:35:13 GMT Lines: 18 Xref: agate comp.lang.eiffel:16233 comp.lang.sather:3154 Thanks to the Sather people who responded to my queries about: - Separation of subtyping from code inclusion - Contravariance - Supertyping. I'll need to go away and digest what I can before pursuing it further. Had a brief look at the Sather home page to see what was there. Hopefully, I can print some stuff off next week. The penny may also be dropping on Bertrand's new System Validity Rules. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au From shang@corp.mot.com Sun Nov 3 14:44:47 PST 1996 Article: 3143 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!nntp.primenet.com!news-peer.gsl.net!news.gsl.net!hammer.uoregon.edu!news.uoregon.edu!news.u.washington.edu!uw-beaver!uw-coco!news-wa16.mdd.comm.mot.com!lego.wes.mot.com!mothost.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Re: Eiffel and Java Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Thu, 31 Oct 1996 16:22:18 GMT Message-ID: <1996Oct31.162218.8386@schbbs.mot.com> References: <55562c$nkd@mulga.cs.mu.OZ.AU> Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 59 Xref: agate comp.lang.eiffel:16209 comp.lang.ada:53276 comp.lang.sather:3143 comp.lang.java.advocacy:2505 comp.object:57401 In article <55562c$nkd@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: > Suppose I have two existing library classes (perhaps supplied by different > vendors) which have some commonality, but don't inherit from a common > base class. In Sather, one can simply create a new interface and > declare these classes to be instances of this interface, without > modifying the existing code. > > (Is that possible in Java?) > No. Java supports only top-down class hierarchy construction (from superclass to subclasses), but not bottom-up: from subclasses to superclass. But Sather's superclass construction is limited to non-parametrerized classes only. Transframe provides a more powerful superclass construction that can support parameterized classes. Suppose we have two existing classes class Stack #(MemberType: type of any) { function push(MemberType); function pop:MemberType; } class Queue #(MemberType: type of any) { function push(MemberType); function pop:MemberType; } and later, we decide to have a superclass from them, we can have class StackOrQueue #(MemberType: type of any) is super Stack, Queue { function push(MemberType); function pop:MemberType; } without modifying the existing subclasses. Now, we can write polymophic code like: x: StackOrQueue; if (some_condition) x = Stack#(T1)(); else x:=Queue#(T2)(); y: any = GetObject(); assume (y is x#.MemberType) x.push(y); otherwise do_nothing(); We can do the push without knowing whether "x" is a queue or a stack; we don't know the exact member type either, the type assurance statement will guarantee that the program free of run-time type exceptions. David Shang From jsa@alexandria Sun Nov 3 14:45:13 PST 1996 Article: 3140 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!howland.erols.net!feed1.news.erols.com!uunet!in2.uu.net!alexandria.organon.com!alexandria!jsa From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java In-Reply-To: shang@corp.mot.com's message of Thu, 31 Oct 1996 16:22:18 GMT Message-ID: Sender: news@organon.com (news) Organization: Organon Motives, Inc. References: <55562c$nkd@mulga.cs.mu.OZ.AU> <1996Oct31.162218.8386@schbbs.mot.com> Date: Fri, 1 Nov 1996 23:24:22 GMT Lines: 113 Xref: agate comp.lang.eiffel:16193 comp.lang.ada:53248 comp.lang.sather:3140 comp.lang.java.advocacy:2496 comp.object:57369 In article <1996Oct31.162218.8386@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes: > In article <55562c$nkd@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus > Henderson) writes: > > Suppose I have two existing library classes (perhaps supplied by different > > vendors) which have some commonality, but don't inherit from a common > > base class. In Sather, one can simply create a new interface and > > declare these classes to be instances of this interface, without > > modifying the existing code. > > > > (Is that possible in Java?) > > > > No. Java supports only top-down class hierarchy construction > (from superclass to subclasses), but not bottom-up: from > subclasses to superclass. But in general it is _trivial_ to do in Ada. Note that "inheritance" aspects need not (and typically will not) even enter into the "equation" since the functionality is provided by separating the "module" aspect of class from the "type" aspect and allowing the module aspect to have separate spec. and impl. > Suppose we have two existing classes > > class Stack #(MemberType: type of any) > { > function push(MemberType); > function pop:MemberType; > } > class Queue #(MemberType: type of any) > { > function push(MemberType); > function pop:MemberType; > } > > and later, we decide to have a superclass from them, we can have > > class StackOrQueue #(MemberType: type of any) > is super Stack, Queue > { > function push(MemberType); > function pop:MemberType; > } > > without modifying the existing subclasses. > > Now, we can write polymophic code like: > > x: StackOrQueue; > if (some_condition) x = Stack#(T1)(); else x:=Queue#(T2)(); > y: any = GetObject(); > assume (y is x#.MemberType) x.push(y); otherwise do_nothing(); OK, this example is a little more involved... with Stacks; -- Generic with Queues; -- Generic generic type Any_Obj is tagged private; package Stack_Or_Queue package S is new Stacks(Any_Obj); package Q is new Queues(Any_Obj); type Any is access all Any_Obj'Class; type Stack_Queue ( S : access S.Stack; Q : access Q.Queue ) is private; ... procedure Push (Element : Any; Onto : Stack_Queue); function Pop (SQ : Stack_Queue) return Any; ... private type Stack_Queue ... ... end Stack_Or_Queue; with Stack_Or_Queue; ... package SQ_T1 is new Stack_Or_Queue(T1); package ST1 renames SQ_T1.S; package SQ_T2 is new Stack_Or_Queue(T2); package QT2 renames SQ_T2.Q; ... S : ST1; Q : QT2; ... if (some condition) then declare X : SQ_T1(S, null); -- X is a stack of T1s Y : SQ_T1.Any := Get_Object; begin push(Y, Onto => X); end; else declare X : SQ_T2(null, Q); -- X is a queue of T2s Y : SQ_T2.Any := Get_Object; begin ... end if; ... /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com From fjh@murlibobo.cs.mu.OZ.AU Sun Nov 3 14:45:44 PST 1996 Article: 3145 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!munnari.OZ.AU!cs.mu.OZ.AU!murlibobo.cs.mu.OZ.AU!fjh From: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Subject: Re: Eiffel and Java Date: 2 Nov 1996 12:14:09 GMT Organization: Comp Sci, University of Melbourne Lines: 57 Message-ID: <55fduh$6nc@mulga.cs.mu.OZ.AU> References: <55562c$nkd@mulga.cs.mu.OZ.AU> <1996Oct31.162218.8386@schbbs.mot.com> NNTP-Posting-Host: murlibobo.cs.mu.oz.au Xref: agate comp.lang.eiffel:16212 comp.lang.ada:53280 comp.lang.sather:3145 comp.lang.java.advocacy:2509 comp.object:57404 jsa@alexandria (Jon S Anthony) writes: ]shang@corp.mot.com (David L. Shang) writes: ] ]> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: ]> > Suppose I have two existing library classes (perhaps supplied by different ]> > vendors) which have some commonality, but don't inherit from a common ]> > base class. In Sather, one can simply create a new interface and ]> > declare these classes to be instances of this interface, without ]> > modifying the existing code. ]> > ]> > (Is that possible in Java?) ]> ]> No. Java supports only top-down class hierarchy construction ]> (from superclass to subclasses), but not bottom-up: from ]> subclasses to superclass. Why not? I would have thought that since Java has separate interface inheritence already, it would not be difficult to provide this feature. ]But in general it is _trivial_ to do in Ada. I'm skeptical. ]with Stacks; -- Generic ]with Queues; -- Generic ]generic ] type Any_Obj is tagged private; ]package Stack_Or_Queue ] ] package S is new Stacks(Any_Obj); ] package Q is new Queues(Any_Obj); ] ] type Any is access all Any_Obj'Class; ] type Stack_Queue ( S : access S.Stack; Q : access Q.Queue ) is private; ]... ]procedure Push (Element : Any; Onto : Stack_Queue); ]function Pop (SQ : Stack_Queue) return Any; ]... ]private ] type Stack_Queue ... ]... ]end Stack_Or_Queue; Can I use this stack_or_queue interface to access different implementations of the stack type (e.g. using arrays or using linked lists?) How about priority_queues? With the Sather version, anything that implements push and pop can be declared to implement the stack_or_queue interface. It looks like your stack_or_queue interface has exactly two implementations and can't be extended. (And that's despite being much more verbose and complicated than the Sather version.) -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From jsa@alexandria Sun Nov 3 14:46:16 PST 1996 Article: 3151 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!howland.erols.net!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!uunet!in2.uu.net!alexandria.organon.com!alexandria!jsa From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java In-Reply-To: fjh@murlibobo.cs.mu.OZ.AU's message of 2 Nov 1996 12:14:09 GMT Message-ID: Sender: news@organon.com (news) Organization: Organon Motives, Inc. References: <55562c$nkd@mulga.cs.mu.OZ.AU> <1996Oct31.162218.8386@schbbs.mot.com> <55fduh$6nc@mulga.cs.mu.OZ.AU> Date: Sun, 3 Nov 1996 01:16:41 GMT Lines: 84 Xref: agate comp.lang.eiffel:16224 comp.lang.ada:53303 comp.lang.sather:3151 comp.lang.java.advocacy:2522 comp.object:57434 In article <55fduh$6nc@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes: > jsa@alexandria (Jon S Anthony) writes: > > ]shang@corp.mot.com (David L. Shang) writes: >... > ]> > ]> No. Java supports only top-down class hierarchy construction > ]> (from superclass to subclasses), but not bottom-up: from > ]> subclasses to superclass. > > Why not? I would have thought that since Java has separate interface > inheritence already, it would not be difficult to provide this feature. David Shang wrote that. And, actually, I would tend to agree with you. So, why would Java have a problem here? > ]But in general it is _trivial_ to do in Ada. > > I'm skeptical. :-). Always a wise stance! Clearly I waxed hyperbolic... > ]with Stacks; -- Generic > ]with Queues; -- Generic > ]generic > ] type Any_Obj is tagged private; > ]package Stack_Or_Queue > ] > ] package S is new Stacks(Any_Obj); > ] package Q is new Queues(Any_Obj); > ] > ] type Any is access all Any_Obj'Class; > ] type Stack_Queue ( S : access S.Stack; Q : access Q.Queue ) is private; > ]... > ]procedure Push (Element : Any; Onto : Stack_Queue); > ]function Pop (SQ : Stack_Queue) return Any; > ]... > ]private > ] type Stack_Queue ... > ]... > ]end Stack_Or_Queue; > > Can I use this stack_or_queue interface to access different > implementations of the stack type (e.g. using arrays or using > linked lists?) Yes. > How about priority_queues? You mean something like, how does this work if you keep extending the queues? That should be OK. If you mean something like, I have a _different_ priority_queue thingy here (not derived from queues) - will it just fit in and work? No, that will require going back and futzing... > With the Sather version, anything that implements push and pop can be > declared to implement the stack_or_queue interface. Good point. > It looks like your stack_or_queue interface has exactly two > implementations and can't be extended. (And that's despite being > much more verbose and complicated than the Sather version.) It has exactly two sorts of _interfaces_ (despite being more verbose and complicated). You can have different implementations of these and that should still work. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com From dbudor@zems.fer.hr Sun Nov 3 14:46:35 PST 1996 Article: 3144 of comp.lang.sather Path: agate!howland.erols.net!newsfeed.internetmci.com!in3.uu.net!01-newsfeed.univie.ac.at!CARNet.hr!not-for-mail From: dbudor@zems.fer.hr (Darko BUDOR) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Subject: Re: Eiffel and Java Followup-To: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Date: 2 Nov 1996 12:39:07 GMT Organization: ZEMS-FER Lines: 40 Distribution: world Message-ID: <55ffdb$cki@bagan.srce.hr> References: <550sm2$sn1@buggy.news.easynet.net> <55562c$nkd@mulga.cs.mu.OZ.AU> NNTP-Posting-Host: diana.zems.fer.hr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Xref: agate comp.lang.eiffel:16211 comp.lang.ada:53279 comp.lang.sather:3144 comp.lang.java.advocacy:2506 Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote: : donh@syd.csa.com.au (Don Harrison) writes: : : >What is the purpose of separating interface and implementation inheritance? : : Suppose I have two existing library classes (perhaps supplied by different : vendors) which have some commonality, but don't inherit from a common : base class. In Sather, one can simply create a new interface and : declare these classes to be instances of this interface, without : modifying the existing code. : : (Is that possible in Java?) Yes, it is. Suppose you have 2 classes from different vendors, class A and class B, with common methods void foo() and void bar(). You can declare an interface for common methods: public interface common { public void foo(); public void bar(); } Now declare 2 new classes: public class MyA extends A implements common { /* need constructors */. }; public class MyB extends B implements common {}; and use MyA and MyB instead of A and B. -- Darko Budor -- budor@fly.cc.fer.hr; dbudor@diana.zems.fer.hr All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. --IBM maintenance manual, 1925 From fjh@murlibobo.cs.mu.OZ.AU Sun Nov 3 14:46:50 PST 1996 Article: 3146 of comp.lang.sather Path: agate!howland.erols.net!newsfeed.internetmci.com!in2.uu.net!munnari.OZ.AU!cs.mu.OZ.AU!murlibobo.cs.mu.OZ.AU!fjh From: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Subject: Re: Eiffel and Java Date: 2 Nov 1996 13:14:38 GMT Organization: Comp Sci, University of Melbourne Lines: 49 Message-ID: <55fhfu$8p0@mulga.cs.mu.OZ.AU> References: <550sm2$sn1@buggy.news.easynet.net> <55562c$nkd@mulga.cs.mu.OZ.AU> <55ffdb$cki@bagan.srce.hr> NNTP-Posting-Host: murlibobo.cs.mu.oz.au Xref: agate comp.lang.eiffel:16213 comp.lang.ada:53281 comp.lang.sather:3146 comp.lang.java.advocacy:2510 dbudor@zems.fer.hr (Darko BUDOR) writes: ]Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote: ]: Suppose I have two existing library classes (perhaps supplied by different ]: vendors) which have some commonality, but don't inherit from a common ]: base class. In Sather, one can simply create a new interface and ]: declare these classes to be instances of this interface, without ]: modifying the existing code. ]: ]: (Is that possible in Java?) ] ]Yes, it is. If your code below is the only way of doing it, then I would say that it *isn't* possible in Java. The code below doesn't do the same thing as the Sather code -- it has significant disadvantages. ]Suppose you have 2 classes from different vendors, class A and ]class B, with common methods void foo() and void bar(). You can declare an ]interface for common methods: ] ]public interface common { ] public void foo(); ] public void bar(); ]} Fine so far... ]Now declare 2 new classes: ] ]public class MyA extends A implements common { ] /* need constructors */. ]}; Disadvantage number one: you have to manually delegate all the constructors. That is tedious and causes maintenance difficulties when someone later adds new constructors for A. ]and use MyA and MyB instead of A and B. Disadvantage number two: you can't use the new interface on the original types. This is *really* bad news. It basically means is that you can't use this method when interfacing with existing code that uses A and B rather than MyA and MyB. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From %%spam repellent: remove this prefix%%kennel@msr.epm.ornl.gov Sun Nov 3 14:47:04 PST 1996 Article: 3152 of comp.lang.sather Path: agate!howland.erols.net!newspump.sol.net!news.mindspring.com!cssun.mathcs.emory.edu!cs.utk.edu!utk.edu!mbk From: mbk@caffeine.engr.utk.edu (Matt Kennel) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Subject: Re: Eiffel and Java Followup-To: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Date: 3 Nov 1996 03:19:39 GMT Organization: University of Tennessee, Knoxville and Oak Ridge National Laboratory Lines: 26 Message-ID: <55h30b$gjk@gaia.ns.utk.edu> References: <550sm2$sn1@buggy.news.easynet.net> <55562c$nkd@mulga.cs.mu.OZ.AU> <55ffdb$cki@bagan.srce.hr> <55fhfu$8p0@mulga.cs.mu.OZ.AU> Reply-To: %%spam repellent: remove this prefix%%kennel@msr.epm.ornl.gov NNTP-Posting-Host: caffeine.engr.utk.edu X-Newsreader: TIN [version 1.2 PL2] Xref: agate comp.lang.eiffel:16225 comp.lang.ada:53306 comp.lang.sather:3152 comp.lang.java.advocacy:2525 Fergus Henderson (fjh@murlibobo.cs.mu.OZ.AU) wrote: : Disadvantage number two: you can't use the new interface on the : original types. This is *really* bad news. It basically means is that : you can't use this method when interfacing with existing code that uses : A and B rather than MyA and MyB. This issue comes about when your library framework which you can't change creates and returns new objects of type A and B. : -- : Fergus Henderson | "I have always known that the pursuit : WWW: | of excellence is a lethal habit" : PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. -- Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ I would not, could not SAVE ON PHONE, |================================== I would not, could not BUY YOUR LOAN, |The US Government does not like I would not, could not MAKE MONEY FAST, |spam either. It is ILLEGAL! I would not, could not SEND NO CA$H, |USC Title 47, section 227 I would not, could not SEE YOUR SITE, |p (b)(1)(C) www.law.cornell.edu/ I would not, could not EAT VEG-I-MITE, | /uscode/47/227.html I do *not* *like* GREEN CARDS AND SPAM! |================================== M A D - I - A M! From mernst@x4u2.desy.de Sun Nov 3 14:47:38 PST 1996 Article: 3157 of comp.lang.sather Path: agate!newsgate.cuhk.edu.hk!hammer.uoregon.edu!hunter.premier.net!www.nntp.primenet.com!nntp.primenet.com!nntp.uio.no!nntp.zit.th-darmstadt.de!fu-berlin.de!news.dfn.de!news.dkrz.de!dscomsa.desy.de!x4u2!mernst From: mernst@x4u2.desy.de (Matthias Ernst) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Subject: Re: Eiffel and Java Followup-To: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Date: 3 Nov 1996 19:22:34 GMT Organization: DESY Lines: 23 Message-ID: <55irdr$hrb@dscomsa.desy.de> References: <550sm2$sn1@buggy.news.easynet.net> <55562c$nkd@mulga.cs.mu.OZ.AU> NNTP-Posting-Host: x4u2.desy.de X-Newsreader: TIN [version 1.2 PL2] Xref: agate comp.lang.eiffel:16235 comp.lang.ada:53327 comp.lang.sather:3157 comp.lang.java.advocacy:2531 Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote: : Suppose I have two existing library classes (perhaps supplied by different : vendors) which have some commonality, but don't inherit from a common : base class. In Sather, one can simply create a new interface and : declare these classes to be instances of this interface, without : modifying the existing code. We have seen examples how to do it in Sather, Transframe, Ada and Java(or not). These are all languages where one explicitly has to annotate in the definition of A or the one of B if A is to be subtype of B. There exist however languages (Emerald, PolyToil, Quest (not even OO), others ?) with structural subtyping which means that a type A automagically is subtype of a type B if it has a conforming interface. This introduces the possibility of 'subtyping by chance' but on the other hand eliminates the problem described above. If you want a supertype just declare it. The existing types will be substitutable for it. I wonder if anyone out there has experience with this form of type system. Though it is easier to use, does one perhaps confuse more easily the type hierachy ? -- Matthias From dbudor@zems.fer.hr Sun Nov 3 16:15:15 PST 1996 Article: 3158 of comp.lang.sather Path: agate!howland.erols.net!news.mathworks.com!uunet!in3.uu.net!01-newsfeed.univie.ac.at!CARNet.hr!not-for-mail From: dbudor@zems.fer.hr (Darko BUDOR) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Subject: Re: Eiffel and Java Followup-To: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy Date: 3 Nov 1996 22:48:18 GMT Organization: ZEMS-FER Lines: 36 Distribution: world Message-ID: <55j7fi$f4d@bagan.srce.hr> References: <550sm2$sn1@buggy.news.easynet.net> <55562c$nkd@mulga.cs.mu.OZ.AU> <55ffdb$cki@bagan.srce.hr> <55fhfu$8p0@mulga.cs.mu.OZ.AU> NNTP-Posting-Host: diana.zems.fer.hr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Xref: agate comp.lang.eiffel:16237 comp.lang.ada:53339 comp.lang.sather:3158 comp.lang.java.advocacy:2532 Fergus Henderson (fjh@murlibobo.cs.mu.OZ.AU) wrote: : ]: (Is that possible in Java?) : ] : ]Yes, it is. : : If your code below is the only way of doing it, then I would say that : it *isn't* possible in Java. The code below doesn't do the same : thing as the Sather code -- it has significant disadvantages. It doesn't do the same thing, but that is as close as you can get. : Disadvantage number one: you have to manually delegate all the constructors. : That is tedious and causes maintenance difficulties when someone later adds : new constructors for A. So you will have to add one to MyA, if you want to use it. I see no problem there. : ]and use MyA and MyB instead of A and B. : : Disadvantage number two: you can't use the new interface on the : original types. This is *really* bad news. It basically means is that : you can't use this method when interfacing with existing code that uses : A and B rather than MyA and MyB. That IS a bit of a problem, but it could be solved with copy constructors in derived classes, IMHO. -- Darko Budor -- budor@fly.cc.fer.hr; dbudor@diana.zems.fer.hr All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. --IBM maintenance manual, 1925 From dongar@earthlink.net Mon Nov 4 12:00:32 PST 1996 Article: 3159 of comp.lang.sather Path: agate!howland.erols.net!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!uunet!in3.uu.net!nntp.earthlink.net!usenet From: "Don Garrett" Newsgroups: comp.lang.sather Subject: Implicit inheritance Date: 3 Nov 96 20:29:43 -0600 Organization: Earthlink Network, Inc. Lines: 37 Message-ID: NNTP-Posting-Host: cust9.max24.dallas.tx.ms.uu.net Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Cyberdog/1.1 X-News-Servers: news.earthlink.net X-Newsgroups-TO: nntp://news.earthlink.net/comp.lang.sather In Sather it is possible to do delayed super typing, but it must be explicitly declared. It seems to me that it is also be possible to allow super type relationships to be automatically discovered at compile time. Whenever an attempt is made to use a concrete type in the context of an abstract type, the current check is to see if there is an immediate or extended inheritance relationship. It should be possible to instead check to see if the concrete types interface conforms to the interface of the abstract type regardless of inheritance. This is a form of dynamic checking, but it is performed entirly at compile time. This seems to me to provice the same degree of safety, but place less burden on the programmer. One specific case would be in the instantiation of parameterized types. One could simply define an abstract type that has the constraints required by the parameterized class and then specialize using any type which meets these requirements. This is superior to C++ since you can still check the correctness of the parameterized class prior to specialization, but it is more elegant (I think) than the current scheme which can call for the creation of dummy classes to help in the delayed super typing process. The only difficulty I see is in resolving calls to overloaded methods when some of the parameters are abstract types, an already complicated scheme would get worse. One could perhaps limit this implicit inheritance to only abstract class that are explictly marked as allowing implicit type inheritance. I'm not really suggesting a change in the Sather language, but I am very curious as to what problems people forsee with this type matching scheme. -- Don Garrett http://www.network-1.com/~garrett/ dongar@earthlink.net From gomes@ICSI.Berkeley.EDU Mon Nov 4 12:00:36 PST 1996 Article: 3162 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Implicit inheritance Date: 4 Nov 1996 19:37:51 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 25 Message-ID: <55lgmf$dbe@agate.berkeley.edu> References: NNTP-Posting-Host: samosa.icsi.berkeley.edu In article , Don Garrett wrote: > In Sather it is possible to do delayed super typing, but it must be >explicitly declared. It seems to me that it is also be possible to allow >super type relationships to be automatically discovered at compile time. > > Whenever an attempt is made to use a concrete type in the context of an >abstract type, the current check is to see if there is an immediate or >extended inheritance relationship. It should be possible to instead check >to see if the concrete types interface conforms to the interface of the >abstract type regardless of inheritance. This is a form of dynamic >checking, but it is performed entirly at compile time. What you suggest (structural conformance), in fact, the approach taken by Sather1.1's sibling language Sather-K and also by the 'where' clauses in Theta. There are pro's, as you and Matt have pointed out, in terms of easing the programmer burden vs making the bounds conceptually clear. However, when using structural conformance, the parameter type is not really in the type hierarchy at all, so it cannot be assigned to variables of other types. This is what leads to problems in resolving issues such as overloaded method invocation in the parametrized class. ben From ok@goanna.cs.rmit.edu.au Mon Nov 4 12:02:20 PST 1996 Article: 3160 of comp.lang.sather Path: agate!howland.erols.net!feed1.news.erols.com!news.ecn.uoknor.edu!munnari.OZ.AU!news.unimelb.EDU.AU!news.rmit.EDU.AU!goanna.cs.rmit.edu.au!not-for-mail From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.object,comp.lang.java.advocacy,comp.lang.c++,comp.lang.smalltalk,comp.lang.clos,fr.comp.objet Subject: Re: Eiffel and Java Date: 4 Nov 1996 18:02:49 +1100 Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 44 Message-ID: <55k4ep$p30$1@goanna.cs.rmit.edu.au> References: <550sm2$sn1@buggy.news.easynet.net> NNTP-Posting-Host: localhost.cs.rmit.edu.au NNTP-Posting-User: ok X-Newsreader: NN version 6.5.1 (NOV) Xref: agate comp.lang.eiffel:16246 comp.lang.ada:53347 comp.lang.sather:3160 comp.object:57476 comp.lang.java.advocacy:2540 comp.lang.c++:224431 comp.lang.smalltalk:46068 comp.lang.clos:3999 fr.comp.objet:310 Sacha@easynet.fr (Vincent WEBER) writes: > By the way, one more thing : I just had a look at ADA 95 and it's "OO" model. >Even if I admit it is powerful, I think it's very heavy. This puzzles me considerably. The Ada 95 OO model is essentially the same as the C++ model, restricted to single inheritance. Unlike OOP in Smalltalk, Simula 67, and the proposed OOP extensions to Pascal, objects need not be referred to via pointers. The syntax is very lightweight as well. >However, one thing interested me : Ada >fanatics claim that the dot notation break the symetry of natural operation, >and that Ada's model of dynamic bindings in all the parameters of a procedure >is better (that is, writing for instance Add(VectorA, VectorB) instead of >VectorA.Plus(VectorB). I don't know what to think about this controversy. Any >idea ? (a) Where did you find any Ada fanatics? People are usually drawn to Ada because they are aware of their own fallibility. (b) It baffles me that this late in the millenium, some people think that whether you write f(x) or x.f is something important. In the Pop family of languages, the two notations have been identical for 3 decades or more. There was a paper from Xerox on uniform reference which probably needs republishing. (c) What _does_ matter is semantics, and here C++ runs into a problem that Ada 95 avoids: an expresssion "a < b" could be interpreted _either_ as a call to a function operator <(a, b) _or_ as a method call a.operator <(b). This can interact with inheritance in surprising ways. > Thanks to anyone that would help to elect my favourite language :) Currently, >I believe that Eiffel is the best OOPL, even if the reality of industry force >me to live the nightmare of C++ everyday :) It sounds as though you have already made your choice. And that without looking at CLOS, or Sather, or Self, or Cecil, or ... -- Mixed Member Proportional---a *great* way to vote! Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. From eachus@spectre.mitre.org Mon Nov 4 17:46:03 PST 1996 Article: 3163 of comp.lang.sather Path: agate!newsgate.cuhk.edu.hk!hammer.uoregon.edu!hunter.premier.net!news.mathworks.com!news.sgi.com!sdd.hp.com!bone.think.com!blanket.mitre.org!news.mitre.org!spectre!eachus From: eachus@spectre.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Subject: Re: Eiffel and Java Followup-To: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Date: 04 Nov 1996 22:38:56 GMT Organization: The Mitre Corp., Bedford, MA. Lines: 67 Message-ID: References: <550sm2$sn1@buggy.news.easynet.net> <55crp0$qn9@dscomsa.desy.de> NNTP-Posting-Host: spectre.mitre.org In-reply-to: mernst@x4u2.desy.de's message of 1 Nov 1996 12:51:44 GMT Xref: agate comp.lang.eiffel:16259 comp.lang.ada:53381 comp.lang.sather:3163 In article <55crp0$qn9@dscomsa.desy.de> mernst@x4u2.desy.de (Matthias Ernst) writes: > All languages that unify inheritance and subtyping enforce that > once you inherit from a class you build a subtype. There are > several examples (mostly with binary methods and the type Self, > SAME, like Current or whatever) that show that it may be the > implementation you are interested in but you can't guarantee > subtype relationship. > class Comparable > is > "<="(other: Self): Bool is abstract; > ">="(other: Self): Bool is other <= self end; > ">"(other: Self): Bool is ~(self <= other) end; > "<"(other: Self): Bool is other > self end; > end;... I think I understand what you want here, but it works fine in Ada 95: package Compare is type Comparable is tagged private; function "<=" (L,R: Comparable) return Boolean is abstract; function ">=" (L,R: Comparable) return Boolean; function ">" (L,R: Comparable) return Boolean; function "<" (L,R: Comparable) return Boolean; private type Comparable is null record; end Compare; package body Compare is function ">=" (L,R: Comparable) return Boolean is begin return R <= L; end ">="; function ">" (L,R: Comparable) return Boolean is begin return not (L <= R); end ">"; function "<" (L,R: Comparable) return Boolean; begin return not (R <= L); end "<"; end Compare; For types derived from Comparable, you only need to define the one inequality operation. The other possibility is that you want a generic template. That works in Ada 95 as well: generic type Comparable is tagged private; with function "<=" (L,R: Comparable) return Boolean is <>; package Compare is function ">=" (L,R: Comparable) return Boolean; function ">" (L,R: Comparable) return Boolean; function "<" (L,R: Comparable) return Boolean; end Compare; package body Compare is -- (same as above) I went through all this because it is one of the cases where the symmetric Ada notation does have technical advantages. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From eachus@spectre.mitre.org Mon Nov 4 21:18:57 PST 1996 Article: 3164 of comp.lang.sather Path: agate!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!us1.rhbnc.ac.uk!yama.mcc.ac.uk!rmplc!rmplc!Aladdin!www.nntp.primenet.com!nntp.primenet.com!enews.sgi.com!news.sgi.com!sdd.hp.com!bone.think.com!blanket.mitre.org!news.mitre.org!spectre!eachus From: eachus@spectre.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Subject: Re: Eiffel and Java Date: 04 Nov 1996 23:44:35 GMT Organization: The Mitre Corp., Bedford, MA. Lines: 35 Message-ID: References: <55562c$nkd@mulga.cs.mu.OZ.AU> <1996Oct31.162218.8386@schbbs.mot.com> <55fduh$6nc@mulga.cs.mu.OZ.AU> NNTP-Posting-Host: spectre.mitre.org In-reply-to: jsa@alexandria's message of Sun, 3 Nov 1996 01:16:41 GMT Xref: agate comp.lang.eiffel:16263 comp.lang.ada:53391 comp.lang.sather:3164 comp.lang.java.advocacy:2553 comp.object:57503 In article jsa@alexandria (Jon S Anthony) writes: > You mean something like, how does this work if you keep extending > the queues? That should be OK. If you mean something like, I > have a _different_ priority_queue thingy here (not derived from > queues) - will it just fit in and work? No, that will require > going back and futzing... This looks like a case where you want interface inheritance, so implement interface inheritance: generic type Stack_or_Queue is limited tagged private; type Element is tagged private; with function Pop(SQ: in Stack_or_Queue) return Element'Class is <>; with procedure Push(E: in Element; Onto: in out Stack_or_Queue) is <>; with function Is_Empty(SQ: in Stack_or_Queue) return Boolean is <>; -- etc. -- your procedure, function, or package goes here. For any Stack, Queue, Deque, etc., which matches the interface you can instantiate your generic. You can even figure out a meaningful definition of Is_Empty for a queue connected to a pipe if that is what you have. (For example, delay until the other end of the pipe is closed and return false, or until another element is put into the pipe and return true.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From shang@corp.mot.com Tue Nov 5 11:00:27 PST 1996 Article: 3166 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!newsgate.cuhk.edu.hk!hpg30a.csc.cuhk.hk!news.cuhk.edu.hk!news.sprintlink.net!news-stk-11.sprintlink.net!www.nntp.primenet.com!nntp.primenet.com!hunter.premier.net!news.uoregon.edu!news.u.washington.edu!uw-beaver!uw-coco!news-wa16.mdd.comm.mot.com!lego.wes.mot.com!mothost.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Re: Eiffel and Java Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Mon, 4 Nov 1996 14:27:15 GMT Message-ID: <1996Nov4.142715.5411@schbbs.mot.com> References: Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 106 Xref: agate comp.lang.eiffel:16265 comp.lang.ada:53398 comp.lang.sather:3166 comp.lang.java.advocacy:2555 comp.object:57507 In article jsa@alexandria (Jon S Anthony) writes: > In article <1996Oct31.162218.8386@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes: > > > No. Java supports only top-down class hierarchy construction > > (from superclass to subclasses), but not bottom-up: from > > subclasses to superclass. > > But in general it is _trivial_ to do in Ada. Note that "inheritance" > aspects need not (and typically will not) even enter into the > "equation" since the functionality is provided by separating the > "module" aspect of class from the "type" aspect and allowing the > module aspect to have separate spec. and impl. > Don't you think that the Ada's code is rather complicated and involves too many concepts to describe things clearly? Transframe's version: use Stack, Queue; class StackOrQueue #(MemberType: type of any) is super Stack, Queue { function push(MemberType); function pop:MemberType; } use StackOrQueue; function MyTestCode() { x: StackOrQueue; if (some_condition) x = Stack#(T1)(); else x:=Queue#(T2)(); y: any = GetObject(); assume (y is x#.MemberType) x.push(y); otherwise do_nothing(); .... } Your Ada's Version: with Stacks; -- Generic with Queues; -- Generic generic type Any_Obj is tagged private; package Stack_Or_Queue package S is new Stacks(Any_Obj); package Q is new Queues(Any_Obj); type Any is access all Any_Obj'Class; type Stack_Queue ( S : access S.Stack; Q : access Q.Queue ) is private; procedure Push (Element : Any; Onto : Stack_Queue); function Pop (SQ : Stack_Queue) return Any; private type Stack_Queue ... end Stack_Or_Queue; with Stack_Or_Queue; package SQ_T1 is new Stack_Or_Queue(T1); package ST1 renames SQ_T1.S; package SQ_T2 is new Stack_Or_Queue(T2); package QT2 renames SQ_T2.Q; S : ST1; Q : QT2; if (some condition) then declare X : SQ_T1(S, null); -- X is a stack of T1s Y : SQ_T1.Any := Get_Object; begin push(Y, Onto => X); end; else declare X : SQ_T2(null, Q); -- X is a queue of T2s Y : SQ_T2.Any := Get_Object; begin ... end if; And the above Ada's code is still not equivalent to Transframe's code. There is no polymophism on the generic class StackOrQueue in Ada's code: the variable "X" is not polymorphic, and is only valid within a local scope. What happen if I want a function to return the value of "X" for other people to use? For example: use StackOrQueue; function CreateStackOrQueue(some_condition: bool): StackOrQueue { x: StackOrQueue; if (some_condition) x := Stack#(T1)(); else x:=Queue#(T2)(); y: any= GetObject(); while (y) { assume (y is x#.MemberType) x.push(y); otherwise do_nothing(); y:= GetObject(); } return x; } David Shang From objcur@wwa.com Tue Nov 5 11:00:37 PST 1996 Article: 3167 of comp.lang.sather Path: agate!newsgate.cuhk.edu.hk!hammer.uoregon.edu!hunter.premier.net!www.nntp.primenet.com!nntp.primenet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!newsfeed.internetmci.com!news.wwa.com!not-for-mail From: Bob Hathaway Newsgroups: comp.object.corba,comp.lang.tcl,comp.lang.python,comp.lang.dylan,comp.lang.clu,comp.lang.sather Subject: Object Currents - ANNOUNCEMENT/CALL FOR PAPERS- Free New Journal Followup-To: comp.object Date: 4 Nov 1996 20:57:22 -0600 Organization: Object Currents Lines: 90 Sender: objcur@sashimi.wwa.com Distribution: inet Message-ID: <55maei$b46@shoga.wwa.com> Reply-To: Bob Hathaway NNTP-Posting-Host: shoga.wwa.com Summary: Object Currents - ANNOUNCEMENT/CALL FOR PAPERS- Free New Journal Keywords: Free WWW OO Object-Oriented Journal Xref: agate comp.object.corba:2851 comp.lang.tcl:57724 comp.lang.python:14901 comp.lang.dylan:7509 comp.lang.clu:322 comp.lang.sather:3167 OBJECT CURRENTS =============== OBJECT CURRENTS ONLINE HYPERTEXT JOURNAL FREE NEW MONTHLY OBJECT-ORIENTED FORUM Location: http://www.sigs.com/objectcurrents/ Editor-In-Chief: Bob Hathaway Issues: January - November, 11 issues. Next Issue: December 1 Publisher: SIGS: C++ Report, JOOP/ROAD, Object Magazine, Object Expert, Smalltalk Report, X Journal, Java Report, Object Buyer's Guide, ... This is an invitation to join us at Object Currents and view, engage in, and participate in the latest in object-oriented technology using the newest in information technology, the WWW. Object Currents is a complete new free monthly journal with original Feature Articles, Columns, and Departments along with several *new* articles from SIGS' Journals. NEW NEWS I am adding a new Web server which should run everything from Object Databases to VRML frames. By next year OCJ should be on the forefront of modern Web technology so stay tuned in - you haven't seen anything yet... OCJ ARTICLES We are accepting original Feature Articles to present in OCJ which include honorarium and the opportunity to publish. Please see our URL for Authors' Guidelines. Object Currents' World Class Columnists: Watts Humphrey: SEI Process Director, CMM & PSP Inventor Bertrand Meyer: Eiffel, OO Design and Software Engineering Francois Bancilhon: President, O2 Technology, Leading ODBMS Expert Michael Jesse Chonoles: Chief of Methodology, Advanced Concepts Center of Lockheed Martin David Shang: OO Programming Language Designer, Motorola Labs Michael Spertus: President, Geodesic Systems, Program Automation Prof. Brain Henderson-Sellers: Director, Centre for Object Technology Applications and Research (Victoria) Ian Mitchell: Heads of Rapid Prototyping Laboratory: http://osiris.sund.ac.uk/research/canopus/mitchell/rpl.html Interviews: January: Grady Booch February: James Rumbaugh March: Ivar Jacobson (Part I) - Get the latest on the UML June: Steve Mellor, Plus Jacobson (Part II) Soon: Sally Shlaer Newsgroup Dialog: - Monthly "Best Thread" from comp.object Robert Martin Week in OT: Jane Grau - Late breaking news on object technology 4 times/month Feature Articles: Too many to repeat here, OCJ has presented over 25 original features on object technology. Departments: Several including Newsgroup Dialog, Editorial, C++ Puzzle, Code Watch, Question + Answer. Best new articles every month from SIGS January thru November issues July 1996 issues including: C++ Report, JOOP/ROAD, Object Magazine, Smalltalk Report, Object Expert, Object Buyer's Guide Thanks to our readership for patronage, praise, and feedback. Please keep visiting or give us a try soon. Please also feel free to inform friends and colleagues of this free new medium. >From the Guidelines: Object Currents' unique hypertext media provides for advances over earlier journals - links to home pages, sites, databases and information servers, interaction, animation, graphics, code retrieval and execution, expanded pages, video, virtual reality and chat sessions. While all of these may not have appeared in these first issues, they will appear in the future. Check it out! Best Regards, Bob Hathaway Robert John Hathaway III Editor in Chief Object Currents Hypertext Journal Email: objcur@wwa.com - Correspondence, Submissions From %%spam repellent: remove this prefix%%kennel@msr.epm.ornl.gov Tue Nov 5 15:56:14 PST 1996 Article: 3168 of comp.lang.sather Path: agate!spool.mu.edu!munnari.OZ.AU!news.Hawaii.Edu!news.uoregon.edu!news.ironhorse.com!op.net!news.mathworks.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!cpk-news-feed4.bbnplanet.com!utk.edu!mbk From: mbk@caffeine.engr.utk.edu (Matt Kennel) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Subject: Re: Eiffel and Java Followup-To: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Date: 5 Nov 1996 18:07:00 GMT Organization: University of Tennessee, Knoxville and Oak Ridge National Laboratory Lines: 137 Message-ID: <55nvo4$mgk@gaia.ns.utk.edu> References: <55ditr$pnh@gaia.ns.utk.edu> <1996Nov4.140227.4601@schbbs.mot.com> Reply-To: %%spam repellent: remove this prefix%%kennel@msr.epm.ornl.gov NNTP-Posting-Host: caffeine.engr.utk.edu X-Newsreader: TIN [version 1.2 PL2] Xref: agate comp.lang.eiffel:16276 comp.lang.ada:53422 comp.lang.sather:3168 comp.lang.java.advocacy:2563 comp.object:57525 David L. Shang (shang@corp.mot.com) wrote: : In article <55ditr$pnh@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel) : writes: : > David L. Shang (shang@corp.mot.com) wrote: : > : But Sather's superclass construction is limited to non-parametrerized : > : classes only. : > : > This isn't true, at least in 1.1. The following compiles and executes. : > : > ------------------------------------------------------- : > -- demonstrate abstract superclass over a parameterized type. : > ------------------------------------------------------- : > abstract class $OVER{T} > $P{T} is : > feature1(arg:T); : > end; : > : > abstract class $P{T} is : > feature1(arg:T); : > feature2(arg:T); : > end; : > : > class CONCRETE{T} < $OVER{T} is : > feature1(arg:T) is #OUT + "In feature\n"; end; : > create:SAME is return new; end; : > end; : > : > : > class MAIN is : > main is : > #OUT + "Hello World.\n"; : > : > ob :$OVER{INT} := #CONCRETE{INT}; : > ob.feature1(42); : > : > end; : > end; : > : Try the following, if Sather's compiler does not complain, then, : Sather's generic class is equivalent to Transframe's: : class MAIN is : main is : #OUT + "Hello World.\n"; : : ob :$OVER; : if (some_input_condition) ob := #CONCRETE{INT}; : else ob = #P(STRING); : : // at this point, we don't know the exact element type of ob : // type assurance must be used : assume (typeof(ob).ElementType is INT) ob.feature1(42); : end; I don't think the generic class concept is the same, but the following appears to do what you desire. The main difference is that in Sather $TYPE{T} and $TYPE are wholly unrelated _a priori_. $TYPE is not a superytpe of $TYPE{T} unless explicitly declared that way, as in this example. --------------------- abstract class $OVER is -- over everything end; abstract class $OVER{T} < $OVER > $P{T} is feature1(arg:T); end; abstract class $P{T} is feature1(arg:T); feature2(arg:T); end; class CONCRETE{T} < $OVER{T} is feature1(arg:T) is #OUT + "In feature\n"; end; create:SAME is return new; end; end; class MAIN is main(args:ARRAY{STR}) is #OUT + "Hello World.\n"; ob :$OVER; if args[1] = "int" then #OUT + "Creating int\n"; ob := #CONCRETE{INT}; else ob := #CONCRETE{STR}; end; typecase ob when $OVER{INT} then ob.feature1(42); else #OUT + "No matching typecase\n"; end; end; end; ------- (~/sather1/hello) caffeine.engr.utk.edu > a.out int Hello World. Creating int In feature (~/sather1/hello) caffeine.engr.utk.edu > a.out other Hello World. No matching typecase (~/sather1/hello) caffeine.engr.utk.edu > ------- : > : Transframe provides a more powerful superclass construction that : > : can support parameterized classes. : > : > : Suppose we have two existing classes : > : .... : > : > I believe that Sather could express the same concept. : > : The concept of generic class in Sather is different than Transframe's. : David Shang -- Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ I would not, could not SAVE ON PHONE, |================================== I would not, could not BUY YOUR LOAN, |The US Government does not like I would not, could not MAKE MONEY FAST, |spam either. It is ILLEGAL! I would not, could not SEND NO CA$H, |USC Title 47, section 227 I would not, could not SEE YOUR SITE, |p (b)(1)(C) www.law.cornell.edu/ I would not, could not EAT VEG-I-MITE, | /uscode/47/227.html I do *not* *like* GREEN CARDS AND SPAM! |================================== M A D - I - A M! From jsa@alexandria Wed Nov 6 16:16:04 PST 1996 Article: 3170 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!www.nntp.primenet.com!nntp.primenet.com!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!alexandria.organon.com!alexandria!jsa From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java In-Reply-To: eachus@spectre.mitre.org's message of 04 Nov 1996 23:44:35 GMT Message-ID: Sender: news@organon.com (news) Organization: Organon Motives, Inc. References: <55562c$nkd@mulga.cs.mu.OZ.AU> <1996Oct31.162218.8386@schbbs.mot.com> <55fduh$6nc@mulga.cs.mu.OZ.AU> Date: Tue, 5 Nov 1996 20:57:16 GMT Lines: 47 Xref: agate comp.lang.eiffel:16284 comp.lang.ada:53453 comp.lang.sather:3170 comp.lang.java.advocacy:2571 comp.object:57541 In article eachus@spectre.mitre.org (Robert I. Eachus) writes: > In article jsa@alexandria (Jon S Anthony) writes: > > > You mean something like, how does this work if you keep extending > > the queues? That should be OK. If you mean something like, I > > have a _different_ priority_queue thingy here (not derived from > > queues) - will it just fit in and work? No, that will require > > going back and futzing... > > This looks like a case where you want interface inheritance, so > implement interface inheritance: > > generic > type Stack_or_Queue is limited tagged private; > type Element is tagged private; > with function Pop(SQ: in Stack_or_Queue) return Element'Class is <>; > with procedure Push(E: in Element; Onto: in out Stack_or_Queue) is <>; > with function Is_Empty(SQ: in Stack_or_Queue) return Boolean is <>; > -- etc. > -- your procedure, function, or package goes here. > > For any Stack, Queue, Deque, etc., which matches the interface you > can instantiate your generic. You can even figure out a meaningful > definition of Is_Empty for a queue connected to a pipe if that is what > you have. (For example, delay until the other end of the pipe is > closed and return false, or until another element is put into the pipe > and return true.) Right. Actually, what occured to me after I wrote that was that this sort of example should be dealt with by means of generic formal package parameters. After all, defining this sort of "generic" signature is one of the very things that they were defined for... I suppose (since I've gone this far along) that I should write up the example using this technique. I am pretty sure it will be about exactly what one wants in this sort of case. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com From jsa@alexandria Wed Nov 6 16:16:12 PST 1996 Article: 3169 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!alexandria.organon.com!alexandria!jsa From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java In-Reply-To: shang@corp.mot.com's message of Mon, 4 Nov 1996 14:27:15 GMT Message-ID: Sender: news@organon.com (news) Organization: Organon Motives, Inc. References: <1996Nov4.142715.5411@schbbs.mot.com> Date: Tue, 5 Nov 1996 21:08:19 GMT Lines: 90 Xref: agate comp.lang.eiffel:16283 comp.lang.ada:53452 comp.lang.sather:3169 comp.lang.java.advocacy:2570 comp.object:57540 In article <1996Nov4.142715.5411@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes: > In article jsa@alexandria (Jon S Anthony) writes: > > But in general it is _trivial_ to do in Ada. Note that "inheritance" > > aspects need not (and typically will not) even enter into the > > "equation" since the functionality is provided by separating the > > "module" aspect of class from the "type" aspect and allowing the > > module aspect to have separate spec. and impl. > > > > Don't you think that the Ada's code is rather complicated and > involves too many concepts to describe things clearly? The "solution" I gave is indeed just plain not the right one. As Robert Eachus pointed out, this is interface inheritance (with the ability to have multipe impls of the interface(s)) and the way this should be handled here is with generic formal packages. I suppose I should write up that solution and see how well it goes (in terms of "verbosity and complex"). > with Stack_Or_Queue; > package SQ_T1 is new Stack_Or_Queue(T1); > package ST1 renames SQ_T1.S; > package SQ_T2 is new Stack_Or_Queue(T2); > package QT2 renames SQ_T2.Q; > S : ST1; > Q : QT2; > if (some condition) then > declare > X : SQ_T1(S, null); -- X is a stack of T1s > Y : SQ_T1.Any := Get_Object; > begin > push(Y, Onto => X); > end; > else > declare > X : SQ_T2(null, Q); -- X is a queue of T2s > Y : SQ_T2.Any := Get_Object; > begin > ... > end if; > > And the above Ada's code is still not equivalent to Transframe's > code. There is no polymophism on the generic class StackOrQueue Actually, there is - but wrt to implementations. > in Ada's code: the variable "X" is not polymorphic, and is only It is on the various possible implementations of Qs & Ss, but not otherwise. > [X..] is only valid within a local scope. What happen if I want a > function to return the value of "X" for other people to use? For > example: Right. > use StackOrQueue; > function CreateStackOrQueue(some_condition: bool): StackOrQueue > { > x: StackOrQueue; > if (some_condition) x := Stack#(T1)(); else x:=Queue#(T2)(); > y: any= GetObject(); > while (y) > { > assume (y is x#.MemberType) x.push(y); > otherwise do_nothing(); > y:= GetObject(); > } > return x; > } Actually, this is not a problem in the above "solution". You can certainly return X from either scope (assuming a function context). I will see how this fits with the "correct" sort of solution using package parameters. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com From tkeitt@santafe.edu Wed Nov 6 16:40:39 PST 1996 Article: 3176 of comp.lang.sather Path: agate!usenet.ins.cwru.edu!news1.cle.ab.com!uunet!in2.uu.net!news.sandia.gov!tesuque.cs.sandia.gov!SantaFe!usenet From: "Timothy H. Keitt" Newsgroups: comp.lang.sather Subject: calling Sather from C Date: Tue, 05 Nov 1996 18:57:22 -0700 Organization: The Santa Fe Institute Lines: 47 Message-ID: <327FF082.87A@santafe.edu> NNTP-Posting-Host: ultra04.santafe.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4u) Hi, I would like to call Sather code from C. I know this sounds odd, but I want to integrate Sather code with C code generated in Khoros (http://www.khoral.com/). Is there a way to make the Sather compiler generate a non-mangled interface to a method? Also, is there a way to stop the compiler from generating a main() function? I'm thinking something like: -- Sather code class KLIB is k_do_something(kfile: C_CHAR_PTR) -- Operates on the khoros data object in kfile is kob ::= #KOBJECT(kfile); ... end; end; /* C code (generated by khoros) */ void main() { char *kfile="myfile.kdf"; k_do_something(kfile); } I know that the call to k_do_something would, in the C generated by Sather, look like KLIB_k_do_something_C_CHAR_PTR((KLIB)klib_struct,...). What I'm wondering is if there is a way to turn off the name mangling of certain methods. Perhaps there could be a "C" prefix for methods so that you could write something like: class KLIB is C k_do_something(...) is ... end; end; Thanks in advance. Tim -- Timothy H. Keitt SFI Postdoctoral Fellow tkeitt@santafe.edu From zxmsv01@hp11.zdv.uni-tuebingen.de Wed Nov 6 16:41:07 PST 1996 Article: 3174 of comp.lang.sather Path: agate!spool.mu.edu!newspump.sol.net!www.nntp.primenet.com!nntp.primenet.com!nntp.uio.no!nntp.zit.th-darmstadt.de!fu-berlin.de!news.belwue.de!newsserv.zdv.uni-tuebingen.de!hp11!zxmsv01 From: zxmsv01@hp11.zdv.uni-tuebingen.de (Erik Schnetter) Newsgroups: comp.lang.sather Subject: Re: calling Sather from C Date: 6 Nov 1996 16:08:05 GMT Organization: InterNetNews at ZDV Uni-Tuebingen Lines: 64 Message-ID: <55qd55$f4f@newsserv.zdv.uni-tuebingen.de> References: <327FF082.87A@santafe.edu> NNTP-Posting-Host: @hp11.zdv.uni-tuebingen.de X-Newsreader: TIN [version 1.2 PL2] Timothy H. Keitt (tkeitt@santafe.edu) wrote: : Hi, : I would like to call Sather code from C. I know this sounds odd, but I : want to integrate Sather code with C code generated in Khoros : (http://www.khoral.com/). Is there a way to make the Sather compiler : generate a non-mangled interface to a method? Also, is there a way to : stop the compiler from generating a main() function? I'm thinking : something like: : -- Sather code : class KLIB is : k_do_something(kfile: C_CHAR_PTR) : -- Operates on the khoros data object in kfile : is : kob ::= #KOBJECT(kfile); : ... : end; : end; : /* C code (generated by khoros) */ : void main() { : char *kfile="myfile.kdf"; : k_do_something(kfile); : } [snip] You want to use external C classes. The solution would look something like external C class KLIB is k_do_something (kfile: C_CHAR_PTR) is ... end; some_khoros_function (some_parameter: C_INT): C_INT; end; External classes can be used in two ways; either to make C functions known to Sather (like 'some_khoros_function'), or to write a Sather function that can be called from C (like 'k_do_something', that is with a routine body). The names of the corresponding C functions are the names that appear in the external C class. Your second problem, namely not generating a main function in the Sather program, is a little bit more difficult. As far as I know the only solution is to replace the name 'main' in the generated C file 'system.c' by somthing like 'start_sather'. You then call 'start_sather' from the Khoros system, causing the Sather runtime system to initialize. From the Sather main routine you then call back the Khoros system which does what the program is intended to do. But this is ugly, because it means changing the generated C code every time you compile the Sather system. Some time ago someone at ICSI agreed to add a command line switch to the Sather compiler; that would be the most elegant solution. I don't think that that has happened yet. Then you'd probably have C funtions called 'startup_sather', 'shutdown_sather', and 'sather_main' that could be called independently. -erik ----- Erik Schnetter, erik.schnetter@student.uni-tuebingen.de From davids@ICSI.Berkeley.EDU Wed Nov 6 16:41:22 PST 1996 Article: 3178 of comp.lang.sather Path: agate!davids From: davids@ICSI.Berkeley.EDU (David Petrie Stoutamire) Newsgroups: comp.lang.sather Subject: Re: calling Sather from C Date: 6 Nov 1996 19:46:00 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 23 Message-ID: <55qpto$s55@agate.berkeley.edu> References: <327FF082.87A@santafe.edu> <55qd55$f4f@newsserv.zdv.uni-tuebingen.de> NNTP-Posting-Host: icsib18.icsi.berkeley.edu In article <55qd55$f4f@newsserv.zdv.uni-tuebingen.de>, Erik Schnetter wrote: >Your second problem, namely not generating a main function in the Sather >program, is a little bit more difficult. As far as I know the only >solution is to replace the name 'main' in the generated C file 'system.c' >by somthing like 'start_sather'. You then call 'start_sather' from the >Khoros system, causing the Sather runtime system to initialize. From the >Sather main routine you then call back the Khoros system which does what the >program is intended to do. > >But this is ugly, because it means changing the generated C code every time >you compile the Sather system. On some systems, clever use of the linker can be used to accomplish the same thing; a dummy routine can be linked to the Sather "main", and then a command line switch is used to allow another "main" to superceed it as the distinguished routine to invoke in the executable. The Sather main can then be accessed by the dummy name. - Dave -- David Stoutamire http://www.icsi.berkeley.edu/~davids From shang@corp.mot.com Thu Nov 7 09:32:20 PST 1996 Article: 3179 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!ihnp4.ucsd.edu!swrinde!tank.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!feed1.news.erols.com!uunet!in1.uu.net!nwnews.wa.com!nwfocus.wa.com!news-wa16.mdd.comm.mot.com!lego.wes.mot.com!mothost.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Re: Eiffel and Java Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Wed, 6 Nov 1996 13:52:31 GMT Message-ID: <1996Nov6.135231.13466@schbbs.mot.com> References: <55nvo4$mgk@gaia.ns.utk.edu> Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 28 Xref: agate comp.lang.eiffel:16311 comp.lang.ada:53524 comp.lang.sather:3179 comp.lang.java.advocacy:2591 comp.object:57587 In article <55nvo4$mgk@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel) writes: > > I don't think the generic class concept is the same, but the following > appears to do what you desire. The main difference is that in Sather > $TYPE{T} and $TYPE are wholly unrelated _a priori_. $TYPE is not a superytpe > of $TYPE{T} unless explicitly declared that way, as in this example. > Correct. That's the major difference. Making $TYPE{T} be subtype of $TYPE without explicit declaration will simplify the type system and avoid redundant class hierarchy. Besides, in Sather code, > typecase ob > when $OVER{INT} then ob.feature1(42); > else #OUT + "No matching typecase\n"; > end; you have to know the exact type of "ob" before you can call "feature1". In Transframe, what you want to assure is just the element type to be "int". You are not necessary to know the enclosing type. David Shang From shang@corp.mot.com Tue Nov 12 20:51:55 PST 1996 Article: 3192 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!spool.mu.edu!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!serv.hinet.net!spring.edu.tw!howland.erols.net!news.sprintlink.net!news-peer.sprintlink.net!uunet!in1.uu.net!nwnews.wa.com!nwfocus.wa.com!news-wa16.mdd.comm.mot.com!lego.wes.mot.com!mothost.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Re: Eiffel and Java Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Tue, 12 Nov 1996 14:34:51 GMT Message-ID: <1996Nov12.143451.16691@schbbs.mot.com> References: <5694r8$c9c@mulga.cs.mu.OZ.AU> Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 99 Xref: agate comp.lang.eiffel:16428 comp.lang.ada:53817 comp.lang.sather:3192 comp.lang.java.advocacy:2668 comp.object:57788 In article <5694r8$c9c@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: > shang@corp.mot.com (David L. Shang) writes: > > But separation subtype from subclass is not [good]. > > Why not? Doesn't this also serve to "reduce the dependency > among software components"? > No, the separation subtype from subclass does not help dependency reduction. Let "A" be a parent class, and "B" be a subclass but not a subtype. "C" cannot use "B" unless it is dependent on "B", because depending on "A" does not provide any polymorphism that can guide the implementation to "B". However, it helps subclass reuse the code in its parent class by violating the constraining requirement regulated by its parent. That is why I say that it is not good. When a subclass has to violate the regulation, either the subclass should not be a child, or the parent class provides a wrong regulation. > ]In Sather, implementation classes are not always subtype of the > ]parent class. They merely reuse the code (inherite the implementation) > ]defined in their parent, but not necessarily be subtype of it. > ]Without subtyping, the interface provided in the parent cannot > ]serve as a polymorphic interface for all the implementations. > > Yes, and that's a good thing, isn't it? > It decouples the interface and the implementation, > making it easier to use a different implementation. > As I stated above, it does not make it easier to use a different implementation, rather, it makes it easier to create a different implementation that is not a subtype, or that violates the parent's regulation. > ]In Java, implementation classes are always subtype of the > ]interface class, but they cannot reuse the code in the interface > ]class, because there is no implementation in the interface. > > So the code is elsewhere, big deal. They can still > reuse it, can't they? > Let's check the client-server architecture. If Server provides only the interface, then the clients must provide all the implementation. No reuse. If Server provides an interface as well as a default implementation or a set of alternative implementations by a number of subclasses of the interface, and if the client wants to reuse the implementation by subclassing, it must inherit the implementation subclass provided by the sever. If server's implementation changes, the client changes because it is dependent on the implementation class. Therefore, the client must reuse the code by aggregation, or by a "use" relation, not by a "is-a" relation. Let "A" be the interface, and "B" be the implementation in the sever. In client, if we want a subclass of "A" to reuse the code of "B" without dependent on "B", we have to write: class C inherit A // cannot inherit B { private A imp; public void A_method1(...) { imp.A_method1(...); }; public int A_method2(...) { return imp.A_method2(...); }; ... A() { imp = new B; }; }; It's kind of cumbersome, isn't it? When mutiple inheritance is invovled, the situition is even more complicated. Transframe's multiple interface inheritance plus implementation delegation provides a perfect way for both subtyping and implementation reuse. Let A1, A2, A3, ... be the interfaces, and B1, B2, B3 be the implementations in the sever. In client, if we want a subclass of A1, A2, A3, ... to reuse the code of B1, B2, B3 without dependent on B1, B2, B3, we can simply write: class C is A1 by B1, A2 by B2, A3 by B3,...; For detail, refer to: Multiple Inheritance -- A Critical Comparion http://www.sigs.com/publications/docs/oc/9611/oc9611.shang.c.html David Shang From shang@corp.mot.com Tue Nov 12 20:52:04 PST 1996 Article: 3191 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!spool.mu.edu!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!arclight.uoregon.edu!news.sprintlink.net!news-peer.sprintlink.net!uunet!in1.uu.net!nwnews.wa.com!nwfocus.wa.com!news-wa16.mdd.comm.mot.com!lego.wes.mot.com!mothost.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Re: Eiffel and Java Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Tue, 12 Nov 1996 14:51:05 GMT Message-ID: <1996Nov12.145105.17219@schbbs.mot.com> References: <1996Nov12.143451.16691@schbbs.mot.com> Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 26 Xref: agate comp.lang.eiffel:16427 comp.lang.ada:53816 comp.lang.sather:3191 comp.lang.java.advocacy:2667 comp.object:57787 In article <1996Nov12.143451.16691@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes: > Let A1, A2, A3, ... be the interfaces, and B1, B2, B3 be the > implementations in the sever. In client, if we want a subclass > of A1, A2, A3, ... to reuse the code of B1, B2, B3 without > dependent on B1, B2, B3, we can simply write: > > class C is A1 by B1, A2 by B2, A3 by B3,...; > Note that C is dependent only on A1, A2, A3,..., but not on B1, B2, B3,.... Server can change or replace the implementation without affecting the client applications. Such implementations can be supplied by other clients. The client "C1" can use the implementation provided by the client "C2" without dependent on "C2". This makes dynamic software components much easier. > For detail, refer to: > > Multiple Inheritance -- A Critical Comparion > http://www.sigs.com/publications/docs/oc/9611/oc9611.shang.c.html > > David Shang > From %%spam repellent: remove this prefix%%kennel@msr.epm.ornl.gov Wed Nov 13 15:42:20 PST 1996 Article: 3193 of comp.lang.sather Path: agate!howland.erols.net!www.nntp.primenet.com!nntp.primenet.com!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!cpk-news-feed4.bbnplanet.com!utk.edu!mbk From: mbk@caffeine.engr.utk.edu (Matt Kennel) Newsgroups: comp.lang.eiffel,comp.lang.sather Subject: Sather version of trivial benchmark (was Re: Benchmark with Source: Eiffel/Jave/C++) Date: 13 Nov 1996 21:04:40 GMT Organization: University of Tennessee, Knoxville and Oak Ridge National Laboratory Lines: 180 Message-ID: <56dd58$sk5@gaia.ns.utk.edu> References: <5602l4$br8@news-central.tiac.net> <564u2s$ea@muller.loria.fr> Reply-To: %%spam repellent: remove this prefix%%kennel@msr.epm.ornl.gov NNTP-Posting-Host: caffeine.engr.utk.edu X-Newsreader: TIN [version 1.2 PL2] Xref: agate comp.lang.eiffel:16439 comp.lang.sather:3193 Dominique Colnet (colnet@loria.fr) wrote: : In article <5602l4$br8@news-central.tiac.net>, jws@tiac.net (Jeffrey W. Stulin) writes: : |> ISE Melted: 0.0015 : |> ISE Frozen: 0.025 : |> ISE Finalized: 1.0 : |> Café 1.5 1.9 : |> Visual Café 3.83 : |> C++ 6.76 I extracted the article and attempted to do a literal translation into Sather of the micro benchmark. First of all, I must comment that there are BUGS in the C++ version that I found. The loop bounds were not thought out correctly: x_size*y_size array elements were allocated, but [0.. x_size,0..y_size] elements were extracted. I.e. as a real C++ program it would have read/written past the ends of the array and done screwy things in the middle. That's a good lesson. I corrected both versions to (Fortran style) index >from 1..size inclusively. (i.e. subtracting 1 from x and y in the 'index routine'.) On my machine, 120 Mhz Pentium, Linux 1.2.13, "g++ -v" gives "gcc version 2.7.2p" The C++ code was compiled with "g++ -O2 main.cc funny.cc". The Sather code was compiled with "cs -main TESTER -O_fast bench.sa", using "gcc -O2" on the generated C. I used 100000 iterations. ------------------------------------------------------------------- Execution time Stripped/Unstripped binary size Sather 1.1: 8.91 sec 33932 / 48315 bytes GNU C++: 25.5 sec 5492 / 31750 bytes Sather 1.1: (alternate) 11.39 sec 33916 / 48066 bytes ------------------------------------------------------------------- What is the 'alternate' version? It uses Sather's standard-library "ARRAY2". This is a more realistic situation, using an array class whose dimensions are NOT fixed at compile time. This is often harder for C++ compilers, as they seem less able to prove that the 'size' attributes of a matrix type are loop invariants. For the Sather executable: (~/sather1/bench) caffeine.engr.utk.edu > ldd a.out libm.so.5 => /lib/libm.so.5.0.5 libc.so.5 => /lib/libc.so.5.2.18 For the C++ executable: (~/sather1/bench/cpp) caffeine.engr.utk.edu > ldd a.out libg++.so.27 => /usr/lib/libg++.so.27.1.0 libstdc++.so.27 => /usr/lib/libstdc++.so.27.1.0 libm.so.5 => /lib/libm.so.5.0.5 libc.so.5 => /lib/libc.so.5.2.18 (~/sather1/bench/cpp) caffeine.engr.utk.edu > Sather statically links in the Boehm et al garbage collector {which does not move live objects} into the executable. -- -- Compilation was as follows: -- "cs -main TESTER -O_fast bench.sa" -- -- begin Sather code class FUNNY_ARRAY is const x_size:= 40; const y_size:= 40; attr body: AREF{INT}; create:SAME is res ::= new; res.body := #(x_size*y_size); return res; end; set(x,y,val:INT) is body[index(x,y)] := val; end; get(x,y:INT):INT is return body[index(x,y)]; end; index(x,y:INT):INT is return (x-1)*x_size + y-1; end; end; -- class FUNNY_ARRAY class TESTER is const number_iterations := 100000; attr x_size,y_size:INT; attr test_body: FUNNY_ARRAY; main is test_body := #FUNNY_ARRAY; x_size := test_body.x_size; y_size := test_body.y_size; loop number_iterations.times!; do_scans; end; end; do_scans is x::= 1; loop until!(x > x_size); y::=1; loop until!(y> y_size); val ::= test_body.get(x,y); test_body.set(x,y,x+y); y:=y+1; end; x := x+1; end; end; end; -- end Sather code. -- Alternate version, using built in ARRAY2 class TESTER2 is const number_iterations := 100000; const x_size := 40; const y_size := 40; attr test_body: ARRAY2{INT}; main is test_body := #ARRAY2{INT}(x_size,y_size); loop number_iterations.times!; do_scans; end; end; do_scans is x::= 0; loop until!(x >= x_size); y::=0; loop until!(y>= y_size); val ::= test_body[x,y]; test_body[x,y] := x+y; y:=y+1; end; x := x+1; end; end; end; ----------- -- tests.cc -- Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ I would not, could not SAVE ON PHONE, |================================== I would not, could not BUY YOUR LOAN, |The US Government does not like I would not, could not MAKE MONEY FAST, |spam either. It is ILLEGAL! I would not, could not SEND NO CA$H, |USC Title 47, section 227 I would not, could not SEE YOUR SITE, |p (b)(1)(C) www.law.cornell.edu/ I would not, could not EAT VEG-I-MITE, | /uscode/47/227.html I do *not* *like* GREEN CARDS AND SPAM! |================================== M A D - I - A M! From aster@horz.technopark.gmd.de Fri Nov 15 14:14:54 PST 1996 Article: 3195 of comp.lang.sather Path: agate!howland.erols.net!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!fu-berlin.de!news-ber1.dfn.de!news-ham1.dfn.de!news-han1.dfn.de!news-koe1.dfn.de!RRZ.Uni-Koeln.DE!nntp.gmd.de!newsmaster From: Alexander Asteroth Newsgroups: comp.lang.sather Subject: Re: calling Sather from C Date: Fri, 15 Nov 1996 10:49:58 +0100 Organization: GMD, Sankt Augustin, Germany Lines: 27 Message-ID: <328C3CC6.44B54176@horz.technopark.gmd.de> References: <327FF082.87A@santafe.edu> <55qd55$f4f@newsserv.zdv.uni-tuebingen.de> Reply-To: Alexander Asteroth NNTP-Posting-Host: fly.horz.technopark.gmd.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.11 i586) CC: Alexander Asteroth Hi, zxmsv01@hp11.zdv.uni-tuebingen.de (Erik Schnetter) writes: > External classes can be used in two ways; either to make C functions known > to Sather (like 'some_khoros_function'), or to write a Sather function that > can be called from C (like 'k_do_something', that is with a routine body). > I'm using this to call Sather from C. But the following is not competely true: > The names of the corresponding C functions are the names that appear in > the external C class. Sometimes the functions are labeled with the class's name and sometimes they are not. I'm sure there is a system behin that, but I don't understand it. Is there a easier way to determin the name of a function than looking at the generated C-Code? Any help? Thaks, Alex From fjh@mundook.cs.mu.OZ.AU Sun Nov 17 12:31:59 PST 1996 Article: 3198 of comp.lang.sather Path: agate!overload.lbl.gov!marlin.ucsf.edu!news.uoregon.edu!hunter.premier.net!hammer.uoregon.edu!csulb.edu!news.sgi.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!newsfeed.internetmci.com!feed1.news.erols.com!news.ecn.uoknor.edu!munnari.OZ.AU!cs.mu.OZ.AU!mundook.cs.mu.OZ.AU!fjh From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Subject: Re: Eiffel and Java Date: 16 Nov 1996 02:12:41 GMT Organization: Comp Sci, University of Melbourne Lines: 78 Message-ID: <56j7up$h1n@mulga.cs.mu.OZ.AU> References: <5694r8$c9c@mulga.cs.mu.OZ.AU> <1996Nov12.143451.16691@schbbs.mot.com> NNTP-Posting-Host: mundook.cs.mu.oz.au Xref: agate comp.lang.eiffel:16483 comp.lang.ada:53954 comp.lang.sather:3198 comp.lang.java.advocacy:2743 comp.object:57956 shang@corp.mot.com (David L. Shang) writes: >fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: >> shang@corp.mot.com (David L. Shang) writes: >> > But separation subtype from subclass is not [good]. >> >> Why not? Doesn't this also serve to "reduce the dependency >> among software components"? > >No, the separation subtype from subclass does not help >dependency reduction. Let "A" be a parent class, and "B" be >a subclass but not a subtype. "C" cannot use "B" unless it is >dependent on "B", because depending on "A" does not provide >any polymorphism that can guide the implementation to "B". In this situation, a Sather programmer would make an interface $A that was a supertype of B, and then C could use B via the $A interface. interface $A > B is ... end; class C < $A is private include B; ... end; If you want the compiler to make sure that C does not depend on B, you can encapsulate the dependency on B as follows: class C_A < $A is private include B end; class C < $A is private include C_A; ... end; Later another programmer could change things so that C used any other class B2 < $A instead of B, just by changing the one-line definition of C_A. This seems much better than languages such as C++ or Eiffel which don't separate subtype and subclass inheritence, where a programmer would probably make C access B via A rather than $A. If A is not an abstract interface, this makes it difficult to change the program to use a different implementation. So I think separating subtype from subclass does serve to reduce the dependency among software components. >> ]In Sather, implementation classes are not always subtype of the >> ]parent class. They merely reuse the code (inherite the implementation) >> ]defined in their parent, but not necessarily be subtype of it. >> ]Without subtyping, the interface provided in the parent cannot >> ]serve as a polymorphic interface for all the implementations. >> >> Yes, and that's a good thing, isn't it? >> It decouples the interface and the implementation, >> making it easier to use a different implementation. >> >As I stated above, it does not make it easier to use a different >implementation, I think it does. Requiring people to use only abstract interfaces for polymorphism does make it easier to use different implementations. >rather, it makes it easier to create a >different implementation that is not a subtype, or that >violates the parent's regulation. If you said "as well" rather than "rather", then I might agree with you. But I'm not yet convinced that creating a different implementation that is not a subtype is necessarily a bad thing, in a language which separates subtyping and subclassing. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From mernst@x4u2.desy.de Sun Nov 17 12:32:48 PST 1996 Article: 3199 of comp.lang.sather Path: agate!spool.mu.edu!uwm.edu!math.ohio-state.edu!howland.erols.net!blackbush.xlink.net!news-kar1.dfn.de!news-koe1.dfn.de!news-han1.dfn.de!news-ham1.dfn.de!news.dkrz.de!dscomsa.desy.de!x4u2!mernst From: mernst@x4u2.desy.de (Matthias Ernst) Newsgroups: comp.lang.sather Subject: Re: calling Sather from C Date: 16 Nov 1996 14:50:07 GMT Organization: DESY Lines: 57 Message-ID: <56kkb1$8ca@dscomsa.desy.de> References: <327FF082.87A@santafe.edu> <55qd55$f4f@newsserv.zdv.uni-tuebingen.de> <328C3CC6.44B54176@horz.technopark.gmd.de> NNTP-Posting-Host: x4u2.desy.de X-Newsreader: TIN [version 1.2 PL2] Alexander Asteroth (aster@horz.technopark.gmd.de) wrote: : Hi, : zxmsv01@hp11.zdv.uni-tuebingen.de (Erik Schnetter) writes: : > External classes can be used in two ways; either to make C functions known : > to Sather (like 'some_khoros_function'), or to write a Sather function that : > can be called from C (like 'k_do_something', that is with a routine body). : > : I'm using this to call Sather from C. But the following is not : competely true: : > The names of the corresponding C functions are the names that appear in : > the external C class. : Sometimes the functions are labeled with the class's name : and sometimes they are not. True, this corresponds to the two ways how you can use the external C interface: 1. Access C functions from Sather: external C class UNIXFS is stat(file: C_CHAR_PTR, buf: STAT_BUF_PTR): C_INT; end; A call to UNIXFS::stat in Sather code will be translated to call C function stat --- no mangling. 2. Access Sather routines from C: external C class GATEWAY is callme(param: C_INT) is an_implementation; end; end; This is garantueed to be translated to a C function 'GATEWAY_callme(int)'. You cannot rely on the mangling of other functions, i.e. regular Sather methods. -- Matthias : I'm sure there is a system behin that, but I don't understand it. : Is there a easier way to determin the name of a function than : looking at the generated C-Code? : Any help? : Thaks, : Alex From zxmsv01@hp11.zdv.uni-tuebingen.de Sun Nov 17 12:33:29 PST 1996 Article: 3200 of comp.lang.sather Path: agate!howland.erols.net!news.nacamar.de!news-kar1.dfn.de!news-stu1.dfn.de!news.belwue.de!newsserv.zdv.uni-tuebingen.de!hp11!zxmsv01 From: zxmsv01@hp11.zdv.uni-tuebingen.de (Erik Schnetter) Newsgroups: comp.lang.sather Subject: Re: calling Sather from C Date: 16 Nov 1996 21:34:13 GMT Organization: InterNetNews at ZDV Uni-Tuebingen Lines: 55 Message-ID: <56lc0l$fbh@newsserv.zdv.uni-tuebingen.de> References: <327FF082.87A@santafe.edu> <55qd55$f4f@newsserv.zdv.uni-tuebingen.de> <328C3CC6.44B54176@horz.technopark.gmd.de> NNTP-Posting-Host: @hp11.zdv.uni-tuebingen.de X-Newsreader: TIN [version 1.2 PL2] Alexander Asteroth (aster@horz.technopark.gmd.de) wrote: : Hi, : zxmsv01@hp11.zdv.uni-tuebingen.de (Erik Schnetter) writes: : > External classes can be used in two ways; either to make C functions known : > to Sather (like 'some_khoros_function'), or to write a Sather function that : > can be called from C (like 'k_do_something', that is with a routine body). : > : I'm using this to call Sather from C. But the following is not : competely true: : > The names of the corresponding C functions are the names that appear in : > the external C class. : Sometimes the functions are labeled with the class's name : and sometimes they are not. : I'm sure there is a system behin that, but I don't understand it. : Is there a easier way to determin the name of a function than : looking at the generated C-Code? Yes, there definitely is a system behind it. There is the old-style Sather 1.0 convention, and there is the new-style Sather 1.1 convention. Old style had the class name prepended for routines *with* body in external classes. The new style never has the class' name added. However, the new style only allows external C class types as arguments. Whenever there is a definition that is not legal by the new style standard, the Sather compiler automatically (and without warning; sadly) falls back to the old standard. Every time you use INT or CHAR or STR as arguments (instead of C_INT, C_CHAR, and C_CHAR_PTR), the compiler assumes old style and adds the class name. So, here it is in short: external C class DADIDA is old_style (x: INT) is ... end; new_style (x: C_INT) is ... end; end; generates the routines void DADIDA_old_style (INT x); and void new_style (int x); When using the new style, you shouldn't forget that you have to cast the arguments in your Sather code. -erik ----- Erik Schnetter, erik.schnetter@student.uni-tuebingen.de From borisv@icsi.berkeley.edu Mon Nov 18 15:27:16 PST 1996 Article: 3203 of comp.lang.sather Path: agate!usenet From: Vaysman Boris Newsgroups: comp.lang.sather Subject: Re: calling Sather from C Date: Mon, 18 Nov 1996 13:59:39 -0800 Organization: University of California, Berkeley Lines: 49 Message-ID: <3290DC4B.7FA6@icsi.berkeley.edu> References: <327FF082.87A@santafe.edu> <55qd55$f4f@newsserv.zdv.uni-tuebingen.de> <328C3CC6.44B54176@horz.technopark.gmd.de> <56lc0l$fbh@newsserv.zdv.uni-tuebingen.de> NNTP-Posting-Host: 128.32.201.129 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 i86pc) Erik Schnetter wrote: > Yes, there definitely is a system behind it. > > There is the old-style Sather 1.0 convention, and there is the new-style > Sather 1.1 convention. > > Old style had the class name prepended for routines *with* body in > external classes. The new style never has the class' name added. > This is a pretty accurate description. > However, the new style only allows external C class types as arguments. This is not quite true. Methods with bodies come in two flavors. Those that can be called from C must have all arguments of external C types (these may be called from within Sather as well). Such methods are mangled the way Erik described - no mangling ;-) Methods that have non C type arguments (INT, CHAR, etc) can be called only from Sather. As far as binding of these method names goes - Sather does not guarantee anything. True, for compatibility with pre 1.1 code we recognize the old style and mangle things appropriately to avoid breaking old code, but the support for this will be dropped in time. It's best not to rely on this at all and use the new external classes the way it is described in the 1.1 Programming Manual and the Spec. > Whenever there is a definition that is not legal by the new style standard, > the Sather compiler automatically (and without warning; sadly) falls back Yes, you are right that a warning may be useful here, but it could be only used for methods implemented in C (no body). I believe, the original question had to do with calls from C into Sather. There is not much we can do here since methods that have non C arguments are perfectly legal in 1.1. It is best not to rely on the old functionality - it is retained only temporarily to ease the transition to Sather 1.1. Thanks, -Boris ----------------------------------------------------------------------- ICSI, Office 640 home: 1947 Center St. Suite 600 2206 Haste Str, #25 Berkeley CA 94704-1198 Berkeley, Ca 94704 (510) 642-4274 x126 (510)204-9643 fax (510) 643-7684 ------------------------------------------------------------------------ From borisv@icsi.berkeley.edu Mon Nov 18 15:28:08 PST 1996 Article: 3204 of comp.lang.sather Path: agate!usenet From: Vaysman Boris Newsgroups: comp.lang.sather Subject: Re: casting Date: Mon, 18 Nov 1996 14:12:13 -0800 Organization: University of California, Berkeley Lines: 32 Message-ID: <3290DF3D.C44@icsi.berkeley.edu> References: <56jak6$pn@phavl.ultranet.com> NNTP-Posting-Host: 128.32.201.129 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 i86pc) Rob Ransbottom wrote: > > In the absence of it's declared type a void reference can > only be determined to be a void of some reference type. > > With some cheating a cast function can pass a void reference > to another reference type. This seems reasonable considering > the above. > Hi Rob, You have brought up a point that was discussed quite a few times locally. Clearly, there could be a different language design with typed void (or tagged void). This would be slightly less efficient, but a lot cleaner conceptually. If you post some more details on what you are trying to achieve, perhaps we'd be able to come up with a nicer solution for Sather 1.1 Thanks a lot, -Boris -- ----------------------------------------------------------------------- ICSI, Office 640 home: 1947 Center St. Suite 600 2206 Haste Str, #25 Berkeley CA 94704-1198 Berkeley, Ca 94704 (510) 642-4274 x126 (510)204-9643 fax (510) 643-7684 ------------------------------------------------------------------------ From rir@phavl.ultranet.com Tue Nov 19 00:51:35 PST 1996 Article: 3207 of comp.lang.sather Path: agate!usenet.ins.cwru.edu!slider.bme.ri.ccf.org!kira.cc.uakron.edu!neoucom.edu!news.ysu.edu!news.ecn.uoknor.edu!feed1.news.erols.com!insync!eit.com!news.sprintlink.net!news-chi-13.sprintlink.net!news.ultranet.com!usenet From: rir@phavl.ultranet.com (Rob Ransbottom) Newsgroups: comp.lang.sather Subject: Reflection Date: 16 Nov 1996 02:41:50 GMT Organization: Occasionally Considered Lines: 30 Message-ID: <56j9le$8na@decius.ultra.net> NNTP-Posting-Host: phavl.ultranet.com These thoughts follow upon David Stoutamire's extended comments on persistence here in c.l.sather mid-1995. REFLECT::create_object(tp:INT):$OB REFLECT::tp_for_str(s:STR):INT These need to be preserved. These don't break encapsulation, these are required to give reflections substance. If there are constraints on the types of objects which may be created, then the program environment needs to be examined. This could use more support. Such as: is_sub_tp(sub:INT, tp:INT):BOOL is_concrete_tp(tp:INT):BOOL is_reference_tp(tp:INT):BOOL is_parameterized(tp:INT):BOOL n_parms(tp:INT):INT parm_tp(tp:INT, idx:INT):INT Comments? -- Rob Ransbottom rir@phavl.ultranet.com From gomes@ICSI.Berkeley.EDU Tue Nov 19 00:51:38 PST 1996 Article: 3208 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Reflection Date: 19 Nov 1996 08:42:24 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 45 Message-ID: <56rrtg$88k@agate.berkeley.edu> References: <56j9le$8na@decius.ultra.net> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <56j9le$8na@decius.ultra.net>, Rob Ransbottom wrote: >These thoughts follow upon David Stoutamire's >extended comments on persistence here in c.l.sather mid-1995. > > > REFLECT::create_object(tp:INT):$OB This does break encapsulation, because the class no longer has control over the object creation. It is possible, using this method, to create an invalid object, that could never arise from a legitimate creation. While I feel that this should not be a standard part of the language for common use, I think it is just fine for debugging and for language tools. In fact, immutable classes suffer from exactly this problem - after they have been declared (but before they have been *created* - and they need never be created) they exist in a state where all attributes are void. This void object may not be a valid state for an immutable class (for instance, suppose you wanted an immutable class that represented numbers > 0). > REFLECT::tp_for_str(s:STR):INT I presume you want this in order to use with the above call.... > is_sub_tp(sub:INT, tp:INT):BOOL > is_concrete_tp(tp:INT):BOOL > is_reference_tp(tp:INT):BOOL > is_parameterized(tp:INT):BOOL > n_parms(tp:INT):INT > parm_tp(tp:INT, idx:INT):INT > These routines would certainly be nice to add... Though I feel that reflection is extremely useful, it should not be used to work around the type system and for regular coding! If there are ways in which the type system is too restrictive, maybe that would make an interesting discussion itself? ben From gomes@ICSI.Berkeley.EDU Tue Nov 19 10:19:31 PST 1996 Article: 3209 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: casting Date: 19 Nov 1996 08:51:18 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 29 Message-ID: <56rse6$8c4@agate.berkeley.edu> References: <56jak6$pn@phavl.ultranet.com> <3290DF3D.C44@icsi.berkeley.edu> <56rfs4$1re@phavl.ultranet.com> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <56rfs4$1re@phavl.ultranet.com>, Rob Ransbottom wrote: >In article <3290DF3D.C44@icsi.berkeley.edu>, >Determining immutability is used to skip catching referential loops in >data. > >It is tempting to store all of the type info that sather has. For what would this be used (other than reading the information back into sather, for which the type name is sufficient)? >This is only difficult due to the implicit nature of immutability. >Which only becomes an issue with voids. > >At present 0.0d is flattened to void. This seems odd and unseemly >though I have no solid argument that it is bad. Just vague >thoughts of IEEE specs and support of other languages. I don't understand why it is flattened to void. You can test if the object is immutable, and if it is, just store its regular value, no? ben b.t.w. If anyone is using the STORE classes, please contact me for the latest versions, since I had a few bugs in the released version. From cfl@zurich.ibm.com Tue Nov 19 10:20:31 PST 1996 Article: 3212 of comp.lang.sather Path: agate!spool.mu.edu!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!uunet!in1.uu.net!newsgate.watson.ibm.com!watnews.watson.ibm.com!grimsel.zurich.ibm.com!usenet From: Claudio Fleiner Newsgroups: comp.lang.sather Subject: Re: Reflection Date: Tue, 19 Nov 1996 13:53:03 +0100 Organization: IBM Zurich Research Laboratory Lines: 46 Message-ID: <3291ADAF.41C6@zurich.ibm.com> References: <56j9le$8na@decius.ultra.net> NNTP-Posting-Host: jungfrau.zurich.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; AIX 2) Rob Ransbottom wrote: > > REFLECT::create_object(tp:INT):$OB As Ben already pointed out, this breaks encapsulation realy badly, as it creates an object without calling the constructor. > is_sub_tp(sub:INT, tp:INT):BOOL This is currenly not possible at runtime, and would need some support from the compiler. Basically a copy of the type tree needs to be available at runtime. > is_concrete_tp(tp:INT):BOOL This is always true, as non concrete types have no type number. > is_reference_tp(tp:INT):BOOL is return tp>0; end; (that works at least in the current compiler) > is_parameterized(tp:INT):BOOL > n_parms(tp:INT):INT > parm_tp(tp:INT, idx:INT):INT Those can be implemented with tp_for_str and some string manipulation (not very efficient, but possible). Note that there is a real danger inside the current sather compiler when using reflection for data storage: the type numbers used are NOT guaranteed to be the same when you recompile your program, and they will change for sure if you use a new class or don't use one anymore. Furthermore, if a class is not used inside the program it is not possible to create an object of this class and even if you create an object with an unused type number with some hacks, you will have instant problems with typecases and abstract method calls. Also all methods that are never called anywhere in the program do not exist in the C code. -- Claudio Fleiner (cfl@zurich.ibm.com) IBM Zurich Research Laboratory, Saumerstrasse 4, CH-8803 Rueschlikon/Switzerland Tel. +41-1-724-84-32, Fax. +41-1-710-36-08 From shang@corp.mot.com Tue Nov 19 10:22:11 PST 1996 Article: 3210 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!spool.mu.edu!uwm.edu!newsfeed.internetmci.com!news.idt.net!uunet!in1.uu.net!ott.istar!istar.net!van.istar!west.istar!news-w.ans.net!newsfeeds.ans.net!news.phx.mcd.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Re: Eiffel and Java Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Mon, 18 Nov 1996 18:05:20 GMT Message-ID: <1996Nov18.180520.12596@schbbs.mot.com> References: <56j7up$h1n@mulga.cs.mu.OZ.AU> Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 64 Xref: agate comp.lang.eiffel:16517 comp.lang.ada:54064 comp.lang.sather:3210 comp.lang.java.advocacy:2809 comp.object:58046 In article <56j7up$h1n@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: > shang@corp.mot.com (David L. Shang) writes: > >No, the separation subtype from subclass does not help > >dependency reduction. Let "A" be a parent class, and "B" be > >a subclass but not a subtype. "C" cannot use "B" unless it is > >dependent on "B", because depending on "A" does not provide > >any polymorphism that can guide the implementation to "B". > > In this situation, a Sather programmer would make an interface $A > that was a supertype of B, and then C could use B via the $A interface. > > interface $A > B is ... end; > > class C < $A is > private include B; > ... > end; > Here you evaded the question. It is not the separation but the delegation in your example that helps the reduction of the dependency. Transframe supports automatic delegation: you are not necessary to delegate all the methods manually. Just write: class C is A by B; Separation is not necessary. B is subtype of A; C is subtype of A; but C is not subtype, nor subclass of of B. > If you want the compiler to make sure that C does not depend on B, > you can encapsulate the dependency on B as follows: > > class C_A < $A is private include B end; > > class C < $A is > private include C_A; > ... > end; > > Later another programmer could change things so > that C used any other class B2 < $A instead of B, > just by changing the one-line definition of C_A. > > This seems much better than languages such as C++ or Eiffel which don't > separate subtype and subclass inheritence, where a programmer would > probably make C access B via A rather than $A. If A is not an abstract > interface, this makes it difficult to change the program to use a > different implementation. > > So I think separating subtype from subclass does serve to > reduce the dependency among software components. > Again, you miss the nail head. The purpose of Sather's separation is not for the reduction of dependency, but for allowing subclass to have covariant constraints, i.e. to have presumptions that violates the specification in its parent class. Using delegation manually in C++ and Effel, you can reduce the dependency in the same way as you did in Sather. David Shang From shang@corp.mot.com Tue Nov 19 10:22:37 PST 1996 Article: 3211 of comp.lang.sather Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Path: agate!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!ott.istar!istar.net!van.istar!west.istar!news-w.ans.net!newsfeeds.ans.net!news.phx.mcd.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Re: Eiffel and Java Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Mon, 18 Nov 1996 22:32:39 GMT Message-ID: <1996Nov18.223239.21147@schbbs.mot.com> References: Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 15 Xref: agate comp.lang.eiffel:16518 comp.lang.ada:54068 comp.lang.sather:3211 comp.lang.java.advocacy:2810 comp.object:58048 In article Kai.Quale@usit.uio.no (Kai Quale) writes: > How does separation of subtype from subclass help a subclass in violating > the constraining requirement regulated by its parent ? Exactly by allowing subclass not being a subtype. When it violates, it cannot be a subtype, but it still can be a subclass. > Btw, by "parent", > do you mean its supertype or superclass ? > Hence the "parent" is the superclass in general. David Shang From gomes@ICSI.Berkeley.EDU Tue Nov 19 16:51:00 PST 1996 Article: 3216 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Reflection Date: 20 Nov 1996 00:50:14 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 29 Distribution: inet Message-ID: <56tkk6$490@agate.berkeley.edu> References: <56j9le$8na@decius.ultra.net> <56rrtg$88k@agate.berkeley.edu> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article , Ari Juhani Huttunen wrote: >existed a "dynamic type" which didn't need this definition, but instead >it would be defined that *any* class that actually conforms to this >dynamic type is a subtype thereof. > >dynamic type $PERSISTENT is > save_to(f:FILE) ... > restore_from(f:FILE) ... >end; ... >One benefit this brings that this sort of 'subtype' relation need >not be transitive. An object which is persistent may have children >which are not persistent. I don't follow. If the child is abstract, then its subtypes must support the routine. If the child is concrete, then it has no subtypes. This is also similar to the structural conformance that is used for checking parameter type bounds in both Sather-K and in Theta. It seems like it might be a compromise between the Sather-1 and Sather-K versions of type bounds - the type bound is really a supertype, but it is an implicit supertype. This will permit our overloading rules (which depend on the type parameter being a supertype) in the structural conformance scheme.... ben From Ari.Huttunen@hut.fi Tue Nov 19 16:54:12 PST 1996 Article: 3215 of comp.lang.sather Path: agate!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!nntp.inet.fi!news.csc.fi!nntp.hut.fi!usenet From: Ari.Huttunen@hut.fi (Ari Juhani Huttunen) Newsgroups: comp.lang.sather Subject: Bi-directional pointers? Date: 20 Nov 1996 01:41:20 +0200 Organization: Helsinki University of Technology, Finland Lines: 54 Sender: ahuttune@delta.hut.fi Distribution: inet Message-ID: NNTP-Posting-Host: delta.hut.fi X-Newsreader: Gnus v5.1 I'm just wondering if anyone has figured out the cleanest way to implement bidirectional pointers in Sather. What I mean is the same concept in databases, i.e. class A is b:B; end; class B is a:A; end; Assume a1:A and b1:B. Now it should hold that a1.b=b1 if and only if b1.a=a1 There exists no problem if we can assume the user makes no errors and always remembers to assign both references. Unfortunately users make errors and the assumption doesn't hold. It would be desirable to have a method that given a1.b=b1, b1.a=a1, b2.a=void and the assignment a1.b:=b2 would result a1.b=b2, b1.a=void, b2.a=a1 without the user having to explicitly do this. There are methods to do something like this. For example we could think of a ONE_TO_ONE{A,B} library class that would contain bound routines for reading and writing the corresponding attribute in the other object. This can be done but could be awkward. Would it be a possibility of having this sort of functionality built-in to Sather? Assuming this existed in Sather, do you think it could be used to implement ONE_TO_MANY{} and MANY_TO_ONE{} relations? Anyway, I wanted to write these for the library but I fail to find any time to do that. They are potentially useful additions, though. -- --- -- -- -- Ari Huttunen ---- ---- -- -- -- ---- -- From cfl@zurich.ibm.com Wed Nov 20 00:52:03 PST 1996 Article: 3217 of comp.lang.sather Path: agate!spool.mu.edu!uwm.edu!cs.utexas.edu!howland.erols.net!news.sprintlink.net!news-peer.sprintlink.net!uunet!in2.uu.net!newsgate.watson.ibm.com!watnews.watson.ibm.com!grimsel.zurich.ibm.com!usenet From: Claudio Fleiner Newsgroups: comp.lang.sather Subject: Re: Bi-directional pointers? Date: Wed, 20 Nov 1996 09:16:08 +0100 Organization: IBM Zurich Research Laboratory Lines: 41 Message-ID: <3292BE48.446B@zurich.ibm.com> References: NNTP-Posting-Host: jungfrau.zurich.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; AIX 2) To: Ari Juhani Huttunen Just declare the following routines in A and B: class A is bp:B; -- private pointer to B, should never be used directly b:B is return bp; end; b(new_b:B) is bp:=new_b; bp.ap:=self; end; end; class B is ap:A; -- private pointer to A, should never be used directly a:A is return ap; end; a(new_a:A) is ap:=new_a; ap.bp:=self; end; end; One would like to make bp and ap only visible to A and B and not the whole world, but this is unfortuantly not possible. Note that this works because a.b:=new_b; is syntactic sugar for a.b(new_b); This is one of the nice features of Sather missing in either Java or C++. -- Claudio Fleiner (cfl@zurich.ibm.com) IBM Zurich Research Laboratory, Saumerstrasse 4, CH-8803 Rueschlikon/Switzerland Tel. +41-1-724-84-32, Fax. +41-1-710-36-08 From rir@phavl.ultranet.com Thu Nov 21 11:09:34 PST 1996 Article: 3219 of comp.lang.sather Path: agate!spool.mu.edu!uwm.edu!www.nntp.primenet.com!nntp.primenet.com!news.sprintlink.net!news-peer.sprintlink.net!uunet!in3.uu.net!news.ultranet.com!phavl.ultranet.com!not-for-mail From: rir@phavl.ultranet.com (Rob Ransbottom) Newsgroups: comp.lang.sather Subject: Re: Reflection Date: 19 Nov 1996 22:31:57 -0500 Organization: Occasionally Considered Lines: 65 Message-ID: <56tu3d$uqn@phavl.ultranet.com> References: <56j9le$8na@decius.ultra.net> <3291ADAF.41C6@zurich.ibm.com> NNTP-Posting-Host: phavl.ultranet.com In article <3291ADAF.41C6@zurich.ibm.com>, Claudio Fleiner wrote: >Rob Ransbottom wrote: >> >> REFLECT::create_object(tp:INT):$OB >As Ben already pointed out, this breaks encapsulation >realy badly, as it creates an object without calling >the constructor. I contest the "really badly" part of this. See my response to Ben's post. I have a less theoretical perspective than Ben and yourself, I'm sure. >> is_sub_tp(sub:INT, tp:INT):BOOL >This is currenly not possible at runtime, and would >need some support from the compiler. Basically a >copy of the type tree needs to be available at >runtime. Or a permutation of typecase. Yuck. >> is_concrete_tp(tp:INT):BOOL >This is always true, as non concrete types have no type >number. >> is_reference_tp(tp:INT):BOOL > is return tp>0; end; >(that works at least in the current compiler) > >> is_parameterized(tp:INT):BOOL >> n_parms(tp:INT):INT >> parm_tp(tp:INT, idx:INT):INT >Those can be implemented with tp_for_str and some >string manipulation (not very efficient, but possible). True, with the caution: at least in the current compiler. >Note that there is a real danger inside the current >sather compiler when using reflection for data storage: >the type numbers used are NOT guaranteed to be the same >when you recompile your program, and they will change >for sure if you use a new class or don't use >one anymore. Furthermore, if a class is >not used inside the program it is not possible to >create an object of this class and even if you >create an object with an unused type number with >some hacks, you will have instant problems with >typecases and abstract method calls. Also all >methods that are never called anywhere in the program >do not exist in the C code. This was why I was asking, a while back, for a statement that the result of calls like SYS::str_for_tp( SYS::tp("Rethas")) are guaranteed to be consistent. I see it as risky to assume that this will not return "TYPE17" on one compile and "STR" on another. Deferring these dangers to the application level doesn't lessen them. STR::create_from_memory_location(EXT_OB,INT):SAME. -- Rob Ransbottom rir@phavl.ultranet.com From gomes@ICSI.Berkeley.EDU Thu Nov 21 11:36:54 PST 1996 Article: 3223 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: casting Date: 21 Nov 1996 19:36:26 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 13 Message-ID: <572avq$96n@agate.berkeley.edu> References: <56jak6$pn@phavl.ultranet.com> <56rfs4$1re@phavl.ultranet.com> <56rse6$8c4@agate.berkeley.edu> <56vd16$3dm@phavl.ultranet.com> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <56vd16$3dm@phavl.ultranet.com>, Rob Ransbottom wrote: >No, because if the void object is a reference you >crash checking if it is an immutable. > Righ. I checked on the code in store, and in fact it does not discriminate. A great deal of effort went into making immutable and reference types behave indistinguishably (except that they don't when void!). Personally, I would not mind a $IMMUT_OB and a $REF_OB implicitly over all immutable and reference objects - they were in an earlier design of the language. ben From holger@uni-muenster.de Thu Nov 21 11:46:04 PST 1996 Article: 3220 of comp.lang.sather Path: agate!howland.erols.net!blackbush.xlink.net!news-kar1.dfn.de!news-koe1.dfn.de!uni-muenster.de!news From: "Holger Klawitter" Newsgroups: comp.lang.sather Subject: Re: Immutable Class & Immutable Reference Class Date: 21 Nov 1996 09:27:46 +0100 Organization: Westfaelische Wilhelms-Universitaet Muenster, Germany Lines: 48 Sender: "Holger Klawitter" Message-ID: References: <1996Nov20.223511.13400@schbbs.mot.com> NNTP-Posting-Host: nirvana.uni-muenster.de X-Newsreader: Gnus v5.2.25/XEmacs 19.14 shang@corp.mot.com (David L. Shang) writes: > 1. Can an immutable class be a subtype of an abstract class? > Particularly, the class other than $OB? Yes it can. > What does "b.bar()" shouid return? An immutable object or a > reference object? It depends on the context. If b is some abstract class, it's done by 'boxing'. Whenever an immutable object is passed into an abstract context the immutable will be wrapped into a reference object. But this is just an implementation detail. If it goes back into the concrete context it will be unboxed. (This leads to some extra code for each routine being called in an immutable class, as you need an unbox_routine which in turn calls the 'normal' routine.) > 2. What is an immutable reference class? I cannot find the definition in the > language manual. If it is the feature that allows to use mutable class as > being used for immutable object, consider, All immutable classes are - from the viewpoint of the user - reference classes, there are no value classes in Sather (that's why we changed the keyword >from 'value' to 'immutable' when migrating from 1.0 to 1.1). Immutable classes are just reference classes with some restrictions regarding writer-routines to their fields. Reference classes allow setting the field of an existing object b := a; a.foo := 0; (a and b still reference the same object.) Immutable classes create a new instance of their class with the new value in the field: b := a; a := a.foo(5); -- a.foo := 5 is illegal (Note that a and b are different objects afterwards.) Hope this helps Holger Klawitter Holger Klawitter holger@math.uni-muenster.de Institut fuer Informatik http://www.icsi.berkeley.edu/~holger Einsteinstr. 62 http://wwwmath.uni-muenster.de/~holger 48149 Muenster, Germany Tel: +49 251 83 37 47 Fax: +49 251 83 37 55 From shang@corp.mot.com Thu Nov 21 11:49:37 PST 1996 Article: 3221 of comp.lang.sather Newsgroups: comp.lang.sather Path: agate!ihnp4.ucsd.edu!swrinde!howland.erols.net!news.mathworks.com!usenet.eel.ufl.edu!news-feed-1.peachnet.edu!paperboy.wellfleet.com!news-w.ans.net!newsfeeds.ans.net!news.phx.mcd.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Immutable Class & Immutable Reference Class Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Wed, 20 Nov 1996 22:35:11 GMT Message-ID: <1996Nov20.223511.13400@schbbs.mot.com> Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 93 Two questions and the guess of the answers: 1. Can an immutable class be a subtype of an abstract class? Particularly, the class other than $OB? If yes, what is the status of the "self" reference within the immutable class? It could be different when the "self" reference is passed down from the supertype via a overridden function. My guess is that an immutable object cannot use "self" reference at all. For example: abstract class foo is bar (SAME): SAME is return self; immutable class ifoo inherit foo is attr x, y: INT; bar (other: SAME): SAME is return #SAME(x+other.x,y+other.y); -- but "return self" is wrong Now, consider: b: ifoo; -- an immutable object What does "b.bar()" shouid return? An immutable object or a reference object? My guess is that it should be an reference object, otherwise, consider: a: foo; if some_conidtion then a:= b else ... c: foo := a.bar(b); The actual "bar" called may be defined in "ifoo", but a reference object is expected at the level of "foo". Suppose that it be an reference object, we consider: d: ifoo := b.bar(b); First, the output reference must be converted to an immutable object. Second, the input of "bar" must converted into a reference in case the function "bar" is not overriden in an immutable subtype. Third, if "b" is assigned to "a": a:=b; "b" is converted into a new reference object and then let "a" refers to it. And lastly, if the "bar" function defined in immutable class wants to call the function defined in its mutable supertype, it must convert itself into new reference. 2. What is an immutable reference class? I cannot find the definition in the language manual. If it is the feature that allows to use mutable class as being used for immutable object, consider, concrete class foo is attr: x, y: INT; bar (): SAME is { ... gee(self); -- gee changes x and y ... } immutable a: foo; -- I'm not sure about the syatx b: foo; a.bar(); -- "self" in bar should not be "a" b.bar(); -- "self" in bar should be "b" I guess you should convert "a" into a new reference object before calling "a.bar()", because we assume that the state of "a" can never be changed after its creation. After the call, the tempary created reference object shall be garbage collected and "a" remains unchanged. My guess is based on the Transframe's "Name Attachment Conversion Rules". Does Sather use the similar technique? I did not find any rules in the language specification. David Shang From Ari.Huttunen@hut.fi Thu Nov 21 11:51:49 PST 1996 Article: 3222 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!swrinde!www.nntp.primenet.com!nntp.primenet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!uunet!in2.uu.net!nntp.inet.fi!news.funet.fi!nntp.hut.fi!usenet From: Ari.Huttunen@hut.fi (Ari Juhani Huttunen) Newsgroups: comp.lang.sather Subject: Re: Bi-directional pointers? Date: 21 Nov 1996 02:47:01 +0200 Organization: Helsinki University of Technology, Finland Lines: 89 Sender: ahuttune@delta.hut.fi Distribution: inet Message-ID: References: NNTP-Posting-Host: delta.hut.fi In-reply-to: Ari.Huttunen@hut.fi's message of 20 Nov 1996 01:41:20 +0200 X-Newsreader: Gnus v5.1 On Wed, 20 Nov 1996, Claudio Fleiner wrote: > Just declare the following routines in A and B: Some code seems to be missing, although I'm uncertain whether this new version is correct either. In pSather it could probably break anyway. > class A is > bp:B; -- private pointer to B, should never be used directly > > b:B is return bp; end; > b(new_b:B) is if ~void(bp) then bp.ap:=void end; > bp:=new_b; if ~void(bp) > bp.ap:=self; end; > end; > end; > > class B is > ap:A; -- private pointer to A, should never be used directly > > a:A is return ap; end; > a(new_a:A) is if ~void(ap) then ap.bp:=void end; > ap:=new_a; if ~void(ap) > ap.bp:=self; end; > end; > end; > > One would like to make bp and ap only visible > to A and B and not the whole world, but this > is unfortuantly not possible. Yes, unfortunately. Anyway, it seems clear that this is not a good way to reduce errors in a program. While trying to make two pointers that point to each other's enclosing object be more foolproof, it was necessary for the user to write code that is even more probable to contain errors. It seems that if you could parameterize a class with attribute names, you could put all this stuff in a library class and just write the following in a user class: class A is include ONE_TO_ONE{b,bp,B,ap,A}; end; class ONE_TO_ONE{b,bp,B,ap,A} is -- b/bp/ap are name parameters -- B/A are type parameters bp:B; -- private pointer to B, should never be used directly b:B is return bp; end; b(new_b:B) is if ~void(bp) then bp.ap:=void end; bp:=new_b; if ~void(bp) bp.ap:=self; end; end; end; This is not yet a very good solution, but it has the benefit that the hairy stuff is hidden inside the library. Since this is the reason we have a library, I think it ought be possible to put it there. Unfortunately I don't see how it could be done with the current language specification. Note that the name parameter to a parameterized class is in a way the same functionality that could be achieved in Eiffel by renaming the attributes to have new names in the user class. In Sather it doesn't work because renaming doesn't dig inside the routine bodies. (Changing the rename semantics in Sather is probably not a good way to proceed, however...) It could be said that this is not a very important application, but because it tries to push the language to its limits, there should be lessons that can be learned from it. -- --- -- -- -- Ari Huttunen ---- ---- -- -- -- ---- -- From shang@corp.mot.com Sat Nov 23 17:04:38 PST 1996 Article: 3226 of comp.lang.sather Newsgroups: comp.lang.sather Path: agate!howland.erols.net!newsxfer2.itd.umich.edu!portc01.blue.aol.com!newstf01.news.aol.com!newsjunkie.ans.net!newsfeeds.ans.net!news.phx.mcd.mot.com!schbbs!news From: shang@corp.mot.com (David L. Shang) Subject: Re: Immutable Class & Immutable Reference Class Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Fri, 22 Nov 1996 23:15:10 GMT Message-ID: <1996Nov22.231510.3660@schbbs.mot.com> References: Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 91 In article "Holger Klawitter" writes: > shang@corp.mot.com (David L. Shang) writes: > > > 1. Can an immutable class be a subtype of an abstract class? > > Particularly, the class other than $OB? > > Yes it can. > > > What does "b.bar()" shouid return? An immutable object or a > > reference object? > > It depends on the context. If b is some abstract class, it's done by > 'boxing'. Whenever an immutable object is passed into an abstract context > the immutable will be wrapped into a reference object. > Thanks! According to the specification, the state of immutable objects cannot be changed. So, when you wrap an immutable with a reference object, do you have to created a new copy of the immutable for the wrapper, right? Otherwise, how do you prevent the mutable superclass to change the state of the object? Also, consider: a: $mutable_superclass; b: immutable_subclass; Is this possible: a:=b; ? If so, "a" must get a different object from "b". But whatever it is, it is still an immutable object. So, how do you prevent the operation in "a" changes the state of the the object? Is it true that only the state defeined in the immutable subclass is immutable for an given immutable object with mutable super case? > > 2. What is an immutable reference class? I cannot find the > > definition in the language manual. If it is the feature > > that allows to use mutable class as being used for > > immutable object, consider, > > All immutable classes are - from the viewpoint of the user - > reference classes, > there are no value classes in Sather (that's why we changed the keyword > from 'value' to 'immutable' when migrating from 1.0 to 1.1). > > Immutable classes are just reference classes with some restrictions regarding > writer-routines to their fields. Reference classes allow setting the field > of an existing object > b := a; > a.foo := 0; > (a and b still reference the same object.) I understand. But is it still possible to make a mutable class have static memory (or distinct memory)? > Immutable classes create a new instance of their class with the new value > in the field: > b := a; > a := a.foo(5); -- a.foo := 5 is illegal > (Note that a and b are different objects afterwards.) > But can the state of an immutable object be changed inside by "a"'s operation? What I don't understand is the reason why you chose to replace "value" with "immutable", while you already had "read-only" attributes? The concept of mutable or immutable is largely dependent on the interpretation of the class designer. It has no tight relationship with its storage model. An immutable object could be referenced, for example, a reference to an integer. And there is no prblem if it is referred by more than one references. On the other hand, a mutable object could be statically allocated. And there is no conflict when it must be cloned. David Shang From fjh@mundook.cs.mu.OZ.AU Sun Nov 24 21:21:20 PST 1996 Article: 3228 of comp.lang.sather Path: agate!howland.erols.net!feed1.news.erols.com!news.ecn.uoknor.edu!munnari.OZ.AU!cs.mu.OZ.AU!mundook.cs.mu.OZ.AU!fjh From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.sather Subject: Re: Immutable Class & Immutable Reference Class Date: 24 Nov 1996 07:17:03 GMT Organization: Comp Sci, University of Melbourne Lines: 46 Message-ID: <578spf$4ap@mulga.cs.mu.OZ.AU> References: <1996Nov22.231510.3660@schbbs.mot.com> NNTP-Posting-Host: mundook.cs.mu.oz.au [Disclaimer: my knowledge of Sather is pretty minimal... consider the following as educated guesses. Please correct me if I'm wrong!] shang@corp.mot.com (David L. Shang) writes: >"Holger Klawitter" writes: >> shang@corp.mot.com (David L. Shang) writes: >> >> > 1. Can an immutable class be a subtype of an abstract class? >> > Particularly, the class other than $OB? >> >> Yes it can. But of course the abstract class can't have any mutating operations, otherwise the subtype relation wouldn't hold. >According to the specification, the state of immutable objects >cannot be changed. So, when you wrap an immutable with a reference >object, do you have to created a new copy of the immutable for >the wrapper, right? No. >Otherwise, how do you prevent the mutable >superclass to change the state of the object? The type system prevents it. You can't have a mutable superclass of an immutable object. >Also, consider: > > a: $mutable_superclass; > b: immutable_subclass; > >Is this possible: > > a:=b; Only if immutable_subclass < $mutable_superclass, which can only be true if $mutable_superclass doesn't have any mutating operations (in which case it's name is a misnomer). -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From Kai.Quale@usit.uio.no Tue Nov 26 00:12:11 PST 1996 Article: 3230 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!swrinde!howland.erols.net!feed1.news.erols.com!in1.nntp.cais.net!nntp.uio.no!macusit36.uio.no!user From: Kai.Quale@usit.uio.no (Kai Quale) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object Subject: Re: Eiffel and Java Date: 25 Nov 1996 20:49:11 GMT Organization: USIT Univeritetet i Oslo Lines: 26 Message-ID: References: <1996Nov18.223239.21147@schbbs.mot.com> NNTP-Posting-Host: macusit36.uio.no Xref: agate comp.lang.eiffel:16587 comp.lang.ada:54368 comp.lang.sather:3230 comp.lang.java.advocacy:2995 comp.object:58242 In article <1996Nov18.223239.21147@schbbs.mot.com>, shang@corp.mot.com wrote: > In article Kai.Quale@usit.uio.no > (Kai Quale) writes: > > How does separation of subtype from subclass help a subclass in violating > > the constraining requirement regulated by its parent ? > > Exactly by allowing subclass not being a subtype. When it violates, > it cannot be a subtype, but it still can be a subclass. A subclass has SOME supertype(s) - if nothing is given it defaults to $OB. This means it inherits INTERFACE from the supertype(s). Being a subclass, it also inherits CODE from superclass(es). The superclasses however, don't have to have the same name as the supertypes. Result: The subclass inherits TYPE constraints from its supertype(s), and other constraints from its superclass(es). It cannot violate either. Where's the problem ? kai -- Kai Quale USIT, University of Oslo email: Kai.Quale@usit.uio.no From cfl@zurich.ibm.com Thu Dec 5 15:48:07 PST 1996 Article: 3239 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!swrinde!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!129.34.139.15!newsgate.watson.ibm.com!watnews.watson.ibm.com!grimsel.zurich.ibm.com!usenet From: Claudio Fleiner Newsgroups: comp.lang.sather Subject: Re: pSather and solaris/tcpip Date: Thu, 05 Dec 1996 08:20:26 +0100 Organization: IBM Zurich Research Laboratory Lines: 28 Message-ID: <32A677BA.41C6@zurich.ibm.com> References: <329CE440.EE@santafe.edu> NNTP-Posting-Host: ybrig.zurich.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; AIX 1) To: "Timothy H. Keitt" Timothy H. Keitt wrote: > > I'm interested in using pSather on a network of (mostly uniprocessor) > Suns. I can compile the solaris/tcpip platform no problem, but I can't > find any documentation on how to configure things. The "Hello World" > program from the pSather manual compiles and runs fine with > -solaris/1cluster, but core dumps using -solaris/tcpip. Any help > appreciated. > I tried to find out more details, but was unable to connect to ICSI the last few days. So the explanation may not be completely accurate: 1. Inside the tcp/ip directory in System (probably solaris/tcp) should be a file with all the hosts you can use. 2. There is also a startup script that you have to patch. This script gets a number n and the command line arguments of your program and has to start the program on the top n hosts listed in the file described above. This script uses 'export', which you may not have. In this case you have to write it to use 'rsh'. Make sure that you 'cd' to the correct directory before starting the program Hope this helps. Claudio From gomes@ICSI.Berkeley.EDU Sun Dec 8 18:22:55 PST 1996 Article: 3244 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Compiling Sather with tcl7.6/tk4.2 Date: 8 Dec 1996 23:43:16 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 52 Message-ID: <58fjqk$t7m@agate.berkeley.edu> References: NNTP-Posting-Host: samosa.icsi.berkeley.edu In article , marduk wrote: >Hello. I am trying to compile Sather on my Linux workstation, which has >tcl version 7.6 and tk version 4.2. I have edited the Platform.module files. >Then I ran 'make' wich ran fine. So then I tried 'make optional' but this >doesn't go through do to tcl_RcFileName not being declared. Sure enough, I >check the tcl7.6 readme file which says that the C tcl_RcFileName is no longer >used and has been replaced by the tcl variable tcl_rcFileName. > >Is there a patch for this so that I may get Sather to compile on my system. >I don't know tcl/tk, and so am unable to figure out how to do this myself. > Unfortunately there isn't. The last release used Tk 4.0 and Tcl 7.4 (7.5 worked as well, I believe), which are what are installed locally. I don't have the time to install the new versions and make the changes right now. However, if anyone else out there has made the changes, please let me know, and I'll be happy to incorporate them into the next release. ben The particular error you allude to occurs in Library/System/TclTk/c_interface.c int Tk_AddRaster(interp) Tcl_Interp *interp; /* Interpreter for application. */ { Tk_Window main; main = Tk_MainWindow(interp); if ( main == NULL ) { return TCL_ERROR; } if (RasterInit(interp) == TCL_ERROR) { return TCL_ERROR; } Tcl_CreateCommand(interp, "raster", RasterCmd, (ClientData) main, (void (*)()) NULL); >>>>> tcl_RcFileName = "~/.wishrc"; return TCL_OK; } From gomes@ICSI.Berkeley.EDU Sun Dec 8 18:22:59 PST 1996 Article: 3246 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Easiest way to read INT/FLT from STR? Date: 9 Dec 1996 02:22:25 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 31 Message-ID: <58ft51$4bg@agate.berkeley.edu> References: <58fpe5$pop$1@enyo.uwa.edu.au> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <58fpe5$pop$1@enyo.uwa.edu.au>, Llew Mason wrote: >Hi all, quick question. > >What's the easiest way (read as shortest amount of code required) to read >an integer or float from a string? > >I currently make a cursor on the string and call get_flt or get_int. It's not too bad... s: STR := "3"; i:INT := s.cursor.get_int; It is what I usually do, but I just looked and found a create routine in both INT and FLT that take a string as an argument. They are built-ins and call atoi or atof i:INT := #("3"); >I would rather use an int/flt routine in STR itself. :( I would, but STR is already a pretty large class as it stands! Maybe... I too tend to look in the class being converted for the conversion routine, and the STR class is probably one of the first that newcomers to Sather must deal with. ben From lmason@tartarus.uwa.edu.au Tue Dec 10 23:05:53 PST 1996 Article: 3250 of comp.lang.sather Path: agate!spool.mu.edu!uwm.edu!cs.utexas.edu!news.sprintlink.net!news-peer.sprintlink.net!worldnet.att.net!feed1.news.erols.com!news.ecn.uoknor.edu!munnari.OZ.AU!news.mel.connect.com.au!news.uwa.edu.au!not-for-mail From: lmason@tartarus.uwa.edu.au (Llew Mason) Newsgroups: comp.lang.sather Subject: Implementing immutable is_eq for keys of MAP Date: 11 Dec 1996 05:23:54 GMT Organization: The University of Western Australia Lines: 90 Message-ID: <58lgha$v0u$2@enyo.uwa.edu.au> NNTP-Posting-Host: lethe.uwa.edu.au X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Hi all, (apologies for this rather long message) I'm trying to write a new class to be used as the key type for a MAP. Unfortunately, I can't get the map to recognise when two of my keys are the same after inheriting from $IS_EQ and implementing my own version of is_eq. Some code which demonstrates my problem follows : --------------------------------------------------------- class KEY < $IS_EQ, $STR is include COMPARABLE; create : SAME is return new; end; create(o : SAME) : SAME is ret : SAME := new; ret.list := o.list.copy; return ret; end; create(l : LIST{INT}) : SAME is ret : SAME := new; ret.list := l.copy; return ret; end; is_eq(s : SAME) : BOOL is return s.list.equals(list); end; str : STR is return list.str; end; attr list : LIST{INT}; end; class MAIN is main is la : LIST{INT} := #LIST{INT}; lb : LIST{INT} := #LIST{INT}; la.append(1); la.append(2); la.append(3); lb.append(1); lb.append(2); lb.append(3); a : KEY := #KEY(la); b : KEY := #KEY(lb); c : MAP{KEY, INT} := #MAP{KEY, INT}; c[a] := 1; #OUT + a + " = " + b + " is " + (a = b) + "\n"; #OUT + c + " has_ind " + b + " is " + c.has_ind(b) + "\n"; #OUT + c + " + [" + b + " = 2] is "; c[b] := 2; #OUT + c + "\n"; end; end; --------------------------------------------------------- It outputs : {1,2,3} = {1,2,3} is true {[{1,2,3}]=1} has_ind {1,2,3} is false {[{1,2,3}]=1} + [{1,2,3} = 2] is {[{1,2,3}]=1,[{1,2,3}]=2} and I would like it to output : {1,2,3} = {1,2,3} is true {[{1,2,3}]=1} has_ind {1,2,3} is true {[{1,2,3}]=1} + [{1,2,3} = 2] is {[{1,2,3}]=2} So can anyone tell me what I'm doing wrong? cya Llew From gomes@ICSI.Berkeley.EDU Tue Dec 10 23:57:22 PST 1996 Article: 3251 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Implementing immutable is_eq for keys of MAP Date: 11 Dec 1996 07:50:39 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 29 Message-ID: <58lp4f$och@agate.berkeley.edu> References: <58lgha$v0u$2@enyo.uwa.edu.au> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <58lgha$v0u$2@enyo.uwa.edu.au>, Llew Mason wrote: >Hi all, (apologies for this rather long message) > >I'm trying to write a new class to be used as the key type for a MAP. >Unfortunately, I can't get the map to recognise when two of my keys are >the same after inheriting from $IS_EQ and implementing my own version of >is_eq. I've rewritten some of the comparison routines to have somewhat better error reporting, especially when checking is turned on. The current version of the library at ICSI prints out the following message when you try to compile your program: ---- Uncaught STR exception: Cannot provide a default hash for:KEY since is_eq is defined.Redefine hash and subtype from $HASH. ---- The error message points out the source of the problem; the hash routine must be redefined so that it is consistent with the equality routine (if two things are equal they must have the same hash value), and you must subtype from $HASH. After making this fix, the program should work. Hope that helps! ben From i.joyner@acm.org Fri Dec 13 13:42:44 PST 1996 Article: 3259 of comp.lang.sather Path: agate!spool.mu.edu!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!psinntp!psinntp!bbnews1!plnews.pl.unisys.com!not-for-mail From: Ian Joyner Newsgroups: comp.lang.misc,comp.object,comp.programming,comp.lang.java.programmer,comp.lang.java.advocacy,microsoft.public.vc.language,comp.lang.c,comp.lang.objective-c,comp.lang.sather,comp.lang.smalltalk Subject: C++?? Critique available in HTML WEB format Date: Fri, 13 Dec 1996 13:03:26 +1100 Organization: Unisys Lines: 27 Message-ID: <32B0B96E.557F@acm.org> Reply-To: i.joyner@acm.org NNTP-Posting-Host: 192.146.252.190 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (WinNT; I) Xref: agate comp.lang.misc:27768 comp.object:58905 comp.programming:37746 comp.lang.java.programmer:24926 comp.lang.java.advocacy:3743 comp.lang.c:223834 comp.lang.objective-c:6111 comp.lang.sather:3259 comp.lang.smalltalk:47928 Dear fellow programmers, The third edition of the C++?? Critique which I announced recently is now available in HTML format. The URL for the HTML and links to other postscript sites is: http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html The critique will not only be of interest to C++ programmers, but also to Java and Eiffel programmers, as the critique now contains comparisons to these languages. Thank you to Geoff Eldridge of University of Technology Sydney for the conversion to HTML and making this available at his site. It is still available from many sites in Postscript form for a more easily readable printed copy. Thank you to the many sites that have made the postscript available. Please feel free to copy the critique and hand it around. It is, however, copyright against publication for profit. ------------------------------------------------------------------------ Ian Joyner | "for when lenity and cruelty play | All opinions are Internet email: | for a kingdom, the gentler | personal and are i.joyner@acm.org | gamester is the soonest winner" | not Unisys | William Shakespeare Henry V | official comment ------------------------------------------------------------------------ From lmason@tartarus.uwa.edu.au Wed Jan 29 02:47:58 PST 1997 Article: 3279 of comp.lang.sather Path: agate!howland.erols.net!newspump.sol.net!newsfeeds.sol.net!hammer.uoregon.edu!csulb.edu!drivel.ics.uci.edu!news.service.uci.edu!ihnp4.ucsd.edu!munnari.OZ.AU!news.uwa.edu.au!not-for-mail From: lmason@tartarus.uwa.edu.au (Llew Mason) Newsgroups: comp.lang.sather Subject: ANNOUNCE : Win32 SATHER 1.1 Port Date: 28 Jan 1997 09:43:28 GMT Organization: The University of Western Australia Lines: 257 Message-ID: <5ckho0$lo$1@enyo.uwa.edu.au> NNTP-Posting-Host: lethe.uwa.edu.au X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] A Win32 port of the object-oriented language Sather is available at : http://maths.uwa.edu.au/~lmason/ If you find that this site is too slow (which is likely if you are in Europe or the US - ie. the rest of the world :) then mail me and I may be able to make other arrangements. If you have any problems or suggestions feel free to mail me at lmason@maths.uwa.edu.au. Please note that as of the 1st of March 1997 my mail address will change to lmason@keating.anu.edu.au. The distribution has been zipped with WinZip and requires long filename support and either Windows 95 or Windows NT. I have included the ReadMeFirst.txt file and Win32Changes.txt file below. Apologies for the length of this message, but I thought this information may be of interest to other people who have been trying to port Sather to Win32. thanks, Llew Mason PS : If anyone from ICSI would like to make my life easier by making some minor changes to facilitate porting to Win32 then give me a buzz. ------------------------------------------------------------------ ReadMeFirst.txt file follows ------------------------------------------------------------------ This is a port of Sather 1.1 to Win32 (Windows 95 / Windows NT). If you have any problems or suggestions feel free to mail me at lmason@maths.uwa.edu.au. Please note that as of the 1st of March 1997 my mail address will change to lmason@keating.anu.edu.au. This is a complete distribution with the following exceptions : o No pSather. o No tcl/tk. If you are interested in either of these then give me a buzz and I may consider trying to get them to work. The complete source distribution is available at : http://www.isci.berkeley.edu/~sather The compiler has been compiled using VC++ 4.1 under Windows 95. You should not need VC++ 4.1 in order use the compiler. You will need a Win32 compliant C compiler that can handle the makefiles generated by the Sather compiler and can link to libraries generated by VC++ (unless you are willing to rebuild the garbage collector). If you are using VC++ you must set the INCLUDE and LIB environment variables to point to your include and lib directories within the VC++ install directory. You must set the SATHER_HOME environment variable to point to the base Sather directory. You should add Sather/Bin to your path. By modifying the settings in the file Sather/System/Common/CONFIG you should hopefully be able to get the compiler working under most commerical compilers running under Windows 95 or Windows NT. If you are not using VC++ it will be necessary to modify the CONFIG file to specify all of the compiler flags. If you are not using Win95 it will be necessary to modify the CONFIG file to specify the command line separator for NT. It is not currently possible to build the compiler using the compiler under VC++ 4.1 due to some problems with the code generated (see the detailed notes below if you are interested). It is not currently possible to build all of the test suites using the compiler under VC++ 4.1. This is due to the fact that some of the test suites generate C code with divide by zeros and VC++ 4.1 catches these as compile time errors. I have not changed the Sather source for the compiler, only the bootstrap C code. See the Win32Changes.txt file for a list of things that have been modified. The only relevant makefiles are : Sather/Boot/cs.code/makefile - builds the bootstrap compiler Sather/System/Common/gc/makefile - builds the garbage collector ------------------------------------------------------------------ Win32Changes.txt follows ------------------------------------------------------------------ Sather v1.1 distribution. VC++ 4.1 Set SATHER_HOME to point to the base Sather directory. Add Sather/Bin directory to the path. Garbage collector : Sather/System/Common/gc/ Copied NT_MAKEFILE to Makefile. > nmake nodebug=1 all CONFIG file : Sather/System/Common/ > cl /EP CONFIG.proto > CONFIG Modified the first section as follows : *** PLATFORMS: "Win32"; *** DEFAULT_PLATFORM: "Win32"; *** DISTRIBUTED: false; *** THREADS: false; *** ZONES: false; *** TRACE: false; *** LIBRARY: "SATHER_LIBRARY","Library/Library.module"; *** VERSION: "1.1"; *** C_COMPILER: "cl "; *** CC_OPTIONS: "-DWIN32 /nologo"; *** GC_LINK: "$(SATHER_HOME)/System/Common/gc.lib"; *** LINK_OPTIONS: "libc.lib kernel32.lib advapi32.lib"; *** MAKE_COMMAND: "nmake"; *** OBJECT_EXT: ".obj"; *** LIB_EXT: ".lib"; *** C_EXT: ".c"; *** SHELL_SEP: " | "; *** EXEC_OPTION: "/Fe"; *** NULL_SEGFAULTS: false; *** SEPARATE_POINTERS: false; *** PSATHER_FLAG: "",""; *** CC_DEBUG_FLAG: "","-g"; *** CC_OPTIMIZE_FLAG: "","-Ot"; *** CC_PROLIX_FLAG: "",""; *** MAKE_VERBOSE_FLAG: "/NOLOGO /S","/NOLOGO /S"; Serial libraries : Built on UNIX platform. Copied complete Library directory over from UNIX build. CS executable : Sather/Boot/cs.code/ Makefile : *** CFLAGS= -DWIN32 -I. -Ot -I../System/Common *** CC= cl *** HDR= sather.h tags.h *** LIBS= $(SATHER_HOME)/System/Common/gc.lib libc.lib kernel32.lib advapi32.lib *** CS= cs.exe *** OBJ= ABSTRACT_FRAME_LAYOUT.obj AM_CURSOR.obj AM_CURSOR_POS.obj AM_CURSORx.obj AM_CURSORxx.obj AM_CURSORxxx.obj AM_OUT.obj AM_OUTx.obj AS_FAR_EXPR.obj AS_OUT.obj AS_OUTx.obj CALL_SIG.obj CGEN.obj CGENx.obj CGENxx.obj CGENxxx.obj CGENxxxx.obj CGENxxxxx.obj CGENxxxxxx.obj CGENxxxxxxx.obj CGENxxxxxxxx.obj CGENxxxxxxxxx.obj CODE_FILE.obj CODE_OPTIONS.obj CONFIG_ROUT.obj CS.obj CS_OPTIONS.obj CS_OPTIONSx.obj FIND_TYPES.obj FLISTINT.obj FMAPAM_ROUT_DEFFLISTAM_I.obj FMAPSTRSIG.obj FMAPdTPdLAYOUT.obj FSETBOUND_TYPE_LAYOUT.obj FSETSTR.obj GET_MAIN_SIG.obj IMPL.obj INLINE_ITER.obj MANGLE.obj OPTIMIZE.obj OPT_ITER.obj OPT_LOCAL.obj OPT_PREFETCH.obj PARSER.obj PARSERx.obj PARSERxx.obj PARSERxxx.obj PROG_AS_TBL.obj SE_CONTEXT.obj STAT1.obj TP_CLASS.obj TP_ITER_TBL.obj TRANS.obj TRANSx.obj TRANSxx.obj TRANSxxx.obj TRANSxxxx.obj TUPIDENTARRAYdTP.obj XFORM_CODE.obj globals.obj strings.obj stringsx.obj stringsxx.obj system.obj dispatch.obj unbox.obj *** *** ../$(CS): $(OBJ) runtime.obj $(HDR) *** $(CC) $(CFLAGS) /Fe../$(CS) $(OBJ) runtime.obj $(LIBS) *** *** $(OBJ): $(HDR) *** $(CC) $(CFLAGS) -c $*.c *** *** runtime.obj: ../../System/Common/runtime.c $(HDR) *** $(CC) $(CFLAGS) -c ../../System/Common/runtime.c Problems -------- Sather/System/Common/runtime.c 4 : sys/file.h does not exist (include only if WIN32 not defined). 301 : fork() and sleep() not available under these names in VC++ (but there's no need for this code under 95/NT since this is for GDB only) (include only if WIN32 not defined). 389 : SIGQUIT not defined in VC++ signal.h (include only if WIN32 not defined). 392 : SIGBUS not defined in VC++ signal.h (include only if WIN32 not defined). 459 : Divide by zero not allowed on compile by VC++ (What should be done instead?). 460 : Divide by zero not allowed on compile by VC++ (What should be done instead?). Sather/System/Common/exception.h 16 : sys/utsname.h does not exist (include only if WIN32 not defined). Sather/Boot/cs.code/CS_OPTIONS.c 3350 : Way too much nesting for VC++4.1 parser stack in CS_OPTIONS_handle_other_1(). De-nested by hand. Sather/Boot/cs.code/system.c 5495 : VC++4.1 internal compiler error if compiled using -O2 (-Ot is ok). Sather/Boot/cs.code/CGEN.c 7281 : Do not prepend '../' to the sather home path if it doesn't begin with '/'. 95/NT paths can begin with a drive letter. See Sather/Compiler/Back/cgen.sa : 344 7490 : Do not prepend '../' to the sather home path if it doesn't begin with '/'. 95/NT paths can begin with a drive letter. See Sather/Compiler/Back/cgen.sa : 366 Sather/Boot/cs.code/CGENxxxxxxxx.c 8065 : Do not prepend '../' to the sather home path if it doesn't begin with '/'. 95/NT paths can begin with a drive letter. See Sather/Compiler/Back/cgen.sa : 1021 Sather/Boot/cs.code/strings.c 4881 : Default executable should not be a.out for 95/NT. (Use aout.exe) See Sather/Compiler/Configuration/cs_options.sa : 458 Sather/Boot/cs.code/stringsxx.c 2906 : This hack for removing a directory should be part of the CONFIG options. (deltree /Y works for 95/NT) See Sather/Compiler/Back/cgen.sa : 1048 Sather/System/Common/runtime.h 165 : FLTDEXP10(f) should be defined to be pow(10.0,f) if WIN32 is defined. Notes ----- o Win95 DOS command shell has no real command separator. If you only wish to use 'cd' as the first of two commands then '|' can be used. This actually pipes the non-existant output of 'cd' into the next command. o Win95 has no proper command shell language - PP is useless under Win95 and the serial libraries cannot be built. PP needs to be a C program which is compiled before the serial libraries are built. o UNIX directory notation ('/') should be used wherever possible since some of the directories are sometimes used as inline Sather/C strings as well as actual directories in the makefile and '\' is escape character in Sather/C strings. o The ultra-deep nesting generated by the compiler for the compiler is a real problem for VC++4.1. It shouldn't cause a problem for most programs, but it is a real pain to modify the bootstrapped compiler by hand to reduce the nesting level. o Divide by zeros are caught at compile-time by VC++, so many of the test suites fail to compile. ------------------------------------------------------------------ From holger@uni-muenster.de Wed Jan 29 12:50:37 PST 1997 Article: 3282 of comp.lang.sather Path: agate!newsgate.cuhk.edu.hk!hammer.uoregon.edu!news.mathworks.com!fu-berlin.de!news-ber1.dfn.de!news-fra1.dfn.de!news-koe1.dfn.de!uni-muenster.de!news From: "Holger Klawitter" Newsgroups: comp.lang.sather Subject: Re: ANNOUNCE : Win32 SATHER 1.1 Port Date: 29 Jan 1997 13:45:49 +0100 Organization: Westfaelische Wilhelms-Universitaet Muenster, Germany Lines: 17 Sender: "Holger Klawitter" Message-ID: References: <5ckho0$lo$1@enyo.uwa.edu.au> <5cnarb$pl@agate.berkeley.edu> NNTP-Posting-Host: nirvana.uni-muenster.de X-Newsreader: Gnus v5.2.25/XEmacs 19.14 gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) writes: > >A Win32 port of the object-oriented language Sather is available at : > > http://maths.uwa.edu.au/~lmason/ > I've copied that distribution to ICSI's ftp server > and it should be available at: > ftp://ftp.icsi.berkeley.edu/pub/sather/Sather-1.1-Win32.ZIP The distribution is now available in Europe on ftp://ftp.uni-muenster.de/pub/languages/sather/Sather-1.1-Win32.ZIP Holger Klawitter holger@math.uni-muenster.de Institut fuer Informatik http://www.icsi.berkeley.edu/~holger Einsteinstr. 62 http://wwwmath.uni-muenster.de/~holger 48149 Muenster, Germany Tel: +49 251 83 33747 Fax: +49 251 83 33755 From cfl@zurich.ibm.com Fri Jan 31 11:55:01 PST 1997 Article: 3283 of comp.lang.sather Path: agate!newsxfer3.itd.umich.edu!howland.erols.net!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!uunet!in2.uu.net!129.34.139.15!newsgate.watson.ibm.com!watnews.watson.ibm.com!grimsel.zurich.ibm.com!usenet From: Claudio Fleiner Newsgroups: comp.lang.sather Subject: Re: ANNOUNCE : Win32 SATHER 1.1 Port Date: Thu, 30 Jan 1997 17:10:02 +0100 Organization: IBM Zurich Research Laboratory Lines: 14 Message-ID: <32F0C7DA.15FB@zurich.ibm.com> References: <5ckho0$lo$1@enyo.uwa.edu.au> NNTP-Posting-Host: boval.zurich.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; AIX 1) Just for the records: there is a port of most of the GNU utilities to Win95 and WinNT. This includes among others bash, gcc and gmake. By using this port I could compile the boot compiler without patching. However, I did not have to time to investigate how to compile the garbage collector. However, as soon as someone is able to compile it with this tools, supporting the Sather compiler on Windows should be easy for the Sather team. (Much easier than to patch the boot compiler because of VC++ compiler bugs). Besides, gcc is free, while VC++ is not. The home page of this project: http://www.cygnus.com/misc/gnu-win32/ Claudio From lmason@tartarus.uwa.edu.au Fri Jan 31 21:26:32 PST 1997 Article: 3284 of comp.lang.sather Path: agate!usenet.ins.cwru.edu!news.ysu.edu!news.radio.cz!voskovec.radio.cz!news.radio.cz!CESspool!www.nntp.primenet.com!nntp.primenet.com!feed1.news.erols.com!howland.erols.net!spool.mu.edu!munnari.OZ.AU!news.uwa.edu.au!not-for-mail From: lmason@tartarus.uwa.edu.au (Llew Mason) Newsgroups: comp.lang.sather Subject: Re: ANNOUNCE : Win32 SATHER 1.1 Port Date: 31 Jan 1997 04:23:00 GMT Organization: The University of Western Australia Lines: 54 Message-ID: <5crs34$jah$1@enyo.uwa.edu.au> References: <5ckho0$lo$1@enyo.uwa.edu.au> <32F0C7DA.15FB@zurich.ibm.com> NNTP-Posting-Host: lethe.uwa.edu.au X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Claudio Fleiner (cfl@zurich.ibm.com) wrote: : Just for the records: there is a port of most of the GNU utilities : to Win95 and WinNT. This includes among others bash, gcc and gmake. : By using this port I could compile the boot compiler : without patching. However, I did not have to time to investigate : how to compile the garbage collector. However, as soon as someone : is able to compile it with this tools, supporting the Sather : compiler on Windows should : be easy for the Sather team. (Much easier than to patch the : boot compiler because of VC++ compiler bugs). : Besides, gcc is free, while VC++ is not. : : The home page of this project: http://www.cygnus.com/misc/gnu-win32/ Just for the record (from the other side of the fence) : I attempted to use these tools some time ago to port Sather to Win32 (to save me the trouble of dealing with VC++'s inadequacies in porting UNIX code to Win32) but found that it did not have enough POSIX compliance implemented (especially in relation to compiling the GC). I also looked at using DJGPP and RSX, but I found that the VC++ was the only system under which I could get a stable build working. Also, it is not really fair to say that the patches are needed to get around VC++ compiler bugs - I encountered only one real compiler bug and this was with full optimisation on and downgrading the optimisation level removed the problem. I suppose you could consider the problem with the overly deep nesting of if/else statements filling the parser stack as a compiler bug, but the level of nesting was 100 deep or so and would never occur except in automatically generated code (unless you had a real interesting coding style :). VC++ does have some advantages for Win32 though : o Most serious Windows developers already have it installed. (Apologies to those Windows developers who don't but consider themselves to be serious :) o It is (in my experience) _much_ faster than gcc (especially with minimal rebuild, incremental compilation, incremental linking and pre-compiled header files enabled). o It produces (in my experience) better optimised code than gcc. I'm not advertising MS products - gcc is free, which is a big plus, especially for something like the Sather project. The biggest advantage to using something like the Cygnus tools is a UNIX compliant make utility and a UNIX shell. cya Llew Mason From manfred.schneider@rhein-neckar.de Sat Feb 1 19:16:08 PST 1997 Article: 3285 of comp.lang.sather Path: agate!howland.erols.net!news.nacamar.de!news.bln.de!mind.de!bolzen.in-berlin.de!news.all.de!IN-Berlin.DE!fub!zrz.TU-Berlin.DE!news-ber1.dfn.de!news-lei1.dfn.de!news-nue1.dfn.de!news-mue1.dfn.de!news-stu1.dfn.de!news.belwue.de!news.uni-mannheim.de!news From: "Manfred Schneider" Newsgroups: comp.lang.modula3,comp.lang.oberon,comp.lang.objective-c,comp.lang.pascal.delphi.misc,comp.lang.perl.misc,comp.lang.python,comp.lang.sather,comp.lang.smalltalk,comp.lang.tcl Subject: 2 new pages / 3700+ links about Object-Orientation Date: 1 Feb 1997 05:48:25 GMT Organization: Private Site Lines: 65 Message-ID: <01bc1003$abb51950$b259c5c1@cetus> NNTP-Posting-Host: cetus.rhein-neckar.de X-Newsreader: Microsoft Internet News 4.70.1160 Xref: agate comp.lang.modula3:7956 comp.lang.oberon:8189 comp.lang.objective-c:6352 comp.lang.pascal.delphi.misc:86959 comp.lang.perl.misc:63682 comp.lang.python:17608 comp.lang.sather:3285 comp.lang.smalltalk:50762 comp.lang.tcl:62332 Subject: Collection of 3700+ links about Object-Orientation Newsgroups: Some comp.* newsgroups related to OO Reply-To: manfred.schneider@rhein-neckar.de (Manfred Schneider) Summary: Topics and URLs of Cetus Links Posting-Freq.: Monthly Organization: Private Site Hello, are you interested in a collection of more than 3700 links about Object-Orientation? No ads, few graphics, fast and free access! Main topics of the collection are: o General Information and Links o Distributed Objects, Business Objects, Object Request Brokers, ActiveX/OLE, Corba, JavaBeans/RMI, OpenDoc o OOA/OOD Methods and Tools, Diagram Layout o Languages, Ada, C++, Delphi, Eiffel, Java, JavaScript, Modula-3, Oberon, Objective-C, Perl (new!), Python, Sather, Smalltalk, Tcl/Tk (new!), VBScript, Visual Basic, Visual C++ o Databases, OO DBMS, OR DBMS, OR Mapping o Patterns, Libraries, Frameworks o Metrics, Reuse, Testing, Numerics o Services and Companies The collection runs on a server in Heidelberg, Germany. Mirrors are available for faster access from other countries. URL of original site: o http://www.rhein-neckar.de/~cetus/software.html URLs of mirror sites: o Australia, Melbourne http://www.csse.swin.edu.au/manfred/software.html o Austria, Vienna http://www.infosys.tuwien.ac.at/cetus/software.html o Brazil, RS, Porto Alegre http://www.intuitive.com.br/cetus/software.html o Japan, Osaka http://aries.ise.eng.osaka-u.ac.jp/cetus/software.html o USA, IL, Chicago http://www.objenv.com/cetus/software.html o USA, UT, Provo http://mini.net/cetus/software.html I hope you will find the Cetus Links useful. Please feel free to send suggestions, comments, new or changed URLs. Manfred From fjh@murlibobo.cs.mu.OZ.AU Sat Feb 1 19:16:52 PST 1997 Article: 3287 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!munnari.OZ.AU!cs.mu.OZ.AU!murlibobo.cs.mu.OZ.AU!fjh From: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.sather Subject: Re: ANNOUNCE : Win32 SATHER 1.1 Port Date: 31 Jan 1997 20:27:08 GMT Organization: Comp Sci, University of Melbourne Lines: 31 Message-ID: <5ctkis$qkr@mulga.cs.mu.OZ.AU> References: <5ckho0$lo$1@enyo.uwa.edu.au> <32F0C7DA.15FB@zurich.ibm.com> <5crs34$jah$1@enyo.uwa.edu.au> NNTP-Posting-Host: murlibobo.cs.mu.oz.au lmason@tartarus.uwa.edu.au (Llew Mason) writes: >Claudio Fleiner (cfl@zurich.ibm.com) wrote: >: Just for the records: there is a port of most of the GNU utilities >: to Win95 and WinNT. [...] >: The home page of this project: http://www.cygnus.com/misc/gnu-win32/ > >Just for the record (from the other side of the fence) : > >I attempted to use these tools some time ago to port Sather to Win32 >(to save me the trouble of dealing with VC++'s inadequacies in porting >UNIX code to Win32) but found that it did not have enough POSIX >compliance implemented (especially in relation to compiling the GC). The tools have improved a lot recently; try the latest version (b17.1), it's much better. >VC++ does have some advantages for Win32 though : Yes, one of them being that you can't write commercial code with the gnu-win32 gcc, since the cygwin.dll code is GLP'ed, not LGLP'ed. Still, even if you use the VC++ compiler, the presence of the other gcc tools may make porting a hell of a lot easier, since you can reuse the existing Makefiles and other infrastructure. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From fjh@murlibobo.cs.mu.OZ.AU Sat Feb 1 19:17:29 PST 1997 Article: 3286 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!munnari.OZ.AU!cs.mu.OZ.AU!murlibobo.cs.mu.OZ.AU!fjh From: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.sather Subject: Re: ANNOUNCE : Win32 SATHER 1.1 Port Date: 31 Jan 1997 20:21:45 GMT Organization: Comp Sci, University of Melbourne Lines: 135 Message-ID: <5ctk8p$qck@mulga.cs.mu.OZ.AU> References: <5ckho0$lo$1@enyo.uwa.edu.au> <32F0C7DA.15FB@zurich.ibm.com> NNTP-Posting-Host: murlibobo.cs.mu.oz.au Claudio Fleiner writes: >Just for the records: there is a port of most of the GNU utilities >to Win95 and WinNT. This includes among others bash, gcc and gmake. >By using this port I could compile the boot compiler >without patching. However, I did not have to time to investigate >how to compile the garbage collector. You guys are using the Boehm collector, aren't you? I ported it to gnu-win32 for the Windows port of Mercury. Well, to be accurate, I ported just enough of it to get Mercury working. It doesn't figure out the stack bottom automatically -- you have to set GC_stackbottom manually -- and I don't think it supports DLLs or incremental collection. Here's the diffs I sent Hans Boehm. He's incorporated some of this into the latest version. ---------------------------------------- This is a necessary but not sufficient change to make things work. [It doesn't define GC_stackbottom. At least with the latest release (beta-14) of gnu-win32, you still have to fool around with the Makefile a bit changing `-o foo' into `-o foo.exe'. It might also be necessary to modify the #ifs in mach_dep.c to select the right i386 code. Also, I think I had a problem with SIG_FILL not being defined in os_dep.c.] Cheers, Fergus. =================================================================== RCS file: /home/staff/zs/imp/mercury/boehm_gc/config.h,v retrieving revision 1.5 diff -b -u -r1.5 config.h --- config.h 1996/03/05 11:06:21 1.5 +++ config.h 1996/05/08 07:25:08 @@ -188,6 +188,11 @@ # define DJGPP /* MSDOS running the DJGPP port of GCC */ # define mach_type_known # endif +# if defined(__CYGWIN32__) +# define I386 +# define CYGWIN32 +# define mach_type_known +# endif # if defined(__BORLANDC__) # define I386 # define MSWIN32 @@ -492,6 +497,13 @@ # define STACKBOTTOM ((ptr_t)0xc0000000) # define MPROTECT_VDB # endif +# ifdef CYGWIN32 +# define OS_TYPE "CYGWIN32" + extern int _bss_start__; +# define DATASTART ((ptr_t)&_bss_start__) + extern int _data_end__; +# define DATAEND ((ptr_t)&_data_end__) +# endif # ifdef OS2 # define OS_TYPE "OS2" /* STACKBOTTOM and DATASTART are handled specially in */ Index: boehm_gc/mach_dep.c =================================================================== The following changes might also be necessary: =================================================================== RCS file: /home/staff/zs/imp/mercury/boehm_gc/mach_dep.c,v retrieving revision 1.4 diff -b -u -r1.4 mach_dep.c --- mach_dep.c 1996/03/05 11:06:45 1.4 +++ mach_dep.c 1996/05/05 10:04:30 @@ -168,7 +168,7 @@ # endif /* __MWERKS__ */ # endif /* MACOS */ -# if defined(I386) &&!defined(OS2) &&!defined(SVR4) &&!defined(MSWIN32) && !defined(SCO) && (!defined(LINUX) || !defined(__ELF__)) +# if defined(I386) &&!defined(OS2) &&!defined(SVR4) && !defined(SCO) && (!defined(LINUX) || !defined(__ELF__)) /* I386 code, generic code does not appear to work */ /* It does appear to work under OS2, and asms dont */ asm("pushl %eax"); asm("call _GC_push_one"); asm("addl $4,%esp"); @@ -191,7 +191,7 @@ asm("pushl %ebx"); asm("call GC_push_one"); asm("addl $4,%esp"); # endif -# if defined(I386) && defined(MSWIN32) +# if defined(I386) && defined(MSWIN32) && 0 /* I386 code, Microsoft variant */ __asm push eax __asm call GC_push_one Index: boehm_gc/os_dep.c =================================================================== RCS file: /home/staff/zs/imp/mercury/boehm_gc/os_dep.c,v retrieving revision 1.5 diff -b -u -r1.5 os_dep.c --- os_dep.c 1996/03/05 11:07:02 1.5 +++ os_dep.c 1996/05/05 10:41:42 @@ -227,7 +227,9 @@ void GC_disable_signals() { if (!mask_initialized) { +#if 0 SIG_FILL(new_mask); +#endif SIG_DEL(new_mask, SIGSEGV); SIG_DEL(new_mask, SIGILL); Index: boehm_gc/test.c =================================================================== RCS file: /home/staff/zs/imp/mercury/boehm_gc/test.c,v retrieving revision 1.4 diff -b -u -r1.4 test.c --- test.c 1996/03/05 11:07:12 1.4 +++ test.c 1996/05/08 07:02:40 @@ -851,6 +851,9 @@ int main() #endif { + char dummy; + extern char*GC_stackbottom; + GC_stackbottom = &dummy; n_tests = 0; # if defined(MACOS) Index: compiler/mercury_compile.pp -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From boehm@mti.sgi.com Sun Feb 2 15:35:13 PST 1997 Article: 3288 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!info.ucla.edu!news.ucdavis.edu!kirin.wwa.com!news-out.internetmci.com!newsfeed.internetmci.com!news.msfc.nasa.gov!www.nntp.primenet.com!nntp.primenet.com!news.idt.net!enews.sgi.com!chronicle.mti.sgi.com!news From: Hans-Juergen Boehm Newsgroups: comp.lang.sather Subject: Re: ANNOUNCE : Win32 SATHER 1.1 Port Date: Sat, 01 Feb 1997 09:46:07 -0800 Organization: Silicon Graphics Inc., Mountain View, CA Lines: 28 Message-ID: <32F3815F.41C6@mti.sgi.com> References: <5ckho0$lo$1@enyo.uwa.edu.au> <32F0C7DA.15FB@zurich.ibm.com> <5ctk8p$qck@mulga.cs.mu.OZ.AU> NNTP-Posting-Host: hoh.mti.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0SC-SGI (X11; I; IRIX 6.3 IP22) To: Fergus Henderson Fergus Henderson wrote: > You guys are using the Boehm collector, aren't you? > I ported it to gnu-win32 for the Windows port of Mercury. > Well, to be accurate, I ported just enough of it to get > Mercury working. It doesn't figure out the stack bottom > automatically -- you have to set GC_stackbottom manually -- > and I don't think it supports DLLs or incremental collection. > > Here's the diffs I sent Hans Boehm. He's incorporated > some of this into the latest version. > ... Most of Fergus' changes should be in 4.11, though I may have omitted some things that looked like temporary workarounds. I also got some changes from Tim Newsham at Arizona which are in my unreleased version. This should allow the stack pointer to be determined automatically. If someone wants to work on this, I should be able to roll a test version that includes all my changes. This should make it easier for you. And it'll make it easier for me, since it'll help the "official" version converge to something that actually works straight out of the box. I believe the current Microsoft or Borland ports still have more bells and whistles (e.g. incremental GC) than the Cygnus/GNU win32 port. -- Hans-Juergen Boehm boehm@mti.sgi.com From i.joyner@acm.org Sun Feb 2 15:35:21 PST 1997 Article: 3290 of comp.lang.sather Path: agate!biosci!news.Stanford.EDU!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.idt.net!psinntp!bbnews1!plnews.pl.unisys.com!not-for-mail From: Ian Joyner Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.ada,comp.lang.oberon,comp.lang.misc,comp.object,comp.programming,comp.software-eng,comp.lang.java.misc,comp.lang.java.advocacy,microsoft.public.vc.language,comp.lang.c,comp.lang.objective-c,comp.lang.sather,comp.lang.smalltalk,comp.sys.mac.oop.macapp3,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer.misc Subject: C++?? Critique: Now in PDF Date: Thu, 30 Jan 1997 14:16:52 +1100 Organization: Unisys Lines: 22 Message-ID: <32F012A4.2BC0@acm.org> Reply-To: i.joyner@acm.org NNTP-Posting-Host: 192.146.252.190 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (WinNT; I) Xref: agate comp.lang.c++:245635 comp.lang.eiffel:18210 comp.lang.ada:57113 comp.lang.oberon:8198 comp.lang.misc:28382 comp.object:61033 comp.programming:40154 comp.software-eng:53555 comp.lang.java.misc:11713 comp.lang.java.advocacy:5325 comp.lang.c:234587 comp.lang.objective-c:6367 comp.lang.sather:3290 comp.lang.smalltalk:50868 comp.sys.mac.oop.macapp3:11441 comp.sys.mac.programmer.codewarrior:62435 comp.sys.mac.programmer.misc:21744 The C++?? Critique is now available in PDF as well as Postscript and HTML. It is available at the site: http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html >From here you can access many other sites with the postscript available. If you have the postscript already available at your site, and would like to make a local copy of the PDF also, please feel free to do so. To display PDF is easy, just download Acrobat Reader from: http://www.adobe.com/prodindex/acrobat/download.html Happy reading, and please feel free to pass the critique around to your colleagues. ------------------------------------------------------------------------ Ian Joyner | "for when lenity and cruelty play | All opinions are Internet email: | for a kingdom, the gentler | personal and are i.joyner@acm.org | gamester is the soonest winner" | not Unisys | William Shakespeare Henry V | official comment ------------------------------------------------------------------------ From jim_n@ix.netcom.com Thu Feb 6 10:34:45 PST 1997 Article: 3291 of comp.lang.sather Path: agate!usenet.ins.cwru.edu!news.ysu.edu!news.radio.cz!voskovec.radio.cz!news.radio.cz!CESspool!hammer.uoregon.edu!news.mathworks.com!worldnet.att.net!ix.netcom.com!news From: "James Nelson" Newsgroups: comp.lang.sather Subject: Re: ANNOUNCE : Win32 SATHER 1.1 Port Date: 5 Feb 1997 05:04:25 GMT Organization: Netcom Lines: 278 Message-ID: <01bc1322$21efa2e0$8b7b5ecf@atlantis> References: <5ckho0$lo$1@enyo.uwa.edu.au> NNTP-Posting-Host: dal-tx9-11.ix.netcom.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NETCOM-Date: Tue Feb 04 11:04:25 PM CST 1997 X-Newsreader: Microsoft Internet News 4.70.1155 Llew, I downloaded your port, and like my attempt at porting the 1.1 version, I can't get it to compile to compiler, even with the only_C mode. I get an abnormal program termination error. At first I thought it was because I was using so much virtual memory (on a 32meg machine), however when I tried it on a 64meg machine, it still failed (only much more quickly). The problem seems to be in the stage when it is suppossed to be outputing the C code. The compiler does work on smaller projects, but fails on the compiler source itself. I also noticed that this 1.1 version used much more memory than the 1.07 version. Jim Nelson Llew Mason wrote in article <5ckho0$lo$1@enyo.uwa.edu.au>... > > A Win32 port of the object-oriented language Sather is available at : > > http://maths.uwa.edu.au/~lmason/ > > If you find that this site is too slow (which is likely if you > are in Europe or the US - ie. the rest of the world :) then > mail me and I may be able to make other arrangements. > > If you have any problems or suggestions feel free to mail me at > lmason@maths.uwa.edu.au. Please note that as of the 1st of March > 1997 my mail address will change to lmason@keating.anu.edu.au. > > The distribution has been zipped with WinZip and requires > long filename support and either Windows 95 or Windows NT. > > I have included the ReadMeFirst.txt file and Win32Changes.txt file > below. Apologies for the length of this message, but I thought > this information may be of interest to other people who have been > trying to port Sather to Win32. > > thanks, > > Llew Mason > > PS : If anyone from ICSI would like to make my life easier by > making some minor changes to facilitate porting to Win32 then give > me a buzz. > > ------------------------------------------------------------------ > ReadMeFirst.txt file follows > ------------------------------------------------------------------ > > This is a port of Sather 1.1 to Win32 (Windows 95 / Windows NT). > > If you have any problems or suggestions feel free to mail me at > lmason@maths.uwa.edu.au. Please note that as of the 1st of March > 1997 my mail address will change to lmason@keating.anu.edu.au. > > This is a complete distribution with the following exceptions : > > o No pSather. > o No tcl/tk. > > If you are interested in either of these then give me a buzz > and I may consider trying to get them to work. > > The complete source distribution is available at : > > http://www.isci.berkeley.edu/~sather > > The compiler has been compiled using VC++ 4.1 under Windows 95. > > You should not need VC++ 4.1 in order use the compiler. You > will need a Win32 compliant C compiler that can handle the > makefiles generated by the Sather compiler and can link to > libraries generated by VC++ (unless you are willing to rebuild > the garbage collector). > > If you are using VC++ you must set the INCLUDE and LIB environment > variables to point to your include and lib directories within the > VC++ install directory. > > You must set the SATHER_HOME environment variable to point to > the base Sather directory. > > You should add Sather/Bin to your path. > > By modifying the settings in the file Sather/System/Common/CONFIG > you should hopefully be able to get the compiler working under > most commerical compilers running under Windows 95 or Windows NT. > > If you are not using VC++ it will be necessary to modify the > CONFIG file to specify all of the compiler flags. > > If you are not using Win95 it will be necessary to modify the > CONFIG file to specify the command line separator for NT. > > It is not currently possible to build the compiler using the > compiler under VC++ 4.1 due to some problems with the code > generated (see the detailed notes below if you are interested). > > It is not currently possible to build all of the test suites > using the compiler under VC++ 4.1. This is due to the fact > that some of the test suites generate C code with divide by > zeros and VC++ 4.1 catches these as compile time errors. > > I have not changed the Sather source for the compiler, only > the bootstrap C code. See the Win32Changes.txt file for a list > of things that have been modified. > > The only relevant makefiles are : > Sather/Boot/cs.code/makefile - builds the bootstrap compiler > Sather/System/Common/gc/makefile - builds the garbage collector > > ------------------------------------------------------------------ > Win32Changes.txt follows > ------------------------------------------------------------------ > > Sather v1.1 distribution. > VC++ 4.1 > > Set SATHER_HOME to point to the base Sather directory. > Add Sather/Bin directory to the path. > > Garbage collector : > Sather/System/Common/gc/ > Copied NT_MAKEFILE to Makefile. > > nmake nodebug=1 all > > CONFIG file : > Sather/System/Common/ > > cl /EP CONFIG.proto > CONFIG > Modified the first section as follows : > *** PLATFORMS: "Win32"; > *** DEFAULT_PLATFORM: "Win32"; > *** DISTRIBUTED: false; > *** THREADS: false; > *** ZONES: false; > *** TRACE: false; > *** LIBRARY: "SATHER_LIBRARY","Library/Library.module"; > *** VERSION: "1.1"; > *** C_COMPILER: "cl "; > *** CC_OPTIONS: "-DWIN32 /nologo"; > *** GC_LINK: "$(SATHER_HOME)/System/Common/gc.lib"; > *** LINK_OPTIONS: "libc.lib kernel32.lib advapi32.lib"; > *** MAKE_COMMAND: "nmake"; > *** OBJECT_EXT: ".obj"; > *** LIB_EXT: ".lib"; > *** C_EXT: ".c"; > *** SHELL_SEP: " | "; > *** EXEC_OPTION: "/Fe"; > *** NULL_SEGFAULTS: false; > *** SEPARATE_POINTERS: false; > *** PSATHER_FLAG: "",""; > *** CC_DEBUG_FLAG: "","-g"; > *** CC_OPTIMIZE_FLAG: "","-Ot"; > *** CC_PROLIX_FLAG: "",""; > *** MAKE_VERBOSE_FLAG: "/NOLOGO /S","/NOLOGO /S"; > > Serial libraries : > Built on UNIX platform. > Copied complete Library directory over from UNIX build. > > CS executable : > Sather/Boot/cs.code/ > > Makefile : > *** CFLAGS= -DWIN32 -I. -Ot -I../System/Common > *** CC= cl > *** HDR= sather.h tags.h > *** LIBS= $(SATHER_HOME)/System/Common/gc.lib libc.lib kernel32.lib > advapi32.lib > *** CS= cs.exe > *** OBJ= ABSTRACT_FRAME_LAYOUT.obj AM_CURSOR.obj AM_CURSOR_POS.obj > AM_CURSORx.obj AM_CURSORxx.obj AM_CURSORxxx.obj AM_OUT.obj AM_OUTx.obj > AS_FAR_EXPR.obj AS_OUT.obj AS_OUTx.obj CALL_SIG.obj CGEN.obj CGENx.obj > CGENxx.obj CGENxxx.obj CGENxxxx.obj CGENxxxxx.obj CGENxxxxxx.obj > CGENxxxxxxx.obj CGENxxxxxxxx.obj CGENxxxxxxxxx.obj CODE_FILE.obj > CODE_OPTIONS.obj CONFIG_ROUT.obj CS.obj CS_OPTIONS.obj CS_OPTIONSx.obj > FIND_TYPES.obj FLISTINT.obj FMAPAM_ROUT_DEFFLISTAM_I.obj FMAPSTRSIG.obj > FMAPdTPdLAYOUT.obj FSETBOUND_TYPE_LAYOUT.obj FSETSTR.obj GET_MAIN_SIG.obj > IMPL.obj INLINE_ITER.obj MANGLE.obj OPTIMIZE.obj OPT_ITER.obj > OPT_LOCAL.obj OPT_PREFETCH.obj PARSER.obj PARSERx.obj PARSERxx.obj > PARSERxxx.obj PROG_AS_TBL.obj SE_CONTEXT.obj STAT1.obj TP_CLASS.obj > TP_ITER_TBL.obj TRANS.obj TRANSx.obj TRANSxx.obj TRANSxxx.obj > TRANSxxxx.obj TUPIDENTARRAYdTP.obj XFORM_CODE.obj globals.obj strings.obj > stringsx.obj stringsxx.obj system.obj dispatch.obj unbox.obj > *** > *** ../$(CS): $(OBJ) runtime.obj $(HDR) > *** $(CC) $(CFLAGS) /Fe../$(CS) $(OBJ) runtime.obj $(LIBS) > *** > *** $(OBJ): $(HDR) > *** $(CC) $(CFLAGS) -c $*.c > *** > *** runtime.obj: ../../System/Common/runtime.c $(HDR) > *** $(CC) $(CFLAGS) -c ../../System/Common/runtime.c > > Problems > -------- > > Sather/System/Common/runtime.c > 4 : sys/file.h does not exist (include only if WIN32 not defined). > 301 : fork() and sleep() not available under these names in VC++ > (but there's no need for this code under 95/NT since this is for > GDB only) (include only if WIN32 not defined). > 389 : SIGQUIT not defined in VC++ signal.h (include only if WIN32 not > defined). > 392 : SIGBUS not defined in VC++ signal.h (include only if WIN32 not > defined). > 459 : Divide by zero not allowed on compile by VC++ (What should be > done instead?). > 460 : Divide by zero not allowed on compile by VC++ (What should be > done instead?). > > Sather/System/Common/exception.h > 16 : sys/utsname.h does not exist (include only if WIN32 not defined). > > Sather/Boot/cs.code/CS_OPTIONS.c > 3350 : Way too much nesting for VC++4.1 parser stack in > CS_OPTIONS_handle_other_1(). De-nested by hand. > > Sather/Boot/cs.code/system.c > 5495 : VC++4.1 internal compiler error if compiled using -O2 (-Ot is > ok). > > Sather/Boot/cs.code/CGEN.c > 7281 : Do not prepend '../' to the sather home path if it doesn't begin > with '/'. 95/NT paths can begin with a drive letter. > See Sather/Compiler/Back/cgen.sa : 344 > 7490 : Do not prepend '../' to the sather home path if it doesn't begin > with '/'. 95/NT paths can begin with a drive letter. > See Sather/Compiler/Back/cgen.sa : 366 > > Sather/Boot/cs.code/CGENxxxxxxxx.c > 8065 : Do not prepend '../' to the sather home path if it doesn't begin > with '/'. 95/NT paths can begin with a drive letter. > See Sather/Compiler/Back/cgen.sa : 1021 > > Sather/Boot/cs.code/strings.c > 4881 : Default executable should not be a.out for 95/NT. (Use aout.exe) > See Sather/Compiler/Configuration/cs_options.sa : 458 > > Sather/Boot/cs.code/stringsxx.c > 2906 : This hack for removing a directory should be part of the CONFIG > options. (deltree /Y works for 95/NT) > See Sather/Compiler/Back/cgen.sa : 1048 > > Sather/System/Common/runtime.h > 165 : FLTDEXP10(f) should be defined to be pow(10.0,f) if WIN32 is > defined. > > Notes > ----- > > o Win95 DOS command shell has no real command separator. If you only wish > to use 'cd' as the first of two commands then '|' can be used. This > actually pipes the non-existant output of 'cd' into the next command. > > o Win95 has no proper command shell language - PP is useless under Win95 > and the serial libraries cannot be built. PP needs to be a C program > which is compiled before the serial libraries are built. > > o UNIX directory notation ('/') should be used wherever possible since > some of the directories are sometimes used as inline Sather/C strings as > well as actual directories in the makefile and '\' is escape character > in Sather/C strings. > > o The ultra-deep nesting generated by the compiler for the compiler is a > real problem for VC++4.1. It shouldn't cause a problem for most > programs, but it is a real pain to modify the bootstrapped compiler by > hand to reduce the nesting level. > > o Divide by zeros are caught at compile-time by VC++, so many of the test > suites fail to compile. > ------------------------------------------------------------------ > > From lhn@netman.dk Mon Feb 10 16:06:13 PST 1997 Article: 3294 of comp.lang.sather Path: agate!howland.erols.net!newspump.sol.net!newsfeeds.sol.net!nntp.uio.no!news-feed.inet.tele.dk!news1.tele.dk!cph-1.news.DK.net!dkuug!dknet!tinderbox.netman.dk!not-for-mail From: "Lars H. Nielsen" Newsgroups: comp.lang.sather Subject: OS/2 Port Date: Mon, 10 Feb 1997 11:04:24 +0100 Organization: NetMan, Copenhagen, Denmark Lines: 3 Message-ID: <32FEF2A8.41C6@netman.dk> NNTP-Posting-Host: duckling.netman.dk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (X11; I; OSF1 V3.2 alpha) Did anyone port 1.1 to OS/2 ? Lars Hupfeldt. From johann@physics20.berkeley.edu Mon Feb 10 16:06:22 PST 1997 Article: 3293 of comp.lang.sather Path: agate!physics20.berkeley.edu!johann From: johann@physics20.berkeley.edu (Johann Hibschman) Newsgroups: comp.lang.sather Subject: Is Sather practical for numeric work? Date: 10 Feb 1997 09:28:07 GMT Organization: UC Berkeley Lines: 51 Message-ID: <5dmpn7$753@agate.berkeley.edu> NNTP-Posting-Host: physics20.berkeley.edu Hello all, I've just stumbled across Sather and have been playing with it for the past weekend, trying to evaluate its suitability for my work. (Numerical computation-type nonsense.) I did a few basic test of speed and found that (on my PC) the Sather code was comparatively slow. I tried addition and multiplication of 100x100 matrices, and got the following times: [ 500 iterations of a=b+c, d=a*b ] C : 12.7s -O2 optimization C++ : 18.5s -O2 Sather: 23.5s -O_fast I didn't do anything special in the C or C++, and I used the basic Sather matrix class I found sitting in the Library directory. To be honest, I'm not too impressed. I've been doing my work in C++, and I don't see much reason to switch. Sather seems to be a bit more elegant, but C++ has a larger code base. Was this test too simplistic? My only thought is that somehow Sather performs better on larger, more complex code than what I tested it on. Is this true? Or is the matrix-multiplying example a poor test to choose? My work really doesn't involve big matrix-multiplies, but they are very easy to write test code for. I'm really computing Chebyshev polynomial approximations to ugly integral transform kernels (themselves involving integrals of Bessel functions), then using those approximations to perform the integral transform. Then I iterate the transform to find successive approximations to an integral equation. In other words, many many small operations that don't really involve vectors or matrices at all. However, I don't really want to rewrite my code in Sather to find out if I should rewrite my code in Sather. :-) I'm interested in Sather primiarily because I've been going nuts trying to manipulate function-type objects in C++, and Sather seems to offer a better interface with proper closures, etc. Well, that's enough rambling for now. I should probably just wander across campus and knock on some doors... Cheers, - Johann -- Johann Hibschman johann@physics.berkeley.edu From gomes@ICSI.Berkeley.EDU Mon Feb 10 16:06:26 PST 1997 Article: 3297 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: Is Sather practical for numeric work? Date: 11 Feb 1997 00:05:13 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 46 Message-ID: <5dod3q$kq@agate.berkeley.edu> References: <5dmpn7$753@agate.berkeley.edu> NNTP-Posting-Host: samosa.icsi.berkeley.edu In article <5dmpn7$753@agate.berkeley.edu>, Johann Hibschman wrote: >Hello all, > >I've just stumbled across Sather and have been playing with it for >the past weekend, trying to evaluate its suitability for my work. >(Numerical computation-type nonsense.) > >I did a few basic test of speed and found that (on my PC) the >Sather code was comparatively slow. I tried addition and multiplication >of 100x100 matrices, and got the following times: > >[ 500 iterations of a=b+c, d=a*b ] > C : 12.7s -O2 optimization > C++ : 18.5s -O2 > Sather: 23.5s -O_fast > Some performance testing of Sather was done by Claudio Fleiner, in order to evaluate the quality of the optimizations. The results are different from yours - this may be due to the use of a different compiler, or possibly the startup overhead for loops is higher, so that a 100 by 100 multiply behaves differently from 300 by 300 matrix multiply? Check out: http://www.icsi.berkeley.edu/~sather/performance/benchmarks/matrix.sa.html --------------------------------------------------------------------------- This is the "real" Matrix Multiplaktion program matrix.sa. It multiplies two 300x300 matrices. Note that the equivalent C (matrix.c) and C++ (matrix.cc) are nearly an order of magnitude slower, unless they are optimized by hand (opt_matrix.c and opt_matrix.cc). Program non optimized compiler optimized hand optimized Sather 96.9 12.3 n/a C 87.5 58.3 9.9 C++ 91.2 57.6 12.7 The C and C++ version were compiled with GCC 2.7.1 and -O3. ----------------------------------------------------------------------------- ben From borisv@icsi.berkeley.edu Mon Feb 10 22:36:01 PST 1997 Article: 3298 of comp.lang.sather Path: agate!usenet From: Vaysman Boris Newsgroups: comp.lang.sather Subject: Re: Is Sather practical for numeric work? Date: Mon, 10 Feb 1997 17:06:41 -0800 Organization: data communication and networking services Lines: 101 Message-ID: <32FFC621.5B1B@icsi.berkeley.edu> References: <5dmpn7$753@agate.berkeley.edu> NNTP-Posting-Host: samosa.icsi.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4m) Johann Hibschman wrote: > > Hello all, > > I've just stumbled across Sather and have been playing with it for > the past weekend, trying to evaluate its suitability for my work. > (Numerical computation-type nonsense.) > > I did a few basic test of speed and found that (on my PC) the > Sather code was comparatively slow. I tried addition and multiplication > of 100x100 matrices, and got the following times: > > [ 500 iterations of a=b+c, d=a*b ] > C : 12.7s -O2 optimization > C++ : 18.5s -O2 > Sather: 23.5s -O_fast > > I didn't do anything special in the C or C++, and I used the basic > Sather matrix class I found sitting in the Library directory. > Well, you did use the matrix multiplication from the Sather library, while you probably coded this stuff in C and C++ yourself;-) More seriously, a lot of locality issues on the register/tlb/cache levels are involved even for a simple matrix multiplication benchmark. In fact, this example was used for a number of years in the CS267, a Berkeley Graduate Parallel Software course to illustrate the importance of taking the memory hierarchy into account. Cehck out http://HTTP.CS.Berkeley.EDU/~demmel/cs267/assignment1.html http://HTTP.CS.Berkeley.EDU/~demmel/cs267/lecture02.html If I remember correctly, the speed of matrix multiplcation for RS6000 compiled with f77, optimizations off, is about 4Mflops, while a very expensive IBM numeric library gives you up to 266Mflops. In a week long homework assignment, Berkeley students came up with versions in excess of 270Mflops. Jeff Bilmes and a few others even wrote a BLAS generator for various architectures: http://www.icsi.berkeley.edu/~bilmes/phipac Compiler optimization levels, inlining, alignment of data placement can all influence the timings. I am trying to say is that what you were obsering was probably due to many factors and one can probably get 10-100 better performance than the fastest time for straightforward C. I agree that the "standard" Sather library is not as fast as it could be. However what Sather does privide (and C and C++) do not, is a type-safe portable interface to Fortran. Since by and large the numerical speed of light is usually displayed by various versions of optimized BLAS written in Fortran, the intention behind the Sather matrix/vector library was to be eventually replaced by the calls to corresponding native BLAS primitives while still providing a nice Sather interface. I have heard from a couple of phyisicists who said they actually had a Sather BLAS level 2 (3?) interface, however it did not find its way yet into the Sather libraries that ICSI distributes. Hopefully, this will be done in the future. > > Was this test too simplistic? My only thought is that somehow Sather > performs better on larger, more complex code than what I tested it on. > Is this true? > I'd say, serial performance should be comparable to that of C and C++, while development/debugging time should be a lot less (no pointers, garbage collection, parametrizations, good library, etc.) On the other hand, Sather does have parallel constructs that you can use, say, on the SMP or a network of workstations. > I'm interested in Sather primiarily because I've been going nuts > trying to manipulate function-type objects in C++, and Sather seems > to offer a better interface with proper closures, etc. we even have closures of Fortran functions now that can be passed to Fortran numerical libraries ... > > Well, that's enough rambling for now. I should probably just wander > across campus and knock on some doors... > You are perfectly welcome to stop by, though we are located a few blocks away from campus... -Boris -- ----------------------------------------------------------------------- ICSI, Office 640 home: 1947 Center St. Suite 600 2206 Haste Str, #25 Berkeley CA 94704-1198 Berkeley, Ca 94704 (510) 642-4274 x126 (510)204-9643 fax (510) 643-7684 ------------------------------------------------------------------------ From cfl@zurich.ibm.com Tue Feb 11 00:36:04 PST 1997 Article: 3300 of comp.lang.sather Path: agate!ihnp4.ucsd.edu!swrinde!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!129.35.248.10!ausnews.austin.ibm.com!sjnews.sanjose.ibm.com!watnews.watson.ibm.com!grimsel.zurich.ibm.com!usenet From: Claudio Fleiner Newsgroups: comp.lang.sather Subject: Re: Is Sather practical for numeric work? Date: Mon, 10 Feb 1997 16:30:46 +0100 Organization: IBM Zurich Research Laboratory Lines: 13 Message-ID: <32FF3F26.167E@zurich.ibm.com> References: <5dmpn7$753@agate.berkeley.edu> NNTP-Posting-Host: boval.zurich.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; AIX 1) To: Johann Hibschman I suggest that you check the the following page http://www.icsi.berkeley.edu/~fleiner/benchmarks/ which has some discussion about benchmarks regarding Sather and C++. Obviously, as Sather compiles through C you cannot make Sather faster than C. However, you may get the same or nearly the same performance much easier. Sather offers you also a nice interface to Fortran, and therefor you can use Fortran libraries directly in your Sather code. Claudio From fjh@murlibobo.cs.mu.OZ.AU Tue Feb 11 11:27:30 PST 1997 Article: 3302 of comp.lang.sather Path: agate!howland.erols.net!worldnet.att.net!news.maxwell.syr.edu!insync!uunet!in2.uu.net!128.250.1.21!munnari.OZ.AU!cs.mu.OZ.AU!murlibobo.cs.mu.OZ.AU!fjh From: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.sather Subject: Re: Is Sather practical for numeric work? Date: 11 Feb 1997 13:34:24 GMT Organization: Comp Sci, University of Melbourne Lines: 69 Message-ID: <5dpsh0$pko@mulga.cs.mu.OZ.AU> References: <5dmpn7$753@agate.berkeley.edu> <32FF3F26.167E@zurich.ibm.com> <5dpf3a$klu@mulga.cs.mu.OZ.AU> <3300488F.2781@zurich.ibm.com> NNTP-Posting-Host: murlibobo.cs.mu.oz.au Claudio Fleiner writes: >Fergus Henderson wrote: >> >> Claudio Fleiner writes: >> >> >Obviously, as Sather compiles through C you cannot make Sather faster >> >than C. >> >> That may seem obvious, but it's not true ;-) >> >Hmm... The SatherCompiler takes Sather code and produces C code, >a C compiler (usually gcc, but any Ansi C compiler will do) then >takes the C code and produces an executable. The same is true of the Mercury compiler. >How can the Sather >Compiler ever write code that runs faster than hand written C Code? The Mercury compiler achieves this by making selective use of non-portable constructs including gcc extensions and a very tiny amount of inline assembler. The use of these constructs is controlled by conditional compilation (#ifdefs), so the Mercury compiler's output can be compiled by any ANSI C compiler (albeit with potential loss of performance). >I can always write the same code as the Sather Compiler does, >and then it is guaranteed that my C code runs at least >as fast as the Sather Code. But then your code might not be portable anymore. In order to make it portable _and_ efficient, you might need a very large number of #ifdefs, macros, and so forth... and in practice this might not be feasible. >It may be possible that the Sather Compiler writes very complicated >Code that runs faster than what a C programmer would write >in his first try, Yes, that's what the Mercury compiler does, in the benchmarks where it beats C. >but in the end a good C programmer will at >least catch up with the speed of the executable produced >by the Sather compiler. This is not necessarily true. A good C programmer would not dream of writing code like the awful rubbish that the Mercury compiler spits out. If it were not automatically generated, it would be unmaintainable. Now it's true that the Sather team have taken a somewhat different approach -- they generate high-level, relatively maintainable C -- so your claim is likely to be mostly true in the case of the current Sather compiler. However, the claim that compiling through C makes it impossible to go faster than C is in practice not true, despite its initially compelling logic! Note that even a C to C compiler could well improve performance, if it performed optimizations that your C to native code compiler didn't perform. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From johann@physics20.berkeley.edu Tue Feb 11 16:18:57 PST 1997 Article: 3303 of comp.lang.sather Path: agate!physics20.berkeley.edu!johann From: johann@physics20.berkeley.edu (Johann Hibschman) Newsgroups: comp.lang.sather Subject: Re: Is Sather practical for numeric work? Date: 11 Feb 1997 21:54:43 GMT Organization: UC Berkeley Lines: 95 Message-ID: <5dqpr3$54r@agate.berkeley.edu> References: <5dmpn7$753@agate.berkeley.edu> <32FFC621.5B1B@icsi.berkeley.edu> NNTP-Posting-Host: physics20.berkeley.edu In article <32FFC621.5B1B@icsi.berkeley.edu>, Vaysman Boris wrote: >More seriously, a lot of locality issues on the >register/tlb/cache levels are involved even for a simple matrix >multiplication benchmark. In fact, this example was used for >a number of years in the CS267, a Berkeley Graduate Parallel Software >course to illustrate the importance of taking the memory hierarchy >into account. > >Cehck out > http://HTTP.CS.Berkeley.EDU/~demmel/cs267/assignment1.html > http://HTTP.CS.Berkeley.EDU/~demmel/cs267/lecture02.html Interesting. My advisor has mentioned a few times that there is some program in numerical computing through the Berkeley CS department for grad students in other fields, but I have yet to find any actual information on it. >Compiler optimization levels, inlining, alignment of data >placement can all influence the timings. I am trying >to say is that what you were obsering was probably due to many >factors and one can probably get 10-100 better performance than the >fastest time for straightforward C. I thing you're right. I got the code (Sather, C, and optimized C) from the Sather Benchmark page, compiled it, and found that it all ran much slower than my original C code. It was even slower than my naive implementation of a Sather matrix multiply using the MAT class. (Yes, even the "optimized" C.) I thought this was odd, so I looked more closely at the timing results. The code that I got from the Sather Benchmark page reported huge numbers of pagefaults, while my own code reported significantly less. I have no idea why this was the case. (To be honest, I'm more than a little fuzzy on what exactly a "pagefault" is, other than that it involves the wrong chunk of memory being mapped into addressable space. I have no idea what a "major" vs a "minor" one is.) ---------------------------- TIME RESULTS: gcc 2.7.2, Sather 1.1, Linux 2.0.18, on a Pentium Pro 200. Using the examples from the Sather benchmark page, I got the following times for multiplying random 100x100 matrices 500 times: matrix.c (unoptimized c, compiled with -O2) [johann@random mat]$ time c_matrix 100 500 Command exited with non-zero status 16 44.06user 0.25system 0:44.46elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (55major+4909minor)pagefaults 0swaps opt_matrix.c (optimized c, compiled with -O2) [johann@random mat]$ time opt_c_matrix 100 500 Command exited with non-zero status 16 33.39user 0.28system 0:33.82elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (55major+4909minor)pagefaults 0swaps matrix.sa (sather, compiled with -O_fast) [johann@random mat]$ time sa_matrix 100 500 wall time: 46.94 sec. user time: 46.79 sec. system time: 0.01 sec. user+system time: 46.80 sec. CPU usage: 99 % 46.85user 0.01system 0:47.04elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (94major+111minor)pagefaults 0swaps mattest.sa (my sather using MAT class, compiled with -O_fast) [johann@random mat]$ time mattest 22.85user 0.00system 0:22.90elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (67major+89minor)pagefaults 0swaps mattest.c (my optimized c, compiled with -O2) [johann@random mattest2]$ time mattest2 500 Command exited with non-zero status 64 12.44user 0.00system 0:12.55elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (52major+35minor)pagefaults 0swaps -------------------------------------------- >we even have closures of Fortran functions now that can be passed >to Fortran numerical libraries ... Any closures of C functions? I'm trying my best to avoid Fortran. :-) Thanks, - Johann -- Johann Hibschman johann@physics.berkeley.edu From johann@physics20.berkeley.edu Tue Feb 11 16:20:28 PST 1997 Article: 3304 of comp.lang.sather Path: agate!physics20.berkeley.edu!johann From: johann@physics20.berkeley.edu (Johann Hibschman) Newsgroups: comp.lang.sather Subject: Re: Is Sather practical for numeric work? Date: 11 Feb 1997 23:28:07 GMT Organization: UC Berkeley Lines: 63 Message-ID: <5dqva7$8jv@agate.berkeley.edu> References: <5dmpn7$753@agate.berkeley.edu> <32FFC621.5B1B@icsi.berkeley.edu> <5dqpr3$54r@agate.berkeley.edu> NNTP-Posting-Host: physics20.berkeley.edu Well, here's another pack of results, this time on my SPARCstation 2 in my office with gcc 2.7.0. The weird thing is that using the Sather MAT class is almost as fast as my C code, while all of the other contenders are slower. I'm confused. I expected the order to be my c, the "optimized" c, the benchmark sather code, the simple sather code, then the naive c code. Memory issues, perhaps? - Johann ------------------------- Sather benchmarks: % time sa_matrix 300 1 wall time: 24.28 sec. user time: 21.67 sec. system time: 0.07 sec. user+system time: 21.74 sec. CPU usage: 89 % 24.86u 0.30s 0:27.75 90.6% % time c_matrix 300 1 112.58u 0.35s 1:57.97 95.7% % time opt_c_matrix 300 1 20.52u 0.25s 0:22.47 92.4% My C code: % time mattest3/mattest3 300 1 13.93u 0.31s 0:14.68 97.0% My Sather code: % time mattest 300 1 17.54u 0.29s 0:18.60 95.8% Sather Benchmarks II % time sa_matrix 100 25 wall time: 18.82 sec. user time: 18.32 sec. system time: 0.03 sec. user+system time: 18.35 sec. CPU usage: 97 % 18.79u 0.16s 0:19.85 95.4% % time c_matrix 100 25 97.66u 0.30s 1:44.02 94.1% % time opt_c_matrix 100 25 15.12u 0.25s 0:15.58 98.6% My C code: % time mattest3/mattest3 100 25 9.70u 0.13s 0:10.11 97.2% My Sather code: % time mattest 100 25 12.71u 0.12s 0:13.01 98.6% -- Johann Hibschman johann@physics.berkeley.edu From gomes@ICSI.Berkeley.EDU Tue Feb 11 19:52:57 PST 1997 Article: 3305 of comp.lang.sather Path: agate!gomes From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Newsgroups: comp.lang.sather Subject: Re: top level/interpreter Date: 12 Feb 1997 03:42:37 GMT Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Lines: 21 Message-ID: <5dre7d$h0q@agate.berkeley.edu> References: NNTP-Posting-Host: samosa.icsi.berkeley.edu In article , Michael Hohn wrote: >Hello, >I have been experimenting with Sather, and was wondering if there is >now a new version of the Sather interpreter for version 1.1. > >If not, which of the older versions of Sather does the old Sather >interpreter work with? > >Thanks, > Mike > No, there are no newer versions of the Sather interpreter (the version provided is contributed, unsupported code). The version of the interpreter that is available will work with release 1.0.5, and possibly 1.0.6. ben From borisv@icsi.berkeley.edu Tue Feb 11 22:49:56 PST 1997 Article: 3307 of comp.lang.sather Path: agate!usenet From: Vaysman Boris Newsgroups: comp.lang.sather Subject: Re: Is Sather practical for numeric work? Date: Tue, 11 Feb 1997 22:49:43 -0800 Organization: data communication and networking services Lines: 57 Message-ID: <33016807.5CD0@icsi.berkeley.edu> References: <5dmpn7$753@agate.berkeley.edu> <32FFC621.5B1B@icsi.berkeley.edu> <5dqpr3$54r@agate.berkeley.edu> NNTP-Posting-Host: samosa.icsi.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4m) Johann Hibschman wrote: > > Interesting. My advisor has mentioned a few times that there is some > program in numerical computing through the Berkeley CS department for > grad students in other fields, but I have yet to find any actual > information on it. Sorry, I do not have any information on this program, but I was TAing CS267 last year and about 50% of folks were from outside: engineering, math, astronomy, etc. There are two versions of 267. A more mathematical one will probably be taught next year. Professor Kahan is teaching a numerical course this semester. > of pagefaults, while my own code reported significantly less. I have > no idea why this was the case. (To be honest, I'm more than a little > fuzzy on what exactly a "pagefault" is, other than that it involves > the wrong chunk of memory being mapped into addressable space. I have > no idea what a "major" vs a "minor" one is.) ... or more precisely, the right chunk is not there ;-) > > ---------------------------- > TIME RESULTS: > ... lots of interesting numbers skipped. I guess, the lesson here is that Sather and C are in the same performance class. Obviously, both versions of mm could be optimized endlessly (blocked for cache, register usage, etc.), but one can probably match the best C code with Sather and vice versa. I wonder where Java currently belongs in the performance space. Somebody posted a few benchmarks a while back, and Java did not look good compared to C or Sather. > > >we even have closures of Fortran functions that can be passed > >to Fortran numerical libraries ... > > Any closures of C functions? I'm trying my best to avoid Fortran. :-) > good, this was the main reason for the Sather/Fortran interface. -Boris -- ----------------------------------------------------------------------- ICSI, Office 640 home: 1947 Center St. Suite 600 2206 Haste Str, #25 Berkeley CA 94704-1198 Berkeley, Ca 94704 (510) 642-4274 x126 (510)204-9643 fax (510) 643-7684 ------------------------------------------------------------------------ From fjh@murlibobo.cs.mu.OZ.AU Wed Feb 12 14:34:33 PST 1997 Article: 3309 of comp.lang.sather Path: agate!spool.mu.edu!munnari.OZ.AU!cs.mu.OZ.AU!murlibobo.cs.mu.OZ.AU!fjh From: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.lang.sather,comp.lang.java.programmer Subject: Re: java numerics, was Re: Is Sather practical for numeric work? Date: 12 Feb 1997 11:52:48 GMT Organization: Comp Sci, University of Melbourne Lines: 37 Message-ID: <5dsaug$dnp@mulga.cs.mu.OZ.AU> References: <5dmpn7$753@agate.berkeley.edu> <32FFC621.5B1B@icsi.berkeley.edu> <5dqpr3$54r@agate.berkeley.edu> <33016807.5CD0@icsi.berkeley.edu> <5ds2tu$on7@news1.ucsd.edu> NNTP-Posting-Host: murlibobo.cs.mu.oz.au Xref: agate comp.lang.sather:3309 comp.lang.java.programmer:38359 kennel@lyapunov.ucsd.edu (Matt Kennel) writes: >Vaysman Boris (borisv@icsi.berkeley.edu) wrote: >: I wonder where Java currently belongs in the performance space. > >I'm not so concerned about current implementations, but there seems to >be a major designed-in sticking point. > >Other than the fact that multidimensional arrays are still not there >(a bonehead omission), any array bounds violation may generate a catchable >'array bounds exception'. > >This doesn't sound too ominous, except when you stop to consider that >it is thus legal to use 'out of bound' array exceptions as legitimate >transfers of control in standard Java programs, and thus they cannot >easily be turned off during optimizing code generation, unlike what we do >with Sather. Implementations will offer non-standard switches to turn them off. You can already get at lease one Java implementations that compiles to native code (via C) and does little or not checking for things like array index errors. So, you're right it may be a problem standards-wise, but I doubt it will be a problem in practice. Note that the situation in Ada is basically pretty similar, in that Ada programs can in theory use array bounds exceptions as legitimate transfers of control. Nevertheless, every Ada compiler on the market offers compiler switches off the checks, and in fact I think there are also standardized pragmas for doing this over a particular section of code. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. From kennel@lyapunov.ucsd.edu Wed Feb 12 17:48:49 PST 1997 Article: 3308 of comp.lang.sather Path: agate!spool.mu.edu!munnari.OZ.AU!ihnp4.ucsd.edu!news1.ucsd.edu!kennel From: kennel@lyapunov.ucsd.edu (Matt Kennel) Newsgroups: comp.lang.sather,comp.lang.java.programmer Subject: java numerics, was Re: Is Sather practical for numeric work? Date: 12 Feb 1997 09:35:57 GMT Organization: The University of California at San Diego Lines: 66 Message-ID: <5ds2tu$on7@news1.ucsd.edu> References: <5dmpn7$753@agate.berkeley.edu> <32FFC621.5B1B@icsi.berkeley.edu> <5dqpr3$54r@agate.berkeley.edu> <33016807.5CD0@icsi.berkeley.edu> NNTP-Posting-Host: lyapunov.ucsd.edu X-Newsreader: TIN [version 1.2 PL2] Xref: agate comp.lang.sather:3308 comp.lang.java.programmer:38336 Vaysman Boris (borisv@icsi.berkeley.edu) wrote: : I wonder where Java currently belongs in the performance space. : Somebody posted a few benchmarks a while back, and Java did not : look good compared to C or Sather. I'm not so concerned about current implementations, but there seems to be a major designed-in sticking point. Other than the fact that multidimensional arrays are still not there (a bonehead omission), any array bounds violation may generate a catchable 'array bounds exception'. This doesn't sound too ominous, except when you stop to consider that it is thus legal to use 'out of bound' array exceptions as legitimate transfers of control in standard Java programs, and thus they cannot easily be turned off during optimizing code generation, unlike what we do with Sather. Any caller, no matter how far back in the stack, might decide to catch that 'illegal array bounds' exception. One cannot legitimately know whether the illegal array bounds was a mistake or intentionally used to signal a change in the flow of control. The compiler would have to prove case by case that such exceptions are not generatable for any particular array access no matter the input data or arguments passed to a subroutine. This is about as likely as Smalltalk compilers proving the static type of variables sufficiently precisely to rival idiomatic C++ or Sather or Eiffel programs. My hopes are not high. Before you start to get too cocky about the smartness of compilers consider that a ''2-d'' array of array access m[i][j] with loops through i and j would have to know the precise details of exactly how m[*] was initialized (i.e. what are the array bounds of the referred to arrays in in m[*]?), information implicitly given by the results of the execution of the constructor. In other words, there's no obvious information that m[i][j] is a rectangular array except by human convention. The Bill will renounce his earthly wealth and join the Dalai Lama in Nepal before commonly used Java compilers figure this out. I understand the need for always checking in a high-security sandbox *environment*, but not as part of the language definiton. We always want the option to turn off these checks if we're willing to take the risk of a crash. Put simplistically, the Java designers mistook a precondition violation (wrong array index) for an exception, making high performance computations on arrays needlessly difficult to achieve through the Java language. In my opinion it's a major blunder, even worse than mixing in Starbucks beans into a wonderful brew of Peet's. ;-) I could be wrong about this, but I haven't been convinced yet. The easiest way to fix it is to make Java like Sather ASAP. Allow user-defined '[ ]' on user-defined classes (including multi-variable [i,j] sorts of access) which don't raise exceptions unless explicitly mentioned. Deprecate the use of built-in [] arrays except in internal class implementations. Matt Kennel INLS, mbk@lyapunov.ucsd.edu (yes UCSD again). From gomes@ICSI.Berkeley.EDU Wed Feb 12 17:57:20 1997 Received: from smorgasbord.ICSI.Berkeley.EDU (root@smorgasbord.ICSI.Berkeley.EDU [128.32.201.6]) by icsia.ICSI.Berkeley.EDU (8.8.2/8.8.3) with ESMTP id RAA06124 for ; Wed, 12 Feb 1997 17:57:18 -0800 (PST) Received: from samosa.Berkeley.EDU (gomes@samosa.ICSI.Berkeley.EDU [128.32.201.205]) by smorgasbord.ICSI.Berkeley.EDU (8.8.2/1.8) with SMTP id RAA23509 for ; Wed, 12 Feb 1997 17:57:16 -0800 (PST) Received: by samosa.Berkeley.EDU (SMI-8.6/SMI-SVR4) id RAA00749; Wed, 12 Feb 1997 17:57:12 -0800 Date: Wed, 12 Feb 1997 17:57:12 -0800 From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Message-Id: <199702130157.RAA00749@samosa.Berkeley.EDU> To: johann@physics20.Berkeley.EDU Subject: Re: Closures and opererator questions. Newsgroups: comp.lang.sather In-Reply-To: <5dtq1i$59n@agate.berkeley.edu> Organization: International Computer Science Institute, Berkeley, CA, U.S.A. Cc: gomes@icsi.Berkeley.EDU Status: O In article <5dtq1i$59n@agate.berkeley.edu> you write: >[ I hope this doesn't show up multiple times. I've been having problems > with the news server. ] > >Hello all, > >I've been reading the Sather docs, and was wondering: > (1) What are the limitations of the existing closure implementation? > (2) How to calculate 1.0/f, where f is my own class? > >Re: (1), I've found that I can't do > > f ::= #MYCLASS; > g: ROUT{FLT}: FLT := bind(f.my_func(_)); > >nor can I make sub- or super- classes of ROUT{T}: T. > What is the signature of my_func? What you describe above should work, if the signature of my_func is correct. And no, you cannot sub or super-type from ROUT{T}:T. That is as the spec says. However, one thing that the spec may still claim that you cannot do: there are no implicit typing relationships between ROUT{$A} and ROUT{$B} even if $A < $B i.e. there are no implicit typing relationships at all. >Is there any way I can make a class which implements a "call" routine >so that it can be passed to code expecting a ROUT{T}:T object? > No - that is quite a nice suggestion, though. You could define your own abstraction with a run routine in it, but then you would have to handle the two cases (bound routines and objects with an equivalent routine in them) separately, though you can probably overload the routine name. >Re: (2), what do I do if I want to overload the other side of the >operation? overloading div would only let me do f/1.0, not 1.0/f. > Sorry! And I don't know of any trick that will give you the effect you want. However, permitting stuff like this can get complex, because the method looks like it is in the interface to FLT, but is really in the interface to 'f''s class ben