Re: Ada.strings.bounded problems?

[Magnus.Kempe@di.epfl.ch (Magnus Kempe)]

In article <1995Jan20.120612@lglsun.epfl.ch>, nebbe@lglsun.epfl.ch (Robb Nebbe) writes:
: 
: There should probably be a section in the programming FAQ about
: these cases where the semantics of the language are goofy (if
: not outright wrong). If you wrote something up I'm sure Magnus
: would include it in the FAQ.

I'd rather see it fixed in the language than described in the FAQ :-)

Anyway, if you want to see something added to the FAQ, write it (the
question _and_ answer, not just the question) and email it to me.

The case of "lost equality" is actually quite unfortunate, because there
is no justification in trying to preserve "backward compatibility".  If
some reckless soul did use the "Goodenough trick" in production code,
they would have to check their code, but that'd hardly be an undeserved
task (and that's what a reckless course of action is about).

It really turns out to be a major failure for type composition.
User-defined equality should be treated like user-defined control.
It should transparently compose, not be shackled with tags and
obscure rules.  "Free Equality!"

Maybe an artistic interpretation of RM 9X 4.5.2(14) could declare
that what the paragraph intended was
  For a type extension, predefined equality is defined in terms of the
  primitive (possibly user-defined) equals operator of the parent type
  and of the components of the extension part.

instead of
  For a type extension, predefined equality is defined in terms of the
  primitive (possibly user-defined) equals operator of the parent type
  and of any tagged components of the extension part, and predefined
  equality for any other components not inherited from the parent type.

And then another artistic interpretation would say that RM 9X 4.5.2(24)
really means
  Otherwise, the result is defined in terms of the primitive equals
  operator for any matching components.

instead of
  Otherwise, the result is defined in terms of the primitive equals
  operator for any matching tagged components, and the predefined equals
  for any matching untagged components.

If artists are not permitted to offer their interpretations of rm9x, we
can still go for GNAT, add a -artistic option, and ask other compiler
vendors to do the same.  Finally, note that comments on rm9x should be
sent to ada-comment@sei.cmu.edu, following the format described in the
introduction of the reference manual.  I don't know how artistic the
interpretations will be, though.


Don't ask me what I think of the selection of operations for "generic
formal derived types" that are not "formal private extensions" (12.5.1).
-- 
Magnus Kempe		"I know not what course others may take, but as for me,
Magnus.Kempe@di.epfl.ch  Give me Liberty... or give me Death!" -- Patrick Henry