RE: Clause 10, Expression Evaluation

["David James" <dvj@xxxxxxxxxxxx>]

Jason,

Well put.

IMHO, one needs to:
  1) Unambiguously define all operations.
  2) Clearly list all options.
  3) Specify which options are part of the "repeatibility" suite.
  4) Provide guidance on how languages "could" follow through,
     to ensure repeatability, within an informative annex.

Unfortunately, I observe that:
  1) Some vendors prefer the ambiguities of the standard, as
     I have gathered from personal discussions at meetings.
     Comments to expose them (through detailed tables) have
     been consistently rejected.
  2) Options are currently well hidden.
     Comments to expose them (through detailed listings)
     have previously been rejected.
3-4) Folks seem to be getting carried away and numerical
     analysts may be overextending their expertise into
     the areas of compilers.

I don't have much of a religious zeal on technical details,
but continue to have concerns with respect to ambiguities
and options. These are great for job-retention purposes,
but not helpful to the community at large.

Cheers,
DVJ



> > -----Original Message-----
> > From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of Jason
> > Riedy
> > Sent: Thursday, July 12, 2007 11:00 AM
> > To: Malcolm Cohen
> > Cc: stds-754@xxxxxxxx
> > Subject: Re: Clause 10, Expression Evaluation
> >
> >
> > And Guillaume Melquiond writes:
> > > In some languages, they are called polymorphic functions.
> >
> > And Malcolm Cohen writes:
> > > Bah humbug.  Not in any sensible language they're not.
> >
> > And that example demonstrates one reason why I stopped working on
> > this.
> >
> > There are too many vocal camps that swear their terminology is
> > the *only* reasonable one.  There's no way a standard will be
> > accepted if it chooses one of the terminologies over the others
> > or even if it invents its own.  And then convincing all the
> > hardware people to think of providing tools for languages/users
> > rather than providing "an implementation" that ends their
> > responsibility ain't easy.
> >
> > The language interface needs to be at the level of formal
> > semantics.  Getting that provably correct, clearly expressed, and
> > widely acceptable requires more time than is (or was) available.
> > It's all possible, and many parts are "too easy" to be considered
> > research from the language side.
> >
> > It's not time yet to standardize the language interface, alas.
> > A little more research&implementation, then the hard part:
> > political buy-in from some well-respected folks in language and
> > hardware communities.
> >
> > Jason