GNAT-Problem Set_Line(), Set_Col()

GNAT-Problem Set_Line(), Set_Col()

[Andreas Krohn]

When I use these functions with a variable then the compiler says 
"Invalid parameter list in call".
If it is a number then it works. Where is the problem ?

  Andreas

Re: GNAT-Problem Set_Line(), Set_Col()

[Robert Dewar]

Andreas asks about Set_Col not working with a variable.
First, such problems should be addressed to gnat-report
second, we need sources that duplicate the problem or we can't do anything
   with such reports

Re: GNAT-Problem Set_Line(), Set_Col()

[Norman H. Cohen]

In article <395jba$kbs@tucs6.rz.tu-cottbus.de>, ak@informatik.tu-cottbus.de
(Andreas Krohn) writes: 

|> When I use these functions with a variable then the compiler says
|> "Invalid parameter list in call".
|> If it is a number then it works. Where is the problem ?

My guess is that you've declared the variables to be of type Integer.
Set_Line and Set_Col take parameters of the integer type Text_IO.Count.
(An integer literal is acceptable where a value of any integer type is
expected.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: GNAT-Problem Set_Line(), Set_Col()

[Michael Feldman]

In article <3aad5q$qn9@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>In article <395jba$kbs@tucs6.rz.tu-cottbus.de>, ak@informatik.tu-cottbus.de
>(Andreas Krohn) writes: 
>
>|> When I use these functions with a variable then the compiler says
>|> "Invalid parameter list in call".
>|> If it is a number then it works. Where is the problem ?
>
>My guess is that you've declared the variables to be of type Integer.
>Set_Line and Set_Col take parameters of the integer type Text_IO.Count.
>(An integer literal is acceptable where a value of any integer type is
>expected.)

I'd like to hear from Norm or another Ada Wise Person why it was thought 
necessary to declare a new type for Text_IO.Count, instead of simply using 
Positive. I know the usual arguments about portability and predefined types, 
but of course Text_IO.Count is also a predefined type with implementation
defined range, so the advantage is not at all obvious.

In my opinion, the use of a new type here causes exactly the kind of
confusion Andreas encountered; are the benefits of a distinct type in
this case worth it when balanced against the confusion?

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: GNAT-Problem Set_Line(), Set_Col()

[Tucker Taft]

In article <3aari4$jlc@felix.seas.gwu.edu>,
Michael Feldman <mfeldman@seas.gwu.edu> wrote:

>In article <3aad5q$qn9@watnews1.watson.ibm.com>,
>Norman H. Cohen <ncohen@watson.ibm.com> wrote:

>>In article <395jba$kbs@tucs6.rz.tu-cottbus.de>, 
>>  ak@informatik.tu-cottbus.de (Andreas Krohn) writes: 
>>
>>|> When I use these functions with a variable then the compiler says
>>|> "Invalid parameter list in call".
>>|> If it is a number then it works. Where is the problem ?
>>
>>My guess is that you've declared the variables to be of type Integer.
>>Set_Line and Set_Col take parameters of the integer type Text_IO.Count.
>>(An integer literal is acceptable where a value of any integer type is
>>expected.)
>
>I'd like to hear from Norm or another Ada Wise Person why it was thought 
>necessary to declare a new type for Text_IO.Count, instead of simply using 
>Positive. I know the usual arguments about portability and predefined types, 
>but of course Text_IO.Count is also a predefined type with implementation
>defined range, so the advantage is not at all obvious.

The justification, if any, for a separate type is not because
of the implementation-dependence of the range, but rather because
there is some value in having a strong type distiction here.

>In my opinion, the use of a new type here causes exactly the kind of
>confusion Andreas encountered; are the benefits of a distinct type in
>this case worth it when balanced against the confusion?

I personally think this was (mild) overkill in the strong typing 
department.  On the other hand, there are those who are still annoyed 
that the predefined type String is indexed by Positive rather than its
own unique type, so I doubt if you can please everyone in this
area.  "Use type" makes it a little more palatable to have multiple
integer types running about in Ada 9X.

As usual, there is the tension between naive and simple use,
and the advantages provided by strong type checking.
Since Set_Col and Set_Line are a bit more sophisticated than
other Text_IO features, beginning to use them is perhaps a 
good indication that it is time to start learning about the 
advantages (and occasional mild annoyances ;-) of strong type 
distinctions between numeric types.  It is an important
strength of Ada, IMHO, that integers used for indexing into
arrays are distinguishable by type.  If one thinks of the
characters on a page as being in an array, then it is appropriate
that Set_Col and Set_Line have their own "index" type (of course, 
this line of reasoning argues that Set_Col and Set_Line really ought 
each to have its own separate "index" type).

>Mike Feldman

-Tucker Taft   stt@inmet.com

Re: GNAT-Problem Set_Line(), Set_Col()

[Michael Feldman]

In article <CzBp9A.CoC@inmet.camb.inmet.com>,
Tucker Taft <stt@spock.camb.inmet.com> wrote:
>>I know the usual arguments about portability and predefined types, 
>>but of course Text_IO.Count is also a predefined type with implementation
>>defined range, so the advantage is not at all obvious.
>
>The justification, if any, for a separate type is not because
>of the implementation-dependence of the range, but rather because
>there is some value in having a strong type distiction here.

I don't really see it.

>I personally think this was (mild) overkill in the strong typing 
>department.  On the other hand, there are those who are still annoyed 
>that the predefined type String is indexed by Positive rather than its
>own unique type, so I doubt if you can please everyone in this
>area.  "Use type" makes it a little more palatable to have multiple
>integer types running about in Ada 9X.

Well, I think it would be more palatable to be consistent. The same
justification for indexing String by Positive would justify using
Positive as the file count, as you point out below.

>As usual, there is the tension between naive and simple use,
>and the advantages provided by strong type checking.

Of course, but that is not enough in itself to justify the type.

The month, day, and year types in Calendar are mere Integer subtypes;
the index type in String is a mere Integer subtype; yet the record
count, column count, and line count - three different ranges with
different uses - are all the same new type.

>Since Set_Col and Set_Line are a bit more sophisticated than
>other Text_IO features, beginning to use them is perhaps a 
>good indication that it is time to start learning about the 
>advantages (and occasional mild annoyances ;-) of strong type 
>distinctions between numeric types.  It is an important
>strength of Ada, IMHO, that integers used for indexing into
>arrays are distinguishable by type.  If one thinks of the
>characters on a page as being in an array, then it is appropriate
>that Set_Col and Set_Line have their own "index" type (of course, 
>this line of reasoning argues that Set_Col and Set_Line really ought 
>each to have its own separate "index" type).

Indeed, and the same goes for String. And, truth to tell, for
Calendar.Month_Number, Day_Number, Year_Number. This is a mild
inconsistency, not a source of major grief in the language, but it
is aggravating enough that I'd hoped for a better language-lawyerly
justification than you gave, Tuck... Generally the design of Ada is
very careful and I hesitate to come down too hard on what look like
inconsistencies, because they usually are well-thought-out. IMHO,
this one is not. Oh well.

Cheers -

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: GNAT-Problem Set_Line(), Set_Col()

[Norman H. Cohen]

In article <3aari4$jlc@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu
(Michael Feldman) writes: 

|> I'd like to hear from Norm or another Ada Wise Person why it was thought
|> necessary to declare a new type for Text_IO.Count, instead of simply using
|> Positive.

In fact, in the Ada 80 RM, it was Positive.  By the July 1982 draft of
the revised RM, it had been changed to a new integer type.  I would guess
from the timing that the change was in response to a comment received
during the ANSI canvass.

It is easy to envision (and it was even easier to envision in 1980) a
16-bit machine for which the natural range for type Integer is
-32_768 .. 32_768, but for which files can easily exceed 32,768 lines (or
the single line of a file with only one line terminator can exceed 32,768
columns).  Then type Integer is not wide enough to serve in the role
played by Text_IO.Count.

|>           I know the usual arguments about portability and predefined types,
|> but of course Text_IO.Count is also a predefined type with implementation
|> defined range, so the advantage is not at all obvious.

It allows the implementation to define an efficient size for type
Integer, based on the width of a machine register, even if that type is
too small for numbering columns, lines, and pages in the target file
system.  Had a single type been used in the RM, the implementation would
have been forced to make type Integer wide enough to number columns,
lines, and pages, possibly imposing a substantial performance penalty
(doing all Integer arithmetic in terms of separate low-order and
high-order halves of a word) for a marginal purpose.  (How often do you
use Set_Line and its cousins?)

|> In my opinion, the use of a new type here causes exactly the kind of
|> confusion Andreas encountered; are the benefits of a distinct type in
|> this case worth it when balanced against the confusion?

I agree that a separate type here is a pain, but it appears to be a
decision made for pragmatic rather than aesthetic reasons.  (After all,
column numbers, line numbers, and page numbers are distinct abstractions,
so if the motivation were methodological, we would expect to see three
different types.  Note also that Text_IO.Field and Text_IO.Number_Base
ARE subtypes of Integer, because any realistic definition of type Integer
would be sufficient to accommodate the uses of those subtypes.)  I don't
think there was any other reasonable choice.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: GNAT-Problem Set_Line(), Set_Col()

[Robert Dewar]

Ah that triggers the memory, yes indeed, we discussed the problem of files
being limited to integer size lines, which on 16-bit machines (e.g. compilers
for DOS) would be an intolerable restriction.

Re: GNAT-Problem Set_Line(), Set_Col()

[Keith Thompson]

In <3aari4$jlc@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
> I'd like to hear from Norm or another Ada Wise Person why it was thought 
> necessary to declare a new type for Text_IO.Count, instead of simply using 
> Positive. I know the usual arguments about portability and predefined types, 
> but of course Text_IO.Count is also a predefined type with implementation
> defined range, so the advantage is not at all obvious.
> 
> In my opinion, the use of a new type here causes exactly the kind of
> confusion Andreas encountered; are the benefits of a distinct type in
> this case worth it when balanced against the confusion?

Well, I'd like to think of myself as an "Ada Wise Person".  8-)}

Why should the maximum number of lines in a text file be the same as
the largest value of type Integer?  Text_IO.Count is a predefined type,
but it's predefined by the implementer of Text_IO, who can choose a
reasonable range for it.

On some targets, you might want type Integer to be only 16 bits (this
was probably more true in 1983 than it is now, but it's still allowable).
Having Text_IO blow up on text files longer than 32767 lines would have
been A Bad Thing (though I suppose that, with careful implementation,
it wouldn't necessarily blow up unless you try to set or query the
current line number).

Overuse of the predefined types is considered (by many) to be bad style
anyway, since it weakens Ada's strong type checking.  It's too bad when
that checking complains about something that's actually safe, but that's
the price we pay for having the compiler detect more of our mistakes.
This is exactly what user-defined integer types are for.

function "+"(Left: Apples; Right; Oranges) return Fruits;

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)

Re: GNAT-Problem Set_Line(), Set_Col()

[Michael Feldman]

In article <CzC5AG.65A@alsys.com>, Keith Thompson <kst@alsys.com> wrote:
>In <3aari4$jlc@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>
>Well, I'd like to think of myself as an "Ada Wise Person".  8-)}

Of course!

>On some targets, you might want type Integer to be only 16 bits (this
>was probably more true in 1983 than it is now, but it's still allowable).
>Having Text_IO blow up on text files longer than 32767 lines would have
>been A Bad Thing (though I suppose that, with careful implementation,
>it wouldn't necessarily blow up unless you try to set or query the
>current line number).

>Overuse of the predefined types is considered (by many) to be bad style
>anyway, since it weakens Ada's strong type checking.  It's too bad when
>that checking complains about something that's actually safe, but that's
>the price we pay for having the compiler detect more of our mistakes.

Well, certainly. This is the standard lecture we give each other about 
the predefined types - indeed, I've given it a number of times myself. :-)

But as Norm Cohen pointed out, it is not obvious that Line and Col
are of the _same_ type. And it's easy to see, in this context, why
some folks have complained that the index type of String is Positive.
I agree that files should be allowed have more than 32767 lines; by 
that argument, why restrict Strings to 32767 characters? I think 
that a consistent approach would have been much clearer and easier 
to justify to others. 

Oh well. In the order of things, it's a small issue, just fun to 
debate on the net. :-)

Thanks for setting it out, Keith.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------