Prev: FYI -- Lunar lander project relies on SPARK programming language
Next: Simple hack to get $500 to your home
From: BrianG on 14 Jun 2010 22:24
Maciej Sobczak wrote:
>>> Or is there somewhere a public list of such incompatibilities?
>> What incompatibilities, incompatible with what?
>
> With Short_Short_Integer, of course.
>
> I will take the opportunity to extend my question: is there a
> "compatibility list" for Ada compilers with regard to all language
> features that are described as optional? Not just Short_Short_Integer,
> but also Long_Long_Integer (just joking :-) ), pragmas, annexes, etc.?
>
> --
> Maciej Sobczak * http://www.inspirel.com
>
> YAMI4 - Messaging Solution for Distributed Systems
> http://www.inspirel.com/yami4

Let me try to make my point again, since you conveniently cut out my
reference to the actual language definition you're discussing.

What makes Short_Short_Integer an "optional" part of the language? Just
because the RM mentions it as an example of types an implementation
"may" provide (as "names of the form")? Should implementations that
provide no "nonstandard integer types" also be listed in your
"compatibility list", since they are also a "may provide"?

How many Ada compilers implement "type Day is (Mon, Tue, Wed, Thu, Fri,
Sat, Sun);" listed in 3.5.1(14)?

BTW, what you're asking for (see M (13)) is required to be documented
for each compiler (e.g. in the GNAT RM 4(13)). My original point is
that I've never heard of anyone compiling that for all compilers
(whatever "all" means - how could you prove the non-existence of
others?). If you could come up with what you would consider a useful
definition of "all" compilers, and you had the documentation for each
(which I presume might require a license in some cases), this shouldn't
be difficult to compile. But what's the point?
Standard.Short_Short_Integer gains you nothing you can't get by defining
your own.

(Which brings up another question: What is your "compatible" definition
of Short_Short_Integer? There's nothing in the wording that mandates it
be 8 bits.)

--Half the world cries
-- Half the world laughs
--Half the world tries
-- To be the other half
From: Martin Krischik on 15 Jun 2010 00:54
Am 14.06.2010, 18:45 Uhr, schrieb Keith Thompson <kst-u(a)mib.org>:

> Not all Ada compilers implement Short_Short_Integer, but all Ada
> compilers do implement:
> type My_Type is range -128 .. 127;

for My_Type'Size use 8;

otherwise you type might not be as short as you think it is.

Martin
--
Martin Krischik
mailto://krischik(a)users.sourceforge.net
https://sourceforge.net/users/krischik
From: Maciej Sobczak on 15 Jun 2010 17:21
On 15 Cze, 04:24, BrianG <briang...(a)gmail.com> wrote:

> Let me try to make my point again, since you conveniently cut out my
> reference to the actual language definition you're discussing.

I have conveniently cut it out as it was not convincing.
Now let's have that spelled out explicitly.

> What makes Short_Short_Integer an "optional" part of the language?

AARM.

> Just
> because the RM mentions it as an example of types an implementation
> "may" provide

Well, that's my understanding of the word "may" -> it's optional.

> Should implementations that
> provide no "nonstandard integer types" also be listed in your
> "compatibility list", since they are also a "may provide"?

The implementations can be divided into two groups: those that provide
this type and those that don't. Is it that difficult to document?

> How many Ada compilers implement "type Day is (Mon, Tue, Wed, Thu, Fri,
> Sat, Sun);" listed in 3.5.1(14)?

Again not convincing - this point is in the "Examples" part, which
explains possible uses of the language and not what is provided by
language implementations.

> BTW, what you're asking for (see M (13)) is required to be documented
> for each compiler

Excellent - that just makes it easier to compile a compatibility list.

> My original point is
> that I've never heard of anyone compiling that for all compilers

That's an exact answer to my question.

> (whatever "all" means -  how could you prove the non-existence of
> others?).

Excellent point - what about making the list open for additional
entries? Like, you know, a wiki page instead of carving something in
stone?
The C++ community could do that, no?

> If you could come up with what you would consider a useful
> definition of "all" compilers,

Like, you know, this one:

http://en.wikibooks.org/wiki/Ada_Programming/Installing

Looks like a reasonable list for me.

> But what's the point?

There is a parallel discussion about making the web content more
attractive and friendly for Ada newcomers. Sounds like a valid point
to me.

> Standard.Short_Short_Integer gains you nothing you can't get by defining
> your own.

Why not correcting the AARM to express this in the first place?

> (Which brings up another question:  What is your "compatible" definition
> of Short_Short_Integer?  There's nothing in the wording that mandates it
> be 8 bits.)

Excellent - what about providing additional information to the
"compatibility list" about what are the actual implementation choices?


In short - I think you are getting too hot for no reason.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4
From: Georg Bauhaus on 15 Jun 2010 19:39
On 6/15/10 11:21 PM, Maciej Sobczak wrote:



> In short - I think you are getting too hot for no reason.

Might it not be tempting to get a little hot because the Implementation
Permission integer types seem to have the same characteristics
as the row of C int types?
Few programmers can handle these.
The CVE around libc/strfmon in May is another fine example of that.
But newcomers will start using just familiar types if they are there,
don't you think?
From: BrianG on 15 Jun 2010 21:27
Maciej Sobczak wrote:
> On 15 Cze, 04:24, BrianG <briang...(a)gmail.com> wrote:
>
>> Let me try to make my point again, since you conveniently cut out my
>> reference to the actual language definition you're discussing.
>
> I have conveniently cut it out as it was not convincing.
> Now let's have that spelled out explicitly.

Um, ok, but I'm not sure why:

"An implementation may provide additional predefined signed integer
types, declared in the visible part of Standard, whose first subtypes
have names of the form Short_Integer, Long_Integer, Short_Short_Integer,
Long_Long_Integer, etc."

I take the "of the form" and ", etc." as meaning these are examples of a
sequence.
Shouldn't we also consider Short_Short_Short_Short_Short_Integer? (I
assume this would "normally" equate to 1 bit; what's the required range?
- I think it would have to be -1..0 to meet the "standard integer type"
rules. :-)

(That may not be what you meant. ;-) No offense intended.
>
>> Should implementations that
>> provide no "nonstandard integer types" also be listed in your
>> "compatibility list", since they are also a "may provide"?
>
> The implementations can be divided into two groups: those that provide
> this type and those that don't. Is it that difficult to document?
>
So, this one type is the only "incompatibility" you want in your "list"?
That seems of extremely limited use. I could understand compiling all
of the Annex M stuff for a set of implementations, or even all of the
'optional' types, but not one piece.

>
>> My original point is
>> that I've never heard of anyone compiling that for all compilers
>
> That's an exact answer to my question.
>
As long as you understand that this is but one data point (and a small
one at that:-).

>> (whatever "all" means - how could you prove the non-existence of
>> others?).
>
> Excellent point - what about making the list open for additional
> entries? Like, you know, a wiki page instead of carving something in
> stone?
> The C++ community could do that, no?
They'd do that for Ada? Wow! :-):-)
For the Ada community, it just takes one person who cares about the
issue and who cares to start the list. (That's not me. I don't use
these types and wouldn't use that name in any case. It has no meaning
to me.)

>
> In short - I think you are getting too hot for no reason.
I haven't been the slightest bit hot (or even particularly warm) about
this topic. (Driving home today, that's different - the heat index was
around 115, the car was probably 140+ (F).)
My comment was simply questioning your use of the word "incompatibility"
in this context. You haven't provided anything that is convincing in
that regard.

I don't think that it is incompatible to fail to provide something
that's not required. We apparently have different definitions of the
word. Se la vie.


--The whole wide world
-- An endless universe
--Yet we keep looking through
-- The eyeglass in reverse
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: FYI -- Lunar lander project relies on SPARK programming language
Next: Simple hack to get $500 to your home