hsrender@happy.colorado.edu (05/23/91)
Is there any news on the status of Sather? If I recall correctly, Sather is (was) an OO language similar to a stripped down version of Eiffel. The developers announced a pre-release version of the user's manual last Fall and said that they hoped to release a translator for the language this Spring. Has anybody gotten either? If so, what do you think? If not, does anyone have any more recent news? Thanks for any help. hal render render@zeppo.colorado.edu
rick@tetrauk.UUCP (Rick Jones) (05/28/91)
In article <1991May23.092025.1@happy.colorado.edu> hsrender@happy.colorado.edu writes: >Is there any news on the status of Sather? If I recall correctly, Sather >is (was) an OO language similar to a stripped down version of Eiffel. >The developers announced a pre-release version of the user's manual last >Fall and said that they hoped to release a translator for the language >this Spring. Has anybody gotten either? If so, what do you think? If not, >does anyone have any more recent news? Thanks for any help. I got a copy of the manual a few months back (I got it "second hand" - via Rock Howard - since I couldn't make direct contact with Stephen Omohundro, the author). The basic concept seems quite good, but I do have some criticisms. The main idea seems to be to simplify some of the constructs in Eiffel in order to produce a language which can be implemented efficiently more easily than full Eiffel. It does mean that there are a number of syntax differences between Sather and Eiffel which prevents it from being just a subset. In particular, one-dimensional arrays of objects are handled with an embedded syntax (and an embedded object structure), rather than ARRAY being a class. This results in square brackets being used for arrays, and so braces are used for genericity, instead of Eiffel's square brackets. It doesn't support restricted exports, which is what Eiffel uses braces for. All assertions use the "assert" statement, instead of Eiffel's "require", "ensure", etc. There are a number of other keyword changes which seem to have been done on the basis of personal taste. A significant difference is that variable declarations are of two types, depending on whether dynamic despatch will be used on the variable. A simple declaration "c: A_CLASS" indicates static binding; "c: $A_CLASS" must be used for dynamic binding. I think this is a retrograde step, since it is making the programmer do things that the compiler should be able to do - but it makes the compiler easier to write! Loop syntax is different, and allows a "break" statement. No comment, everyone has their own opinion on this, including me :-) A nice idea is that assert and debug clauses are each given a key-name, and the compiler will enable these clauses on the basis of the key-name rather than the class they appear in. This gives rather more flexible control for debugging, although it's one more thing to think about when programming. Although it is statically typed, the compiler makes no claim to be type-safe. There has been a lot said about Eiffel's loop-holes, but Sather is even leakier. If the main goal is to produce run-time programs which are more efficient than current Eiffel technology (which I do not consider inefficient anyway), then my main criticism is that the implementation issues have been dragged too far into the language, rather than being solved in the compiler. I would have much preferred to have seen a true subset of Eiffel, which I think could have achieved the same goals. I could be tempted to christen it QDE - for "quick & dirty Eiffel" - but that might be a bit unfair. As an Eiffel user, I would not be tempted to switch over, but it could be a useful start for some people if it is readily available and cheap. -- Rick Jones, Tetra Ltd. Maidenhead, Berks, UK rick@tetrauk.uucp Any fool can provide a solution - the problem is to understand the problem