Re: why not

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

Hypothetically speaking, you could take a library of utilities, specs *and*
bodies, and tack them onto the ARM and say "The following source code shall
be provided as part of the implementation of Ada..." and that pretty much
takes care of any sort of verification.  There are obvious problems with
this - such as not guaranteeing that any of it works at all and not
stipulating what sort of results should come out of it, but it *is* a kind
of standard.

If you look at the standard libraries of functions that come with ANSI C,
you notice that they aren't horribly well thought out and the definitions
are not terribly mathematically precise, but they *are* useful and they
generally *do* function as expected across a variety of implementations. It
got that way because implementations of C started sharing common libraries
of source code that gradually became accepted as being part of the
language - even though they weren't really part of "Standard C". One
compiler is out there with library source available. Other compiler projects
picked up on the libraries and either duplicated them or licensed them or
otherwise started sharing what was there. Pretty soon, everyone just expects
"strchr" and "malloc" and such to be there, just because every
implementation has them. ANSI C comes out and - Bam! - its been kicked up a
notch by requiring a set of standard libraries. Ada might be able to do the
same thing - albeit with a bit more rigor than we are used to seeing with C.

Assuming something is agreed upon as a desirable set of packages and some
implementation is available under favorable license terms and compiler
vendors start bundling it with their compiler, I don't see anything wrong
with saying "See that implementation over there? That constitutes the
standard..."

Of course I don't believe it has to be part of the ARM at all. I think it
would be just as useful and acceptable if there *was* an implementation that
was commonly included with most compilers. Maybe it should be driven by the
grass roots and maybe it should be driven by the vendors, but I don't think
it needs to start with the ARM.

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/


"Darren New" <dnew@san.rr.com> wrote in message
news:3BE05304.5AB6862D@san.rr.com...
> > > No question. But then it's harder to precisely specify what the
behavior
> > > is without saying "it behaves like this implementation."
> >
> > You need to specify time and space semantics for any abstraction.  This
is a
> > solved problem.
>
> Right. It seems like you've misunderstood what I was trying to say. I
> was simply saying that trying to specify the time, space, and result
> semantics of the Booch components would be pointless if you can just
> point at the implementation and say "do this." If you're going to make a
> more abstract interface that can be implemented in a variety of ways,
> it's easier to specify the time, space, and semantics of the operations
> on a more simple interface than it is to try to deduce them from an
> existant implementation as complex as Booch.
>