Re: why not

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Darren New" <dnew@san.rr.com> wrote in message
news:3BDEF0FE.B55FED9E@san.rr.com...
> Marin David Condic wrote:
> > Part of the problem is
> > specifying the behavior in sufficient detail to make it verifiable.
>
> That's what ADTs are supposed to be for. (Not ADT's in the computer
> programming sense. ADTs in the "Abstract Data Type" sense, the
> mathematical sense.)
>
> It's not hard. It's just that most programmers think ADTs have (say)
> implementations and such.
>

Perhaps. But not all things in the known universe are ADTs. Some TBD
collection of utilities to be added to Ada might be useful, but not
mathematically verifiable, or at all simple to write a detailed enough
standard for that it can be readily verified by some means. (Think for
example what it might mean if part of your collection of tools were to
connect up to the OS for some kinds of services? OS Services might vary
enough that it would be difficult to demonstrate that you are in compliance
with the spirit and/or letter of the law.) I'm not saying it can't be done.
Look over Ada.Strings... - it has a reasonably detailed description that can
apparently be verified. But getting to that point might not be a simple
matter.

Its an objection I have heard here from vendors in the past. It might be
some disguised version of "That's a lot of work and I don't want to spend
time and company resources doing that...", but if it is objected to for any
reason, it isn't going to make it into an implementation. Hence, you need
some kind of buy-in from the implementors.

> > There is
> > also a certain amount of inflexibility once it gets into the standard.
>
> I thought that was the point, yes? Inflexible == you can rely on it not
> changing?
>
Yes, but..... Until you have a collection of code (or at least interfaces)
that have maybe built up some experience with usability, you aren't sure if
this is quite what the world wants. While extensions might be easily cobbled
in by the casual coder (extending the packages, changing the interfaces,
etc...) its kind of hard to go back to the standard and say "See that
chapter? Let's gut it and start over..." I think until you have a collection
of stuff that has a little bit of practical usage behind it, it might be
best to avoid enshrining it in a standard where changes are really hard to
make.

Like I said, I'm not against the idea of it worming its way into an annex in
the fullness of time, but I think it would be a good idea to build up some
informal semi-standard first just to let it have a little time to evolve.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/