I would like to come back to the issue since I have not yet heard a
satisfactory answer to Peter's request.
Eiffel is a language which allows elegant and readable code. This is an
advantage and a burden at the same time. People think a lot about class
names and feature names and want to chose the most appropriate ones.
If I wanted to write an Eiffel compiler, I have to represent classes and
features. What is a better name for a class which represents an Eiffel
class? Rhetoric question! Is is "CLASS". And the class name for a class
which represents a feature shall be "FEATURE", isn't it?
Since this is not (yet) possible, I would invent some private escape
mechanism. E.g. prefix all classes with a common prefix or whatever. In
other languages it wouldn't disturb me so much, since I have to make a
lot of compromises with readability anyhow. But in Eiffel it disturbs.
And for those who want to extract user documentation from the code base
it is disturbing very much!
And yes, it is not a question of life or death. But let me quote some
author which once stated "... style matters ...".
What is the benefit? The benefit is clear. Better readable code. What is
the price? I would say nearly nothing. E.g. let us take the escape
mechanism with single quotes
class 'FEATURE' .... end
class 'ATTRIBUTE' inherit 'FEATURE' ... end
class 'CLASS' ... end
class EIFFEL_SYSTEM feature
features: ARRAY['FEATURE']
system: ARRAY['CLASS']
...
end
Then it is a matter of the lexer to handle it. There are no one letter
keywords (and probably never will be), therefore no clash with manifest
characters. The readability is good, the single quotes are not disturbing.
Summary: The benefit is high in case of clashes, there is no
disadvantage and the cost to implement it for a reasonably written
compiler is low. Those who don't use it are not disturbed. Those who use
it are happier.
So the question of all questions: Why not?
Regards
Helmut
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.
>
>
>
> Let's assume that we get into a frenzy of language extensions and introduce
> a keyword every two years over the next 50 years (after which few of the
> current users will presumably be interested). That's 25 keywords, of which
> presumably only a few, say half, might be common words that have a
> significant chance of clashing with identifiers in existing code. Is it
> necessary to add a special language mechanism for a dozen cases?
>
>
>
> The problem is of course common words such as `note' turned into keywords
> after many years in which they were free. A special compiler hack for such
> cases, whenever possible, seems preferable to a language mechanism. The
> problem with any language mechanism is that it requires changing user code
> anyway. 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? This avoids polluting the code with strange notations, and encouraging
> nonstandard identifiers even in the absence of a conflict with existing code
> (i.e. what if people start calling their identifiers `@do' and `@feature' in
> new code?) 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.
>
>
>
> So while I am willing to be convinced otherwise I don't think a special
> notation is justified.
>
>
>
> Of course I sympathize with programmers who had the bad luck of choosing
> names that became keywords later on.
>
>
>
> At the moment the only common word that could become a keyword is `across'.
> It's a good idea to stay away from it.
>
>
>
> Thanks,
>
>
>
> -- BM
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
