Using keywords as identifiers

[helmut.brandl]

Bertrand Meyer wrote:
> I am skeptical of the benefit of all this. The rule that identifiers may not
> clash with keywords seems sound, especially given that there are not so many
> keywords.

Eiffel does have a rich set of keywords. And Eiffel allows elegant
source code. Sometimes the search for elegancy and the rich set of
keywords work in opposite directions.

If I want to write a compiler for Eiffel in Eiffel, what is the best
name to represent a feature? Wouldn't it be FEATURE?

You can always workaround them by using e.g. EIFFEL_FEATURE and
EIFFEL_CLASS. But this is more disturbing than in other languages. If
you program in C++ or java, you know that your code won't look very
nice. But if you start to program in Eiffel you want your code look nice.

Therefore I have some sympathy for Peter's proposal. `CLASS' and
`FEATURE' are well readable and due to the escape avoid clashes with
keywords. And it does not disturb anything. So why not?

I know that it is a matter of taste and style, but sometimes style
matters (I recall some phrases of OOSC2 ;-)).

Helmut

P.S.: I don't think that Peter does complain about the need to edit his
source files. He is more complaining about the fact that he needs to
give his identifiers names which don't fit very well into the problem
domain.

[Peter Gummer-2]

Bertrand Meyer wrote:
> ... A special compiler hack for such
> cases, whenever possible, seems preferable to a language mechanism.
>  

That's fine by me, if the Eiffel parser is able to do it reliably.


> ... If you are going to change every occurrence of the identifier `note'
> to `@note' or some such convention, why not change it to a normal identifier
> name?
>  

Because the correct name of the domain concept is 'note' or, in our
case, 'attribute'. We don't want to call it anything else: it already
has the correct name, and it appears in all of our documentation with
that name. We are not going to call it anything else and we don't want
the compiler to force us to do so.

My concern is not with editing source files. That is easy: we could do
it in a few minutes. My concern is with keeping our Eiffel code, and the
artefacts generated from it, accurate and legible.


> ... At least a compiler hack lets you keep your code as it is, with
> the expectation that you will clean it up when you have time. Such a cleanup
> should happen just once.
>  

No, these identifier names reflect domain concepts. We want to use these
names forever.

- Peter Gummer

[Paul Bates [ES]]

I just wanted to add my two cents, and they are my personal two cents:

There's a lot of talk about prefixing/suffixing identifiers with a special character to get around the keyword as identifier issue. This has come to light because we have introduced keywords that are currently in use as identifiers. Ask yourself, why has this subject never been brought about before? Keywords such a 'end' and 'class' could have also been used as domain specific names - e.g. start/end when dealing with positions or locations. The fact is, we saw they were reserved words and dealt with it accordingly. New Eiffel developers will also act accordingly and simply see note/attribute as identifiers they cannot use, just like other languages. Existing developers have a harder time because not only is code affected but also documentation or other written concepts, which can be more frustrating that changing your code so I see why this thread has come about.

Really, I want to address suffixing and prefixing. There was an earlier comment that using something like - attribute_ - looks ugly, yet %/@/`' or even prefixing _ isn't?! In addition, it's just not Eiffel-like. It may look nice when expressing it as a single declaration but try any specification in an proper expression:

To be confused with object @ index:
* object.@attribute

Common notion for class attributes in C++ and the like, and not an Eiffel identifier:
* object._attribute

Free operator conflict:
* object.%attribute -

Doesn't look too bad, but how to we write comments addressing this attribute -- ``attribute'':
* object.`attribute'

Still looks like Eiffel:
* object.attribute_

The latter is clearly a winner in my book, when changing the identifier is not viable.

C#/VB had to introduce a method of using keywords as identifiers, prefixing their use with '@', and as Peter already mentioned only for use in expressions/instructions rather than declarations. This was a needed solution because the common language specification allows other developers to write code in different languages, with different keywords, so conflicts are going to happen. Even Eiffel for .NET had to resolve such conflicts and the way it was done was to suffix '_'.

Generally speaking, languages do not provide any means to declare keywords as identifiers because there is little need because one can use in identifier name '_'.

Best,
Paul.

--- In [hidden email], Peter Gummer <p-gummer@...> wrote:

>
> Bertrand Meyer wrote:
> > ... A special compiler hack for such
> > cases, whenever possible, seems preferable to a language mechanism.
> >  
>
> That's fine by me, if the Eiffel parser is able to do it reliably.
>
>
> > ... If you are going to change every occurrence of the identifier `note'
> > to `@note' or some such convention, why not change it to a normal identifier
> > name?
> >  
>
> Because the correct name of the domain concept is 'note' or, in our
> case, 'attribute'. We don't want to call it anything else: it already
> has the correct name, and it appears in all of our documentation with
> that name. We are not going to call it anything else and we don't want
> the compiler to force us to do so.
>
> My concern is not with editing source files. That is easy: we could do
> it in a few minutes. My concern is with keeping our Eiffel code, and the
> artefacts generated from it, accurate and legible.
>
>
> > ... At least a compiler hack lets you keep your code as it is, with
> > the expectation that you will clean it up when you have time. Such a cleanup
> > should happen just once.
> >  
>
> No, these identifier names reflect domain concepts. We want to use these
> names forever.
>
> - Peter Gummer
>

[Eric Bezault]

Paul Bates wrote:

> I just wanted to add my two cents, and they are my personal two cents:
>
> There's a lot of talk about prefixing/suffixing identifiers with a special character to get around the keyword as identifier issue. This has come to light because we have introduced keywords that are currently in use as identifiers. Ask yourself, why has this subject never been brought about before? Keywords such a 'end' and 'class' could have also been used as domain specific names - e.g. start/end when dealing with positions or locations. The fact is, we saw they were reserved words and dealt with it accordingly. New Eiffel developers will also act accordingly and simply see note/attribute as identifiers they cannot use, just like other languages. Existing developers have a harder time because not only is code affected but also documentation or other written concepts, which can be more frustrating that changing your code so I see why this thread has come about.
>
> Really, I want to address suffixing and prefixing. There was an earlier comment that using something like - attribute_ - looks ugly, yet %/@/`' or even prefixing _ isn't?! In addition, it's just not Eiffel-like. It may look nice when expressing it as a single declaration but try any specification in an proper expression:
>
> To be confused with object @ index:
> * object.@attribute
>
> Common notion for class attributes in C++ and the like, and not an Eiffel identifier:
> * object._attribute
>
> Free operator conflict:
> * object.%attribute -
>
> Doesn't look too bad, but how to we write comments addressing this attribute -- ``attribute'':
> * object.`attribute'
>
> Still looks like Eiffel:
> * object.attribute_
>
> The latter is clearly a winner in my book, when changing the identifier is not viable.

What about introducing yet another keyword to escape
keywords: 'identifier' ;-)

   identifier attribute
   identifier note

or even:

   identifier identifier

;-)

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

[Peter Gummer-2]

Paul Bates wrote:
> ... There was an earlier comment that using something like - attribute_ - looks ugly, yet %/@/`' or even prefixing _ isn't?! In addition, it's just not Eiffel-like. It may look nice when expressing it as a single declaration but try any specification in an proper expression:

I already did so, Paul, in my original post:

        `attribute' (name: STRING): ATTRIBUTE_NODE


        a := complex_node.`attribute' ("1234")



Somehow I'm not making myself clear. I'm not too concerned about how an
extra underscore would look in our code:

        attribute_ (name: STRING): ATTRIBUTE_NODE


        a := complex_node.attribute_ ("1234")


Both look as bad as each other to me.

What I *am* worried about is that the underscore hack means that the
name of the identifier is now *wrong*. The underscore will appear in
documentation, the Features tool, XMI export, etc., etc.:

       attribute_

By contrast, if Eiffel allowed quoting of the identifier, those tools
and documents would omit the quote character(s):

       attribute

Eiffel is meant to be a specification language, isn't it?

- Peter Gummer

[dlebansais]

Things would be different if Eiffel compilers accepted structured text (XML and such) instead of plain text only.

Like:

<class>Shiny class</class>
<create>make</create>

instead of

class
  SHINY_CLASS

create
  make


Then you could use more characters for class and feature names, like chinese characters, or heaven forbid, space!

It still annoys me to no end that I cannot name my media files with ? or /, just because it was decided you couldn't fifty years ago.

But maybe I'm thinking out of the box. I must come back in.

David Le Bansais.

[kkkkg999]

Despite of introducing a mechanism in the language or not, I agree with Paul using the suffix "_". Because no matter how, we need something that must be different with the keyword. This is the simplest and most readable form. Better than `class', @class ...

Why not using prefix "_"? A symbolic prefix does not follow rule of Eiffel identifier definition. This also applies to the forms of `class', @class...

Regards,
Ted

--- In [hidden email], "Paul Bates" <paul.bates@...> wrote:

>
> I just wanted to add my two cents, and they are my personal two cents:
>
> There's a lot of talk about prefixing/suffixing identifiers with a special character to get around the keyword as identifier issue. This has come to light because we have introduced keywords that are currently in use as identifiers. Ask yourself, why has this subject never been brought about before? Keywords such a 'end' and 'class' could have also been used as domain specific names - e.g. start/end when dealing with positions or locations. The fact is, we saw they were reserved words and dealt with it accordingly. New Eiffel developers will also act accordingly and simply see note/attribute as identifiers they cannot use, just like other languages. Existing developers have a harder time because not only is code affected but also documentation or other written concepts, which can be more frustrating that changing your code so I see why this thread has come about.
>
> Really, I want to address suffixing and prefixing. There was an earlier comment that using something like - attribute_ - looks ugly, yet %/@/`' or even prefixing _ isn't?! In addition, it's just not Eiffel-like. It may look nice when expressing it as a single declaration but try any specification in an proper expression:
>
> To be confused with object @ index:
> * object.@attribute
>
> Common notion for class attributes in C++ and the like, and not an Eiffel identifier:
> * object._attribute
>
> Free operator conflict:
> * object.%attribute -
>
> Doesn't look too bad, but how to we write comments addressing this attribute -- ``attribute'':
> * object.`attribute'
>
> Still looks like Eiffel:
> * object.attribute_
>
> The latter is clearly a winner in my book, when changing the identifier is not viable.
>
> C#/VB had to introduce a method of using keywords as identifiers, prefixing their use with '@', and as Peter already mentioned only for use in expressions/instructions rather than declarations. This was a needed solution because the common language specification allows other developers to write code in different languages, with different keywords, so conflicts are going to happen. Even Eiffel for .NET had to resolve such conflicts and the way it was done was to suffix '_'.
>
> Generally speaking, languages do not provide any means to declare keywords as identifiers because there is little need because one can use in identifier name '_'.
>
> Best,
> Paul.
>
> --- In [hidden email], Peter Gummer <p-gummer@> wrote:
> >
> > Bertrand Meyer wrote:
> > > ... A special compiler hack for such
> > > cases, whenever possible, seems preferable to a language mechanism.
> > >  
> >
> > That's fine by me, if the Eiffel parser is able to do it reliably.
> >
> >
> > > ... If you are going to change every occurrence of the identifier `note'
> > > to `@note' or some such convention, why not change it to a normal identifier
> > > name?
> > >  
> >
> > Because the correct name of the domain concept is 'note' or, in our
> > case, 'attribute'. We don't want to call it anything else: it already
> > has the correct name, and it appears in all of our documentation with
> > that name. We are not going to call it anything else and we don't want
> > the compiler to force us to do so.
> >
> > My concern is not with editing source files. That is easy: we could do
> > it in a few minutes. My concern is with keeping our Eiffel code, and the
> > artefacts generated from it, accurate and legible.
> >
> >
> > > ... At least a compiler hack lets you keep your code as it is, with
> > > the expectation that you will clean it up when you have time. Such a cleanup
> > > should happen just once.
> > >  
> >
> > No, these identifier names reflect domain concepts. We want to use these
> > names forever.
> >
> > - Peter Gummer
> >
>

[Berend de Boer]

>>>>> "Ted" == Ted  <[hidden email]> writes:

    Ted> Despite of introducing a mechanism in the language or not, I
    Ted> agree with Paul using the suffix "_". Because no matter how,
    Ted> we need something that must be different with the
    Ted> keyword. This is the simplest and most readable form. Better
    Ted> than `class', @class ...  Why not using prefix "_"? A
    Ted> symbolic prefix does not follow rule of Eiffel identifier
    Ted> definition. This also applies to the forms of `class',
    Ted> @class...

See Peter Gummer's comments. This _ ends up everywhere, in
documentation etc. Also code generation tools need to know what
identifiers are key words. An escaping mechanism is the answer to
both.

--
Cheers,

Berend de Boer

[rfo]

Hi All!

There have been many points made in this thread.  Some were actually
related :)
Peter's remarks are central to the problem.  Forbidding the use of the
correct name for a class or feature makes Eiffel less valuable than it
could be.  Long-time Eiffelistas enjoy claiming that the flow between
real-world problem space and implementation is seamless and reversible
(sound familiar?).
I can understand resistence to change, but the issue is very real and
needs to be addressed in a way that is more responsible than "Get over
it" or "Just us a different name".
I had made a couple of suggestions earlier and a counter claim used them
incorrectly.  What I am proposing is an escape mechanism.  That is a
well understood mechanism.  I don't care if it's a compiler hack or a
change to the language - as long as it addresses the actual problem.
When I suggested using a prefix as a syntactic element, I did not say,
imply, nor intend the prefix to become part of the identifier.  That
would miss the point, wouldn't it?
If an escape mechanism were used, it would be not be needed everywhere -
it's simply (let me make this even more clear) Not Part of the
Identifier.  Eiffel keywords have their meaning but they also separate
other tokens.  The escape mechanism would introduce another token.
A counter claim used a construct like this to show how ugly or stupid (I
forget which) an escape character would be:
      a := b.?class
to me, this is unnecessary because the context should allow
      a := b.attribute

Other places might include
     attribute := b.c

OK, that looks like trouble, so the identifier needs escaping.  I don't
know if all keywords would be escapable without heroic mods to the
language, but I would hope that at least new ones (which, by the way
really _are_ language changes) would.

The smart guys (and you know who you are) need at least to consider
this, not with the predisposition to prove it's a dumb idea, but with
the intent to address the very real problem, as Peter as made quite
clear.

     R

==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460

> -------- Original Message --------
> Subject: Re: [eiffel_software] Re: Using keywords as identifiers
> From: Berend de Boer <[hidden email]>
> Date: Thu, May 14, 2009 7:37 am
> To: [hidden email]
> >>>>> "Ted" == Ted  <[hidden email]> writes:
>     Ted> Despite of introducing a mechanism in the language or not, I
>     Ted> agree with Paul using the suffix "_". Because no matter how,
>     Ted> we need something that must be different with the
>     Ted> keyword. This is the simplest and most readable form. Better
>     Ted> than `class', @class ...  Why not using prefix "_"? A
>     Ted> symbolic prefix does not follow rule of Eiffel identifier
>     Ted> definition. This also applies to the forms of `class',
>     Ted> @class...
> See Peter Gummer's comments. This _ ends up everywhere, in
> documentation etc. Also code generation tools need to know what
> identifiers are key words. An escaping mechanism is the answer to
> both.
> --
> Cheers,
> Berend de Boer

[kkkkg999]

--- In [hidden email], Berend de Boer <berend@...> wrote:

>
> >>>>> "Ted" == Ted  <kkkkg999@...> writes:
>
>     Ted> Despite of introducing a mechanism in the language or not, I
>     Ted> agree with Paul using the suffix "_". Because no matter how,
>     Ted> we need something that must be different with the
>     Ted> keyword. This is the simplest and most readable form. Better
>     Ted> than `class', @class ...  Why not using prefix "_"? A
>     Ted> symbolic prefix does not follow rule of Eiffel identifier
>     Ted> definition. This also applies to the forms of `class',
>     Ted> @class...
>
> See Peter Gummer's comments. This _ ends up everywhere, in
> documentation etc. Also code generation tools need to know what
> identifiers are key words. An escaping mechanism is the answer to
> both.

If escaping mechanism is really needed, suffix '_' can also be a good candidate. '_' won't be anywhere but in the code.

If escaping mechanism is not adopted in the end, suffix '_' is a good choice as a coding style in such case that one needs to use keywords as identifiers.

I don't have strong option whether escaping mechanism is needed, but wanted to address suffix '_' is the first choice for me in either case.

Ted

[Peter Gummer-2]

Ted wrote:
> If escaping mechanism is really needed, suffix '_' can also be a good candidate. '_' won't be anywhere but in the code.
>  

That's a surprising claim, Ted, given that it is legal for an identifier
to end with an underscore, so I tested it in EiffelStudio 6.4. I added a
feature called attribute_ to a class and compiled. The Features tool,
the Feature tool and the Diagram tool all show attribute_ with the
underscore.

So no, if an escaping mechanism is added to Eiffel, it won't be an '_'
suffix.

- Peter Gummer

[kkkkg999]

--- In [hidden email], Peter Gummer <p-gummer@...> wrote:

>
> Ted wrote:
> > If escaping mechanism is really needed, suffix '_' can also be a good candidate. '_' won't be anywhere but in the code.
> >  
>
> That's a surprising claim, Ted, given that it is legal for an identifier
> to end with an underscore, so I tested it in EiffelStudio 6.4. I added a
> feature called attribute_ to a class and compiled. The Features tool,
> the Feature tool and the Diagram tool all show attribute_ with the
> underscore.

It is something still on paper, EiffelStudio of course does not show `attribute_' as `attribute'.

Right, identifier end with an underscore is legal, that's why I say '_' suffix can be a coding style (part of an identifier) if the escaping mechanism is not adopted in the end. Then '_' suffix will unfortunately appear in docs etc, but it's off my point.

> So no, if an escaping mechanism is added to Eiffel, it won't be an '_'
> suffix.

Since "attribute_" is legal, The only problem I see is that you use both "attribute" and "attribute_" as identifiers in your existing code. But I don't think you do.

Ted

[Colin LeMahieu]

Could a solution be to allow someone to rename features in the documentation
tools?

On Thu, May 14, 2009 at 8:20 AM, Peter Gummer <[hidden email]>wrote:

>
>
> Ted wrote:
> > If escaping mechanism is really needed, suffix '_' can also be a good
> candidate. '_' won't be anywhere but in the code.
> >
>
> That's a surprising claim, Ted, given that it is legal for an identifier
> to end with an underscore, so I tested it in EiffelStudio 6.4. I added a
> feature called attribute_ to a class and compiled. The Features tool,
> the Feature tool and the Diagram tool all show attribute_ with the
> underscore.
>
> So no, if an escaping mechanism is added to Eiffel, it won't be an '_'
> suffix.
>
> - Peter Gummer
>
>  
>

[Non-text portions of this message have been removed]

Dear Paul,

> Keywords such as 'end' and 'class'
> could have also been used as domain specific names -
> e.g. start/end when dealing with positions or locations.
> The fact is, we saw they were reserved words
> and dealt with it accordingly.

It is also a matter of fact (judged by the existence
of this thread and my own experiences)
that Eiffel programmers are sometimes forced to resort
to using identifiers that do not perfectly match
the application domain's nomenclature.
Perfect modeling requires perfect names.

> attribute_ - looks ugly,
> yet %/@/`' or even prefixing _ isn't?!

Therefore, I like Eric's idea
of introducing (yet) another keyword:

> identifier attribute
> identifier note
> identifier identifier

Regards,
Karsten

[Alexander Kogtenkov [ES]-2]

Karsten Heusser wrote:

> Perfect modeling requires perfect names.
>
>> attribute_ - looks ugly,
>> yet %/@/`' or even prefixing _ isn't?!
>
> Therefore, I like Eric's idea
> of introducing (yet) another keyword:
>
>> identifier attribute
>> identifier note
>> identifier identifier

This becomes less attractive when used in the context of the feature code:

    something.do_this
    something.indetifier note

So, using a special syntax (that can also be used in other contexts, like comments,
documentation, discussion forums, etc., including the cases where the name should
be highlighted in the plain text) might be better. The current `convention' could be used,
though it could be adapted to match some unicode style of quotes.

Regards,
Alexander Kogtenkov

[Thomas Beale-3]

Alexander Kogtenkov wrote:
 >

 >
 > This becomes less attractive when used in the context of the feature
code:
 >
 > something.do_this
 > something.indetifier note
 >


but surely you only need special syntax (of whatever kind) at the point
of declaration, not the point of referencing? In the expression
something.xxx, there is a leading "something." so the parser knows it is
expecting a routine / attribute dispatch. In the parse context of the
interior of a routine, even a call to a local feature whose name is
'attribute' should not be problematic, because no declaration can occur
in a routine body (outside the local clause, or any type attachment
statement).


--
    Thomas Beale
Chief Technology Officer, Ocean Informatics

Chair Architectural Review Board, openEHR Foundation
Honorary Research Fellow, University College London
Chartered IT Professional Fellow, BCS, British Computer Society

[Alexander Kogtenkov [ES]-2]

Thomas Beale wrote:

> but surely you only need special syntax (of whatever kind) at the point
> of declaration, not the point of referencing? In the expression
> something.xxx, there is a leading "something." so the parser knows it is
> expecting a routine / attribute dispatch. In the parse context of the
> interior of a routine, even a call to a local feature whose name is
> 'attribute' should not be problematic, because no declaration can occur
> in a routine body (outside the local clause, or any type attachment
> statement).

Unfortunately this is not the case, as there are unqualified calls that do not
allow to decide whether a token is an identifier or a keyword. Consider

    ...
    precursor
    ...

Is it a call to a precursor or to a feature of such a name?

Similarly,

    debug ("abc")
        xyz
    end

could be interpreted either as a debug clause or as a sequence of 3 feature calls.

It's possible to say that the unqualified calls to the features with a name that is a keyword
should be prefixed with "identifier" though. But then we are back to the code like

    identifier debug ("abc")
    xyz
    identifier end

And, there is no reasonable way to highlight the feature names in the plain text - in
comments, mails, etc.

Regards,
Alexander Kogtenkov

[Peter Gummer-2]

Karsten Heusser wrote:
> Therefore, I like Eric's idea
> of introducing (yet) another keyword:
>
>  
>> identifier attribute
>> identifier note
>> identifier identifier
>>    

Eric was just joking, wasn't he? I had a good chuckle when I read
"identifier identifier" :-)

- Peter Gummer

[Jonathan S. Ostroff]

In a .NET application one can get access to the foreground colours of text
printed to the console via something like:

  [DllImportAttribute("Kernel32.dll")]
        private static extern bool SetConsoleTextAttribute
        (
            IntPtr hConsoleOutput, // handle to screen buffer
            int wAttributes    // text and background colors
        );

so that we have output to STDOUT as green and likewise one can choose a
different colour, say red, for STDERR.

Is there a standard call for this in the base library (that would work in
linux or windows). Class CONSOLE does not appear to support this.

Also, in .NET one can parse using regular expressions directly (e.g.
Regex("[ \t]+")). Is there a standard facility to this in the base library?

Thanks

Jonathan

[Thomas Beale-3]

probably someone else has made the point, but I did not read every
single post in this thread....can we agree on one point: Eiffel, as a
pascal style language, that uses natural language keywords rather than
symbols (as in a C-style language) is always going to run into this
problem of keyword clashes. It seems to me that the group of languages
constructed like this have a special weakness of this sort, and
therefore should provide a mechanism to deal with it. I think we at
least have to accept the need for a mechanism.

- thomas beale