Team Eiffel

A second edition of ECMA Eiffel, dated June 2006, has been published (PDF). It has been adopted by the General Assembly of ECMA as ECMA-367, and by ISO as ISO standard 25436.

From the document:

The First Edition was completed in April of 2005 and approved by the General Assembly of ECMA in June of 2005. As a result, authors of major Eiffel compilers and tools have committed to supporting the language as described in the Standard; compilers are quickly progressing towards full compliance. The present Second Edition introduces no major change of substance but clarifies and corrects a number of points arising from the experience of using the First Edition and from the feedback of compiler writers and the user community

...

To produce this Standard, TC39-TG4 conducted: 18 face-to-face meetings (15 up to the First Edition), most of them over three full days; numerous phone meetings; and extensive technical correspondence (about 1500 email messages by June 2006).

I cannot find any list of changes between the first and second editions.

I could not sleep this night, for having swallowed way too much coffee last evening. So I coded instead.

My mind found the solution for simply integrating forthcoming SE extensions (esp. ESE) without having to re-parse and re-write SE's main config file.
Well, in fact, I did not invent the solution. Others did, Debian in particular.

The principle is to replace a simple configuration file with a configuration directory, with a priority system (of course, configuration files are still supported). I coded it all this night.

Now, SmartEiffel users will be able to:

• keep system's defaults while changing only some of them (typically: add a C mode, change or add a local loadpath...)
• install an external SmartEiffel package (e.g. ESE) without changing either the system config file or their own config

And it will help distro package maintainers too. All I have left to do is to fix the installer to take that into account.

Eiffel is cool. SE 2.3 will be cooler yet :-)

Till G Bay, from ETH Zurich, has asked me to post this survey request on behalf of Professor Brian Fitzgerald. The survey explores the interaction between a "company" such as Eiffel Software (ISE) or, I suppose, Loria and an open source community (such as the community of ISE Eiffel or SmartEiffel users/developers).

The survey took me less than five minutes to complete. If you choose to supply your name and email address you are entered into the draw for a Nokia internet tablet.

Professor Fitzgerald writes:

Free/Libre/Open Source Software (FLOSS) has in many ways revolutionised software development. We have recently seen a new mode of outsourcing, what we term 'open-sourcing', whereby companies seek to grow a community of open source developers around what has typically (but not always) been a proprietary product previously. Both the company and the developer community have mutual expectations of each other, and if these are not fulfilled, the initiative may not be successful.

We have derived a set of expectations for successful open-sourcing and would like your feedback on these at http://www.calibre.ie/survey/index.php

Cyril Adrian (from the SmartEiffel team) is planning to package SmartEiffel and started an online poll to know which version of SmartEiffel people are using most.
I find this an interesting question, beyond the issue of packaging; Berend and I had a recent discussion about usage trends of SmartEiffel versions on #eiffel.

The poll is at http://cadrian.freepolls.com/cgi-bin/polls/001/poll_center.htm

The Open Source Initiative is "a non-profit corporation dedicated to managing and promoting the Open Source Definition". One of the things they do is to certify software licenses as open-source, which means that the license complies with OSI's Open Source Definition.

OSI certification became important for getting software accepted into open source software distributions such as Debian Linux. Although the Eiffel Forum Freeware License pre-dated OSI by a few years, it became desirable to get them to certify the EFFL as an open-source license. This took a few years of bureaucratic haggling with OSI, but we got there in the end.

Later, the Eiffel Forum License version 2 was created. It was more liberal than the EFFL, so that EFL2-licensed software could be incorporated into GPL-licensed projects. Unlike the EFFL, the EFL2 is pretty similar to the liberal MIT and BSD licenses. The Free Software Foundation confirmed that the EFL2 was GPL-compatible, and OSI certified it as "open source".

For the last year or so, OSI has been pondering the proliferation of open source software licenses. One downside of having so many licenses is that it can hinder software re-use. There are two reasons for this. The first reason is that licenses sometimes have incompatible terms, and software covered by them cannot be legally combined.

The second problem hindering re-use of software covered by many difference licenses is that many organizations are cautious by nature and feel unable to use software under a new license until their lawyers have checked it out at great expense. Clearly, this problem is compounded by the sheer volume of open source licenses that now exist.

It's no surprise that OSI has concluded that the ELF2 license is redundant. This doesn't mean that the EFL2 will lose its open-source certification, it just means that OSI thinks the license is not a useful alternative to other more popular licenses.

Berend de Boer has opened a discussion about this on the NICE-Discuss mailing list. He writes:

Minimising licenses is obviously a good goal and it helps code sharing. On the other hand everyone knows the Eiffel Forum License and many in the Eiffel community use it.

You may wish to hop over there to post your comments.

As the actual operation of my spam filter can best be described as: if it's not on your white list it is spam (although I'm sure the design requirements are entirely different), I regularly go through my spam to check if there's something I've unintentionally discarded. And occasionally I search the subjects for particular keywords to make sure I haven't missed anything.

One of the keywords I use is Eiffel. That turned up two hits today. I can now buy a patch that will make a certain body organ bigger than the Eiffel Tower. Boy, will my wife be "happily" surprised...

I'm a big fan of the approach of using progressive enhancement to build websites. In short this approach builds websites that begin with content/markup (HTML), use CSS to change the style and presentation, and use JavaScript to add behaviour. If you have to support IE with its limited support for CSS you might have to twist your content a bit, but with a decent browser this approach works very well. It will lead to websites that work everywhere and even work when JavaScript is disabled. It will give you quite a bit of guidenance in building robust websites, believe me.

This is also the approach that one should take with HTML controls and capabilities like auto complete support that are possible with AJAX techniques. Make sure the control works when JavaScript is disabled. Use CSS to make it look nice. Use JavaScript to make it work better.

The question is how to add these additional capabilities to HTML. Because in the end, the browser reads and interprets HTML. It uses CSS for the styling and JavaScript for the behaviour. That's how this environment works. And programmers should not be shielded from that. That is how the web really works. Having some magic to make it appear that this isn't the case is very detrimental to any programmer's internal model of how web applications work.

I've occassion these days to do a lot of work with Visual Studio 2005, C#, ASP.NET and Atlas. And the result is horrible. Microsoft's behaviour can be best explained if you believe that they want lock-in. It explains why they will try to shield you from HTML, CSS and JavaScript. They allow absolute positioning of controls. A favorite technique in examples. Because drag/drop of controls works better that way. Woo the programmer who tries such a website on anything else than a pair of perfect eyes, perfect color perception, IE and the screen size of the original programmer. The web isn't a Win32 Visual Basic app. Making it appear so, will only lead people to build an internal model of web programming that is fundamentally untrue.

The same is true for Microsoft's postback approach. How many websites work somewhat fine on intranet and then fundamentally fail on the internet? Again, Microsoft Visual Studio's approach is to give the programmer the idea he is building a Win32 form. He isn't.

And then the controls. You have all those Microsoft controls like asp:Button. What's that? Is it an HTML button? Something else? You set its properties using background color and such. And that doesn't end up in some CSS style sheet let me tell you that. Programmer doesn't need to know CSS because this is just a win32 form.

And then the Atlas toolkit. Exactly how one shouldn't design a toolkit unless you want to shield programmers even more. For example you can extend an existing control with auto complete support. It's supposedly declarative (another rant, I promise). The good thing is that you can extend a normal HTML input. The bad thing is that you have to write that support in some declarative JavaScript, called XMLScript (good luck finding any documentation on that) or with using an atlas:AutoCompleteExtender element in your source. Copy and paste some sample code and things work. That's cool. But how does it all work? The last thing Microsoft wants you to learn is HTML and JavaScript. You have to be shielded from that you know. Instead of JavaScript you write XMLScript. And when ignorance is bliss I suppose this will do.

But sometimes you get paid to take the red pill. And you will need to dynamically, at the client, create an input control and it should get AutoComplete behaviour. And while the mirror starts dissolving you have to take the plunge into how stuff really works.

No need for pills and ignorance does get you nowhere. That summarises EJAX's fundamental approach to HTML controls. It is an explicit design goal to not shield the programmer from the underlying mechanisms. Controls should work such that they guide the programmer into building the proper internal model. This to allow the programmer to easily use the control outside the presented toy example. Create some dynamic HTML? Even if the toy example presented static HTML it should be intuitively clear how to apply that knowledge for that scenario as well. And for returning HTML by some AJAX call, etc. So the control is HTML. The behaviour is applied with a JavaScript call.

Cyril Adrian writes, on the SmartEiffel mailing list:

Thanks to some fixes in SmartEiffel the XML backend of EDC now fully works (storage and retrieval of relational data in an XML database).

The ARG cluster has been improved and now works in most normal cases. This cluster is used to parse a command line.

The ESEB tool is not yet functional but code writing is hot those days. ESEB is the ESE Binder that builds classes that represent the tree of a provided DTD file (something like JAXB for java people) and an XML parser for such files. This tool will be useful to build other tools that will use XML files.

http://ese.sourceforge.net - see you there!

A verb operating on a resource can take zero or more parameters. EJAX has three levels of parameter validation. The first level is entirely browser based and fires if JavaScript is active. The EJAX frameworks spits out a JSON description of the parameters. This looks like this:

var my_form_parameters_text = {
system_id:
  {type: "positiveInteger"},
company_name:
  {type: "string", maxLength: 256, whiteSpace: "collapse"},
contact_name:
  {type: "string", maxLength: 256, whiteSpace: "collapse"},
email:
  {type: "string", minLength: 1, maxLength: 256, whiteSpace: "collapse"},
password:
  {type: "string", minLength: 1, maxLength: 32, whiteSpace: "collapse"},
password2:
  {type: "string", maxLength: 32, whiteSpace: "collapse"},
address1:
  {type: "string", maxLength: 256, whiteSpace: "collapse"},
address2:
  {type: "string", maxLength: 256, whiteSpace: "collapse"},
city:
  {type: "string", maxLength: 256, whiteSpace: "collapse"},
state:
  {type: "string", maxLength: 256, whiteSpace: "collapse"},
zip:
  {type: "string", maxLength: 16, whiteSpace: "collapse"},
country:
  {type: "string", maxLength: 256, whiteSpace: "collapse"},
...

It's pretty equal to the parameter description for the resource. The EJAX.FORM.validate routine in ejax.js can take such a description and validate the controls, match the id in the parameters description against the contents of the controls. If an error occurs, the control is focused and an error message is displayed near it.

This validation isn't always enough. For example password validation cannot be done in this manner. So there is a second level validation as well. This is a collaboration between the browser and the client, again, only if JavaScript is enabled. It takes the contents of all form controls using prototype.js' Form.serialize() and sends it to the action specified in the form. But with one twist: it adds the ejax:validate parameter. When this input is found by the EJAX generated resource classes they will only validate the control and just return a response code such as 200 OK or 400 Form invalid. The error response contains a detailed description of what control had the wrong input and what the user should do to fix it.

If JavaScript is disabled, or if the form is still submitted, or if some malicous program tries to send bad data to an EJAX resource the third level of validation comes into play. This is the final defense and takes place at the server. It simply validates the given user input against the specified parameter data types, before any other action will take place.

Minutes of the 27 June 2006 Gathering of the Bay Area Friends of Eiffel

Attendance was good, especially given the very short notice given for the meeting. Again I apologize, I'd recently returned from Asia, and several of the people who wanted to attend were leaving the US at the end of that week.

Emmanuel Bouyer gave a very nice presentation on concurrent processing and Eiffel. Emmanuel began with a discussion of the limitations the current SCOOP specification. He explained in particular why SCOOP could not be used to implement Eiflex.

He then presented an overview of the Eiflex distributed object framework. The Eiflex framework provides a reliable platform-independent, multithreaded client/server architecture and is the basis of the Chicago Board of Trade's PRICE system.

Emmanuel then ran a "Dining Philosophers" demonstration that involved a GUI client and two server processes. One important aspect of the demo was the fault tolerance. You can kill the servers, but when they are restarted they will carry on where they left off, having preserved their state. Eiflex is highly also scalable. At CBOT, Windows clients connect to over one hundred Solaris servers, with each server running two hundred or more threads.

After Emmanuel's presentation, the gatherers congratulated Eric and Karine on their wedding, spent a little time surfing the Team Eiffel blog for interesting tidbits, and talked about what is going on with the various Open Source Eiffel projects around the world.

The next meeting will be held in September (too many people are traveling in August). I promise to give earlier advance notice.

Future meetings will be every other month, with a special effort to overlap with visits by Eric and Karine.

Emmanuel's presentations were based on those made by Gordon Jones (Emmanuel's partner at Eiflex) for a conference at York University in the UK.
http://www.artist-embedded.org/FP6/ARTIST2Events/Events/Cordie06/

More information about Eiflex can be found here:
http://www.eiflex.com/

The Team Eiffel blog is here:
http://teameiffel.blogspot.com/

A good starting point for more information about Eiffel is at Cetus Links:
http://www.cetus-links.org/oo_eiffel.html

Don't miss future announcements! You can subscribe to the BAFOEiffel mailing list,
http://groups.yahoo.com/group/BAFOEiffel/

by sending an email to BAFOEiffel-subscribe@yahoogroups.com

Brother Bill is seeking an additional programmer for a project in Lilburn Georgia (Northeast Atlanta), between Lake Lanier and Stone Mountain.

The project uses Visual Basic.net for the front end, and EiffelStudio for the database end.

The candidate will have experience in VB.net and an interest in Eiffel. Brother Bill writes:

The project is challenging. There is a lot of code to grind out, and this may be a good opportunity for an unemployed developer.

The pay will be low, but on completion, will most likely get some kind of real profit sharing.

EiffelStudio supports an extension that allows multiple indexing clauses within an Eiffel class. You can have one at the top of the class, plus one at the bottom of the class, and you can also write an indexing clause for any feature of the class.

This can lead to a syntax error, which has become a "Frequently Asked Question" over on the es-devel mailing list. Consider the following code:

class A
...
feature -- Test
   test: ANY
      -- Test
indexing
   ...
end -- class A

How does the compiler know whether this indexing clause is the "end-of-class" indexing clause, or the one associated with the attribute 'test'?

The compiler can't tell, and it throws a syntax error. You can fix this with a judiciously-placed semicolon, for example:

class A
...
feature -- Test
   test: ANY;
      -- Test
indexing
   ...
end -- class A

Now, the indexing clause is taken to be the "end-of-class" indexing clause.

ECMA Eiffel does not have this ambiguity, because it does not support the "indexing" clause. Instead, it supports the "Notes" construct, which uses the "note" keyword. This construct can appear at the top or bottom of a class, but not with a feature.

This is a followup to a previous post titled The Zen of Python - Part I. If you are lazy to read that introduction, this is about some Python design principles analyzed from an Eiffel perspective and comparing it with other languages (specially python itself).

Beautiful is better than ugly

I will not write much about this one. It is about a very subjective idea (beauty) and the assertion is mostly tautological in nature: who would say that ugliness is better? Eiffel users think that Eiffel is beautiful, but most advocates of any language think that of their language.

Anyway, even when almost anyone would agree with "beautiful is better than ugly", a lot of language communities consider beauty as a secondary feature, and one of the first things being traded for other valued attributes (efficiency, compactness, sheer number of features).

Eiffel and Python were designed to be beautiful. At least beauty in the sense of elegant (simple problems should have simple solutions), simple (a term that in engineering, and software engineering in particular, is almost a synonym of beautiful), readable. Most of these will be covered later in this article or in later ones.

Explicit is better than implicit

This rule describes Eiffel more faithfully than Python. After all, static typing, Design by Contract are language features which provide a way to describe more explicitly the semantic interface of routines. Which one do you find more explicit,

    def get_prefix(size): 

or

    prefix (size: INTEGER): STRING is
        require
            size >= 0 
        ensure
            Result /= Void
            Result.count = size.min (count)

?

Other examples of explicitness are having to indicate when redefining a feature (which could be done automatically, but could let slip some obscure bugs), or when a contract is being redefined (the "require else" and "ensure then" clauses). In this aspect perhaps Eiffel is more pythonic than Python.

Python is very clean in the sense that, despite not forcing too much explicitness, it requires a minimum of it in every place. I can not imagine now a Python example where an operation is done without being requested.

Eiffel is mostly that way, but in some places it has had some historical ambiguities that have context dependent semantics. The main one is the different expanded/reference attachment semantics; an a := b statement sometimes creates an object, sometimes overwrites the contents of one, and sometimes reattaches a reference to an existing object. The SmartEiffel dialect have solved this at the cost of making some abstractions difficult (because of breaking the inheritance tree). This has always been a tricky side of Eiffel.

Implicit rules of conversion is another weak point that has had recent changes. Basic predefined types (integer, floating point values) had certain "magic" behind providing type conversion behind the scenes that was something that no user defined type could do, and was not explicit watching the interfaces of classes like INTEGER or REAL. The ISE proposal (included at ECMA) of removing magic convertions and allowing the class to explicitly add conversion routines seems a much better way to do it.

In conclusion... Eiffel has been very pythonic (much more than Python) but with some design issues that are being addressed.

The July 2nd 2006 Interim Release of EiffelStudio 5.7 (Build 5.7.60907) supports the much-anticipated "inline agents". An inline agent is a deferred call that can be coded "inline" without needing to create a new routine. (I implemented inline agents in the Amber Scripting Language and found them very satisfying to use - they were very easy to use and delivered a high "bang per line of code".)

Inline agents are pretty much like unnamed features. They can have all the trappings of a feature such as preconditions and postconditions. If you're not familiar with them, you can find out more in section 8.27 of the ECMA Eiffel specification.

There are a few limitations to the current EiffelStudio implementation of inline agents:

• they must be routines (with a "do ... end" part) and not attributes or externals, and
• there's no special support for inline agents in the IDE

In addition, regular "call agents" have been enhanced - they can now be attributes or externals.

Also in release 5.7.60907 is wild card support for code completion.

EJAX recognises two kinds of resources: static ones, for example an HTML page but also anything made available outside the EJAX frame. A static resource looks like this:

<resource name="quote">
<url>/quote/car.html</url>
<get>
  <representation content-type="text/html">
    <static-page>
      <filename>car.html</filename>
    </static-page>
  </representation>
</get>
</resource>

Note the representation option. Clients can request a resource in various formats, for example HTML for people and XML for machines.

The opposite of a static resource is a dynamic resource. Such representations are created dynamically. Example:

<resource name="quote">
<url>/quote/car.html</url>
<get>
  <representation content-type="text/html">
  <dynamic-page>
    <html-template>car.html</html-template>
    <response-collection>
      <response-name>car-detail</response-name>
      <response-name>options</response-name>
    </response-collection>
  </dynamic-page>
  </representation>
</get>
</resource>

Not a lot is going on here, and that is on purpose. The real work happens in the creation of the individual response. In EJAX a page resource is just replacing elements in an HTML file with parts received elsewhere.