Re: Built-in types (was Re: How can I avoid Using a Semaphore?

[mark_lundquist@my-deja.com]

In article <94g3tf$gb9$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <94fv9d$cjt$1@nnrp1.deja.com>,
>   mark_lundquist@my-deja.com wrote:
> >
> > When a careful Ada programmer writes 'Integer', he's saying
> > that he understands the things about Integer that are
> > implementation-defined and that those things are "don't
> > cares" for him in this instance.  It's not careless to say
> > that and mean it.
>
> It is never actively *useful* to be able to do this, since
> you certainly have *some* requirements on any type you supply,
> and you may as well make them explicit.

Couldn't it be that my only requirement is that this be (using the
example of integer types) the "whatever integer"?  If that's my only
requirement, then I'm being explicit about it when I write "Integer",
because that's what Integer is supposed to be -- the "whatever
integer".  Anything else that I might specify is in fact *not* a
requirement for me.

(Let's see, just for integer types, what can the programmer specify?
There's base range, size, alignment, stream I/O attributes... anything
else?)

>
> The trouble is that 90% of programmers writing Integer
> explicitly do NOT know what they are saying, and make a mess.
> That is why most coding standards wisely suggest not using
> type Integer.

Well that's just it... it seems like if the programmer is sharp enough
to specify all this stuff, then he also ought to be sharp enough to
know when he means the "whatever" types and to use them when that's
what he means.

I suppose if it were a choice between the programmer blindly using
Integer for everything (considerations of scalar abstraction aside),
and blindly specifying everything because a style guide told him to do
so, then I guess I'd prefer the latter (but not by much; see below...)
However, that is a truly bonehead operating level and if these were
really the only alternatives I doubt I'd want that programmer writing
code for anything I cared about! :-)  I mean, if you're going to go to
the trouble to make a style guide that tells them to specify down to
the gn@t'$ @$$ whether they depend on it or not, and expect them to
follow it, then is it really that hard to teach them what Integer
means?  Then give advice with some substance, like "don't write a
record component of type Integer if you're going to apply a
representation clause" -- in which case you know your code will still
compile if it's ported to another platform.  You may or may not care
about slightly different behavior, but you do care that it compile! :-)

Is it OK to use the predefined Float type? :-) Suppose I nail down the
precision and/or range to something I think makes sense for a
particular architecture... might that not result in less-than-optimal
performance if my code is ported to joe random architecture?  So that's
the whole point of having the "whatever" types.  You need to be able to
say "whatever".  The issue is that people know when they're
saying "whatever" and that they don't say it when they don't mean it.

There was a thread here last year, in which someone was lamenting that
Ada's integer types were not as "portable" as Java's because the
language doesn't nail standardize the sizes/ranges.  I argued that (a)
there are different kinds of portability, and (b) of the two kinds
relevant to the argument, Java provides one, and Ada provides both, but
that (c) the objector was looking in the wrong place in Ada for the
Java-style portable integer types -- the right place is not the
Standard integer types but the ones in package Interfaces.  Once again,
you want to be able to say "whatever".

Now, I do have a beef with overspecification, because it obscures.  I'm
always looking for communication of design intent.  So if I see an
integer type declared, and there's no abstraction involved, and we're
nailing down the size, then I say "OK, what intent is being captured
here -- where are the bits that depend on this?"  It's quite annoying
when the answer is "Nothing really depends on it, we just specified
because it's bad not to specify everything".

> There are some exceptions, e.g. as the subscript
> of the standard type String, and you cannot get away from this
> built in type, because of library usage.
>
> P.S. Jean Ichbiah feels it was a bad mistake to have had the
> type Standard.String depend on Integer in this way, but it was
> too late to change.

Changing the subject, speaking of strings... it seems a little
unfortunate that Ada95 has 3 kinds of strings (not counting the
dimension of standard vs. wide), all with essentially the same
interface, and no abstraction of that interface.  As a result, generic
programming across the string types doesn't come naturally, although I
guess this can be more-or-less fixed outside the language with wrapper
classes.

Best Regards,
mark




Sent via Deja.com
http://www.deja.com/