EiffelStudio 6.6 released

by Manu (modified: 2010 May 29)

We are pleased to announce the availability of EiffelStudio 6.6. It can be downloaded at http://www.eiffel.com/downloads.

The release notes are available at http://docs.eiffel.com/book/eiffelstudio/release-notes-eiffelstudio-66.

To me this release brings even more stability and some new language features which I'll highlight below:

  • Some incremental bugs that usually affects large and complex recompilation have been addressed.
  • Our multithreaded runtime has been rewritten to be even more portable and to guarantee the same behavior of mutexes across platforms (before mutexes were recursive on Windows but not on our other platforms, now it is always recursive).
  • We have introduced once per object and the new once syntax (once ("PROCESS") or once ("THREAD") or once ("OBJECT")).
  • We have introduced the new check instructions to simplify the writing of void-safe code:

check attached expression as e then e.do_something endwhen clearly something should be attached but the context is not strong enough for the compiler to guarantee it. If at runtime this was not true a check violation will be raised.

  • We have introduced this not yet adopted feature of the ECMA specification that has been requested by some Eiffel users for many years. The name is not yet decided, so far we have two attempted names: RAT (Remote Anchorted Types) or QAT (Qualified Anchored Types). It basically let you write a type declaration using like with not just a feature name but with an expression, that is to say like a.b.c. This is very practical to reduce the number of copy/paste in types and let you evolve your software easily by only changing a type at one place, instead of at many places (think of changing all your declarations of LINKED_LIST into ARRAYED_LIST in your code).

Tell me more about your experience using EiffelStudio 6.6 and what you are planning on doing with it. In the meantime, Happy Eiffeling!

Manu

Comments
  • Simon Hudon (14 years ago 30/5/2010)

    Block statement

    Thanks for the short summary of the new features: I'll keep an eye open to see how helpful they are :-)

    I saw the new shape for the check statement before but I haven't seen a justification yet for introducing a block around the scope of the object test local. More precisely, I don't see why we wouldn't extend the scope of the local until the end of the block statement that includes the check. Can you enlighten me on that subject please?

    • Manu (14 years ago 30/5/2010)

      Mostly because if you decide to disable assertions, then the object test local does not have a meaning anymore. Of course you could have a rule that the compiler keeps the check.

      Now when an object test local appears in a precondition, we have decided that the scope is only the precondition, not the body. Why? Because if you redefine the routine that has a precondition with an object test local, it would mean that you could use it, but when looking at the redefined routine, you would not know what the meaning of the identifier.

      Mixing both arguments and for consistency, we decided the same for check, the object test local is only valid within the check, not after.

  • David Le Bansais (14 years ago 31/5/2010)

    Check statement

    I had noticed some bugs with the check ... then ... end statement, I will try to reproduce them with the official release.

    Why remote? It's the first time I see it in the context of Eiffel.

    How to name the new anchored type is a dilemna. Will we have CATs and QATs, or CATs and RATs? ;)

  • Simon Hudon (14 years ago 31/5/2010)

    I guess it's nice to have such consistency but, as it happen, I would be very happy if there was some way to use the locals introduced in a precondition even if, to use it in a redefinition, I had some syntactic overhead. For instance, I think the following kind of declaration would be totally justified:

    class SOME_CHILD inherit SOME_PARENT redefine some_routine end feature some_routine is local from {SOME_PARENT}.some_routine object_test_local: STRING do ... end end

    where object_test_local would be the name given to the attached entity resulting from an object test in the precondition of {SOME_PARENT}.some_routine. I expect that it could be smoothly extended for the case where a routine is a redefinition of more than one routine. For example, there could be a renaming clause to merge or separate object test locals. Also, in the case of a set of disjuncted preconditions, I would expect that, to be useable, an object test local would have to be bound in each of the precondition and it would keep the binding created by the first precondition to be completely evaluated to true. It might seem a bit complicated but I am certain that it is completely worth the trouble just to be able to profit from the object tests in preconditions. The alternative that I had to use so far was to repeat the object test in the body of the routine. This is very inconvenient.

    Has any such alternative been studied so far? If so, on what ground was it rejected?

  • Berend de Boer (14 years ago 31/5/2010)

    Let me put in a request of mine:

    I would like to get a better stack dump, basically the SmartEiffel like stackdump. So the proper line of the code where the error occurred + a dump of all local variables and the first level contents of the objects. Perhaps everyone is always using EiffelStudio when running their code, and I'm the only one who hardly ever does.

    An interesting substitute would be a dump file I can load in EiffelStudio.

  • Helmut Brandl (14 years ago 1/6/2010)

    remote anchored types

    Having remote anchored types (like a.b.c) is basically a good extension to the language and in reflects a need in programming generic classes (not often needed; but if needed, it is very practical).

    However the form like a.b.c' is not sufficient. In some cases there is no argumentless query a' in a generic class C[G] ...' to start the remotely anchored type. Sometimes only the formal generic type G' is available to start the anchor chain.

    Therefore I would like to see the extension 

     like {G}.some_query

    to anchor a type within a generic class C[G->CONSTRAINT]' to the result type of some query of its formal generic G'

    or alternatively (but more confusing)

    too allow the start of the anchor chain `a' to be a query with arguments of the surrounding class.

    A need of this extension is described (though not in detail) within my blog http://eiffelroom.com/node/396 which gives a solution to the catcall problem.

    • Alexander Kogtenkov (14 years ago 1/6/2010)

      Type-anchored types

      The notation like {T}.x.y, where T is some type, is indeed supported by this release. The original RAT (Remote Anchored Types) proposal used only the feature name chain, then there was a proposal that uses a type instead of the first feature name (it was called TAT). The combined mechanism QAT (Qualified Anchored Types) allows for both variants.

  • Colin Adams (14 years ago 3/6/2010)

    Use of new check assertion

    I re-coded my example of a MAYBE class using the new check form of assertion:

    note description: "Objects that might contain another object" author: "Colin Adams" last_editor: "$Author: $" date: "$Date: $" revision: "$Revision: $" path: "$File: $" class MAYBE [G] create make, make_nothing feature {NONE} -- Implementation make_nothing is -- Create as object absent. do ensure no_object_present: is_nothing end make (a_object: !G) is -- Create with object. do object := a_object ensure object_present: is_just object_set: object = a_object end feature -- Access from_just: !G is -- Contained object require object_present: is_just do check attached object as l_object then -- From precondition Result := l_object end end feature -- Status report is_nothing: BOOLEAN is -- Is an object absent? do Result := (object = Void) ensure definition: Result = (object = Void) end is_just: BOOLEAN is -- Is an object present? do Result := not is_nothing ensure definition: Result = not is_nothing object_not_void: Result implies object /= Void end feature {NONE} -- Implementation object: ?G -- Possible contained object end

    Finally the program actually behaves as it is supposed to. That is, a caller of from_just, when the precondition does not hold, get a pre-condition violation (if pre-conditions are monitored), or otherwise an assertion violation (even with all assertion monitoring disabled).

    Looking at the code for from_just, the noise is confined to the check statement block (equivalent to an if statement). I still maintain this is too much noise. The pre-condition should act as a CAP, and so we should not have to perform an object test (that is, we ought to be able to simplify the body to Result := object). And while the type checker remains insufficiently powerful to prove that the precondition always holds, it can generate the same runtime-check (in void-safe mode) that the check block generates.

  • Colin Adams (14 years ago 3/6/2010)

    Void safety type-hole

    There still appears to be a bug with Void safety. The following program compiles happily in Void-safety mode, and at runtime reports a call-on-void-target violation:

    note description: "Resuable class for testing Eiffel features" class TEST create execute feature {NONE} -- Initialization execute is -- Run test. local l_string: attached STRING do create hast.make (2) hast.put ("fred", 2) l_string := lookup print (l_string.count) end lookup: attached STRING is -- Test of void-safety do Result := hast.item (1) end hast: attached HASH_TABLE [attached STRING, INTEGER] -- hash table end

    If you change the type of hast to attached HASH_TABLE [STRING, INTEGER], then the compiler correctly fails the program.

    item is declared as detachable G.

    The problem appears to be that detachable G is interpreted as attached when G is declared as an attached type. detachable should have an overriding effect, but in 6.6 it is not doing so. I don't know what ECMA has to say on this.

    • Colin Adams (14 years ago 3/6/2010)

      Conformance

      Actually it appears to be a simple violation of the conformance rule.

      Change HASH_TABLE to HASH_TABLE22 in the program above, and add the following class:

      class HASH_TABLE22 [G -> detachable ANY, K -> detachable HASHABLE] inherit HASH_TABLE [G, K] create make end

      and the results are unchanged.

      • Colin Adams (14 years ago 3/6/2010)

        Hm. That is the conformance

        Hm. That is the conformance rule. So it's not a violation of it. But perhaps it is the underlying problem.

    • Manu (14 years ago 4/6/2010)

      Are you sure you are compiling against the void-safe version of EiffelBase and with all the void-safety settings properly set? If so, please send a problem report at http://support.eiffel.com with your project configuration file.

      • Colin Adams (14 years ago 4/6/2010)

        base-safe.ecf is the key

        The key is that I failed to specify base-safe.ecf in my ECF library.

        When I did this I got the expected compile error message.

  • Colin Adams (14 years ago 4/6/2010)

    I tried it in both default and compatible modes. Full Void safety was turned on. Are there any other options that need turning on to get full void safety (and if so, why?).