Team Eiffel

As people might be aware, I've become the maintainer of the Eiffel Emacs mode. I've gone through the various comments and requests people have send since 2004 and updated the mode accordingly. Some innocent requests have required huge changes unfortunately.

There is a beta release available for those who want to test out the changes. There's also an email list you can subscribe to if you use Emacs or XEmacs.

Colin Paul Adams has been invaluable in testing the changes, so I believe it will work better than before. But some changes might be controversial, so sign up to that mailing list and give your comments.

On the comp.lang.eiffel newsgroup, Colin Adams asked:

Does anyone know of a list of syntax changes between OOSC2 and ECMA Eiffel (or EiffelStudio 5.7)?

I want to insert sheets of paper into the front of copies of OOSC2 so Eiffel learners don't get confused.

Here are two pages related to this question:

• Differences between EiffelStudio and ECMA Eiffel
• Differences between ETL Eiffel and EiffelStudio

Also of interest is the task list showing progress towards implementing ECMA Eiffel in EiffelStudio.

See also the section "Language Changes from the Previous Edition" in Bertrand Meyer's draft of the book "Standard Eiffel" (which will supersede ETL).

Labels: eiffelstudio

ECMA Eiffel brings a number of changes and refinements to the type system of Eiffel. Matthias Konrad has been carefully analysing these, and is documenting his work at the EiffelStudio wiki.

Matthias has worked out a mathematical model of dynamic binding for ECMA Eiffel, and supported this with a substantial worked example and a formal implementation of the model in Haskell.

The ECMA Eiffel Standard defines the "Unfolded Form" of an Eiffel class, and uses this to describe the semantics of various language elements of ECMA Eiffel, such as precursor and repeated inheritance. Matthias examines unfolding, and its consequences on "rename", "select" and "precursor". He also looks at transposition of inherited features into a descendant (for production of the flat-short representation, or in the definition of some unfolded forms), which has consequences for repeated inheritance (with or without covariant redefinition). Replication is given a page of its own. There's also an article under development on multiple generic constraints, for which Matthias proposes two possible solutions, neither of which appears to be completely satisfactory.

The ECMA standard introduces a new solution to the "CAT call" problem, by disallowing covariant argument redefinition except to a detachable type. Matthias notes that this considerably weakens the power of covariance in Eiffel, especially if the solution is extended to covariant generics (which doesn't appear to be explicitly addressed in ECMA Eiffel). Also see Matthias' work on the Dynamic Type Set and CAT call freeness detection algorithms.

Finally there are some notes of minor ECMA problems that will presumably be addressed in a future revision of the specification.

All in all, a most interesting set of pages.

The ESpec project has released a new version of their package, to work with the final release of EiffelStudio 5.7.

ESpec (Eiffel Specification) is a Software Quality Workbench supporting Specification Driven Development by helping developers to write and execute acceptance tests as well as unit tests within the same environment.

ESpec provides support for writing testable requirements and specifications at multiple stages of software development process. Developers can write requirements and specification such as Fit tests, unit tests, contracts as early as possible.

ESpec is a combination of three main components:

• ES-Fit: An Acceptance Testing framework for capturing and testing customer requirements in the form of HTML tables used for Validation
• ES-Test: A Unit Testing framework for testing specifications. A combination of Unit tests and Contracts are used for lightweight Verification
• ES-Verify: A translator from Eiffel to Perfect language used for full Verification

ESpec focuses on Unit Tests and Contracts as testable specifications and Fit Tables as testable requirements.

The Eiffel Wrapper Libraries Collection is a project to provide SmartEiffel bindings to several commonly used Free libraries. Since its announcement in March, it has come a long way. GTK+ bindings (which includes GDK, Glib, Gobject and Pango) are quite usable now and planning a beta release soon. Also included are libglade bindings, so you can now develop GUI Eiffel applications with a RAD builder.
There is a lot of work in progress into the database APIs too.
And a recent newcomer to the collection is a wrapper to the ffmpeg library, also at a usable level (want to do real time video playback in Eiffel? now you can!).
Of course, anyone interested in contributing more libraries (or time to help with the existing one) is welcome.

Whilst testing the Eiffel Search Engine yesterday I was surprised to see this advertisement. I've seen some pretty weird eBay ads before, but this one tops them all!

I've implemented an Eiffel Search Engine that performs a Google search across hundreds of hand-picked Eiffel sites. It's made possible through the Google Co-op program.

The main Eiffel sites are included in their entirety, and I've also added lots of individual project sites as well as individual web pages that contain tutorials, critiques, blogs, reports etc. So why not try out the search, and bookmark it for use whenever you're looking for someting Eiffel-related?

If there's an Eiffel source I've missed, you can post a comment here or on the search page itself and I'll add it to the Eiffel Search Engine.

Great article about Eiffel. Check it out!

Edit by Roger Browne: Links in comments are not clickable, so here's a clickable copy of the Digg link posted in the comments by adamsits: http://digg.com/programming/Speed_of_c_Garbage_collection_like_Java_and_cross_platform

The Board of NICE, the Nonprofit International Consortium for Eiffel, has passed the following motion:

To reduce license proliferation and confusion, NICE encourages users of the EFL2 license to consider relicensing under the MIT License. We do *not* wish to discourage programmers from using other popular GNU and GNU-compatible licenses like the BSD license.

Can I continue to use the Eiffel Forum License?

Certainly. This motion is an "encouragement" and nothing more. You are free to continue using the Eiffel Forum License (version 1 or 2) if it suits your needs.

Will the Eiffel Forum License retain its OSI certification?

Yes. The Eiffel Forum License retains its status as an OSI-certified open source software license.

Why is NICE deprecating the Eiffel Forum License?

OSI, the Open Source Initiative, recently listed the Eiffel Forum License as redundant because it is essentially equivalent to other more widely used software licenses. Proliferation of redundant licenses runs counter to the goals of the open source movement because it can make interoperability more awkward. Also, some corporations are wary of open-source software and may not be able to use software using niche licenses that have not been reviewed by their legal department.

Why is NICE encouraging the MIT license rather than the similar BSD license?

The MIT license is already more widely used within the Eiffel community, including for the SmartEiffel libraries. It is very short and clear.

What if I prefer to use the BSD license, the GPL, the LGPL or some other license?

Feel free to use another license if it meets your needs. All that NICE is doing is encouraging you to consider the MIT license as an alternative to the Eiffel Forum License.

What about compatibility with the GPL?

The MIT license is compatible with the GPL, just as the Eiffel Forum License is. This means that you can take MIT or EFL code and freely combine it with GPL code, provided the resulting work is licensed under the GPL.

But I like the part of the Eiffel Forum License that encourages distributors of compiled code to release their source modifications back into the community.

No problem. That part of the Eiffel Forum License is not legally binding, so you can append it to the MIT license text with equal effect.

I maintain code that is released under the Eiffel Forum License. What should I do?

The choice is yours: you can continue to license your code under the EFL if you wish. Or, you could license future releases under the MIT or some other license. OSI stated in correspondence to NICE that they were not aware of any problems that would arise moving from the EFL2 license to the MIT license.

What is the text of the MIT license?

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.