From: Robert A Duff <bobduff@world.std.com>
Subject: Re: Enumeration representation
Date: 1999/09/13
Date: 1999-09-13T00:00:00+00:00 [thread overview]
Message-ID: <wccso4jar3z.fsf@world.std.com> (raw)
In-Reply-To: 7rhkte$na7$1@nnrp1.deja.com
Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <yeczoyt2hxx.fsf@king.cts.com>,
> Keith Thompson <kst@cts.com> wrote:
> > I still think that enumeration representation clauses, as
> currently
> > defined, are more trouble than they're worth.
>
> I definitely agree, and they have a very nasty implementation
> dependence, namely whether arrays with this index type have
> holes or not (the RM does not specify).
That's a general problem with high-level languages: If there's more than
one "reasonable" way to implement some feature, you can end up with
portability problems. Formally, this is "just" an efficiency issue, so
the RM doesn't address it. But it's such a huge efficiency issue that
it affects your design. Similar examples: generics (whether code is
shared or not) and mutable records (whether they implicitly use the
heap). It's not easy to write RM-style wording that requires one
particular implementation of these features, but it would certainly be
desirable if all compilers took the same approach.
Lower-level languages like C don't have this problem (at least not much)
-- for just about any feature of C, you can pretty much guess what the
compiler is going to do with it.
I agree that enum rep clauses are not worth the trouble -- they
shouldn't be in the language.
By the way, I think the Ada 83 Rationale had some words that made it
seem like the designers thought pragma Pack ought to control whether
arrays have holes or not. That's not a very good solution, though,
and the RM gives no hint of it.
> Well it is easy enough to use unchecked conversion
Well, if the enumeration type is a generic formal...
- Bob
--
Change robert to bob to get my real email address. Sorry.
next prev parent reply other threads:[~1999-09-13 0:00 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-10 0:00 Enumeration representation Alex
1999-09-10 0:00 ` David C. Hoos, Sr.
1999-09-10 0:00 ` Robert Dewar
1999-09-10 0:00 ` Matthew Heaney
1999-09-10 0:00 ` Robert Dewar
1999-09-10 0:00 ` Keith Thompson
1999-09-11 0:00 ` Robert Dewar
1999-09-11 0:00 ` Keith Thompson
1999-09-12 0:00 ` Bryce Bardin
1999-09-13 0:00 ` Robert Dewar
1999-09-13 0:00 ` Keith Thompson
1999-09-13 0:00 ` Robert Dewar
1999-09-12 0:00 ` Keith Thompson
1999-09-13 0:00 ` Robert Dewar
1999-09-13 0:00 ` Ted Dennison
1999-09-13 0:00 ` Keith Thompson
1999-09-14 0:00 ` Robert Dewar
1999-09-13 0:00 ` Robert A Duff [this message]
1999-09-13 0:00 ` Robert Dewar
1999-09-10 0:00 ` Ted Dennison
1999-09-10 0:00 ` Robert Dewar
1999-09-13 0:00 ` Ted Dennison
1999-09-13 0:00 ` Alex
-- strict thread matches above, loose matches on Subject: below --
2004-01-01 20:44 Luke A. Guest
2004-01-01 21:45 ` Stephen Leake
2004-01-01 22:01 ` Luke A. Guest
2004-01-02 1:17 ` tmoran
2004-01-02 1:29 ` Stephen Leake
2004-01-02 3:10 ` Luke A. Guest
2004-01-02 2:46 ` Robert A Duff
2004-01-02 3:12 ` Luke A. Guest
2004-01-02 13:58 ` Marin David Condic
2004-01-02 21:39 ` Pat Rogers
2004-01-03 13:42 ` Marin David Condic
2004-01-03 1:53 ` Robert A Duff
2004-01-02 20:52 ` Randy Brukardt
2004-01-02 21:05 ` Luke A. Guest
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox