On Wednesday, 1 December 2021, 03:04:02 am AEST, liberty-eiffel-request@gnu.org <liberty-eiffel-request@gnu.org> wrote:
Send Liberty-eiffel mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Liberty-eiffel digest..."
Today's Topics:
1. The future of Liberty Eiffel (Laurie Moye)
2. Re: The future of Liberty Eiffel (Eric Bezault)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Nov 2021 17:49:36 +0000
Subject: The future of Liberty Eiffel
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Eiffelers,
I think "Re: Noob First Post" is no longer appropriate to this thread.
Is "The future of Liberty Eiffel" an OK thread name?
As a user of Eiffel since 1993 (Eiffel/S), and of Small/Smart/Liberty
Eiffel from SE-0.75 onwards, I have been overjoyed to see this flurry of
interest in the project after it seemed to be moribund.
I have just one plea to make. This compiler has never been developed in
a very user-friendly way. For those of us who are not software
professionals, but engineers and scientist who just need a robust,
reliable language in which to write our most complicated projects, and
who are devoted to open-source software, the compiler has proved a joy
and a boon, but every new version would contain non-essential changes to
the syntax. This meant that to get the existing code to compile with the
new compiler would require literally thousands of edits. In some cases
it would be easier to produced one's own hacked version of the new
release, reverting parts of the compiler code to allow the old syntax to
be used.
Would it be possible to declare a policy of strict backward
compatibility? The syntax should never be changed for non-essential
reasons. If it becomes absolutely essential to change the syntax to
allow new features, legacy options should be added to allow the old
syntax and disallow the new features so that old code will always be
able to run without any changes.
I would love to be able to contribute to this new project, but, being
even less young than Duke Normandin, my brain cells are a little rusty.
My only contribution ever was to track down a very nasty bug in the
garbage collector. I am now much more at ease hacking the compiler code
(although I would need an expert to check my corrections), so I will try
to help.
I was inspired to learn Eiffel after reading the first 40 pages of
Meyer's "Object-oriented Software Construction" and the Introduction to
his "Eiffel the language". I recommend anybody to re-read these. We
should treat Eiffel as an "industrial strength" object-oriented
language, and make it a delight for engineers and scientists, as well as
software professionals to use.
Laurie
------------------------------
Message: 2
Date: Mon, 29 Nov 2021 21:03:51 +0100
Subject: Re: The future of Liberty Eiffel
Content-Type: text/plain; charset=UTF-8; format=flowed
On 29/11/2021 18:49, Laurie Moye wrote:
> Would it be possible to declare a policy of strict backward
> compatibility? The syntax should never be changed for non-essential
> reasons. If it becomes absolutely essential to change the syntax to
> allow new features, legacy options should be added to allow the old
> syntax and disallow the new features so that old code will always be
> able to run without any changes.
EiffelStudio (and hence Gobo Eiffel which tries to be compatible
with EiffelStudio) is not any better at preserving the syntax
between releases. But it has two solutions at the user's disposal:
1) Classes and clusters are organized into libraries. Each library
has a configuration file (called ECF file) with compilation
options for the classes of this library. Thanks to that, a project
can use a library using an old syntax, another library using
an even older syntax, and a third library using the new syntax.
Even the entire project, not just libraries, can use an old syntax.
2) There is a tool to automatically convert classes in such library
from an old syntax to the new syntax.
Unfortunately there are still some breaking changes that cannot be
handled with ECF files. But ECF files offer more possibilities than
loadpath.se. The configuration files in Gobo used to be Xace files.
They offered less possibilities than ECF files, so I dropped support
for Xace files in favor of ECF files a few years ago and I don't
regret this move. This is probably something which should be considered
as well in Library Eiffel.
--
Eric Bezault
------------------------------
Subject: Digest Footer
_______________________________________________
Liberty-eiffel mailing list
------------------------------
End of Liberty-eiffel Digest, Vol 50, Issue 14
**********************************************