character literals

character literals

[agent]

I have been having a difficulty in my code with character literals.
For example

 IF ch in '0' .. '9' THEN

This gives an error because the compiler is complaining that it does
not know if I mean a character, wide_character, or wide_wide_character
for my literals.  How do I indicate which I want?

Re: character literals

[J-P. Rosen]

Le 11/02/2014 23:27, agent@drrob1.com a écrit :
> I have been having a difficulty in my code with character literals.
> For example
> 
>  IF ch in '0' .. '9' THEN
> 
> This gives an error because the compiler is complaining that it does
> not know if I mean a character, wide_character, or wide_wide_character
> for my literals.  How do I indicate which I want?
> 
if Ch in Character range '0' .. '9' then

Ada recognizes types by name. There are a few cases (like this one)
where the designers tried to save some typing by allowing the type to be
inferred from the values; it is almost always a bad idea, and it is
always possible to state the type explicitely.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: character literals

[Bill Findlay]

"J-P. Rosen" <rosen@adalog.fr> wrote:
> Le 11/02/2014 23:27, agent@drrob1.com a écrit :
>> I have been having a difficulty in my code with character literals.
>> For example
>> 
>>  IF ch in '0' .. '9' THEN
>> 
>> This gives an error because the compiler is complaining that it does
>> not know if I mean a character, wide_character, or wide_wide_character
>> for my literals.  How do I indicate which I want?
>> 
> if Ch in Character range '0' .. '9' then
> 
> Ada recognizes types by name. There are a few cases (like this one)
> where the designers tried to save some typing by allowing the type to be
> inferred from the values; it is almost always a bad idea, and it is
> always possible to state the type explicitely.

Why is the literal type not inferred from the type of Ch in this case?

-- 
Bill Findlay

Re: character literals

[Ludovic Brenta]

Bill Findlay writes on comp.lang.ada:
> "J-P. Rosen" wrote:
>> Le 11/02/2014 23:27, agent@drrob1.com a écrit :
>>> I have been having a difficulty in my code with character literals.
>>> For example
>>> 
>>>  IF ch in '0' .. '9' THEN
>>> 
>>> This gives an error because the compiler is complaining that it does
>>> not know if I mean a character, wide_character, or wide_wide_character
>>> for my literals.  How do I indicate which I want?
>>> 
>> if Ch in Character range '0' .. '9' then
>> 
>> Ada recognizes types by name. There are a few cases (like this one)
>> where the designers tried to save some typing by allowing the type to be
>> inferred from the values; it is almost always a bad idea, and it is
>> always possible to state the type explicitely.
>
> Why is the literal type not inferred from the type of Ch in this case?

Because it's the other way around :) the type of Ch is inferred from the
type of the range.

-- 
Ludovic Brenta.

Re: character literals

[adambeneschan]

On Tuesday, February 11, 2014 3:49:06 PM UTC-8, Ludovic Brenta wrote:

> >> if Ch in Character range '0' .. '9' then

> > Why is the literal type not inferred from the type of Ch in this case?

> Because it's the other way around :) the type of Ch is inferred from the
> type of the range.

No, the type of Ch is inferred from the declaration of Ch, wherever that happens.  You didn't read "if" as "for", did you??

                         -- Adam

Re: character literals

[adambeneschan]

On Tuesday, February 11, 2014 2:27:57 PM UTC-8, ag...@drrob1.com wrote:
> I have been having a difficulty in my code with character literals.
> 
> For example
> 
>  IF ch in '0' .. '9' THEN
> 
> This gives an error because the compiler is complaining that it does
> not know if I mean a character, wide_character, or wide_wide_character
> for my literals.  How do I indicate which I want?

I don't think your compiler should not be giving an "ambiguous" error on the above IF statement.  The literals '0' and '9' are indeed ambiguous, because they are actually overloaded functions that could return Character, Wide_Character, or Wide_Wide_Character, or possibly one or more user-defined enumeration types; however, assuming "ch" is a variable, it will have a known type, and I think that type can be used to resolve the types of the overloaded range.  However, on checking the language rules, it's not 100% clear to me that that's the case.  Neither compiler I tried this on reports an error, though.

This is different, though:

    for Ch in '0' .. '9' loop

because this loop statement *is* the declaration of Ch, so the compiler has to be able to resolve the type just from the literals '0' and '9', and it can't.  However, this is legal:

    Start_Ch : Character;

    for Ch in Start_Ch .. '9' loop

because now although '9' is ambiguous, the language will use the type of Start_Ch to resolve the type of '9'.  I don't think it's necessary (even from a style standpoint) to include the type name in the "for" statement; others may differ.

The first "loop" statement, which is ambiguous, was legal in Ada 83, when there was only one character type; when Wide_Character was added to Ada 95 [Wide_Wide_Character wasn't added until Ada 2005], this became illegal, which caused some compatibility headaches for existing code.  

Also:

    type Traffic_Light is (Red, Yellow, Green);
    type RGB is (Red, Green, Blue);

    for Color in Red .. Green loop    -- ambiguous, illegal
    for Color in Green .. Blue loop   -- legal, since there is only one meaning
                                      -- of Blue

However, I'd definitely recommend including the type name in a case like this.

    for Color in RGB range Green .. Blue loop

Finally, the language does have one special rule:

    for I in 0 .. 9 loop

The literals 0 and 9 could be resolved to any integer type, which would make this ambiguous since there are normally multiple integer types visible in the program (Integer, Long_Integer, Short_Integer, maybe types in Interfaces if you "use" that packaged).  But the language rules decree that the type will be Integer in that case.  This is a situation where some programmers might recommend making the type Integer explicit.

                                -- Adam

Re: character literals

[adambeneschan]

On Tuesday, February 11, 2014 3:56:52 PM UTC-8, I wrote:

>>> IF ch in '0' .. '9' THEN

> I don't think your compiler should not be giving an "ambiguous" error on the above IF statement.  The literals '0' and '9' are indeed ambiguous, because they are actually overloaded functions that could return Character, Wide_Character, or Wide_Wide_Character, or possibly one or more user-defined enumeration types; however, assuming "ch" is a variable, it will have a known type, and I think that type can be used to resolve the types of the overloaded range.  However, on checking the language rules, it's not 100% clear to me that that's the case.  Neither compiler I tried this on reports an error, though.

After taking another look at the rules, I'm convinced that this IF statement is indeed legal.

                              -- Adam

Re: character literals

[agent]

On Tue, 11 Feb 2014 16:18:36 -0800 (PST), adambeneschan@gmail.com
wrote:

>On Tuesday, February 11, 2014 3:56:52 PM UTC-8, I wrote:
>
>>>> IF ch in '0' .. '9' THEN
>
>> I don't think your compiler should not be giving an "ambiguous" error on the above IF statement.  The literals '0' and '9' are indeed ambiguous, because they are actually overloaded functions that could return Character, Wide_Character, or Wide_Wide_Character, or possibly one or more user-defined enumeration types; however, assuming "ch" is a variable, it will have a known type, and I think that type can be used to resolve the types of the overloaded range.  However, on checking the language rules, it's not 100% clear to me that that's the case.  Neither compiler I tried this on reports an error, though.
>
>After taking another look at the rules, I'm convinced that this IF statement is indeed legal.
>
>                              -- Adam

It is a For statement that caused the compiler to complain.  I fixed
this by declaring 
chardgt0 : constant Character := '0';
chardgt9 : constant character := '9';


But now I don't know why this function is failing.  I want to convert
a character value to its integer value.  Modula-2 used the built-in
function ORD for this purpose.

This fails type checking
  I := Natural'Value(CH);
    -- assume I is natural and ch is character

So I tried this
 s: string(1..1);
 s(1) := ch;
I := Natural'Value(s);

This fails saying Constraint_Error explicit raise

I don't get it

Re: character literals

[adambeneschan]

On Tuesday, February 11, 2014 5:34:20 PM UTC-8, ag...@drrob1.com wrote:

> But now I don't know why this function is failing.  I want to convert
> a character value to its integer value.  Modula-2 used the built-in
> function ORD for this purpose.
> 
> This fails type checking
> 
>   I := Natural'Value(CH);

To get the ORD of a character:

    I := Character'Pos (Ch);   
        -- short for "position", i.e. the position of the character literal in        
        -- the list of enumeration literals, which for Character is just the
        -- list of all 256 Extended ASCII characters in order

If Ch is '0', then I will be 48 (the ASCII value of the character '0').

To go the other way:

    Ch := Character'Val (I);

Natural'Value does something completely different.  It takes a string, parses it, and expects the result to be a "Natural".  It raises an exception if the string doesn't have the right format for a "Natural" or is an integer that's out of range.  

In your code, Natural'Value should work fine if Ch is in the range '0' .. '9', because then S will be a validly formatted Natural.  The result will be in the range 0 to 9, not 48 to 57 as Character'Pos (and I think ORD) would give you.  (I don't know Modula-2, but ORD would return 48..57 in Pascal.)  If Ch is something outside that range, then Natural'Value will raise Constraint_Error.  If you think Ch is really in the range '0' .. '9', but you're still getting Constraint_Error on the Natural'Value call, then I'd need to see more of the code.

                                -- Adam

Re: character literals

[agent]

On Tue, 11 Feb 2014 18:03:18 -0800 (PST), adambeneschan@gmail.com
wrote:

>On Tuesday, February 11, 2014 5:34:20 PM UTC-8, ag...@drrob1.com wrote:
>
>> But now I don't know why this function is failing.  I want to convert
>> a character value to its integer value.  Modula-2 used the built-in
>> function ORD for this purpose.
>> 
>> This fails type checking
>> 
>>   I := Natural'Value(CH);
>
>To get the ORD of a character:
>
>    I := Character'Pos (Ch);   
>        -- short for "position", i.e. the position of the character literal in        
>        -- the list of enumeration literals, which for Character is just the
>        -- list of all 256 Extended ASCII characters in order
>
>If Ch is '0', then I will be 48 (the ASCII value of the character '0').
>
>To go the other way:
>
>    Ch := Character'Val (I);
>
>Natural'Value does something completely different.  It takes a string, parses it, and expects the result to be a "Natural".  It raises an exception if the string doesn't have the right format for a "Natural" or is an integer that's out of range.  
>
>In your code, Natural'Value should work fine if Ch is in the range '0' .. '9', because then S will be a validly formatted Natural.  The result will be in the range 0 to 9, not 48 to 57 as Character'Pos (and I think ORD) would give you.  (I don't know Modula-2, but ORD would return 48..57 in Pascal.)  If Ch is something outside that range, then Natural'Value will raise Constraint_Error.  If you think Ch is really in the range '0' .. '9', but you're still getting Constraint_Error on the Natural'Value call, then I'd need to see more of the code.
>
>                                -- Adam

Thanks, that clears it up for me.

Re: character literals

[Jeffrey Carter]

On 02/11/2014 04:56 PM, adambeneschan@gmail.com wrote:
>
> The first "loop" statement, which is ambiguous, was legal in Ada 83, when
> there was only one character type; when Wide_Character was added to Ada 95
> [Wide_Wide_Character wasn't added until Ada 2005], this became illegal, which
> caused some compatibility headaches for existing code.

Nonsense. Ada 83 had user-defined character types. ARM-83 3.5.2 ("Character 
Types") includes the declaration of character type Roman_Digit.

-- 
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89

Re: character literals

[adambeneschan]

On Tuesday, February 11, 2014 5:30:22 PM UTC-8, Jeffrey Carter wrote:
> On 02/11/2014 04:56 PM, Adam Beneschan wrote:
> 
> >
> 
> > The first "loop" statement, which is ambiguous, was legal in Ada 83, when
> > there was only one character type; when Wide_Character was added to Ada 95
> > [Wide_Wide_Character wasn't added until Ada 2005], this became illegal, which
> > caused some compatibility headaches for existing code.
> 
> Nonsense. Ada 83 had user-defined character types. ARM-83 3.5.2 ("Character 
> Types") includes the declaration of character type Roman_Digit.

But '0' and '9' aren't ROMAN_DIGITs, so those wouldn't have made the loop illegal, right?  

OK, technically, you're right, that the loop *might* *not* be legal if there were a visible user-defined enumeration type that included '0' and '9'.  In practice, that would have been extremely uncommon, I think.  (I don't believe I've *ever* seen a user-defined character type in production code.)  We had a lot of Ada 83 code with legal loops like this, and they became illegal with Ada 95, so that part isn't nonsense.
   
                              -- Adam

Re: character literals

[Robert A Duff]

adambeneschan@gmail.com writes:

> On Tuesday, February 11, 2014 2:27:57 PM UTC-8, ag...@drrob1.com wrote:
>> I have been having a difficulty in my code with character literals.
>> 
>> For example
>> 
>>  IF ch in '0' .. '9' THEN

Note to OP:  If you have questions about an error message, it's best to
cut&paste the exact complete compilable code that caused the error,
along with the exact text of the error message.

The above is legal given the right declaration of ch, but you
didn't show that; there are all sorts of reasons the above could
be illegal.

Also look at Ada.Characters.Handling.  You can call the Is_Digit function.

> Finally, the language does have one special rule:
>
>     for I in 0 .. 9 loop
>
> The literals 0 and 9 could be resolved to any integer type, which
> would make this ambiguous since there are normally multiple integer
> types visible in the program (Integer, Long_Integer, Short_Integer,
> maybe types in Interfaces if you "use" that packaged).  But the
> language rules decree that the type will be Integer in that case.
> This is a situation where some programmers might recommend making the
> type Integer explicit.

Like me.  I think the special-case for Integer is a kludge, so I
would write:

    for I in Some_Type range 0 .. 9 loop

One exception:  If I want to say "do this 5 times", I might write:

    for I in 1 .. 5 loop

and there are no references to I in the loop, so its type is irrelevant.

On the other hand, if the type is clear from the bounds, as in

    for I in 1 .. Some_Array'Last - 1 loop

I wouldn't put the type in.

- Bob

Re: character literals

[J-P. Rosen]

Le 12/02/2014 16:53, Robert A Duff a écrit :
>> This is a situation where some programmers might recommend making the
>> > type Integer explicit.
> Like me.  I think the special-case for Integer is a kludge, so I
> would write:
> 
>     for I in Some_Type range 0 .. 9 loop
<shameless_plug> and this can be enforced by AdaControl with the rule:
check statements (untyped_for);
</shameless_plug>

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: character literals

[agent]

On Wed, 12 Feb 2014 18:55:26 +0100, "J-P. Rosen" <rosen@adalog.fr>
wrote:

>Le 12/02/2014 16:53, Robert A Duff a écrit :
>>> This is a situation where some programmers might recommend making the
>>> > type Integer explicit.
>> Like me.  I think the special-case for Integer is a kludge, so I
>> would write:
>> 
>>     for I in Some_Type range 0 .. 9 loop
><shameless_plug> and this can be enforced by AdaControl with the rule:
>check statements (untyped_for);
></shameless_plug>


I'll bite.  What's AdaControl

AdaControl was: Re: character literals

[Simon Clubley]

On 2014-02-14, agent@drrob1.com <agent@drrob1.com> wrote:
> On Wed, 12 Feb 2014 18:55:26 +0100, "J-P. Rosen" <rosen@adalog.fr>
> wrote:
>><shameless_plug> and this can be enforced by AdaControl with the rule:
>>check statements (untyped_for);
>></shameless_plug>
>
>
> I'll bite.  What's AdaControl

A Google search would have revealed:

	http://en.wikipedia.org/wiki/AdaControl

Happy reading. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: character literals

[J-P. Rosen]

Le 14/02/2014 13:39, agent@drrob1.com a écrit :
> On Wed, 12 Feb 2014 18:55:26 +0100, "J-P. Rosen" <rosen@adalog.fr>
> wrote:
> 
>> Le 12/02/2014 16:53, Robert A Duff a écrit :
>>>> This is a situation where some programmers might recommend making the
>>>>> type Integer explicit.
>>> Like me.  I think the special-case for Integer is a kludge, so I
>>> would write:
>>>
>>>     for I in Some_Type range 0 .. 9 loop
>> <shameless_plug> and this can be enforced by AdaControl with the rule:
>> check statements (untyped_for);
>> </shameless_plug>
> 
> 
> I'll bite.  What's AdaControl
> 
It's a tool that can check coding rules, or more generally help you find
many things when doing code analysis.
See http://www.adalog.fr/adacontrol2.htm

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr