From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: Renaming enumeration literals?
Date: 20 Mar 92 22:27:17 GMT [thread overview]
Message-ID: <41931@as0c.sei.cmu.edu> (raw)
In article <EACHUS.92Mar20150027@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Rober
t I. Eachus) writes:
> I'll take your question as serious and not rhetorical. First of
>all a compiler which rejects a static instance of a renamed function
>as a choice in a case statement is wrong. (See AI-438/09-BI-WA
>Renamed enumeration literals can be static.)
Just to complete the exposition: yes, it was an oversight in the original
RM that a renamed enumeral wasn't static; as Robert Eachus points out,
this was discovered and corrected.
The reason this renaming rule is used is that both enumerals and functions
may be overloaded; from the point of view of visibility and overload
resolution, an enumeration literal is simply a parameterless function
that always returns the same value. This semantic unification is a
help to both compiler writer and user, I think.
And the reason enumerals may be overloaded is so that the programmer
can define different character sets with the same literals, thus
ASCII'('A')
EBCDIC'('A')
If the application requires a non-ASCII character set, this makes the
program much clearer, since 'A' can always mean "whatever would look
like letter-A on input or output". The wisdom of this design decision
will become even more evident when we move to ISO Latin-1 as the
standard, and many programs will have to support two character sets
during the changeover.
next reply other threads:[~1992-03-20 22:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1992-03-20 22:27 Robert Firth [this message]
-- strict thread matches above, loose matches on Subject: below --
1992-03-17 9:00 Renaming enumeration literals? Jack W. Sharer
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox