They call me GNU-Eiffel

We are continuing the development of the academic project that acquired in 1998 the status of "Gnu Eiffel compiler". As I wrote in the beginning article of this blog Dominique Colnet is focusing his academic interests on other aspects of Information Technology. Cyril - a member of the former core team of developers - and me still believe that this language has still to a useful role as a free-as-in-freedom project.
We thought to use the existing compiler - SmartEiffel - to bootstrap another one - LibertyEiffel, but we soon realized that it may be evolved into something more modular, more scalable. The only prerequisite to the latter approach is an extensive knowledge of the inner design of the compiler: Cyril has done a good work cleaning it up and know it seems easier to grasp it all. So Liberty design ended up becoming part of our improvements toSmartEiffel.
SmartEiffel also does not implement ECMA-Eiffel, trying to be follow the original design and spirit of the language that wanted to be simple yet powerful. ECMA-Eiffel is quite a different language and more complex: the original definition of Eiffel was under 50 pages, current ECMA is quite bigger.
All those considerations are pushing me to call the language and the tools implementing it GNU-Eiffel.

Insert or non-conforming inheritance

All programming languages have been weak spots that are criticized, Eiffel is no exception.
One of the most sound critique to the original Eiffel is that inheritance was the only modularity mechanism available.
In fact it is a fundamental part of the object oriented approach to programming.
Yet in its pristine, original form inheritance it does not allow to implement shared constant or commodity features (either queries or commands) in a clean way.
For example to implement dictionaries, hash tables and many cryptografic algorithms there's the need to have a handy list of prime numbers or a function that tells the first prime higher than a given integer. Let's say we put all these informations into a PRIMES_LIST class; in pristine Eiffel we would have written:

class DICTIONARY [A_VALUE, A_KEY]
inherit PRIMES_LIST export all {NONE} end
....
end -- class DICTIONARY

In this (oversimplified) example a DICTIONARY actually is a list of primes, but a really strange one, since with "export all {NONE}" we told the compiler that all the features originally defined in PRIMES_LIST cannot be invoked, queried or used by any code handling a DICTIONARY.
Beside looking a palese breach in the OO architecture it actually answered in the wrong way to a rightful need: sharing some code or data between different parts of the programs; the pecualiar aspect is that all that code or data is not linked or bounded to a particular type at all, but they are quite generic.
There's the need to have all the features - queries, commands constants and attributes - of another class without being a subtype of that class; we need what is known as non-conforming inheritance or feature insertion.
That's exactly the role of "insert": to have all the feature on another class without being conforming to that class.
In fact with the previous example you may write:

feature strange is
  local primes_lists: LINKED_LIST[PRIMES_LIST]
  do
    create primes_list
    primes_list.append ( {PRIMES_LIST} )
    primes_list.append ( {DICTIONARY[STRING; INTEGER]} )
    primes_list.append ( {CRYPTO_USING_PRIMES} )
    ...
end

What a strange collection: a list compraising a list of primes, a dictionary containing strings and a cryptografic stream! The designer of a program may actually do not want to have such objects.
When we do want to share some definitions or a list of primes like in this example we may have inserted the features of PRIMES_LIST, like this:

class DICTIONARY [A_VALUE, A_KEY]
insert PRIMES_LIST
....
end -- class DICTIONARY

Actually it is customary to declare those auxiliary classes deferred, in order to forbid direct usage of that class itself.
ECMA Eiffel has the same non-conforming mechanism, but its syntax is "inherit {NONE} PRIMES_LIST", meaning inherit conforming to no class. While this is correct it seems to allow to write "inherit {MY_CLASS} PRIMES_LIST", bringing confusion together with a useful, simple mechanism. I have discussed the rationale behind this some time before SmartEiffel team decided not to implement ECMA, I'll try to dig it out.

Case sensitivity

Eiffel was born as a case-insensitive language. So it would allow to write this code:

cLaSS nice_AnD_READable
INHERIT foo
FEAture BOOO is oD pRiNt("Boo!") end
eND

And using it elsewhere like:

local MY_obj: NICE_and_readABLE
do
CREate my_obj
my_OBj.booo
....

Nice, isn't it?

Now such code quite obviously will give an headache to people reading it and it will make life harder to all tools. While the latter "would not count" if those requirements will make code easier to read it is quite the opposite: making the language case-insensitive does make the language less readable.
The idea was - if I recall correctly OOSC -  to turn casual case-errors into warnings allowing the developer to concentrate on the logic instead of the case of the identifiers.
Actually style counts, so rightfully the definition of the language comes with a very precise style guide:

1. all classes names shall be uppercase
2. all constants shall be lowercase with the first letter uppercase
3. all other identifiers and language reserved words shall be written lowercase

GNU SmartEiffel "only" makes the style rules mandatory so that the code above will read:

class NICE_AND_READABLE
inherit FOO
feature boo is do print("Boo!") end
end
...
local my_obj: NICE_AND_READABLE
do
  create my_obj
  my_obj.boo
...

This may look quite strict and at first it feels so; my experience tells me that this discipline is actually good for the developer writing the code, those reading the code allowing for a smoother reading.

Highlighting Eiffel syntax in Blogger (DONE!)

Syntax highlighting of programming languages seems to require a little tweaking in Blogger. SyntaxHighlighter from Alex Gorbatchev is a most widespread syntax highlighter used in Blogger but it doesn't support Eiffel out-of-the-box.
Luckily it's all JavaScript and supports Delphi and Pascal and it's hosted on github, so I forked it (with git it's fast, light and easy to merge the changes in the main trunk) to add (Smart)Eiffel support, thanks to the nice guide the main developer provided.

2011-12-22 update: I tried a really quick hack and I got a preliminary working version. To use it in Blogger I had to switch to a "simple" theme, one whose sources can be hacked, adding in the head the following code:

<link href="http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css" rel="stylesheet" type="text/css"></link>
<script src="http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js" type="text/javascript">
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shAutoloader.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXML.js' type='text/javascript'/>
<script src='http://www.monodes.com/scripts/shBrushEiffel.js' type='text/javascript'/>

<script language='javascript'>
SyntaxHighlighter.config.bloggerMode = true;
SyntaxHighlighter.config.clipboardSwf = 'http://alexgorbatchev.com/pub/sh/2.1.364/scripts/clipboard.swf';
SyntaxHighlighter.all();
</script>

Please note that I couldn't directly use the file on github, perhaps it does not like https so I falled back putting on a website on mine (namely at 'http://www.monodes.com/scripts/shBrushEiffel.js') until I improve it a little before proposing it to the main trunk. Also since Alex says: While the hosting is offered as a free service, I’m currently receiving approximately 22m requests a and 83GB in bandwidth every month which is costing me an additional $40 on Amazon S3. Where am I going with this? You guessed it – please donate to help me pay for this :) I think I would rather put an entire copy of the package on my domain.

Creation procedures

Eiffel required - a quarter of century ago - explicitly provide a creation procedure for each object; so each creation was in the form of

create my_list.make_empty

Nowadays SmartEiffel allow us to write

create my_list

when a class has put default_create command in the creation clauses list such as:

class LITTLE_LIST [ITEM]
  -- A list to contain few elements
inherit COLLECTION[ITEM]
creation default_create, make, make_empty, with_capacity
...

To create collections, lists, arrays, associative dictionaries you may use the manifest notation, like this:

some_primes := {LINKED_LIST[INTEGER] <<1, 3, 5, 7, 11, 13, 17, 23>> }

dictionary := {HASHED_DICTIONARY[CHARACTER, STRING] << 'a', "key #1";

'z', "key #2";

'z', "key #3";

'a', "key #4" >> }

bijective_dictionary :=

{HASHED_BIJECTIVE_DICTIONARY[STRING, STRING]

<< "value #1", "key #1";

"value #2", "key #2";

"value #3", "key #3" >> }

Please excuse the horrible formatting of the code, I'm working on it. 

diff "Eiffel: the language" "GNU Eiffel"

We have been asked for some informations about the differences between the language originally described in "Eiffel: the language" (1992 by Bertrand Meyer) and those accepted by the current GNU/Smart/Liberty Eiffel compiler.
Such a request is not only reasonable but requires some answer: there have been several additions and quite a few changes to the language.
The main changes are:

1. Creation procedures
2. agents
3. conformance of agents 
4. anonymous, in-lined agents (a_command(12, "Foo", agent (x: INTEGER): REAL is do Result:=x.to_real ^ 2 end )
5. insert, also known as "non-conforming inheritance"
6. case sensitivity
7. inspect allow for integer intervals... 
8. FLOAT is replaced with REAL
9. There is no NONE (pun intended :-)
10. other I don't recall now.

To keep things tidy I am writing a separate post for each point.