ANNOUNCEMENT: exlib 0.35 available under CGPL (Class GPL)

[Wouter Scholten]

ANNOUNCEMENT: exlib 0.35 available under CGPL (Class GPL)

This is a collection of wrappers and classes allowing you to program
in xlib directly in eiffel as if you were programming in C (but
further abstraction is very easy with eiffel).

I've mentioned this library when I wanted feedback about the right
license for classes, and you can now download it from

http://www.cistron.nl/~wouters/eiffel.html

It probably works correctly only with SmallEiffel at the moment as:

- You need a case sensitive eiffel compiler for the Xlib constants
(or else XK_a will be equal to XK_A for example). SmallEiffel is case
sensitive since -0.83.

- external declarations are called with
extern "C_WithoutCurrent"
instead of
extern "C"

- a 'cecil.se' file is used.

and in the case of the demo program:

- some explicit calls *.dispose to free memory used in various
classes for the X C-structures.

I would be interested in any changes needed for other compilers.

The demo program linux-is-cool 0.3 is not a clean OO design, but just
a demonstration of what can be done and how to use various
features. For example, the window creation can be put in a separate
class quite easily. I've easily created my own widgets in eiffel
(eg. popup menu's, button's) while making an application which uses
exlib, and I may release these later.

Also note that various stuff is commented out in the exlib cluster and
the application as I'm testing (the compiler :-) and learning eiffel
while developing this lib and a few programs that use it. For this
reason too, some things are not done in a clean way, but this doesn't
affect anyone who just wants to use the classes. Various details in
the demo program are in fact slightly messy because of a workaround
for some problems due to what looks like a compiler bug.

Please have a look at the license (below) and let me know if you think
there's a problem with it. Just as with the FSF licences I attached a
version number to this license (which is a good idea in the GPL). As
the FSF isn't convinced of the usefullness of a class license, they
will probably not use one, other than the unacceptably limited
versions used in various places (e.g. use in commercial programs
allowed, but altered versions of the library/classes become GPL. This
means you can't improve classes and then use them in commercial
software!!)

Note also that I would prefer this license (or one like it) to be
under the control of a non-profit foundation (I would have wanted the
FSF to do this) and that I would like this license to be a well known
alternative to the GPL/LGPL (which is another reason why I wanted the
FSF to use such a license). The comment that anyone can release
software under whatever license they want, is one that is true, but we
don't need a million different ones, it costs a lot of time to make a
license, and a few well know licenses makes it easier for those using
the software (After a while, you know what you may do when it's GPL
when it's BSD etc. There's no need to read the license for each piece
of software you use if it's a know one)

Wouter Scholten

email: wou...@cistron.nl

----------------------------------------------------------------------

Class GENERAL PUBLIC LICENSE (CGPL)
Version 0.2, October 1997

Copyright (C) 1997 W.H.Scholten.
(wou...@cistron.nl)

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

I may change this license when there's a need, and you can choose
whether to use this or a later version.

Note: With a 'class' is meant any source file (i.e. a human readable
file) that can be considered a separately usable file in the sense of
object oriented programming. I.e. it could be a module or a subroutine
in a separate file in the case of non-object oriented programming.

Note 2: in this license, 'this software' refers to the relevant
software under the CGPL.

The CGPL license conditions:

Permission to use, copy, modify, distribute, and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that

1. the copyright notices appear in all copies (not needed for a
copyright notice that is accompanied with a note saying "This notice
may be removed in altered versions of the software") and that both
these copyright notices and this permission notice appear in
supporting documentation.

2. the name of the copyright holder(s) not be used in advertising or
publicity pertaining to distribution of the software without specific,
written prior permission.

3a. Any improvements and bug fixes you make in this software fall
under this license.

3b. Any improvements and bug fixes you make in this software are
distributed at the same time as any product based on this improved
software, by making it available
a. to the maintainer of the original package or
b. from a (company) www page or ftp server or
c. by uploading it (or diff's) to an ftp server, preferably
one that is well known in the circles the orignal software
is used.

preferably, you should send a note of the release to the current
maintainer (if there is one) and send him the patches or new versions.

4. Any other files used with this software to create an application
do not fall under this license, except, when changed versions of
classes in this software rely on some of the classes you made. In that
case, the classes that are needed by the altered classes also fall
under this license. This means, that there should be a clean
separation between your software and this software. I.e., you should
consider this software as a library, that you link into the resulting
executable. You may of course release all your classes under the CGPL,
in which case this requirement is fullfilled automatically.

5. Translations of this software into another programming language
fall under this license.

6. When distributing binaries based on this software, you must state
clearly in supporting documentation that your software uses this
software and that source for that part is freely available from a
web/ftp server and give an example of where to get it.

WARRANTY

As software under the CGPL license can be maintained and altered by
anyone who wishes to do so, there is no warranty, although when this
software is used to produce a commercial program, then the supplier of
that program should provide a warranty for the complete product.

Specifically:

1. The copyright holder(s) make no representations about the
suitability of this software for any purpose. It is provided "as is"
without express or implied warranty.

2. THE COPYRIGHT HOLDER(S) DISCLAIM ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

The end.

[Eric Bezault]

Wouter Scholten wrote:
>
> ANNOUNCEMENT: exlib 0.35 available under CGPL (Class GPL)
>

>[...]

>
> I've mentioned this library when I wanted feedback about the right
> license for classes, and you can now download it from
>
> http://www.cistron.nl/~wouters/eiffel.html

Wouter's Eiffel URL is actually:

http://www.cistron.nl/~wouters/eiffel/eiffel.html

--
Eric Bezault

[Paul Johnson]

In article <3463463B...@cistron.nl>, Wouter Scholten
<wou...@cistron.nl> writes

>It probably works correctly only with SmallEiffel at the moment as:
>
> - You need a case sensitive eiffel compiler for the Xlib constants
>(or else XK_a will be equal to XK_A for example). SmallEiffel is case
>sensitive since -0.83.

This is a bad move for both SmallEiffel and your library. E:TL
specifies that Eiffel is not case sensitive. Therefore both SmallEiffel
and exlib are wrong. Full stop, no argument. I strongly recommend
that you fix it soon. It will save time later on.

And I *really* hope that the case sensitivity of SmallEiffel is
controlled by a switch. Otherwise it is not an Eiffel compiler.

Apart from that, good work.

Paul.

--------------------------------+---------------------------------
Paul Johnson | You are lost in a maze of twisty
Email: Pa...@treetop.demon.co.uk | little standards, all different.
paul.j...@gecm.com |

[Wouter Scholten]

Paul Johnson wrote:

[case insensitivity]

> This is a bad move for both SmallEiffel and your library. E:TL
> specifies that Eiffel is not case sensitive. Therefore both SmallEiffel
> and exlib are wrong. Full stop, no argument. I strongly recommend
> that you fix it soon. It will save time later on.

No. The constants are directly converted from the Xlib headers. It's a
complete waste of time to convert say the uppercase keycodes to
something else (and there are likely to be more conflicts, just look at
how many Xlib constants there are). This will also not allow the direct
conversion of a C program into eiffel and will cost the Xlib programmer
a lot of rethinking.

I think case insensitivity is a bad thing. The style rules in ETL are
ok, but these are not forced and neither should case insensitivity.

However, the library does NOT depend on case sensitivity other than for
the Xlib constants. If anyone wants to provide new header files, please
do (but this will not replace the header's I converted from C).

> And I *really* hope that the case sensitivity of SmallEiffel is
> controlled by a switch. Otherwise it is not an Eiffel compiler.

It is.

As to being an eiffel compiler or not, who in his right mind uses
different Styles for the same variable? I.e., it shouldn't matter for
any well written program and will help you use the same style throughout
the program (useful for grepping to search for a string for example).

Wouter

[Victor B. Putz]

>I think case insensitivity is a bad thing. The style rules in ETL are
>ok, but these are not forced and neither should case insensitivity.

For a nice discussion of this, see Ian Joyner's critique of C++ (I'm
not sure where it is exactly, but you can find a pointer to it at the
outstanding "GUERL: Geoff's Universal Eiffel Resource Locator" at

http://www.progsoc.uts.edu.au/~geldridg

...after having clamored for case sensitivity for some time, I am now
an avid advocate of case INSENSITIVITY. In fact, I regard it as a
totally superfluous feature of any language (programming language or
"person" language) where some other indicator would do as well
(without requiring a doubling of the character set).

I agree wholeheartedly with the other posters: if any Eiffelish
implementation involves case sensitivity, it IS NOT Eiffel and should
not be advertised as such.

-->VPutz

[Eric Bezault]

Paul Johnson wrote:
>
> In article <3463463B...@cistron.nl>, Wouter Scholten
> <wou...@cistron.nl> writes
>

> >It probably works correctly only with SmallEiffel at the moment as:
> >
> > - You need a case sensitive eiffel compiler for the Xlib constants
> >(or else XK_a will be equal to XK_A for example). SmallEiffel is case
> >sensitive since -0.83.

This is not quite true. SmallEiffel is case-sensitive since
SmallEiffel exists. After I experienced portability problems
and having strongly complained about that, D. Colnet was kind
enough to add a command line option starting with version -0.83
to make the compiler case-insensitive. This option is -case_insensitive.

> This is a bad move for both SmallEiffel and your library. E:TL
> specifies that Eiffel is not case sensitive. Therefore both SmallEiffel
> and exlib are wrong. Full stop, no argument. I strongly recommend
> that you fix it soon. It will save time later on.

For Wouter's case-sensitivity problem, I would suggest to use
the 'alias' clause as follows:

XK_lower_a: INTEGER is
external
"C"
alias
"XK_a"
end

XK_upper_a: INTEGER is
external
"C"
alias
"XK_A"
end

That's why the 'alias' clause has been included in the language
in the first place.

> And I *really* hope that the case sensitivity of SmallEiffel is
> controlled by a switch.

Well, as I said above, it's actually the reverse, but it's better
than nothing.

> Otherwise it is not an Eiffel compiler.

Agreed!

--
Eric Bezault

[W. Scholten]

allEiffel exists. After I experienced portability problems
> and having strongly complained about that, D. Colnet was kind
> enough to add a command line option starting with version -0.83
> to make the compiler case-insensitive. This option is -case_insensitive.

This is not true! SmallEiffel was not case sensitive except for the
first character of a identifier. XK_a and XK_A were regarded as the same
in
-0.84 and earlier.

And what do you mean portability problems? Someone using several
different styles for the same identifier? That's not good programming
practice and I think is a point in favour of case sensitivity (or at the
very least for a style checking program to be applied).

>Grepping?!? You better off using a compiler which provides you with
>browsing facilities. That's much more powerful than 'grep'. But if
>you really want to use 'grep', you can still use the -i option
>(case-insensitive).

Giving extra arguments is a hassle. Browsing? Grepping (with a few
other shell commands) is extremely useful. This will get you the
information you want very fast (which is why the shell is not dead and
will not die. GUI stuff is almost always not as flexible nor as powerful
(though easier for easy things))

Btw, why should I use another compiler for browsing abilities? I can
do that in XEmacs (OO browser).

>BTW, if I call you wouter, will you recognize your name or should I
>really call you Wouter?

I thought such arguments would pop up.
While words have a *meaning*, which is irrespective of case, that does
not mean that case is irrelevant. You (and others) conveniently assume
that identifiers are just made up of words. This often is not the case,
but abreviations/acronyms are used or new ones are made up.
And in the case of abbreviations and acronyms, case matters.

As I said and it may not have been completely clear in my reply to
Paul Johnson: A well designed program should have no problems when it's
compiled on a case sensitive compiler. I.e., the same style should be
used throughout. Further, when consciously *using* case sensitivity this
should be limited where appropriate (e.g. keycodes).

Another advantage to case sensitivity is reduced conflicts with
imported features (renaming? In simple cases or with good utilities yes,
but the X headers are huge and were all converted with a small python
script and then finished with some hand editing).
Importing features from other languages is prominent in eiffel, so I
would expect case sensitivity, while suggesting a certain style for
native eiffel.
The Lisp argument (many more characters allowed in identifiers) of Marc
Machowitz is true, but lets face it, C is what one mostly interfaces
with.

If you really want different capitalizations to have 'the same
meaning', then what you should insist on in a compiler is NOT case
insensitivity, but a check that different capitalizations of the first
instance of an identifier do not exist (i.e. if you use Hello, then you
may not use hELLO, HELLO etc).

Now to Victor's suggestion of having a look at the C++ critique (I did
that some time ago, but probably glanced over the case (in)sensitivity
paragraph.)

The main point made there is : identifiers are all names which have a
meaning independent of case as in normal languages and remembering the
exact capitalization is a burden on the programmer.

Now first of all, this is not true for all identifiers. If I use a
variable tmp, then it's clear that this is a temporary variable, but tmp
itself has no meaning itself, instead it's some sort of abbreviation. In
the world of abbreviations and acronyms, case is most definitely
relevant and a case change changes the meaning.

Secondly, It's funny that I almost never have problems with mis-styled
identifiers, but a lot more with characters I left out somewhere or
typo's which have nothing to do with the case. These are glanced over
quite easily, and I could therefore make a case that this should be
handled too intelligently by a compiler.
So I don't buy that argument. It would save almost no time whatsoever
and really, a much more intelligent parser/corrector is what's advocated
with this argument.

And how do you want to handle things like MyVariable vs my_variable?
These are two quite legitimate ways to connect to 'words' (i.e. having a
meaning) into a compound. A bit later in another file, I want to use
that variable, now what whas it again, my_variable? The style guide
would suggest my_variable as myvariable is not very readable (but it is
acceptable), which also favours a mandatory style instead of case
insensitivity (see below).

I can go on with numbers. Why is it allowed to use variable1,
variable2, ... ??? Numbers do not have a 'meaning' other then for
amounts. So what does variable10 stand for? a string with 10 characters?
The 10th variable in series of variables? But what if variable 7 is no
longer needed, and what if the string needs to be 11 char's long?
(again, in a later file I want to use variable8, or was it variable7? )
Here, the 'meaning' of the number is unrelated to what the variable is
about.

The only real point in favour of insensitivity is the following
mentioned by Joiner: each programmer can use his own style of
capitalization for identifiers even with someone elses classes. But is
this really an advantage?
And this does not take into account the compound case I mentioned above.
MyVariable is quite readable for someone who uses a plain text editor,
but someone who sets his style in a viewer to 'lower for variables' gets
myvariable which is not readable at all (and hence not intuitive when
using it in a new file, now what was that variable again: my_variable?
nope).

And as Joiner mentioned editors that handle the user's preferences,
then why not use the style guide as a mandatory internal (text) format,
and show on screen what the user likes to see? This removes the 'case
sensitivity compiles faster' argument Joiner mentions (although I don't
think it makes much difference).

The above ponderings do not convince me of a case for case
insensitivity, just for better programming tools.

All in all, I think it would be better to make the style guide
mandatory than to insist on case insensitivity. (but I'd prefer the
one-style-allowed compiler I think).

However, the use for the case is limited, and any problems
should thus be resolved without much trouble. So I will use, unless I
change my mind about this issue, the case sensitivity to save me some
work and generally make it easier to use C in eiffel. Anyone who doesn't
like that, will probably not have to make many changes (Note that the
'eiffel compilers are all different' argument by Marc Wachowitz is not a
fair view. There are lot's of similar problems with C/C++ compilers and
the include files, signed right shifting, gmake vs make etc).

Wouter

[Eric Bezault]

Wouter Scholten wrote:
> As to being an eiffel compiler or not, who in his right mind uses
> different Styles for the same variable? I.e., it shouldn't matter for
> any well written program and will help you use the same style throughout
> the program (useful for grepping to search for a string for example).

Grepping?!? You better off using a compiler which provides you with

browsing facilities. That's much more powerful than 'grep'. But if
you really want to use 'grep', you can still use the -i option
(case-insensitive).

BTW, if I call you wouter, will you recognize your name or should I
really call you Wouter?

--
ErIc BeZaUlt

[Eric Bezault]

W. Scholten wrote:
> allEiffel exists. After I experienced portability problems
> > and having strongly complained about that, D. Colnet was kind
> > enough to add a command line option starting with version -0.83
> > to make the compiler case-insensitive. This option is -case_insensitive.
>
> This is not true! SmallEiffel was not case sensitive except for the
> first character of a identifier.

Which is even worse than I thought!!

> And what do you mean portability problems? Someone using several
> different styles for the same identifier?

The Eiffel guidelines suggest to put the first character of the
name of a once function in uppercase, and all other feature names
all in lowercase. There may be arguments for or against this
guideline, but my programming practice is to follow this style.
So I wrote:

deferred class A

feature

foo: INTEGER is deferred end

end -- class A

class B

inherit

A

feature

Foo: INTEGER is once Result := 1 end

end -- class B

This wouldn't compile with SmallEiffel.

> That's not good programming
> practice and I think is a point in favour of case sensitivity (or at the
> very least for a style checking program to be applied).

The style I follow is well defined and goes against case sensitivity.

[A lot of arguments telling how great case sensitivity is.]

As usual, very important language problems such as case sensitivity
generate
endless threads with entrenched debates. To avoid that to happen to the
current
thread, I suggest that we switch to a much more interesting subject:
semicolons.
Should semicolons be optional or not, should they be delimiters or
separators?
Sad, isn't it?

--
Eric Bezault

[Dominique Colnet]

Paul Johnson <Pa...@treetop.demon.co.uk> writes:
|> > - You need a case sensitive eiffel compiler for the Xlib constants
|> >(or else XK_a will be equal to XK_A for example). SmallEiffel is case
|> >sensitive since -0.83.
|>

|> This is a bad move for both SmallEiffel and your library. E:TL
|> specifies that Eiffel is not case sensitive. Therefore both SmallEiffel
|> and exlib are wrong. Full stop, no argument. I strongly recommend
|> that you fix it soon. It will save time later on.

SmallEiffel's case (in)sensitivity is controlled by a switch.
As Paul Johnson would say: "Full stop, no argument."

|> And I *really* hope that the case sensitivity of SmallEiffel is

|> controlled by a switch. Otherwise it is not an Eiffel compiler.

Thus, according to Paul Johnson, SmallEiffel, having a switch to
control case sensitivity, is an Eiffel compiler.

SmallEiffel accepts case insensitive programs like other compilers.
It also offer the possibility to program in a case sensitive way
(which I personnaly prefer).

------------------------------------------------------------
Dominique COLNET -- Talk Eiffel with SmallEiffel Talk Eiffel
C.R.I.N. (Centre de Recherche en Informatique de Nancy)
POST: CRIN,BP 239,54506 Vandoeuvre les Nancy Cedex,FRANCE
EMAIL: col...@loria.fr VOICE:+33 0383593079 FAX:+33 0383413079

[W. Scholten]

Eric Bezault wrote:

[foo & Foo]

> The style I follow is well defined and goes against case sensitivity.

Fair enough.

> [A lot of arguments telling how great case sensitivity is.]

Not at all!!!

You're completely missing the point here. You should read more closely.
I was not telling how great case sensitivty is, I was amongst other
things saying that instead of just case insensitivity there's a case for
even stricter limits on what characters should be allowed, and also a
style rule for how to combine 'words' in an indentifier.

> As usual, very important language problems such as case sensitivity
> generate
> endless threads with entrenched debates. To avoid that to happen to the
> current
> thread, I suggest that we switch to a much more interesting subject:
> semicolons.
> Should semicolons be optional or not, should they be delimiters or
> separators?
> Sad, isn't it?

Sheesh! What kind of reply is this? I said that case sensitivity is not
very important to me, but useful sometimes. I also gave reasons why the
case for case sensitivty as presented by say Joiner is too simplistic
and if you want to follow it though consistently you should consider
what to do when making a compound and that it might be a good idea not
to allow digits in identifiers for various reasons.

In my final remark I also made it rather clear that I have no need to
debate this further.

If you don't like the subject, stop posting about it or don't reply to
that section in a post or say you don't want to discuss it or whatever,
but not such meaningless comments.
But I guess this just confirms what I knew already. USENET is dead. The
noise is reaching unacceptable levels in most groups and mailinglist are
the only real thing left.

USENET: R.I.P.

Wouter

[Eric Bezault]

W. Scholten wrote:
>
> Eric Bezault wrote:
>
> [foo & Foo]

This is a good summary :-)

> > [A lot of arguments telling how great case sensitivity is.]
>
> Not at all!!!
>
> You're completely missing the point here. You should read more closely.
> I was not telling how great case sensitivty is, I was amongst other
> things saying that instead of just case insensitivity there's a case for
> even stricter limits on what characters should be allowed, and also a
> style rule for how to combine 'words' in an indentifier.

Sorry if I missed your point.

> > As usual, very important language problems such as case sensitivity
> > generate
> > endless threads with entrenched debates. To avoid that to happen to the
> > current
> > thread, I suggest that we switch to a much more interesting subject:
> > semicolons.
> > Should semicolons be optional or not, should they be delimiters or
> > separators?
> > Sad, isn't it?
>
> Sheesh! What kind of reply is this?

This was supposed to be a joke, referring to section B.7 "On syntax" in
ETL, second printing, page 505.

> In my final remark I also made it rather clear that I have no need to
> debate this further.

Me neither.

Sorry again for the misunderstanding.

--
Eric Bezault

[Veli-Pekka Nousiainen]

While joking, please remember to add a "smiley" eg. ;-)
----------------------------------------------------------------------------
-----------
Eric Bezault wrote in message <34697E...@stratus.com>...

>W. Scholten wrote:
>>
>> Eric Bezault wrote:
>>

<SNIP>

[Franck Arnaud]

Veli-Pekka Nousiainen:

> While joking, please remember to add a "smiley" eg. ;-)

This is indeed often a problem in international communication.

Here in the UK few people use smileys (unless they're thick) because it
is assumed that the reader is clever enough to understand irony. Of
course it does not always work, and people see jokes when there were
none intended or are offended by some simple irony. Still, some double
entendre spices up conversations which would be much more boring without
the ambiguities.

The problem is the same in face-to-face communication, as Britons
usually don't signal sarcasm or irony physically either, which is
something that takes some time to learn for non-natives.

On the net, it's a bit of a no-win situation because with a smiley you
look like a peasant and without one you're misunderstood.

While we're at it, I find japanese smileys (^_^) to be more convenient
as they don't require any rotation of your monitor.

[Paul Johnson]

In article <649nqv$qgs$1...@muller.loria.fr>, Dominique Colnet
<col...@mouy.loria.fr> writes
>Paul Johnson <Pa...@treetop.demon.co.uk> writes:

>|> This is a bad move for both SmallEiffel and your library. E:TL
>|> specifies that Eiffel is not case sensitive. Therefore both SmallEiffel
>|> and exlib are wrong. Full stop, no argument. I strongly recommend
>|> that you fix it soon. It will save time later on.

(I've read the other posts in this thread about exlib, and quite
understand the problem. Its been a very long time since I used X, and
I'd forgotton that anyone could produce a large, serious piece of
software where "Foo" and "foo" mean two different things)

>SmallEiffel's case (in)sensitivity is controlled by a switch.
>As Paul Johnson would say: "Full stop, no argument."
>
>|> And I *really* hope that the case sensitivity of SmallEiffel is
>|> controlled by a switch. Otherwise it is not an Eiffel compiler.
>
>Thus, according to Paul Johnson, SmallEiffel, having a switch to
>control case sensitivity, is an Eiffel compiler.

Yes, as long as case sensitivity is disabled. With case sensitivity
enabled it becomes a non-standard dialect.

>SmallEiffel accepts case insensitive programs like other compilers.
>It also offer the possibility to program in a case sensitive way
>(which I personnaly prefer).

Well, that is your perogative. I personally make the whole argument
moot by sticking to consistent case-rules for all identifiers and never
using case to distinguish two different identifiers. So (typos apart)
my Eiffel code should compile under SmallEiffel no matter how you set
the flag.

[Paul Johnson]

In article <64ihg5$ic0$1...@news01.btx.dtag.de>, Gandalf The White
<Gandalf....@t-online.de> writes

>Tell us, Paul, how you would write the names for your constants, and
>once routines, then?

I capitalise constants, and generally prefix the names of once routines
that return objects with "the_" to indicate their uniqueness. E.g.

the_queue: PRIORITY_QUEUE [EVENT] is
-- An event queue from a simulation framework
once
!!Result;
ensure
non_void: Result /= Void;
end; -- the_queue

I know this is not entirely consistent. I should probably capitalise
the once routines as well. However the point is that I never introduce
two identifiers which are the same syntactic part (e.g. variable name,
class name) and which are only distinguished by case, even in languages
where that is legal. And I when writing Eiffel I always use consistent
case for any particular identifier. So if I call a constant "Red" then
I refer to it as "Red" from then on, never as "red" or "RED" or any
other variant.