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 ch