Easy question about Character manipulation

Easy question about Character manipulation

[mark]

Hello,

I am quite newbie to ada. I have declared something like that:
size: Integer := 9;
emptySpaces : array (0..size) of Character := "0123456789";
textLine : array (0..size * 3) of Character;

Now I would like to have the possibility to initialize textLine 
variable, but when I write:
textLine := "9876543210" & emptySpaces & "9876543210";

I got an error 'expected type of textLine' ,'found type od 
emptySpacs...'. I know it is connected with very deep contstaint 
checks but have no idea how I could avoid that. Could you tell me how 
can I make it work?!?

Thank you very much, Mark

Re: Easy question about Character manipulation

[Dmitry A. Kazakov]

On 29 Jan 2007 12:01:00 -0800, mark wrote:

> I am quite newbie to ada. I have declared something like that:
> size: Integer := 9;
> emptySpaces : array (0..size) of Character := "0123456789";
> textLine : array (0..size * 3) of Character;

(must be (size+1)*3-1. Indexing from 0 is an evil thing, trust me! (:-))

> Now I would like to have the possibility to initialize textLine 
> variable, but when I write:
> textLine := "9876543210" & emptySpaces & "9876543210";
> 
> I got an error 'expected type of textLine' ,'found type od 
> emptySpacs...'. I know it is connected with very deep contstaint 
> checks

Yes, emptySpaces and textLine have different types.

> but have no idea how I could avoid that.

Why didn't you use:

   Empty_Spaces : String := "0123456789";
   Text_Line : String := "9876543210" & Empty_Spaces & "9876543210";

> Could you tell me how can I make it work?!?

Probably yes, if you tell us a bit more about the problem you are trying to
solve.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easy question about Character manipulation

[Georg Bauhaus]

On Mon, 2007-01-29 at 21:17 +0100, Dmitry A. Kazakov wrote:
> On 29 Jan 2007 12:01:00 -0800, mark wrote:
> 
> > I am quite newbie to ada. I have declared something like that:
> > size: Integer := 9;
> > emptySpaces : array (0..size) of Character := "0123456789";
> > textLine : array (0..size * 3) of Character;
> 
> (must be (size+1)*3-1. Indexing from 0 is an evil thing, trust me! (:-))
> 
> > Now I would like to have the possibility to initialize textLine 
> > variable, but when I write:
> > textLine := "9876543210" & emptySpaces & "9876543210";
> > 
> > I got an error 'expected type of textLine' ,'found type od 
> > emptySpacs...'. I know it is connected with very deep contstaint 
> > checks
> 
> Yes, emptySpaces and textLine have different types.

Yes, and these two different types are *anonymous* types.
This means, you have not given them (the types) a name. The
  array (...) of
both "look" like some array of characters, and they are.
But they are not the same array type because there is no
type name. (Only the object names "emptySpace" and "textLine".)

Unlike Pascal, for example, types in Ada are different when
they have different names. The types of emptySpace and
textLine have no names at all, being anonymous (unnamed)
array types. So they don't have the same name, so to speak.

Consider this

declare
   type My_Array is array (1 .. 10) of Character;
   type Your_Array is array (1 .. 10) of Character;
   x: My_Array;
   y: Your_Array;
begin
   x := y;
end;
   
This won't compile. Ada doesn't permit assignment for objects (x, y)
of different types (My_Array, Your_Array) even when they show the
same structure (array (1 .. 10) of Character)--but different names.

Re: Easy question about Character manipulation

[(see below)]

On 29/1/07 21:30, in article 1170106218.6329.63.camel@localhost, "Georg
Bauhaus" <bauhaus@arcor.de> wrote:
> Unlike Pascal, for example, types in Ada are different when
> they have different names.

On the contrary, this *exactly* like (ISO Standard) Pascal.
 
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Easy question about Character manipulation

[Georg Bauhaus]

On Tue, 2007-01-30 at 00:51 +0000, (see below) wrote:
> On 29/1/07 21:30, in article 1170106218.6329.63.camel@localhost, "Georg
> Bauhaus" <bauhaus@arcor.de> wrote:
> > Unlike Pascal, for example, types in Ada are different when
> > they have different names.
> 
> On the contrary, this *exactly* like (ISO Standard) Pascal.

I don't think so, if a Pascal compiler is supposed
to determine "the same type" (exact same type) by looking
at the definition, not the name. Otherwise two compilers
claiming to support ISO Pascal are broken:

program p;

type 
   T = 1 .. 3;
   S = 1 .. 3;
var
   x : T;
   y : S;
begin
   x := y;   { fine in Pascal }
end.

This program seems to be Standard Pascal, and compiles.
The corresponding Ada program will not compile:

procedure p is
   type T is range 1 .. 3;
   type S is range 1 .. 3;
   x : T;
   y : S
begin
   x := y; -- not the same type, compilation error
end;

Re: Easy question about Character manipulation

[(see below)]

On 30/1/07 01:43, in article 1170121405.6329.89.camel@localhost, "Georg
Bauhaus" <bauhaus@arcor.de> wrote:

>> On the contrary, this *exactly* like (ISO Standard) Pascal.
> 
> I don't think so, if a Pascal compiler is supposed
> to determine "the same type" (exact same type) by looking
> at the definition, not the name. Otherwise two compilers
> claiming to support ISO Pascal are broken:

Trust me, I was one of the team that wrote the standard. 8-)

> program p;
> 
> type 
>    T = 1 .. 3;
>    S = 1 .. 3;
> var
>    x : T;
>    y : S;
> begin
>    x := y;   { fine in Pascal }
> end.
> 
> This program seems to be Standard Pascal, and compiles.

This does not imply that S and T are considered to be the same type.
(See below.)

> The corresponding Ada program will not compile:
> 
> procedure p is
>    type T is range 1 .. 3;
>    type S is range 1 .. 3;
>    x : T;
>    y : S
> begin
>    x := y; -- not the same type, compilation error
> end;

This is not a matter of type equivalence,
it is a matter of automatic type conversion on assignment
(assignment compatibility), and that IS unlike Ada, of course.
 
It would work just as well in Pascal if S were 1..3 and T were 2..4,
and these are obviously not the same type.

(There are further classes of compatibility in other Pascal contexts.)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Easy question about Character manipulation

[Martin Krischik]

mark schrieb:
> Hello,
> 
> I am quite newbie to ada. I have declared something like that:

May is suggest:

http://en.wikibooks.org/wiki/Ada_Programming/Strings
http://en.wikibooks.org/wiki/Ada_Programming/Type_System

to you.

> size: Integer := 9;
> emptySpaces : array (0..size) of Character := "0123456789";
> textLine : array (0..size * 3) of Character;

It has been suggested before so let me emphasis: use

size: Integer := 10;
emptySpaces : array (1..size) of Character := "0123456789";
textLine : array (1..size * 3) of Character;

Martin

Re: Easy question about Character manipulation

[Jeffrey R. Carter]

Martin Krischik wrote:
> 
> It has been suggested before so let me emphasis: use
> 
> size: Integer := 10;

Let me emphasize:

Size : constant := 10;

There's no reason for Size to be an object, much less a variable.

-- 
Jeff Carter
"I soiled my armor, I was so scared."
Monty Python & the Holy Grail
71

Re: Easy question about Character manipulation

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 30/1/07 01:43, in article 1170121405.6329.89.camel@localhost, "Georg
> Bauhaus" <bauhaus@arcor.de> wrote:
>
>>> On the contrary, this *exactly* like (ISO Standard) Pascal.
>> 
>> I don't think so, if a Pascal compiler is supposed
>> to determine "the same type" (exact same type) by looking
>> at the definition, not the name. Otherwise two compilers
>> claiming to support ISO Pascal are broken:
>
> Trust me, I was one of the team that wrote the standard. 8-)

OK.  ;-)

>    T = 1 .. 3;
>    S = 1 .. 3;

> This is not a matter of type equivalence,
> it is a matter of automatic type conversion on assignment
> (assignment compatibility), and that IS unlike Ada, of course.

What about parameter passing?  I was under the impression that one can
pass something of type T to a parameter of type S, or a parameter of
type Integer, or vice versa, in Pascal.  Please correct me if I'm
wrong.

If I'm right on that point, then I claim that we're just arguing over
terminology: saying "so-and-so are different types, but there are all
kinds of implicit conversions" amounts to roughly the same thing as
"so-and-so are the same type".

The point is, if you say this in Ada:

    type T1 is range 1..10;
    type T2 is range 1..10;
    X : T1;
    Y : T2;

is there any equivalent in Pascal that causes "X := Y" to be illegal
(or similarly for parameter passing)?

- Bob

Re: Easy question about Character manipulation

[Robert A Duff]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Martin Krischik wrote:
>> It has been suggested before so let me emphasis: use
>> size: Integer := 10;
>
> Let me emphasize:
>
> Size : constant := 10;
>
> There's no reason for Size to be an object, much less a variable.

I agree that it should probably be constant, but why not give it a type,
as in:

    Size : constant Integer := 10;

I think named numbers are a kludge, and should usually be avoided.

And then we have:

> emptySpaces : array (1..size) of Character := "0123456789";
> textLine : array (1..size * 3) of Character;

If Size is a named number, the index type of these arrays defaults to
Integer -- another language kludge.

Of course, the original poster wanted plain old "String", so all this is
irrelevant to that question.

- Bob

Re: Easy question about Character manipulation

[(see below)]

Bob Duff asked:

>>    T = 1 .. 3;
>>    S = 1 .. 3;
> 
>> This is not a matter of type equivalence,
>> it is a matter of automatic type conversion on assignment
>> (assignment compatibility), and that IS unlike Ada, of course.
> 
> What about parameter passing?  I was under the impression that one can
> pass something of type T to a parameter of type S, or a parameter of
> type Integer, or vice versa, in Pascal.  Please correct me if I'm
> wrong.

It depends on whether they are value parameters or var (-iable) parameters.
Value parameters are in effect assigned their values,
and the permissive semantics of assignment compatibility apply;
var parameters must be of equivalent types, and type-equivalence in
ISO Pascal is name-equivalence.

Caveat, type B in:

   type B = A;

*is* name-equivalent to A when A is a type-identifier.
In Pascal this syntax is somewhat like:

   subtype B is A;

in Ada, whereas:

    type B = <type_definition>

is more like:

    type B is <type_definition>

in Ada.

> If I'm right on that point, then I claim that we're just arguing over
> terminology: saying "so-and-so are different types, but there are all
> kinds of implicit conversions" amounts to roughly the same thing as
> "so-and-so are the same type".

It is unfortunate that the examples being used are subranges,
because the assignment compatibility rules for subranges are
the most lax. This complexity in the semantics of Pascal
is necessary because it lacks the concept of a subtype, and
is forced to smuggle in something of the facility by rather
ad hoc special rules. So to a small extent your claim is valid.

One of the nicest things about Ada is how it cleared this mess up.

That said, there aren't "all kinds of implicit conversions",
Pascal isn't C or PL/1!

> The point is, if you say this in Ada:
> 
>     type T1 is range 1..10;
>     type T2 is range 1..10;
>     X : T1;
>     Y : T2;
> 
> is there any equivalent in Pascal that causes "X := Y" to be illegal
> (or similarly for parameter passing)?

For this example, in Pascal the assignment passes type-checking,
as would passing X to a formal value parameter of type T2,
and Y to a formal value parameter of type T1;
but X could only be passed to a formal var parameter of type T1, etc.

If instead we consider:

type T1 = record i : integer; end; {or an array, file or pointer type}
     T2 = record i : integer; end; {a type that is textually the same}
var  X : T1;
     Y : T2;

then X and Y are neither equivalent nor compatible.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Easy question about Character manipulation

[Dmitry A. Kazakov]

On Tue, 30 Jan 2007 15:18:34 -0500, Robert A Duff wrote:

[...]
> I claim that we're just arguing over
> terminology: saying "so-and-so are different types, but there are all
> kinds of implicit conversions" amounts to roughly the same thing as
> "so-and-so are the same type".

As for terminology, I'd propose to call the latter "subtypes" and the
former "unrelated types."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easy question about Character manipulation

[Dmitry A. Kazakov]

On Tue, 30 Jan 2007 15:24:45 -0500, Robert A Duff wrote:

> "Jeffrey R. Carter" <jrcarter@acm.org> writes:
> 
>> Let me emphasize:
>>
>> Size : constant := 10;
>>
>> There's no reason for Size to be an object, much less a variable.
> 
> I agree that it should probably be constant, but why not give it a type,
> as in:
> 
>     Size : constant Integer := 10;
> 
> I think named numbers are a kludge, and should usually be avoided.

I would agree if Universal_Integer were a proper type name. Integer tells
too much.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easy question about Character manipulation

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 30 Jan 2007 15:24:45 -0500, Robert A Duff wrote:
>
>> "Jeffrey R. Carter" <jrcarter@acm.org> writes:
>> 
>>> Let me emphasize:
>>>
>>> Size : constant := 10;
>>>
>>> There's no reason for Size to be an object, much less a variable.
>> 
>> I agree that it should probably be constant, but why not give it a type,
>> as in:
>> 
>>     Size : constant Integer := 10;
>> 
>> I think named numbers are a kludge, and should usually be avoided.
>
> I would agree if Universal_Integer were a proper type name. Integer tells
> too much.

Well, Universal_Integer is just Root_Integer'Class.  But I agree, they
should have names.  Actually, the name for Root_Integer should be
Integer.

And the name for Standard.Integer should be
Not_Standard_At_All.Machine_Integer.  ;-)

- Bob

Re: Easy question about Character manipulation

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> Bob Duff asked:
>
>>>    T = 1 .. 3;
>>>    S = 1 .. 3;
>> 
>>> This is not a matter of type equivalence,
>>> it is a matter of automatic type conversion on assignment
>>> (assignment compatibility), and that IS unlike Ada, of course.
>> 
>> What about parameter passing?  I was under the impression that one can
>> pass something of type T to a parameter of type S, or a parameter of
>> type Integer, or vice versa, in Pascal.  Please correct me if I'm
>> wrong.
>
> It depends on whether they are value parameters or var (-iable) parameters.

Interesting.  Most parameters are 'in' parameters in Ada, or value
parameters in Pascal.  But what's the story with 'var' parameters in
Pascal?  If we have:

    type T = 1..10;
    procedure P(X: var T);
    var A : 1..10;
    type S = 1..10;
    var B : S;
    var C : 1..12345;

is it legal to pass A, B, and/or C to P's X, in Pascal?

> Value parameters are in effect assigned their values,
> and the permissive semantics of assignment compatibility apply;
> var parameters must be of equivalent types, and type-equivalence in
> ISO Pascal is name-equivalence.

...which seems to say that B and C are illegal above.  That's a surprise
to me.

In case I get accused of being off-topic by discussing Pascal in an Ada
newsgroup: I note that 'in out' in Ada is roughly equivalent to 'var' in
Pascal, but 'in out' can be passed by copy, whereas Pascal requires pass
by reference (which has both good and bad points!).

> Caveat, type B in:
>
>    type B = A;
>
> *is* name-equivalent to A when A is a type-identifier.

...which means that "name equivalence" is a misnomer in Pascal, as it is
in Ada (with some types being anonymous in both languages).

> In Pascal this syntax is somewhat like:
>
>    subtype B is A;
>
> in Ada, whereas:
>
>     type B = <type_definition>
>
> is more like:
>
>     type B is <type_definition>
>
> in Ada.

True, except for implicit conversions.

>> If I'm right on that point, then I claim that we're just arguing over
>> terminology: saying "so-and-so are different types, but there are all
>> kinds of implicit conversions" amounts to roughly the same thing as
>> "so-and-so are the same type".
>
> It is unfortunate that the examples being used are subranges,
> because the assignment compatibility rules for subranges are
> the most lax. This complexity in the semantics of Pascal
> is necessary because it lacks the concept of a subtype, and
> is forced to smuggle in something of the facility by rather
> ad hoc special rules. So to a small extent your claim is valid.

That is, "small extent" means "true for integers, but not true for
records".  Right?

> One of the nicest things about Ada is how it cleared this mess up.

Right.  I think the Ada "subtype S is Integer range 1..10" is pretty
close to Pascal's "type S = 1..10", but Pascal has no rough equivalent
to Ada's "type T is range 1..10".  True?

> That said, there aren't "all kinds of implicit conversions",
> Pascal isn't C or PL/1!

Indeed!  I did not intend to impugn Pascal in that way.  I just meant to
say that there are different ways of defining semantics that amount to
the same thing.

>> The point is, if you say this in Ada:
>> 
>>     type T1 is range 1..10;
>>     type T2 is range 1..10;
>>     X : T1;
>>     Y : T2;
>> 
>> is there any equivalent in Pascal that causes "X := Y" to be illegal
>> (or similarly for parameter passing)?
>
> For this example, in Pascal the assignment passes type-checking,
> as would passing X to a formal value parameter of type T2,
> and Y to a formal value parameter of type T1;
> but X could only be passed to a formal var parameter of type T1, etc.
>
> If instead we consider:
>
> type T1 = record i : integer; end; {or an array, file or pointer type}
>      T2 = record i : integer; end; {a type that is textually the same}
> var  X : T1;
>      Y : T2;
>
> then X and Y are neither equivalent nor compatible.

Thanks for the clarification.

- Bob

Re: Easy question about Character manipulation

[(see below)]

On 30/1/07 22:05, in article wccwt346uhg.fsf@shell01.TheWorld.com, "Robert A
Duff" <bobduff@shell01.TheWorld.com> wrote:

>     type T = 1..10;
>     procedure P(X: var T);
>     var A : 1..10;
>     type S = 1..10;
>     var B : S;
>     var C : 1..12345;
> 
> is it legal to pass A, B, and/or C to P's X, in Pascal?
> 
>> Value parameters are in effect assigned their values,
>> and the permissive semantics of assignment compatibility apply;
>> var parameters must be of equivalent types, and type-equivalence in
>> ISO Pascal is name-equivalence.
> 
> ...which seems to say that B and C are illegal above.

Yes, and A as well.

>>> ...  I claim that we're just arguing over
>>> terminology: saying "so-and-so are different types, but there are all
>>> kinds of implicit conversions" amounts to roughly the same thing as
>>> "so-and-so are the same type".
>> 
>> It is unfortunate that the examples being used are subranges,
>> because the assignment compatibility rules for subranges are
>> the most lax. This complexity in the semantics of Pascal
>> is necessary because it lacks the concept of a subtype, and
>> is forced to smuggle in something of the facility by rather
>> ad hoc special rules. So to a small extent your claim is valid.
> 
> That is, "small extent" means "true for integers, but not true for
> records".  Right?

Not quite.
It is true for subranges of any discrete base type,
i.e. integer, char, boolean, user-defined enumerated types;
it is arguable for set types; and is definitely false for all other types.

>> One of the nicest things about Ada is how it cleared this mess up.
> 
> Right.  I think the Ada "subtype S is Integer range 1..10" is pretty
> close to Pascal's "type S = 1..10", but Pascal has no rough equivalent
> to Ada's "type T is range 1..10".  True?

Yes, because Pascal has no way of getting the equivalent of:

   type T is new ...;

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Easy question about Character manipulation

[Dmitry A. Kazakov]

On Tue, 30 Jan 2007 16:39:23 -0500, Robert A Duff wrote:

> Well, Universal_Integer is just Root_Integer'Class.  But I agree, they
> should have names.  Actually, the name for Root_Integer should be
> Integer.

Yes.

> And the name for Standard.Integer should be
> Not_Standard_At_All.Machine_Integer.  ;-)

Yes, it should be something like that, no smile.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easy question about Character manipulation

[Martin Krischik]

Robert A Duff schrieb:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 30 Jan 2007 15:24:45 -0500, Robert A Duff wrote:
>>
>>> "Jeffrey R. Carter" <jrcarter@acm.org> writes:
>>>
>>>> Let me emphasize:
>>>>
>>>> Size : constant := 10;
>>>>
>>>> There's no reason for Size to be an object, much less a variable.
>>> I agree that it should probably be constant, but why not give it a type,
>>> as in:
>>>
>>>     Size : constant Integer := 10;
>>>
>>> I think named numbers are a kludge, and should usually be avoided.
>> I would agree if Universal_Integer were a proper type name. Integer tells
>> too much.
> 
> Well, Universal_Integer is just Root_Integer'Class.  But I agree, they
> should have names.  Actually, the name for Root_Integer should be
> Integer.

You are aware that this would mean Integer'Size=64 for GNAT?

> And the name for Standard.Integer should be
> Not_Standard_At_All.Machine_Integer.  ;-)

Don't forget Standard.String_Index - or do you thing that a 64 bit 
string index has it's uses?

Martin

Re: Easy question about Character manipulation

[Georg Bauhaus]

On Tue, 2007-01-30 at 02:09 +0000, (see below) wrote:
> On 30/1/07 01:43, in article 1170121405.6329.89.camel@localhost, "Georg
> Bauhaus" <bauhaus@arcor.de> wrote:
> 
> >> On the contrary, this *exactly* like (ISO Standard) Pascal.
> > 
> > I don't think so, ...
> 
> Trust me, I was one of the team that wrote the standard. 8-)

OK. (I _had_ skimmed iso10206.txt at some point but not iso7185.txt.
Sorry ;-)
 
> It would work just as well in Pascal if S were 1..3 and T were 2..4,
> and these are obviously not the same type.

The "same type" phrase has been a bit puzzling because it is
used in the Pascal standard, but not defined (other than via
some indirections IIUC ...)
Reminds me of the Set-equality versus Set-equivalence
discussion that has just been going on here and by the ARG
but I'm not suggesting there is more that needs to be said about
"equivalent type" versus "same type" in Pascal. :)

> (There are further classes of compatibility in other Pascal contexts.)
> 

Re: Easy question about Character manipulation

[(see below)]

On 31/1/07 16:54, in article 1170262469.28280.8.camel@localhost, "Georg
Bauhaus" <bauhaus@futureapps.de> wrote:

> The "same type" phrase has been a bit puzzling because it is
> used in the Pascal standard, but not defined (other than via
> some indirections IIUC ...)
> Reminds me of the Set-equality versus Set-equivalence
> discussion that has just been going on here and by the ARG
> but I'm not suggesting there is more that needs to be said about
> "equivalent type" versus "same type" in Pascal. :)

Yes. I guess any logical structure must rest on some
basic terms that are taken not to need explanation,
and "same type" seems to fall into that category in ISO7185.

I've just realized that it is almost exactly 30 years since
we convened at the London HQ of the British Standards Institute
to begin the Pascal standardization process. Tempus fugit! 8-)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Easy question about Character manipulation

[Jeffrey R. Carter]

(see below) wrote:
> 
> It depends on whether they are value parameters or var (-iable) parameters.
> Value parameters are in effect assigned their values,
> and the permissive semantics of assignment compatibility apply;
> var parameters must be of equivalent types, and type-equivalence in
> ISO Pascal is name-equivalence.

When I learned Pascal (not ISO), my understanding was that

type
    A = 1 .. 3;

was called a subrange, and defined A as what Ada calls a subtype of 
Integer. Since

    B = 1 .. 3;

was another subtype of the same type (in Ada terms), assignment between 
them was no problem.

-- 
Jeff Carter
"Alms for an ex-leper!"
Monty Python's Life of Brian
75

Re: Easy question about Character manipulation

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> I agree that it should probably be constant, but why not give it a type,
> as in:
> 
>     Size : constant Integer := 10;
> 
> I think named numbers are a kludge, and should usually be avoided.

I think they should be used whenever possible.

>> emptySpaces : array (1..size) of Character := "0123456789";
>> textLine : array (1..size * 3) of Character;
> 
> If Size is a named number, the index type of these arrays defaults to
> Integer -- another language kludge.

Right. All such ranges should be a discrete subtype, either by name or 
by being the part to the right of "is" in a subtype declaration: Integer 
range X .. Y;

And there should be no anonymous types.

-- 
Jeff Carter
"Alms for an ex-leper!"
Monty Python's Life of Brian
75

Re: Easy question about Character manipulation

[(see below)]

On 31/1/07 18:11, in article NZ4wh.374843$1i1.113582@attbi_s72, "Jeffrey R.
Carter" <jrcarter@acm.org> wrote:

> When I learned Pascal (not ISO), my understanding was that
> 
> type
>     A = 1 .. 3;
> 
> was called a subrange, and defined A as what Ada calls a subtype of
> Integer. Since
> 
>     B = 1 .. 3;
> 
> was another subtype of the same type (in Ada terms), assignment between
> them was no problem.

That is the practical effect, but it is not what the formal semantics
actually says. And, of course, there is more to type than assignment.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Easy question about Character manipulation

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 31/1/07 18:11, in article NZ4wh.374843$1i1.113582@attbi_s72, "Jeffrey R.
> Carter" <jrcarter@acm.org> wrote:
>
>> When I learned Pascal (not ISO), my understanding was that
>> 
>> type
>>     A = 1 .. 3;
>> 
>> was called a subrange, and defined A as what Ada calls a subtype of
>> Integer.

Well, the original Jensen&Wirth book defining Pascal was so vague that
you couldn't really tell what rule was intended about these things.
The ISO standard clarified all this stuff.

>... Since
>> 
>>     B = 1 .. 3;
>> 
>> was another subtype of the same type (in Ada terms), assignment between
>> them was no problem.
>
> That is the practical effect, but it is not what the formal semantics
> actually says. And, of course, there is more to type than assignment.

The important things are assignment statements, initialization (which
Pascal doesn't have in the Ada sense), parameter passing (with or
without 'var'), and function return.  From what you've explained, all
except 'var' parameters behave the way Jeff says above.

What's the rationale for treating 'var' specially?  As I recall, there's
also a special rule in Pascal that you can't pass a component of a
packed record or array to a 'var' parameter.  Isn't that enough?

- Bob

Re: Easy question about Character manipulation

[(see below)]

On 31/1/07 23:01, in article wcc8xfiztqi.fsf@shell01.TheWorld.com, "Robert A
Duff" <bobduff@shell01.TheWorld.com> wrote:

> The important things are assignment statements, initialization (which
> Pascal doesn't have in the Ada sense), parameter passing (with or
> without 'var'), and function return.  From what you've explained, all
> except 'var' parameters behave the way Jeff says above.

Yup.
 
> What's the rationale for treating 'var' specially?  As I recall, there's
> also a special rule in Pascal that you can't pass a component of a
> packed record or array to a 'var' parameter.  Isn't that enough?

I think this was a matter of backward compatibility with existing
implementations, and our "no new language design by committee"
self-denying ordinance.

(We broke that only to introduce conformant array parameters,
at the urgent request of Hoare and with Wirth's explicit approval.)

I guess there are also run-time checking overheads that would have been
more of an issue in 1977 than 2007.

I don't think that relaxing the rules for var parameters was ever
seriously discussed, but to be honest my memory of this is close to nil.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Easy question about Character manipulation

[Jeffrey R. Carter]

(see below) wrote:
> 
> That is the practical effect, but it is not what the formal semantics
> actually says. And, of course, there is more to type than assignment.

Well, there weren't really formal semantics in J&W. But what I was 
getting at was that Pascal didn't have user-defined numeric types. Like 
C, you were stuck with what the compiler gave you, which generally 
corresponded to what the hardware provided. IIRC, for integers you were 
only guaranteed Integer, though most implementations had additional 
sizes. A subrange was still the same size as Integer, but had run-time 
checks to enforce the smaller range, just like an Ada subtype.

I don't recall ever encountering a situation where I couldn't mix 
subranges on any Pascal compiler I used, and I used a few. Of course, 
that doesn't mean there weren't any ...

-- 
Jeff Carter
"Alms for an ex-leper!"
Monty Python's Life of Brian
75

Re: Easy question about Character manipulation

[(see below)]

On 31/1/07 23:46, in article ST9wh.248683$aJ.115281@attbi_s21, "Jeffrey R.
Carter" <jrcarter@acm.org> wrote:

> Well, there weren't really formal semantics in J&W.

No indeed, I was referring to the BSI/ISO standard.
The J&W language "definition" was a frightful mess
that took us the best part of 2 years to sort out.

> But what I was getting at was that Pascal didn't have
> user-defined numeric types. Like C, you were stuck with
> what the compiler gave you, which generally
> corresponded to what the hardware provided. IIRC, for integers you were
> only guaranteed Integer, though most implementations had additional
> sizes. A subrange was still the same size as Integer, but had run-time
> checks to enforce the smaller range, just like an Ada subtype.

That's exactly right.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk