Something I don't understand

Something I don't understand

[Laurent]

Hi

Doing an exercise from the book "Ada 95 Problem Solving and Program Design".
I am supposed to make a robust function to read some values. It works so far but there is one thing I don't
understand.

   MaxName : CONSTANT Positive := 30; -- defined in other package
   SUBTYPE NameType IS String (1 .. MaxName); -- defined in other package

   Count : Natural RANGE 1.. MaxName;

         Name : LOOP
               BEGIN --exception handler block               
                    Ada.Text_IO.Put ("Name (1 - ");
                    Ada.Integer_Text_IO.Put (Item => MaxName,Width => 1);
                    Ada.Text_IO.Put(Item => " characters) >");
                    Ada.Text_IO.Get_Line (Item => S, Last => Count);
                    Item.Name (1 .. Count) := S (1 .. Count);  
                    Ada.Text_IO.Skip_Line;
            
               EXIT; -- correct Name
               
            EXCEPTION
               WHEN Constraint_Error =>
                  Ada.Text_IO.Skip_Line;
                  Ada.Text_IO.Put (Item => "Name too short/long!");
                  Ada.Text_IO.New_Line;
                  
            END; -- exception handler
         END LOOP Name;


So when I enter nothing as name I get a Constraint_Error which is handled. That's ok but when the name I enter is longer than 30 chars no exception. Is that normal and if yes/no why? 

The chars that are to much are just ignored.

Thanks

Laurent

Re: Something I don't understand

[adambeneschan]

On Thursday, February 13, 2014 3:57:58 PM UTC-8, Laurent wrote:
> Hi
> 
> 
> 
> Doing an exercise from the book "Ada 95 Problem Solving and Program Design".
> 
> I am supposed to make a robust function to read some values. It works so far but there is one thing I don't
> 
> understand.
 
>    MaxName : CONSTANT Positive := 30; -- defined in other package 
>    SUBTYPE NameType IS String (1 .. MaxName); -- defined in other package
> 
>    Count : Natural RANGE 1.. MaxName;
>
>          Name : LOOP
>                BEGIN --exception handler block               
>                     Ada.Text_IO.Put ("Name (1 - ");
>                     Ada.Integer_Text_IO.Put (Item => MaxName,Width => 1);
>                     Ada.Text_IO.Put(Item => " characters) >");
>                     Ada.Text_IO.Get_Line (Item => S, Last => Count);
>                     Item.Name (1 .. Count) := S (1 .. Count);  
>                     Ada.Text_IO.Skip_Line;
> 
>                EXIT; -- correct Name
> 
>             EXCEPTION
>                WHEN Constraint_Error =>
>                   Ada.Text_IO.Skip_Line;
>                   Ada.Text_IO.Put (Item => "Name too short/long!");
>                   Ada.Text_IO.New_Line;
> 
>             END; -- exception handler
> 
>          END LOOP Name;
> 
> 
> 
> 
> 
> So when I enter nothing as name I get a Constraint_Error which is handled. That's ok but when the name I enter is longer than 30 chars no exception. Is that normal and if yes/no why? 

Yes, because that's how the *procedure* Get_Line is defined.  It stops reading when it reaches the end of the string, or the end of the line.  (RM A.10.7(18-20))

If you want to check for input that is too long, you can use the *function* Get_Line, which always reads to the end of the line:

    declare
        Input : String := Ada.Text_IO.Get_Line;
    begin
        if Input'Length <= NameType'Length then
            Item.Name (1 .. Input'Length) := Input;
            --Ada.Text_IO.Skip_Line;  --you shouldn't need this, Get_Line will
                                      --automatically perform this
            exit Name;  -- correct name
        else
            Ada.Text_IO.Put_Line (Item => "Name too long!");
            -- combination of Put and New_Line
        end if;
    end;  -- this ends the block starting with "declare"

                            -- Adam

Re: Something I don't understand

[Charles H. Sampson]

<adambeneschan@gmail.com> wrote:

> On Thursday, February 13, 2014 3:57:58 PM UTC-8, Laurent wrote:
> > Hi
> > 
> > 
> > 
> > Doing an exercise from the book "Ada 95 Problem Solving and Program Design".
> > 
> > I am supposed to make a robust function to read some values. It works so
> > far but there is one thing I don't understand.
>  
> >    MaxName : CONSTANT Positive := 30; -- defined in other package 
> >    SUBTYPE NameType IS String (1 .. MaxName); -- defined in other package
> > 
> >    Count : Natural RANGE 1.. MaxName;
> >
> >          Name : LOOP
> >                BEGIN --exception handler block               
> >                     Ada.Text_IO.Put ("Name (1 - ");
> >                     Ada.Integer_Text_IO.Put (Item => MaxName,Width => 1);
> >                     Ada.Text_IO.Put(Item => " characters) >");
> >                     Ada.Text_IO.Get_Line (Item => S, Last => Count);
> >                     Item.Name (1 .. Count) := S (1 .. Count);  
> >                     Ada.Text_IO.Skip_Line;
> > 
> >                EXIT; -- correct Name
> > 
> >             EXCEPTION
> >                WHEN Constraint_Error =>
> >                   Ada.Text_IO.Skip_Line;
> >                   Ada.Text_IO.Put (Item => "Name too short/long!");
> >                   Ada.Text_IO.New_Line;
> > 
> >             END; -- exception handler
> > 
> >          END LOOP Name;
> > 
> > 
> > 
> > 
> > 
> > So when I enter nothing as name I get a Constraint_Error which is
> > handled. That's ok but when the name I enter is longer than 30 chars no
> > exception. Is that normal and if yes/no why?
> 
> Yes, because that's how the *procedure* Get_Line is defined.  It stops
> reading when it reaches the end of the string, or the end of the line.
> (RM A.10.7(18-20))
> 
> If you want to check for input that is too long, you can use the
> *function* Get_Line, which always reads to the end of the line:
> 
>     declare
>         Input : String := Ada.Text_IO.Get_Line;
>     begin
>         if Input'Length <= NameType'Length then
>             Item.Name (1 .. Input'Length) := Input;
>             --Ada.Text_IO.Skip_Line;  --you shouldn't need this, Get_Line will
>                                       --automatically perform this
>             exit Name;  -- correct name
>         else
>             Ada.Text_IO.Put_Line (Item => "Name too long!");
>             -- combination of Put and New_Line
>         end if;
>     end;  -- this ends the block starting with "declare"

     It should be mentioned that in the OP's version the extra
characters aren't discarded. They're still there to be "gotten" on the
next use of Get or Get_Line. As Mr. Beneschan hinted in his comment
above, if you want to get rid of them you need to call Skip_Line.

     Just another example of Ada not doing things behind the scene.

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

Re: Something I don't understand

[Laurent]

Hi

> Yes, because that's how the *procedure* Get_Line is defined.  It stops reading when it reaches the end of >the string, or the end of the line.  (RM A.10.7(18-20))

This would explain why an IF condition on Count > MaxName never activated.

>It should be mentioned that in the OP's version the extra 
>characters aren't discarded. They're still there to be "gotten" on the 
>next use of Get or Get_Line. As Mr. Beneschan hinted in his comment 
>above, if you want to get rid of them you need to call Skip_Line. 

Yes I know, thats why I put a Skip_Line to prevent the extra chars from getting catcher from the following
input procedure which expects an enumeration.

> The chars that are to much are just ignored. 

I thought that as I get an Constraint_Error for not entering a char at all, Get_Line would also complain if
the String entered is too long. Because Strings are 1D Arrays. Thats why I asked.

Thanks for the example. I think I will use it, even if it is not really necessary. Could be useful later in my own program.

There are still a lot of things I have to learn.

Thank you very much.

Laurent

Re: Something I don't understand

[Laurent]

Hi

Now it works as I think it should.

Name : LOOP            
            BEGIN --exception handler block
               Ada.Text_IO.Put ("Name (1 - ");                  
               Ada.Integer_Text_IO.Put (Item => MaxName, Width => 1);
               Ada.Text_IO.Put (Item => " characters) >"); 
               
               DECLARE
                  S : String := Ada.Text_IO.Get_Line;
               
               BEGIN
                  IF S'Length = 0 THEN
                     RAISE Name_Too_Short;
                  ELSIF S'Length <= MaxName THEN
                     Item.Name (1 .. S'Length) := S;                     
                  ELSE RAISE Name_Too_Long;   
                  END IF;
                  
                  EXIT; -- correct Name                  

               EXCEPTION
                     
                  WHEN Name_Too_Short =>                     
                     Ada.Text_IO.Skip_Line;
                     Ada.Text_IO.Put (Item => "Name too short!");                     
                     Ada.Text_IO.New_Line;                     
                  WHEN Name_Too_Long =>                     
                     Ada.Text_IO.Skip_Line;                     
                     Ada.Text_IO.Put_Line (Item => "Name too long!");                     

               END; -- exception handler
            END;
         END LOOP Name;

The only thing which I find annoying is the fact that I have to tape ENTER 2 times.

@Adam: Thanks for your example

Thanks

Laurent 

Re: Something I don't understand

[Niklas Holsti]

On 14-02-15 21:10 , Laurent wrote:
> Hi
> 
> Now it works as I think it should.
> 
> Name : LOOP            
>             BEGIN --exception handler block
>                Ada.Text_IO.Put ("Name (1 - ");                  
>                Ada.Integer_Text_IO.Put (Item => MaxName, Width => 1);
>                Ada.Text_IO.Put (Item => " characters) >"); 

You might want to insert Ada.Text_IO.Flush here, to make sure that the
preceding Put text appears on the terminal. (I'm not sure if the
standard requires an implicit Flush when a Put is followed by a Get.)

>                DECLARE
>                   S : String := Ada.Text_IO.Get_Line;
    [snip]
>                EXCEPTION
>                      
>                   WHEN Name_Too_Short =>                     
>                      Ada.Text_IO.Skip_Line;
    [snip]

> The only thing which I find annoying is the fact that I
> have to tape ENTER 2 times.

Does that happen only in the exception cases? Then the reason is
probably the Skip_Line calls in the exception handlers. They are
superfluous because the Get_Line function includes the effect of a
Skip_Line (RM 17.2/2) -- it consumes the line terminator. Remove the
Skip_Lines.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Something I don't understand

[Laurent]

Hi

> Does that happen only in the exception cases? Then the reason is
> probably the Skip_Line calls in the exception handlers. They are
> superfluous because the Get_Line function includes the effect of a
> Skip_Line (RM 17.2/2) -- it consumes the line terminator. Remove the 
> Skip_Lines.

Happened also with a correct name.
Probably forgotten to rebuild something. Wouldn't be the first time.

After rebuild correct name was processed after one enter.

Removed the Skip_Line from the Exception Handler part and a wrong name also needs only one enter.

@Niklas: Thanks for your help

Laurent

Re: Something I don't understand

[Jeffrey Carter]

On 02/15/2014 12:10 PM, Laurent wrote:
>
>              BEGIN --exception handler block

There's no exception handler for this "begin". It does nothing and and the 
comment is incorrect, so it should be eliminated.

>                 DECLARE

This block has the exception handler.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: Something I don't understand

[Robert A Duff]

Laurent <daemon2@internet.lu> writes:

> Now it works as I think it should.

Good.

FWIW, Text_IO is a poor design, and I don't blame you for having
trouble with it!

Some stylistic comments on the code below:

Exceptions are for dealing with cases where one piece of code detects
a (possible) error, and another piece of code decides whether it
really is an error, and how to deal with it.  That's not the
case here, so should be written without any exceptions.

No need for a loop name.

You should use typical style, so other Ada programmers can read your
code more easily:  lower case keywords, Max_Name instead of MaxName.
(Or Max_Name_Length?)  Space after "--".

S should declared "constant".  You should enable warnings in GNAT
that detect this mistake.

Why should there be a limit on the length of the name?  Maybe you have
a good reason, but usually such arbitrary limits are a bad idea.

> Name : LOOP            
>             BEGIN --exception handler block
>                Ada.Text_IO.Put ("Name (1 - ");                  
>                Ada.Integer_Text_IO.Put (Item => MaxName, Width => 1);
>                Ada.Text_IO.Put (Item => " characters) >"); 
>                
>                DECLARE
>                   S : String := Ada.Text_IO.Get_Line;
>                
>                BEGIN
>                   IF S'Length = 0 THEN
>                      RAISE Name_Too_Short;
>                   ELSIF S'Length <= MaxName THEN
>                      Item.Name (1 .. S'Length) := S;                     
>                   ELSE RAISE Name_Too_Long;   
>                   END IF;
>                   
>                   EXIT; -- correct Name                  
>
>                EXCEPTION
>                      
>                   WHEN Name_Too_Short =>                     
>                      Ada.Text_IO.Skip_Line;
>                      Ada.Text_IO.Put (Item => "Name too short!");                     
>                      Ada.Text_IO.New_Line;                     
>                   WHEN Name_Too_Long =>                     
>                      Ada.Text_IO.Skip_Line;                     
>                      Ada.Text_IO.Put_Line (Item => "Name too long!");                     
>
>                END; -- exception handler
>             END;
>          END LOOP Name;

Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-15, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>
> FWIW, Text_IO is a poor design, and I don't blame you for having
> trouble with it!
>

I'm always interested in learning how people would do things differently
if they were given a second chance.

So, what do you dislike about Text_IO and what design changes would you
make if given a second chance ?

In a modified Ada, do you still see a role for Text_IO as it stands
(with additional I/O package(s) implementing your desired changes) or do
you think Text_IO should be outright replaced ?

Thanks,

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Sun, 16 Feb 2014 09:08:20 +0000 (UTC), Simon Clubley wrote:

> In a modified Ada, do you still see a role for Text_IO as it stands
> (with additional I/O package(s) implementing your desired changes) or do
> you think Text_IO should be outright replaced ?

Text_IO should be replaced because the design of Character/String was
wrong. It is wrong to have Character, Wide_Character, Wide_Wide_Character.
It is wrong not to separate encoding from characters. The punishment for
that is a combinatorial explosion of variants as observed in Text_IO.

Other stuff hated by many is the page formatting Text_IO does. This is
basically the same problem as above, of not using the language type system
properly.

When it was finally noted, stream I/O (Text_Stream) was introduced. It was
a bit strange that Text_Stream sat on top of Text_IO. Most OSes where this
would reflect the reality are gone (e.g. VMS). In Unix it is rather
formatting that sits on streams. Anyway again, that should be reflected by
type relationships rather than by a patchwork of calls returning access(!)
types.

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

Re: Something I don't understand

[Mike H]

In message <wcc1tz3al9l.fsf@shell01.TheWorld.com>, Robert A Duff 
<bobduff@shell01.TheWorld.com> writes
>Laurent <daemon2@internet.lu> writes:
>
>Some stylistic comments on the code below:
>
In my experience, most Ada shops have in-house coding standards. The 
last place I worked (contracting) placed great emphasis on the 
connection between meaningful names and commenting style. Peer review 
was part of the signing off process so writing self documenting code 
became a matter of habit.

-- 
Mike
Swim? Naturally at Severn Vale
<http://www.severnvalesc.org/>

Re: Text_IO, was: Re: Something I don't understand

[Robert A Duff]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2014-02-15, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>>
>> FWIW, Text_IO is a poor design, and I don't blame you for having
>> trouble with it!
>
> I'm always interested in learning how people would do things differently
> if they were given a second chance.
>
> So, what do you dislike about Text_IO and what design changes would you
> make if given a second chance ?

I/O should be separated from processing.  In this case, the "processing"
I'm talking about is formatting and parsing of data (e.g. turning
an integer into a human-readable sequence of characters).  See how
it's done in Java.

Formatting for type T belongs with type T, not in Text_IO.

Input should be separate from output.  Put(Stream, X), where X is an
integer makes sense, because we know X is an integer.  Get(X)
makes no sense, because we have no idea what the user is going
to type.  For text input, you need "read the next token, and tell
me what it is", not "read an integer token, and blow up if the
user typed something else".

A simplified and type-safe version of C's printf style
(template-based) formatting would be more readable than
concatenating a bunch of strings together to print messages,
and MUCH better than using a series of Put calls to print
a single message.

I/O should be task safe, at least for standard output and friends.

There are various ways operating systems have chosen to represent text
files: lines separated by a single character, lines separated by two
characters (CR/LF), record oriented.  Obviously, the language design
needs to pick one of those models, and the implementation needs to map
that model onto whatever the OS does.  Any model will work, but Ada
chose the least convenient one.

Path names (file names with directory names and so on) should be
represented using an appropriate type, with structure, properly
interoperating with Ada.Directories.  String is the wrong type for that.
See how it's done in Common Lisp, quite portably.

The Get_Line procedure invites people to write broken programs
with arbitrary annoying line-length limitations.  However long
you make that String, it will be either too short or too long,
and most likely both.  The Get_Line function is better.

There should be a convenient way to read an entire file into
a String.  Similar for writing.

String should be a private data type with appropriate operations,
representing full Unicode, probably represented in UTF-8.
But we can't blame the designers of Ada 83 for choosing 7-bit
ASCII.  Even that was a bold move, at a time when most languages
didn't even define a standard character set, leaving it up to
the operating system.

There should be a standard way to represent multi-line text
in a String.

There is no convenient way to open a file in append mode,
creating it (empty) if it doesn't exist, atomically.

Calling Create followed by Close, with no intervening output,
does not create an empty file.  That's broken.

The line-counting business is largely useless, and somewhat confusing.

The page-handling is largely pointless, and gets in the way even
when you don't care about pages.

Finalization (which didn't exist in Ada 83) should be used to
automatically close files.

Open should be a build-in-place function (which didn't exist in Ada 83),
instead of a procedure.

> In a modified Ada, do you still see a role for Text_IO as it stands
> (with additional I/O package(s) implementing your desired changes) or do
> you think Text_IO should be outright replaced ?

You mean if compatibility were not a concern?  Yeah, the only reason
to keep Text_IO as it is is for compatibility.  In a from-scratch
language design, I'd do it rather differently.

- Bob

Re: Text_IO, was: Re: Something I don't understand

[Dennis Lee Bieber]

On Sun, 16 Feb 2014 10:43:57 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> declaimed the following:

>a bit strange that Text_Stream sat on top of Text_IO. Most OSes where this
>would reflect the reality are gone (e.g. VMS). In Unix it is rather

	Fading, but not gone... I'm currently having to update a test plan (and
then perform the tests before SQA) of a program developed under VMS (though
-- using a cross compiler for 68xxx processor).

	VMS is running under an emulator on a Windows box... (granted, they are
using a paid support version but...

http://www.openvms.org/pages.php?page=Hobbyist
http://www.stromasys.com/products/charon-freeware/charon-freeware/


	It lives, Igor!
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> On 2014-02-15, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>>>
>>> FWIW, Text_IO is a poor design, and I don't blame you for having
>>> trouble with it!
>>
>> I'm always interested in learning how people would do things differently
>> if they were given a second chance.
>>
>> So, what do you dislike about Text_IO and what design changes would you
>> make if given a second chance ?
>
> I/O should be separated from processing.  In this case, the "processing"
> I'm talking about is formatting and parsing of data (e.g. turning
> an integer into a human-readable sequence of characters).  See how
> it's done in Java.
>
> Formatting for type T belongs with type T, not in Text_IO.
>

Agreed, but it should be a two-way thing.

There should be both External_To_Internal and Internal_To_External
support to convert between the external (human readable) format and
the internal format. You would also need to specify a format when
going from internal to external format so the output would fit in
the requested field width and obey the requested attributes (for
example, number of decimal places).

> Input should be separate from output.  Put(Stream, X), where X is an
> integer makes sense, because we know X is an integer.  Get(X)
> makes no sense, because we have no idea what the user is going
> to type.  For text input, you need "read the next token, and tell
> me what it is", not "read an integer token, and blow up if the
> user typed something else".
>

While the current input routines need replacing, I don't agree with the
Ada RTL trying to work out what the input format is and pass a token
type back to the program. The problem is that unless you are careful,
you can end up with a Excel type solution in which it works most of
the time but fails when it thinks it knows better than you do what
you entered.

For example, consider the input "123,456".

Is the user entering a array of two numbers ?

Is the user entering one number but with a thousands seperator ?

Is the user in mainland Europe and hence is really entering "123.456" ?

Should this input be treated as a string (because it has a comma in it)
or should the Ada RTL impose it's idea of a number and convert the
input into some standard format even though that may not look anything
like what the user meant ?

What happens when the final destination is a range limited data type ?
You either have to still do the checking manually or take a exception
if the input value is outside of the range of the data type.

> A simplified and type-safe version of C's printf style
> (template-based) formatting would be more readable than
> concatenating a bunch of strings together to print messages,
> and MUCH better than using a series of Put calls to print
> a single message.
>

_Totally_ agree with this. It would also be nice if one could write
something like this (pseudo Fortran style to get the idea across):
"5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth
(in this example) of data cleanly.

>
> There should be a convenient way to read an entire file into
> a String.  Similar for writing.
>

Yes, but you may need two methods. One for binary (unchanged) input and
one for text input with end of line conversions.

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[G.B.]

On 17.02.14 13:52, Simon Clubley wrote:
> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

>> A simplified and type-safe version of C's printf style
>> (template-based) formatting would be more readable than
>> concatenating a bunch of strings together to print messages,
>> and MUCH better than using a series of Put calls to print
>> a single message.
>>
>
> _Totally_ agree with this. It would also be nice if one could write
> something like this (pseudo Fortran style to get the idea across):
> "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth
> (in this example) of data cleanly.

I wonder if this feature could be tacked onto the string
types?  With the help of attribute functions and named
bindings, formatting could be handled flexibly, leaving room
for internationalization, for example. Formatting could also
be handled conveniently, insofar as the language provides
"obvious" default formatting.


    For_Invoice : constant Wide_String :=
      --  not Ada
      Wide_String'Edited ("A total of %{Sum} %{Currency} for %{Pieces}")
        with Bindings =>
           (Sum      => (Value => <>,
                         Money'Wide_Formatted => Using_Pic_String),
            Currency => (I18N.CU, Currency'Wide_Formatted => <>),
            Pieces   => (Amount * 2.0, Three_Colums'Access));

    Format : constant   -- needs to be a static constant
       Wide_String'Edited := "Process # %{pnum} : %{n}µs";

A <> stands for the default choices, viz. a variable or
parameterless function named "Sum" in the first row, and
a default "formatter" in the third.  When no specialized
formatting is needed for an item, write

    with Bindings =>
      (...,
       Foo => <>,
       ...);

As an example of a flexible solution, "Using_Pic_string" from the
first example above would be a function with a profile like that
of 'Wide_Image. (Its body uses existing language features,
in this case picture strings from Information Systems Annex.)
Also, since the generics of Text_IO already provide for
formatting numbers (Putting them into strings), these routines
could be borrowed for the meaning of

   T'[Wide_][Wide_]_Formatted

Safety of the template is guaranteed insofar as the number
of items (and types, I think) in any actual binding is known
at compile time; type checking looks possible.  Hence, the
simplest formatting would be

   String'Edited("%{n} bottles of beer on the wall")
     with Bindings (others => <>);

It requires only that there be a variable/function named N.

Re: Text_IO, was: Re: Something I don't understand

[G.B.]

On 17.02.14 16:32, G.B. wrote:
>             Currency => (I18N.CU, Currency'Wide_Formatted => <>),
               Currency => (I18N.CU, Money'Wide_Formatted => <>),

Sorry.

Re: Something I don't understand

[Laurent]

Am Sonntag, 16. Februar 2014 02:39:34 UTC+1 schrieb Robert A Duff:

> Some stylistic comments on the code below:
 
> Exceptions are for dealing with cases where one piece of code detects
> a (possible) error, and another piece of code decides whether it
> case here, so should be written without any exceptions.

As I wrote in my first post the whole thing is an exercise from a book.
I'm learning programming mostly by myself and it is just an hobby.

The actual chapter is about ADTs and most of them which are part of the exercise I'm 
doing were written by the author of this book.

So I think it was/is best to stick to the way the author named his variables or build his programs.
 
> No need for a loop name.

Not needed yes, but they won't hurt anyone. In this package is not only this loop but a few others.
So I put named loops instead of comments.

> You should use typical style, so other Ada programmers can read your
> code more easily:  lower case keywords, Max_Name instead of MaxName. 
> (Or Max_Name_Length?) 

Dito first answer
 
> S should declared "constant".  You should enable warnings in GNAT
> that detect this mistake.

   MaxName : CONSTANT Positive := 30; -- defined in other package 
   SUBTYPE NameType IS String (1 .. MaxName); -- defined in other package 

It is, unfortunately with the original version of the code GNAT didn't complain about Name >MaxName.

> Why should there be a limit on the length of the name?  Maybe you have
> a good reason, but usually such arbitrary limits are a bad idea.

Book Author's choice

Thanks for the advice but in this case I think I will stick to the formatting given in the book.Still have the possibility to adapt it later.

Laurent

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-17 14:52 , Simon Clubley wrote:
> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
   [snip]
>> A simplified and type-safe version of C's printf style
>> (template-based) formatting would be more readable than
>> concatenating a bunch of strings together to print messages,
>> and MUCH better than using a series of Put calls to print
>> a single message.
>>
> 
> _Totally_ agree with this.

I disagree, but then I don't understand how Robert would make C's
template idea type-safe -- might Robert expand on his ideas?

I think that the present method of concatenating strings or using
several Puts is good; what is needed is to extend or replace the 'Image
attribute with similar value-to-string functions which are more
controllable, flexible, and work also for composite types. Perhaps
something analogous to the stream attributes, but with the ability to
control the output format at each invocation, which is not possible with
the stream attributes.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote:

> I think that the present method of concatenating strings or using
> several Puts is good; what is needed is to extend or replace the 'Image
> attribute with similar value-to-string functions which are more
> controllable, flexible, and work also for composite types.

Except that all these need to be MD primitive operations. There is no way
to solve this without MD.

Needless to say that templates could solve nothing only add further
problems.

> Perhaps
> something analogous to the stream attributes, but with the ability to
> control the output format at each invocation, which is not possible with
> the stream attributes.

I don't think there is any need in having formats. A few formatting
parameters could be passed along to Image or equivalent.

Environment settings (e.g. locale) should come from the rendering surface
object. No need to specify them at all. This is how stuff like fonts,
colors etc is handled in GUI.

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

Re: Text_IO, was: Re: Something I don't understand

[Mike H]

In message <53022b7f$0$6661$9b4e6d93@newsspool2.arcor-online.net>, G.B. 
<rm-dash-bau-haus@dash.futureapps.de> writes
>On 17.02.14 13:52, Simon Clubley wrote:
>> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>
>>> A simplified and type-safe version of C's printf style
>>> (template-based) formatting would be more readable than
>>> concatenating a bunch of strings together to print messages,
>>> and MUCH better than using a series of Put calls to print
>>> a single message.
>>>
>>
>> _Totally_ agree with this. It would also be nice if one could write
>> something like this (pseudo Fortran style to get the idea across):
>> "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth
>> (in this example) of data cleanly.
>
>I wonder if this feature could be tacked onto the string
>types?  With the help of attribute functions and named
>bindings, formatting could be handled flexibly, leaving room
>for internationalization, for example. Formatting could also
>be handled conveniently, insofar as the language provides
>"obvious" default formatting.

Albeit, in COBOL, I once worked on a "convertible currency ledger" (e.g. 
one where the items are recorded in both the currency of the foreign 
customer and the sterling value derived from the exchange rate in force 
at the time of the transaction), Ada generics would probably be my first 
line of investigation.

-- 
Cotswold Mike
"Homo sum, humani nihil a me alienum puto" =
"I am human, (so) I (should) judge nothing of humanity to be strange."
Publius Terentius (195/185–159 BC)

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-17 19:17 , Dmitry A. Kazakov wrote:
> On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote:
> 
>> I think that the present method of concatenating strings or using
>> several Puts is good; what is needed is to extend or replace the 'Image
>> attribute with similar value-to-string functions which are more
>> controllable, flexible, and work also for composite types.
> 
> Except that all these need to be MD primitive operations. There is no way
> to solve this without MD.

Why multiple dispatch? Which would be the multiple controlling
parameters? I think only the input value should be controlling; perhaps
you think that the output channel/device should also be controlling?

>> Perhaps
>> something analogous to the stream attributes, but with the ability to
>> control the output format at each invocation, which is not possible with
>> the stream attributes.
> 
> I don't think there is any need in having formats. A few formatting
> parameters could be passed along to Image or equivalent.

Well, parameters and options is what I meant. For example, the ability
to specify blank fill, zero fill, center/left/right alignment, digit
group spacing (1 123 456,00 or 1_123_456.00), etc.

> Environment settings (e.g. locale) should come from the rendering surface
> object. No need to specify them at all. This is how stuff like fonts,
> colors etc is handled in GUI.

A "rendering surface" is not always available at the point where the
string is generated.

There could be a private predefined type for such settings. A value of
that type could be given as a parameter in the Image call to set the
default format (which could then be overridden if the Image call also
has some specific format parameters). A GUI toolkit could have a
function to to return a suitable value of this type from a "rendering
surface" object. I don't see why this, or the output channel, should be
a controlling parameter.

Something like these flexible Image functions already exists in Annex F
(Information Systems), but it is partly template-driven ("picture"-driven).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Something I don't understand

[Mike H]

In message <48278bd6-740c-40aa-b098-e20fe84fe911@googlegroups.com>, 
Laurent <daemon2@internet.lu> writes
>> No need for a loop name.
>
>Not needed yes, but they won't hurt anyone. In this package is not only 
>this loop but a few others.
>So I put named loops instead of comments.
>
It is all a matter of style.

Personally, on seeing a named loop I would take it as a warning that 
something nasty may be intended. Such as jumping out of an inner loop 
and thus risking leaving some unfinished business behind.

-- 
Who is General Failure and why is he reading my hard disc?
Mike

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 14-02-17 14:52 , Simon Clubley wrote:
>> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>    [snip]
>>> A simplified and type-safe version of C's printf style
>>> (template-based) formatting would be more readable than
>>> concatenating a bunch of strings together to print messages,
>>> and MUCH better than using a series of Put calls to print
>>> a single message.
>>>
>> 
>> _Totally_ agree with this.
>
> I disagree, but then I don't understand how Robert would make C's
> template idea type-safe -- might Robert expand on his ideas?
>

Oh, I can see a way in which it can be made fully type safe.

Assume that support for internal to external conversions is implemented
within the type itself as Robert suggests.

Furthermore, assume, as I suggested, that you need to pass a format
parameter to the type in order for the value to be formatted as required.

The Ada version of printf would iterate over the combined format string
and pass the fragment of it intended for the formatting of the current
variable to the variable type's Internal_To_External support routine.

If the passed format fragment was compatible with the data type, the
Internal_To_External routine would process the format and return the
formatted string back to the Ada version of printf so it can be added
into the output buffer.

If, OTOH, the format fragment was incompatible with the data type, the
Internal_To_External support routine within the type would raise a
exception.

And voila, C printf templates in a fully Ada type safe manner.

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Mon, 17 Feb 2014 19:42:07 +0200, Niklas Holsti wrote:

> On 14-02-17 19:17 , Dmitry A. Kazakov wrote:
>> On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote:
>> 
>>> I think that the present method of concatenating strings or using
>>> several Puts is good; what is needed is to extend or replace the 'Image
>>> attribute with similar value-to-string functions which are more
>>> controllable, flexible, and work also for composite types.
>> 
>> Except that all these need to be MD primitive operations. There is no way
>> to solve this without MD.
> 
> Why multiple dispatch?

Print (Display, Shape)

is a textbook example of MD.

> Which would be the multiple controlling
> parameters?

File and Value

> I think only the input value should be controlling; perhaps
> you think that the output channel/device should also be controlling?

Certainly so. Consider ASCII_File, UTF8_File, Gtk_Text_Buffer_Record and so
on. You cannot convert to string before sending it out, because ASCII will
use E for power of 10, UTF8 will use superscript characters for it, and
Gtk_Text_Buffer_Record will do the GTK markup language.
 
>>> Perhaps
>>> something analogous to the stream attributes, but with the ability to
>>> control the output format at each invocation, which is not possible with
>>> the stream attributes.
>> 
>> I don't think there is any need in having formats. A few formatting
>> parameters could be passed along to Image or equivalent.
> 
> Well, parameters and options is what I meant. For example, the ability
> to specify blank fill, zero fill, center/left/right alignment, digit
> group spacing (1 123 456,00 or 1_123_456.00), etc.

Yes, however, from experience, it quickly gets overcomplicated. I customary
use Input_Parameters and Output_Parameters objects as you suggest below.
They must be controlled as well because you want to be able to extend them.

>> Environment settings (e.g. locale) should come from the rendering surface
>> object. No need to specify them at all. This is how stuff like fonts,
>> colors etc is handled in GUI.
> 
> A "rendering surface" is not always available at the point where the
> string is generated.

String itself is such a surface. That is the point of having it controlled.
You can replace it with whatever type, e.g. File, Stream etc. And string
itself is a Universe of types because of encodings.

> There could be a private predefined type for such settings. A value of
> that type could be given as a parameter in the Image call to set the
> default format (which could then be overridden if the Image call also
> has some specific format parameters).

Yes of course, but this is usually another set of parameters. Less volatile
parameters, such as whether to use '.' or ',' to introduce fraction belong
to the surface.

> A GUI toolkit could have a
> function to to return a suitable value of this type from a "rendering
> surface" object.

Possible but tedious.

> I don't see why this, or the output channel, should be
> a controlling parameter.

Because you cannot predict all possible combinations of and because it is a
huge wasting of human and computational resources as no given application
will ever use more than 1% of it.

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

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Mon, 17 Feb 2014 18:13:40 +0000 (UTC), Simon Clubley wrote:

> On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> On 14-02-17 14:52 , Simon Clubley wrote:
>>> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>>    [snip]
>>>> A simplified and type-safe version of C's printf style
>>>> (template-based) formatting would be more readable than
>>>> concatenating a bunch of strings together to print messages,
>>>> and MUCH better than using a series of Put calls to print
>>>> a single message.
>>>>
>>> 
>>> _Totally_ agree with this.
>>
>> I disagree, but then I don't understand how Robert would make C's
>> template idea type-safe -- might Robert expand on his ideas?
> 
> Oh, I can see a way in which it can be made fully type safe.
> 
> Assume that support for internal to external conversions is implemented
> within the type itself as Robert suggests.
> 
> Furthermore, assume, as I suggested, that you need to pass a format
> parameter to the type in order for the value to be formatted as required.
> 
> The Ada version of printf would iterate over the combined format string
> and pass the fragment of it intended for the formatting of the current
> variable to the variable type's Internal_To_External support routine.
> 
> If the passed format fragment was compatible with the data type, the
> Internal_To_External routine would process the format and return the
> formatted string back to the Ada version of printf so it can be added
> into the output buffer.
> 
> If, OTOH, the format fragment was incompatible with the data type, the
> Internal_To_External support routine within the type would raise a
> exception.

Actually it is possible to have it statically type safe with some little
compiler support. Not that I like that style of text formatting, I find it
extremely boring. Ada's style of independent Put and Get is so much better.
Note that even C++ switched to this style, I mean its out<< and in>>
operators.

Anyway, the method is same as GNAT's Spitbol patterns are treated. Instead
of having the format a string, you do it a full-blown type. With terms
(built-in literals) defined to format certain types. The full format is
composed out of terms using operations like "&". You can make it an aspect
if you don't want living objects of the format type, or of a universal type
for similar reasons.

This has two advantages. Firstly, you require the expression be static and
you can check its terms against the types of the values. Secondly the
format need not to be parsed at run time.

> And voila, C printf templates in a fully Ada type safe manner.

Type-safe it is when statically checked.

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

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-17 20:13 , Simon Clubley wrote:
> On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> On 14-02-17 14:52 , Simon Clubley wrote:
>>> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>>    [snip]
>>>> A simplified and type-safe version of C's printf style
>>>> (template-based) formatting would be more readable than
>>>> concatenating a bunch of strings together to print messages,
>>>> and MUCH better than using a series of Put calls to print
>>>> a single message.
>>>>
>>>
>>> _Totally_ agree with this.
>>
>> I disagree, but then I don't understand how Robert would make C's
>> template idea type-safe -- might Robert expand on his ideas?
>>
> 
> Oh, I can see a way in which it can be made fully type safe.
> 
> Assume that support for internal to external conversions is implemented
> within the type itself as Robert suggests.

Ok. So the type comes with some predefined (perhaps overridable) "Image"
function that takes a value of the type and some kind of format
specification.

> Furthermore, assume, as I suggested, that you need to pass a format
> parameter to the type in order for the value to be formatted as required.

Ok.

> The Ada version of printf would iterate over the combined format string
> and pass the fragment of it intended for the formatting of the current
> variable to the variable type's Internal_To_External support routine.

Ok, but yuck... Why collect all the format "fragments" for all ther
variables into one string, which then has to be picked apart again?
According to some convoluted and at the same time limited
syntax-embedded-in-the-string, such as the C "%" stropping.

This invites errors in matching the fragments in the format string with
the variables in the variable sequence, just as in current
template-based systems e.g. C. You add a variable, but forget to add the
format fragment, et cetera. With the current method using string
concatenation, the format parameters are automatically associated with
the right variable, being parameters in the same Image call.

> If the passed format fragment was compatible with the data type, the
> Internal_To_External routine would process the format and return the
> formatted string back to the Ada version of printf so it can be added
> into the output buffer.

In other words, effectively the same as the current string concatenation
method, but with added formatting parameters to the Image functions.
Except that the current method fits in the normal Ada expression syntax
and semantics, but your proposal would be something special, requiring a
variable-length list of variables to be output, like C varargs.

> If, OTOH, the format fragment was incompatible with the data type, the
> Internal_To_External support routine within the type would raise a
> exception.

So this is only *dynamically* type safe, not statically so. Moreover, as
C formats already demonstrate, sooner or later one will run out of
useful and unique letters and format forms, so a format fragment meant
for variable X, of type T, may by mistake be applied to variable Y, of
type S -- and will happen to be valid for that type, too, but will not
produced the desired result.

> And voila, C printf templates in a fully Ada type safe manner.

No, dynamic type safety is not fully "Ada type safe". Ada is (mainly)
statically type safe; dynamism only enters in subtype safety.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Something I don't understand

[Jeffrey Carter]

On 02/17/2014 09:09 AM, Laurent wrote:
>
> As I wrote in my first post the whole thing is an exercise from a book. I'm
> learning programming mostly by myself and it is just an hobby.
>
> So I think it was/is best to stick to the way the author named his variables
> or build his programs.
>
> Book Author's choice
>
> Thanks for the advice but in this case I think I will stick to the formatting
> given in the book.Still have the possibility to adapt it later.

What book/author?

-- 
Jeff Carter
"I'm off to Alaska. If you need me, I'll be at
Frozen Tundra 6-9290."
Play It Again, Sam
130

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> This invites errors in matching the fragments in the format string with
> the variables in the variable sequence, just as in current
> template-based systems e.g. C. You add a variable, but forget to add the
> format fragment, et cetera. With the current method using string
> concatenation, the format parameters are automatically associated with
> the right variable, being parameters in the same Image call.
>

That could be caught at compilation time because there would be a
mismatch between the format string and the number of variables.

>
> So this is only *dynamically* type safe, not statically so. Moreover, as
> C formats already demonstrate, sooner or later one will run out of
> useful and unique letters and format forms, so a format fragment meant
> for variable X, of type T, may by mistake be applied to variable Y, of
> type S -- and will happen to be valid for that type, too, but will not
> produced the desired result.
>
>> And voila, C printf templates in a fully Ada type safe manner.
>
> No, dynamic type safety is not fully "Ada type safe". Ada is (mainly)
> statically type safe; dynamism only enters in subtype safety.
>

I see your point, but it's still better than what the C language itself
provides and it is guaranteed to catch type mismatches even if it's
deferred to runtime.

I wonder if it's possible to do something along the lines of gcc
which looks at the printf format string during compilation and
complains, during compilation, if there's a mismatch detected in
data types.

I am interested to see what Robert's detailed proposals look like or
what any other ideas for printf style template I/O might look like.

Simon.

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

Re: Something I don't understand

[Dennis Lee Bieber]

On Mon, 17 Feb 2014 17:42:39 +0000, Mike H
<postmaster@ada-augusta.demon.co.uk> declaimed the following:

>In message <48278bd6-740c-40aa-b098-e20fe84fe911@googlegroups.com>, 
>Laurent <daemon2@internet.lu> writes
>>> No need for a loop name.
>>
>>Not needed yes, but they won't hurt anyone. In this package is not only 
>>this loop but a few others.
>>So I put named loops instead of comments.
>>
>It is all a matter of style.
>
>Personally, on seeing a named loop I would take it as a warning that 
>something nasty may be intended. Such as jumping out of an inner loop 
>and thus risking leaving some unfinished business behind.

	Along with the minor overhead of the compiler having to keep the label
and address in some internal table until it falls out of scope... <G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-18 02:50 , Simon Clubley wrote:
> On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> This invites errors in matching the fragments in the format string with
>> the variables in the variable sequence, just as in current
>> template-based systems e.g. C. You add a variable, but forget to add the
>> format fragment, et cetera. With the current method using string
>> concatenation, the format parameters are automatically associated with
>> the right variable, being parameters in the same Image call.
>>
> 
> That could be caught at compilation time because there would be a
> mismatch between the format string and the number of variables.

Only if the format string is a static constant, which would be rather
limiting.

> I wonder if it's possible to do something along the lines of gcc
> which looks at the printf format string during compilation and
> complains, during compilation, if there's a mismatch detected in
> data types.

Again, that works only when the format string is a constant, which is
limiting. Some of that limitation can be worked around in C by using the
'*' character in place of a numerical field width or precision, but that
would be more yucky again -- some variables in the list would now
configure the format string, instead of being output, and one would have
to count and match up the format fragments and the variables in the list
to find out which is which.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-17 21:55 , Dmitry A. Kazakov wrote:
> On Mon, 17 Feb 2014 19:42:07 +0200, Niklas Holsti wrote:
> 
>> On 14-02-17 19:17 , Dmitry A. Kazakov wrote:
>>> On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote:
>>>
>>>> I think that the present method of concatenating strings or using
>>>> several Puts is good; what is needed is to extend or replace the 'Image
>>>> attribute with similar value-to-string functions which are more
>>>> controllable, flexible, and work also for composite types.
>>>
>>> Except that all these need to be MD primitive operations. There is no way
>>> to solve this without MD.
>>
>> Why multiple dispatch?
> 
> Print (Display, Shape)
> 
> is a textbook example of MD.
> 
>> Which would be the multiple controlling
>> parameters?
> 
> File and Value
> 
>> I think only the input value should be controlling; perhaps
>> you think that the output channel/device should also be controlling?
> 
> Certainly so. Consider ASCII_File, UTF8_File, Gtk_Text_Buffer_Record and so
> on.

That could be done using overloading based on the expected type of the
Image function result, instead of multiple dispatch. Of course that
would require different types to represent ASCII strings and UTF8
strings, etc. Using different types for different kinds of strings would
be a good thing anyway, IMO (but I know that this causes problems with a
combinatorial explosion of the number of predefined subprograms
involving strings).

> You cannot convert to string before sending it out, because ASCII will
> use E for power of 10, UTF8 will use superscript characters for it, and
> Gtk_Text_Buffer_Record will do the GTK markup language.

Hrm. I'm not at all sure that I would want such different formatting for
different output channels to happen automatically. For one thing, using
superscripts for exponents would prevent or complicate the user's
copy-paste operations, for example copying the output of a Float number
into a calculator accessory.

There should really be a type "Text" that represents text, with all its
complications of encoding, formatting, styles, fonts, lines, paragraphs,
tabulation, indentation, language, ... True, that is horribly complex,
but that's reality now. It is debatable if this should be in the
language, or in toolkits (GUI or others). Probably some core part of it
should be in the language and the rest in a toolkit or in an optional
Annex to the language.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Georg Bauhaus]

On 17/02/14 21:09, Dmitry A. Kazakov wrote:
> Actually it is possible to have it statically type safe with some little
> compiler support.

What does "little compiler support" mean?

> Ada's style of independent Put and Get is so much better.
> Note that even C++ switched to this style, I mean its out<< and in>>
> operators.

C++, however, has automatic template resolution, Ada hasn't.
Nor does Ada have anything more fancy than ordinary types,
no type parameters of types directly, etc. The Spitbol operators
all return Pattern, and they do so for operands of type Pattern,
character stuff, or function pointers only. No MD.

So, I guess we cannot even have C++-like operator<< etc,
without a "little compiler support"?

Re: Text_IO, was: Re: Something I don't understand

[Georg Bauhaus]

On 18/02/14 07:56, Niklas Holsti wrote:
> Only if the format string is a static constant, which would be rather
> limiting.

Starting from some frequent use cases, such as

- logging and similar technical status reports,
- invoices, bank statements and other economic reports

static constant formats would cover a lot. I'd think that
generics, as Mark H noted, might allow for elaborating
minor variations at run-time, at least in some cases.

A big plus of templates is that they are instances of Bentley's
programming pearls, of proven value. They shift the focus from
how the language achieves printing to what is being printed,
the latter being what matters.

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Tue, 18 Feb 2014 08:50:27 +0100, Georg Bauhaus wrote:

> On 17/02/14 21:09, Dmitry A. Kazakov wrote:
>> Actually it is possible to have it statically type safe with some little
>> compiler support.
> 
> What does "little compiler support" mean?

Binding (and checking) terms of the format expression against the types of
values:

   Put
   (  "Index=" & I (Field=>8, Align=>Right) & "X=" & F (10.2),
      (Index, X)
   );

Here I, integer format, must match Index, F, real format must match X.

>> Ada's style of independent Put and Get is so much better.
>> Note that even C++ switched to this style, I mean its out<< and in>>
>> operators.
> 
> C++, however, has automatic template resolution, Ada hasn't.
> Nor does Ada have anything more fancy than ordinary types,
> no type parameters of types directly, etc.

You would need ad-hoc tuples for handling lists of assorted values to
print, as I used in the example above.

Or else you can use aspects which are so messy anyway that whatever harm to
Ada's syntax it would do, it is already done:

   Put (File) with
      Format => ...,
      Value1 => ...,
      ...
      ValueN => ...;

>The Spitbol operators
> all return Pattern, and they do so for operands of type Pattern,
> character stuff, or function pointers only. No MD.

Yes. I prefer a MD solution and no formats at all.
 
> So, I guess we cannot even have C++-like operator<< etc,
> without a "little compiler support"?

But << operators is an MD solution!

I was talking about a formats. Formats is a poor-man's dispatch. Instead of
using the type information from the value, the format specifies the type
explicitly, e.g. %d, reads among other "integer". That introduces nothing
but yet another source of errors. Also when pursued honestly as FORTRAN and
PL did it requires a whole mess of means for formatting arrays (remember
that horror?) and for a modern OO language records, record extensions etc.
Good luck with that.

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

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Tue, 18 Feb 2014 09:14:26 +0200, Niklas Holsti wrote:

> There should really be a type "Text" that represents text, with all its
> complications of encoding, formatting, styles, fonts, lines, paragraphs,
> tabulation, indentation, language, ... True, that is horribly complex,
> but that's reality now. It is debatable if this should be in the
> language, or in toolkits (GUI or others). Probably some core part of it
> should be in the language and the rest in a toolkit or in an optional
> Annex to the language.

You cannot have that type because texts are formatted differently depending
on the medium. Different mediums deploy integrated mechanisms of
formatting. E.g. paging is postponed until rendering if the medium is HTML.
Alignment with proportional fonts is not about fields and decimal places,
etc.

In 80's there were only typewriter's text medium which is why Text_IO looks
as it does. Today there is no way to handle it as single monolithic chunk.
The way to A) modularize it, B) keep it at the library level, is a better
type system. No hacks will really help, IMO.

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

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-18 10:40 , Dmitry A. Kazakov wrote:
> On Tue, 18 Feb 2014 09:14:26 +0200, Niklas Holsti wrote:
> 
>> There should really be a type "Text" that represents text, with all its
>> complications of encoding, formatting, styles, fonts, lines, paragraphs,
>> tabulation, indentation, language, ... True, that is horribly complex,
>> but that's reality now. It is debatable if this should be in the
>> language, or in toolkits (GUI or others). Probably some core part of it
>> should be in the language and the rest in a toolkit or in an optional
>> Annex to the language.
> 
> You cannot have that type

Misunderstanding, I think...

> because texts are formatted differently depending
> on the medium. Different mediums deploy integrated mechanisms of
> formatting. E.g. paging is postponed until rendering if the medium is HTML.
> Alignment with proportional fonts is not about fields and decimal places,
> etc.

Exactly. I meant that the type "Text" would represent text abstractly,
according to its logical structure, not in rendered form. The final
"Put" would then render according to the output medium. Or, if the GUI
and application are split, the rendering might happen in the GUI
process, and the "Put" would just send across some serialization of the
"Text" structure.

> In 80's there were only typewriter's text medium which is why Text_IO looks
> as it does.

At least, programs in the 80's were expected to produce typewriter text.
Typesetting was its own field. But today most programs are expected to
produce web or GUI pages with formatting, proportional fonts, etc.

> Today there is no way to handle it as single monolithic chunk.
> The way to A) modularize it, B) keep it at the library level, is a better
> type system. No hacks will really help, IMO.

I think I agree. But I'm still not convinced that multiple dispatch is
necessary, and we may disagree on how to modularize it.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:

> On 14-02-18 10:40 , Dmitry A. Kazakov wrote:

>> because texts are formatted differently depending
>> on the medium. Different mediums deploy integrated mechanisms of
>> formatting. E.g. paging is postponed until rendering if the medium is HTML.
>> Alignment with proportional fonts is not about fields and decimal places,
>> etc.
> 
> Exactly. I meant that the type "Text" would represent text abstractly,
> according to its logical structure, not in rendered form.

You mean text buffer like in GUI?

To me text buffer, stream, file, string are all instances of the class of
types over which Put dispatches. OK, we can call the abstract root type of
the class "Text."

> The final
> "Put" would then render according to the output medium.

Yes, that Put would be an implementation of the primitive operation defined
for the class Text.

> Or, if the GUI
> and application are split, the rendering might happen in the GUI
> process, and the "Put" would just send across some serialization of the
> "Text" structure.

Yes, however I dislike stateful things, it is difficult to do it otherwise.

>> Today there is no way to handle it as single monolithic chunk.
>> The way to A) modularize it, B) keep it at the library level, is a better
>> type system. No hacks will really help, IMO.
> 
> I think I agree. But I'm still not convinced that multiple dispatch is
> necessary, and we may disagree on how to modularize it.

I think it is only logical for a strongly typed language to map this kind
of stuff onto types. In a language of other type of decomposition, e.g.
functional, I would consider other means. But for Ada I really fail to see
alternatives.

This search for other "ways" (aspects, generics etc) is really damaging the
language.

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

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:
> 
>> On 14-02-18 10:40 , Dmitry A. Kazakov wrote:
> 
>>> because texts are formatted differently depending
>>> on the medium. Different mediums deploy integrated mechanisms of
>>> formatting. E.g. paging is postponed until rendering if the medium is HTML.
>>> Alignment with proportional fonts is not about fields and decimal places,
>>> etc.
>>
>> Exactly. I meant that the type "Text" would represent text abstractly,
>> according to its logical structure, not in rendered form.
> 
> You mean text buffer like in GUI?

Possibly so, but I'm not familiar with GUI text buffers. It sounds like
a similar thing.

> To me text buffer, stream, file, string are all instances of the class of
> types over which Put dispatches. OK, we can call the abstract root type of
> the class "Text."

Perhaps Put would just be overloaded for these types. It depends if you
consider the types a class, or not. I'm not sure what is best.

>> The final
>> "Put" would then render according to the output medium.
> 
> Yes, that Put would be an implementation of the primitive operation defined
> for the class Text.

I would make Text a type, not a class. This would avoid the need for
multiple dispatch on a controlling Text parameter.

I'm thinking of two levels of "Put":

   Put (To : in out Text, Item : in String);
      Add items to a Text, building a logically structured Text,
      but without rendering it yet. This wil probably need
      some concept of "points in a Text where more stuff can
      be inserted" so that the Put can preserve or extend the
      logical Text structure.

   Put (To : in out File; Item : in Text);
      Render the Text into some external File.

The Text buffer intermediary means that each level of Put can (if
desired) be dispatching on one of the parameters, without needing
multiple dispatch.

> I think it is only logical for a strongly typed language to map this kind
> of stuff onto types.

I agree.

> This search for other "ways" (aspects, generics etc) is really damaging the
> language.

I don't agree. I see aspects as strengthening or broadening the type
concept, and generics as a meta-type level. But I must admit that I have
lately been using generics less often and have instead used classes and
dispaching more often. However, I think that generics are useful and are
not entirely subsumed by classes.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote:

> On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:

>> To me text buffer, stream, file, string are all instances of the class of
>> types over which Put dispatches. OK, we can call the abstract root type of
>> the class "Text."
> 
> Perhaps Put would just be overloaded for these types. It depends if you
> consider the types a class, or not. I'm not sure what is best.

When you overload you get an explosion of variants which is especially
extreme in the case of MD, because you have N x M x L variants. It is
exponential to the number of independent hierarchies. For I/O it is at
least 3: medium, data, aggregated parameters. Fourth candidate could be
transaction state for complex I/O.

Another and even more serious issue is that ad-hoc polymorphism prevents
code reuse. You cannot inherit, you cannot write class-wide code because
you cannot have class-wide objects. Yet a typical usage of Text_IO is
class-wide. When designing a text processing or text rendering application
you don't want to deal with concrete types of medium. E.g. writing an
interpreter you want it working with whatever type of input, not just
string or just File_Type.

>>> The final
>>> "Put" would then render according to the output medium.
>> 
>> Yes, that Put would be an implementation of the primitive operation defined
>> for the class Text.
> 
> I would make Text a type, not a class. This would avoid the need for
> multiple dispatch on a controlling Text parameter.
> 
> I'm thinking of two levels of "Put":
> 
>    Put (To : in out Text, Item : in String);
>       Add items to a Text, building a logically structured Text,
>       but without rendering it yet. This wil probably need
>       some concept of "points in a Text where more stuff can
>       be inserted" so that the Put can preserve or extend the
>       logical Text structure.
> 
>    Put (To : in out File; Item : in Text);
>       Render the Text into some external File.
> 
> The Text buffer intermediary means that each level of Put can (if
> desired) be dispatching on one of the parameters, without needing
> multiple dispatch.

This was attempted before, many many times, actually. From PostScript to
HTML, an intermediate language that would take care of separating higher
level formatting from lower level rendering. It never worked how many times
tried.

And for sure, it will be even more hated than Text_IO page formatting is,
because the overhead will be far bigger. Imagine describing the semantics
of, say, conversion of File, Stream, String to Text and backward.

>> This search for other "ways" (aspects, generics etc) is really damaging the
>> language.
> 
> I don't agree. I see aspects as strengthening or broadening the type
> concept, and generics as a meta-type level.

Either is a parametrization. Parametrization does not broaden anything,
when held at the meta level. You can parametrize type, statement, object,
package, source code itself, you could even do the object code. It is
completely orthogonal to what is being parametrized and by which entities.

Parametrization is bad when the parametric entity is itself not a language
entity. E.g. discriminaned type is OK, because it is still a type. Generic
type is not OK, because it is not a type but something else. The latter is
an erosion of the type system not broadening.

> But I must admit that I have
> lately been using generics less often and have instead used classes and
> dispaching more often. However, I think that generics are useful and are
> not entirely subsumed by classes.

Both are classes, the means of constructing these classes are different and
so are the properties and usage of these classes.

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

Re: Something I don't understand

[Laurent]

> 
> What book/author?

> 
> Jeff Carter

Ada 95:Problem Solving and Program Design by Michael B. Feldman, Elliot B. Koffman

3rd Edition (1999)

Not very recent lecture but I like the way how problems are described and solved. Also the reason why
I chose Ada and not Java. Visited an evening course for Java (+/- 30hrs). Found that the documentation used was unstructured/ confuse, missing clear examples and exercises.

Thanks

Laurent

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-19 11:40 , Dmitry A. Kazakov wrote:
> On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote:
> 
>> On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
>>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:
> 
>>> To me text buffer, stream, file, string are all instances of the class of
>>> types over which Put dispatches. OK, we can call the abstract root type of
>>> the class "Text."

My notion of type "Text" is an internal representation of text meant for
human reading and viewing. I don't see any logical need for making this
type a class; there would be only one predefined (and private) type.

(There might be some technical reasons for making the type a class, for
example with a root type that is low-cost but simple, and some derived
classes which provide more functionality but at greater cost. Perhaps
the simple root type would be a mandatory language feature, and the
derived classes optional features.)

By the way, perhaps the word "text" is ambiguous. I think it is time to
make a clear distinction between:

(1) a text file (sometimes called an "ASCI file"), which is a sequence
of basic symbols (e.g. Character or Wide_Character) used to represent
*data* for either reading by another program, or for human reading
(without formatting), and

(2) a text meant only for human reading/viewing and therefore to be
rendered as nicely and readably as the chosen viewing device allows.
That some parts of the text can be seen as sequences of characters is
secondary, and the specific characters and their sequence can change
according to the rendering.

Ada.Text_IO implements mainly (1), with some basic support for
typewriter-style formatting (column spacing, line spacing, page tracking).

The "Text" type I am talking about aims to be the internal
representation of (2), before rendering on some viewing device.

>> I'm thinking of two levels of "Put":
>>
>>    Put (To : in out Text, Item : in String);
>>       Add items to a Text, building a logically structured Text,
>>       but without rendering it yet. This wil probably need
>>       some concept of "points in a Text where more stuff can
>>       be inserted" so that the Put can preserve or extend the
>>       logical Text structure.
>>
>>    Put (To : in out File; Item : in Text);
>>       Render the Text into some external File.
>>
>> The Text buffer intermediary means that each level of Put can (if
>> desired) be dispatching on one of the parameters, without needing
>> multiple dispatch.
> 
> This was attempted before, many many times, actually. From PostScript to
> HTML, an intermediate language that would take care of separating higher
> level formatting from lower level rendering. It never worked how many times
> tried.

Uh... surely PostScript and HTML "work". I'm pretty sure that a large
fraction, perhaps even a majority of programs today generate most of
their human-readable output as HTML. Even if the final HTML generation
is delegated to some web-application framework.

> And for sure, it will be even more hated than Text_IO page formatting is,
> because the overhead will be far bigger. Imagine describing the semantics
> of, say, conversion of File, Stream, String to Text and backward.

Overhead compared to what? If the need is to generate nicely formatted
output, rendered in device-specific ways, and typewriter formatting is
not enough, what is the alternative?

The overheads of Text_IO are important only when processing large text
*data* files (meaning (1) of "text"). For generating human-readable text
(meaning (2)), especially in an interactive context, the overheads are
utterly negligible.

I don't see any need for converting a File/Stream *into* Text, unless
the File/Stream is a serialized representation of the full internal
structure of a Text object, in which case the File/Stream structure is
private and normal serialization/deserialization methods apply.

I don't intend that the type "Text" should be so fancy and complete that
it could be used as such to implement an advanced word processor.
Following the same rationale as Ada.Containers, "Text" should provide as
much functionality as can be expected to be useful for (and used by)
many Ada programs and programmers, but programmers requiring high
performance or high/specific functionality would have to implement more
advanced "text" representations themselves.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Wed, 19 Feb 2014 15:20:18 +0200, Niklas Holsti wrote:

> On 14-02-19 11:40 , Dmitry A. Kazakov wrote:
>> On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote:
>> 
>>> On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
>>>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:
>> 
>>>> To me text buffer, stream, file, string are all instances of the class of
>>>> types over which Put dispatches. OK, we can call the abstract root type of
>>>> the class "Text."
> 
> My notion of type "Text" is an internal representation of text meant for
> human reading and viewing. I don't see any logical need for making this
> type a class; there would be only one predefined (and private) type.

Class is needed because there must be more than one implementation of the
interface and because the interface itself need to be extended in order to
have Ada library implementations of reasonable size and complexity.

> By the way, perhaps the word "text" is ambiguous. I think it is time to
> make a clear distinction between:
> 
> (1) a text file (sometimes called an "ASCI file"), which is a sequence
> of basic symbols (e.g. Character or Wide_Character) used to represent
> *data* for either reading by another program, or for human reading
> (without formatting), and

Sequence of symbols is a string.

Text is at least a sequence of strings (lines).
 
> (2) a text meant only for human reading/viewing and therefore to be
> rendered as nicely and readably as the chosen viewing device allows.
> That some parts of the text can be seen as sequences of characters is
> secondary, and the specific characters and their sequence can change
> according to the rendering.

Rendered text is a text so long the reader can reconstruct (1) from (2). So
in effect (1) and (2) are equivalent in the sense that both are (1).

> Ada.Text_IO implements mainly (1), with some basic support for
> typewriter-style formatting (column spacing, line spacing, page tracking).
> 
> The "Text" type I am talking about aims to be the internal
> representation of (2), before rendering on some viewing device.

Why should anybody care about (2)? Why Text_IO should have anything to do
with (1)? One of the issues Text_IO had was inference into text issues
(e.g. pages etc). There is nothing wrong with pages except that 80% of
formatting and editing does not care about pages. The result is abstraction
inversion, and you want to make it only worse.

>>> I'm thinking of two levels of "Put":
>>>
>>>    Put (To : in out Text, Item : in String);
>>>       Add items to a Text, building a logically structured Text,
>>>       but without rendering it yet. This wil probably need
>>>       some concept of "points in a Text where more stuff can
>>>       be inserted" so that the Put can preserve or extend the
>>>       logical Text structure.
>>>
>>>    Put (To : in out File; Item : in Text);
>>>       Render the Text into some external File.
>>>
>>> The Text buffer intermediary means that each level of Put can (if
>>> desired) be dispatching on one of the parameters, without needing
>>> multiple dispatch.
>> 
>> This was attempted before, many many times, actually. From PostScript to
>> HTML, an intermediate language that would take care of separating higher
>> level formatting from lower level rendering. It never worked how many times
>> tried.
> 
> Uh... surely PostScript and HTML "work". I'm pretty sure that a large
> fraction, perhaps even a majority of programs today generate most of
> their human-readable output as HTML.

Which is why quality of text is so miserable and why the modern OS makes a
i486 out of whatever many cores, gigahertz and terabytes monster you run it
on.

And of course generating HTML or parsing it is no way simpler than
traditional formatting in any sense of that.

>> And for sure, it will be even more hated than Text_IO page formatting is,
>> because the overhead will be far bigger. Imagine describing the semantics
>> of, say, conversion of File, Stream, String to Text and backward.
> 
> Overhead compared to what?

Compared to direct dispatch to the implementation tailored for the give
medium. Why do I need HTML in order to write a stream or memory string?

> If the need is to generate nicely formatted
> output, rendered in device-specific ways, and typewriter formatting is
> not enough, what is the alternative?

I don't understand the question. It is not about alternatives, the
formatting must be done. It is about decomposition of the task into
software components. I don't want any middlemen especially such that in
order of magnitude more complex than direct formatting.

> The overheads of Text_IO are important only when processing large text
> *data* files (meaning (1) of "text"). For generating human-readable text
> (meaning (2)), especially in an interactive context, the overheads are
> utterly negligible.

It is not completely true. Huge amounts of readable texts are processed
without any human intervention. For those Text_IO performance is a big
problem: Ada project compilation, syntax highlighting, WYSIWYG text
processing etc.

> I don't see any need for converting a File/Stream *into* Text, unless
> the File/Stream is a serialized representation of the full internal
> structure of a Text object, in which case the File/Stream structure is
> private and normal serialization/deserialization methods apply.

But your proposal was:

   procedure Get (From : in out Text; Value : out Integer);
   procedure Get (From : in out File_Type; Item : out Text);

You must create a text object in order to apply type-specific Get operation
on it.

When you emulate MD through cascaded dispatch, and this is what you are
doing, you need temp objects to carry intermediate states. That will be
very expensive for I/O, and extremely complicated because I/O is a stateful
thing. You will have a hell of coordinating the states of the file and its
text proxy.

> I don't intend that the type "Text" should be so fancy and complete that
> it could be used as such to implement an advanced word processor.
> Following the same rationale as Ada.Containers, "Text" should provide as
> much functionality as can be expected to be useful for (and used by)
> many Ada programs and programmers, but programmers requiring high
> performance or high/specific functionality would have to implement more
> advanced "text" representations themselves.

And so you need it extensible, ergo, a class.

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

Re: Text_IO, was: Re: Something I don't understand

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> My notion of type "Text" is an internal representation of text meant for
> human reading and viewing. I don't see any logical need for making this
> type a class; there would be only one predefined (and private) type.

How is your notion of Text different from (say) HTML?
Or an internal tree-ish representation of HTML?

Anyway, I'd say your notion of Text has nothing to do with Text_IO,
which is about plain unformatted text.  Originally 7-bit ASCII.

- Bob

Re: Text_IO, was: Re: Something I don't understand

[Georg Bauhaus]

On 19.02.14 15:13, Dmitry A. Kazakov wrote:
> Compared to direct dispatch to the implementation tailored for the give
> medium. Why do I need HTML in order to write a stream or memory string?

The normal use case for HTML is when there are at least
two computer systems involved:

(1)  one sending documents (->), and receiving requests (<-),
   ███████████████████████████ ███████████████████████████
(2)  one receiving documents (<-), and sending requests (->),

such that each of them is controlled exclusively by
different parties. There is no dispatching, because
a common dispatcher is an impossible part of the setup.
(IOW, the possibility is only a mathematical one, whenever
it refuses to include earthly constraints of the setup.)

The media types of CSS will allow an HTML processor to render
the same HTML on a number of different devices. Still, no MD.

However, once the equivalence class of XSL is taken
into account, you get MD, at least conceptually. But it
happens outside the "producer" program (1).

Re: Text_IO, was: Re: Something I don't understand

[Laurent]

Quite interesting to see that my noob question started such a long discussion.
Wouldn't it be better to move it to an own thread or the ada hacker list if such a thing exits?

Laurent

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-19 17:06 , Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> My notion of type "Text" is an internal representation of text meant for
>> human reading and viewing. I don't see any logical need for making this
>> type a class; there would be only one predefined (and private) type.
> 
> How is your notion of Text different from (say) HTML?

Because "Text" is an internal form with a hidden implementation.

> Or an internal tree-ish representation of HTML?

More or less. Think "abstract syntax tree" instead of "concrete language
sentence". Or "Document Object Model".

> Anyway, I'd say your notion of Text has nothing to do with Text_IO,
> which is about plain unformatted text.  Originally 7-bit ASCII.

Yes, Text_IO is about plain unformatted text, except for "typewriter
formatting" with column, line, and page controls.

The discussion was about how to improve the text (output) facilities of
Ada. The abstract "Text" structure is one suggestion. But it should
perhaps be called something else, to avoid confusing Ada.Text_IO with
Ada.Text.IO :-) Anyway, I'm not suggesting "Text" input, only "Text" output.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-19, Laurent <daemon2@internet.lu> wrote:
> Quite interesting to see that my noob question started such a long discussion.
> Wouldn't it be better to move it to an own thread or the ada hacker list if such a thing exits?
>

I changed the subject line when I asked my question; this is the usual
way to handle a digression in a thread.

The subject line on your message (which I am replying to) is:

Subject: Re: Text_IO, was: Re: Something I don't understand

I see you are using Google Groups as your newsreader however so you may
not have seen the subject line change.

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[Robert A Duff]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>> Input should be separate from output.  Put(Stream, X), where X is an
>> integer makes sense, because we know X is an integer.  Get(X)
>> makes no sense, because we have no idea what the user is going
>> to type.  For text input, you need "read the next token, and tell
>> me what it is", not "read an integer token, and blow up if the
>> user typed something else".
>
> While the current input routines need replacing, I don't agree with the
> Ada RTL trying to work out what the input format is and pass a token
> type back to the program. The problem is that unless you are careful,
> you can end up with a Excel type solution in which it works most of
> the time but fails when it thinks it knows better than you do what
> you entered.

Right, it's not at all clear that this should be part of the language.
But my "read the next token, and tell me what it is" method is how
it should normally be done, and if the language doesn't support it,
then the programmer will do that, which is fine.

But the "read an integer token, and blow up if the user typed something
else" method is rarely useful.  I'd stick with "read a character",
"read a line", and "read the whole file".

> For example, consider the input "123,456".
>
> Is the user entering a array of two numbers ?
>
> Is the user entering one number but with a thousands seperator ?
>
> Is the user in mainland Europe and hence is really entering "123.456" ?
>
> Should this input be treated as a string (because it has a comma in it)
> or should the Ada RTL impose it's idea of a number and convert the
> input into some standard format even though that may not look anything
> like what the user meant ?

All good questions, that are perhaps best left up to the programmer.

> What happens when the final destination is a range limited data type ?

All integer types in Ada are range-limited.  I'd prefer to
allow unbounded integers.

> You either have to still do the checking manually or take a exception
> if the input value is outside of the range of the data type.
>
>> A simplified and type-safe version of C's printf style
>> (template-based) formatting would be more readable than
>> concatenating a bunch of strings together to print messages,
>> and MUCH better than using a series of Put calls to print
>> a single message.
>>
>
> _Totally_ agree with this. It would also be nice if one could write
> something like this (pseudo Fortran style to get the idea across):
> "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth
> (in this example) of data cleanly.

That's not really what I meant by "simplified".  ;-)

>> There should be a convenient way to read an entire file into
>> a String.  Similar for writing.
>
> Yes, but you may need two methods. One for binary (unchanged) input and
> one for text input with end of line conversions.

Maybe.  Should the binary one return a String, or an array of bytes,
or something else?

- Bob

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-19 16:13 , Dmitry A. Kazakov wrote:
> On Wed, 19 Feb 2014 15:20:18 +0200, Niklas Holsti wrote:
> 
>> On 14-02-19 11:40 , Dmitry A. Kazakov wrote:
>>> On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote:
>>>
>>>> On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
>>>>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:
>>>
>>>>> To me text buffer, stream, file, string are all instances of the class of
>>>>> types over which Put dispatches. OK, we can call the abstract root type of
>>>>> the class "Text."
>>
>> My notion of type "Text" is an internal representation of text meant for
>> human reading and viewing. I don't see any logical need for making this
>> type a class; there would be only one predefined (and private) type.
> 
> Class is needed because there must be more than one implementation of the
> interface

Why? It is not expected that there should be more than one
implementation, in the same Ada program, of Ada.Containers.Vectors, for
example.

The "Text" type I am talking about is kind of a container for structured
text ("text" as in meaning (2) below).

> and because the interface itself need to be extended in order to
> have Ada library implementations of reasonable size and complexity.

That does not convince me. Mere volume (e.g. number of operations) is
not, to me, a reason for splitting a coherent interface into different
packages.

>> By the way, perhaps the word "text" is ambiguous. I think it is time to
>> make a clear distinction between:
>>
>> (1) a text file (sometimes called an "ASCI file"), which is a sequence
>> of basic symbols (e.g. Character or Wide_Character) used to represent
>> *data* for either reading by another program, or for human reading
>> (without formatting), and
> 
> Sequence of symbols is a string.
> 
> Text is at least a sequence of strings (lines).

True for meaning (1), false for meaning (2) (see below).

Text (in meaning (2)) is a sequence of paragraphs (with more structure
at both higher and lower levels). Lines only appear after the text (2)
is rendered.

>> (2) a text meant only for human reading/viewing and therefore to be
>> rendered as nicely and readably as the chosen viewing device allows.
>> That some parts of the text can be seen as sequences of characters is
>> secondary, and the specific characters and their sequence can change
>> according to the rendering.
> 
> Rendered text is a text so long the reader can reconstruct (1) from (2). So
> in effect (1) and (2) are equivalent in the sense that both are (1).

No, text (2) is *not* the result of rendering text (1). Text (2) is
logically structured text (probably some kind of tree) that has been
deliberately constructed to have structure.

There are, of course, forms of text (1), such as HTML or other mark-up
languages, which can represent text (2) and which can be interpreted
into text (2) which can then be rendered. It is also possible to extract
character strings from rendered text (2), discarding the structure --
for example, PDF-to-text conversion.

The existence of such interpretations or lossy conversions does not mean
that text (1) and text (2) are equivalent.

To make it very concrete: under Windows you use Notepad to create text
(1), but MS-Word to create text (2).

>> Ada.Text_IO implements mainly (1), with some basic support for
>> typewriter-style formatting (column spacing, line spacing, page tracking).
>>
>> The "Text" type I am talking about aims to be the internal
>> representation of (2), before rendering on some viewing device.
> 
> Why should anybody care about (2)?

Because users want to see nicely formatted output, and I am suggesting
that text (2) is a way to implement that in Ada, by separating the
logical construction of the text (2) from its rendering. As you say,
this is very like the idea of HTML, but HTML has other aims, too
(hypertext, web forms, ...)

I thought we (that is, you and I, perhaps not the other participants in
the thread) were discussing improving the ability to emit nicely
formatted, readable text from Ada programs. If not, I'll stop here.

> Why Text_IO should have anything to do with (1)?

Text (1) can also be processed with Sequential_IO, but usually text (1)
is divided into syntactical, meaningful tokens, such as keywords or
decimal numbers, and Text_IO provides (rudimentary) facilities for
generating such tokens on output, and lexically scanning and evaluating
such tokens on input.

The situation is the same in other programming languages, which all
provide such token-oriented input-output for text (1) files. For example
printf/scanf in C.

> One of the issues Text_IO had was inference into text issues
> (e.g. pages etc). There is nothing wrong with pages except that 80% of
> formatting and editing does not care about pages.

That is true today, because output to printed paper sheets plays such a
small role today. Decades ago, when such output was very common at least
in information systems, pagination was quite important. Think Report
Generator, page headers/footers, page subtotals, page numbering... Of
course it can all be programmed without pagination support in Text_IO,
but that is the old argument about do-it-yourself vs. standard libraries
or standard language facilities.

OMG, this argument is old... Algol 60 left the definition of I/O
facilities to the implementation... Algol 68 put standard I/O for text
(1) into the language.

> The result is abstraction inversion, and you want to make it
> only worse.

I don't see that at all.

>>>> I'm thinking of two levels of "Put":
>>>>
>>>>    Put (To : in out Text, Item : in String);
>>>>       Add items to a Text, building a logically structured Text,
>>>>       but without rendering it yet. This wil probably need
>>>>       some concept of "points in a Text where more stuff can
>>>>       be inserted" so that the Put can preserve or extend the
>>>>       logical Text structure.
>>>>
>>>>    Put (To : in out File; Item : in Text);
>>>>       Render the Text into some external File.
>>>>
>>>> The Text buffer intermediary means that each level of Put can (if
>>>> desired) be dispatching on one of the parameters, without needing
>>>> multiple dispatch.
>>>
>>> This was attempted before, many many times, actually. From PostScript to
>>> HTML, an intermediate language that would take care of separating higher
>>> level formatting from lower level rendering. It never worked how many times
>>> tried.
>>
>> Uh... surely PostScript and HTML "work". I'm pretty sure that a large
>> fraction, perhaps even a majority of programs today generate most of
>> their human-readable output as HTML.
> 
> Which is why quality of text is so miserable and why the modern OS makes a
> i486 out of whatever many cores, gigahertz and terabytes monster you run it
> on.

You are changing the issue from "works" to "needs a lot of resources and
is misused". So you lose the argument :-)

> And of course generating HTML or parsing it is no way simpler than
> traditional formatting in any sense of that.

What do you mean by "traditional formatting"?

I'm not suggesting that the Ada programer would write code to generate
HTML. The Ada programmer's code would create a "Text" (i.e. a text (2)),
which can be output as HTML, if it is emitted to a device/file/channel
which wants HTML. To other devices the same "Text" could be emitted in
other forms. A GUI toolkit could use its own text-rendering functions to
render the "Text" in a window.

>>> And for sure, it will be even more hated than Text_IO page formatting is,
>>> because the overhead will be far bigger. Imagine describing the semantics
>>> of, say, conversion of File, Stream, String to Text and backward.
>>
>> Overhead compared to what?
> 
> Compared to direct dispatch to the implementation tailored for the give
> medium. Why do I need HTML in order to write a stream or memory string?

Stream or memory string are text (1), not text (2).

I'm not suggesting that Text_IO should be removed. Of course Ada
programs must be able to read and write files of text (1). It may even
be desirable to extend the token-level formatting abilities of Text_IO
or the Image functions, either by more parameters or by templates or
pictures.

But my main point is that if our goal is text formatted to modern
standards of appearance (with proportional fonts et cetera) then the
rendering cannot be made token by token, or Put (item) by Put (item);
the renderer must work on a whole text (2). Just as a browser must have
a whole HTML <table> in order to display any cell of the table in its
final form.

>> If the need is to generate nicely formatted
>> output, rendered in device-specific ways, and typewriter formatting is
>> not enough, what is the alternative?
> 
> I don't understand the question. It is not about alternatives, the
> formatting must be done. It is about decomposition of the task into
> software components. I don't want any middlemen especially such that in
> order of magnitude more complex than direct formatting.

Can you give an example of what you mean by "direct formatting"?

>> The overheads of Text_IO are important only when processing large text
>> *data* files (meaning (1) of "text"). For generating human-readable text
>> (meaning (2)), especially in an interactive context, the overheads are
>> utterly negligible.
> 
> It is not completely true. Huge amounts of readable texts are processed
> without any human intervention. For those Text_IO performance is a big
> problem: Ada project compilation,

Ada source-code is clearly text (1), text as data, even if it is also
human-readable and human-writable. I agree that Text_IO overhead can be
significant in text (1) processing, as I said. I believe that GNAT, for
example, reads its source files by mapping the whole file into memory,
and does not use Text_IO, and not even the OS bulk read() function. (But
such tricks are of course system-specific, non-standard.)

> syntax highlighting, WYSIWYG text processing etc.

If you are talking about interactive applications, at most a screenful
of text is shown at a time, therefore Text_IO overheads would be
insignificant. But I think that this kind of application would not use
Text_IO anyway, because the formatting capabilities of Text_IO would not
be sufficient. My proposed "Text", that is text (2), should work better.

>> I don't see any need for converting a File/Stream *into* Text, unless
>> the File/Stream is a serialized representation of the full internal
>> structure of a Text object, in which case the File/Stream structure is
>> private and normal serialization/deserialization methods apply.
> 
> But your proposal was:
> 
>    procedure Get (From : in out Text; Value : out Integer);
>    procedure Get (From : in out File_Type; Item : out Text);

No, I proposed Put operations, not Get operations. "Text" (that is, text
(2)) is meant only for output, not for input. For input, use text (1).

Not all output is symmetric with input. Think about an audio device: it
is simple to generate audio containing any specified mix and score of
pure tones or instrument voices; it would be much more difficult to
recover the same score and instrument/voice parameters by digitizing and
analysing the generated audio signal. Even more so for the analogous
input/output of video.

>> I don't intend that the type "Text" should be so fancy and complete that
>> it could be used as such to implement an advanced word processor.
>> Following the same rationale as Ada.Containers, "Text" should provide as
>> much functionality as can be expected to be useful for (and used by)
>> many Ada programs and programmers, but programmers requiring high
>> performance or high/specific functionality would have to implement more
>> advanced "text" representations themselves.
> 
> And so you need it extensible, ergo, a class.

Not so, if we accept the same rationale as for Ada.Containers: they are
meant for use in applications without extreme or special demands on the
performance of the containers. The Ada container types are tagged types,
but you cannot create a better-performing or significantly more
functional container by deriving from a container type; you can only
extend the interface with new operations or override some operations to
work differently.

Ok, so that leads to ad-hoc polymorphism, which has some draw-backs, as
you have explained. But IMO not a show-stopper.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> I disagree, but then I don't understand how Robert would make C's
> template idea type-safe -- might Robert expand on his ideas?

Most people call me "Bob".  Yeah, I know my "From:" line say "Robert".  ;-)

My answer depends on if (or how much) I'm allowed to change Ada's type
system.  I've done this in pure standard Ada.  Something like:

    type Template is new String;
    procedure Put(T: Template; X1, X2, X3, X4, X5, X6, X7, X8: String := "");

Put("There were \1 warnings and \2 errors.\n",
    Image(Warning_Count), Image(Error_Count));

prints the template as is to standard output, except it replaces \1 with
X1, and \2 with X2, and the "\n" is new-line.  You can have multi-line
templates.  "\\" represents "\".

Note my use of X1...X8 to simulate C's variable-length parameter
lists.  This is a kludge.

Note that Template is a different type from String.  This prevents
a bug that can happen in C, where you say printf(blah), and blah
is some data read off the internet.  That can be a security hole!

The user is responsible for writing suitable Image functions
for their data types, and they can take whatever formatting
parameters you like.  This seems much more readable than C's
way of encoding the field widths and whatnot in the template.

For localization/internationalization, you can have a table
mapping "There were \1 warnings and \2 errors.\n" to the
corresponding template in (say) French.  Different languages
have different word orders, so you might have:

    "... \2 ... \1 ... \n"

to reverse the order of insertion.

This is all 100% type safe.  Most of the checking is static.
It checks at run time that the number of \1, \2, \3, ... escapes
matches the number of non-empty Xn parameters passed.

Now, if you let me change Ada, I'd allow user-defined literals.
Any type derived from the Has_Literals interface allows
literal syntax, and it overrides the Literal_Value function
to convert the sequence of characters to that type.
Template would no longer need to be derived from String; it
could be a private extension of Has_Literals, and the Literal_Value
function could "precompile" the template into some convenient/efficient
internal form.

The Literal_Value call is evaluated at compile time, so the
above-mentioned run-time check can now be static.

Change the types of the Xn parameters to Has_Image'Class,
so you can pass Warning_Count, and it automatically dispatches
to Image(Warning_Count).  If you want to use extra formatting
options you'd call your own Image function explicitly.
Integer types are derived from Has_Image, and the Image function
is not an attribute, and (most importantly of all! ;-))
it doesn't insert an annoying extra blank.

I'd also allow variable-length argument lists and/or arrays of strings.

> I think that the present method of concatenating strings or using
> several Puts is good; 

I think Put (at least to standard output/error) should be task safe.
That is, it should be atomic with respect to other tasks doing Put.
Puts from different tasks would be interspersed, but you wouldn't
get character-by-character interspersal, and you certainly wouldn't
get the Ada rule ("erroneous and therefore unpredictable behavior").

That rules out the "series of Puts" method.  You need to build up
your whole message (possibly multi-line) and then Put it in one
fell swoop.

The concatenating strings method just looks ugly to me -- I can't easily
see what the message is going to look like.  With a template, I see
the whole message, with marks for where variable data is inserted.

>...what is needed is to extend or replace the 'Image
> attribute with similar value-to-string functions which are more
> controllable, flexible, and work also for composite types. Perhaps
> something analogous to the stream attributes, but with the ability to
> control the output format at each invocation, which is not possible with
> the stream attributes.

It is odd that in Ada, 'Image doesn't support the same formatting
control as Text_IO.

- Bob

Re: Text_IO, was: Re: Something I don't understand

[Robert A Duff]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> And voila, C printf templates in a fully Ada type safe manner.

Note that C printf templates are type safe (statically!) if you use
gcc, and if you always use statically-known templates (which in my
experience is true approximately 100% of the time).

- Bob

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-19, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>> _Totally_ agree with this. It would also be nice if one could write
>> something like this (pseudo Fortran style to get the idea across):
>> "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth
>> (in this example) of data cleanly.
>
> That's not really what I meant by "simplified".  ;-)
>

:-)

>>
>> Yes, but you may need two methods. One for binary (unchanged) input and
>> one for text input with end of line conversions.
>
> Maybe.  Should the binary one return a String, or an array of bytes,
> or something else?
>

Conceptually, I would have to say an array of bytes data type distinct
from a String. This is based on my perception of a String as been
associated with text data (after all, it _is_ called a String :-)) and
that conceptually you cannot really assign such meaning to something
you have gone to the trouble to read as binary data.

What really matters is that you can guarantee the binary data will not
be altered during the I/O process, that you know the exact length of
the data, and that you can cleanly access the bytes in the binary data.

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> No, dynamic type safety is not fully "Ada type safe". Ada is (mainly)
> statically type safe; dynamism only enters in subtype safety.

Well, if you take the view that "types" are "those things that can be
checked statically", then all programming languages are statically type
safe, rendering the notion meaningless.  Even something like 'bash',
which has only one (static) type.  In this view, 'bash' does zero static
type checking, yet all the type checking it does is static.

In other words, the term "subtype" in Ada is a cheat, deliberately used
to enable bogus claims about static type safety in Ada, as if the
run-time checks associated with subtypes somehow don't count.

- Bob

Re: Text_IO, was: Re: Something I don't understand

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 14-02-19 17:06 , Robert A Duff wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> 
>>> My notion of type "Text" is an internal representation of text meant for
>>> human reading and viewing. I don't see any logical need for making this
>>> type a class; there would be only one predefined (and private) type.
>> 
>> How is your notion of Text different from (say) HTML?
>
> Because "Text" is an internal form with a hidden implementation.
>
>> Or an internal tree-ish representation of HTML?
>
> More or less. Think "abstract syntax tree" instead of "concrete language
> sentence". Or "Document Object Model".

So what you're asking for is an Ada binding to HTML (or to
Postscript, or something).

>> Anyway, I'd say your notion of Text has nothing to do with Text_IO,
>> which is about plain unformatted text.  Originally 7-bit ASCII.
>
> Yes, Text_IO is about plain unformatted text, except for "typewriter
> formatting" with column, line, and page controls.

Right, what I meant is that if your notion of Text were added
to Ada, it should not replace Text_IO.  There's still a need for
simple I/O of simple sequences of characters.

What Text_IO SHOULD be about is plain text.  I'd get rid of the
page-related stuff, and I'd get rid of the line and column counters
-- we don't need that level of "formatting".

Of course, I'm just criticizing the design.  I'm not suggesting that
it should be changed now.  It should have been changed in 1979.
Compatibility rules!

> The discussion was about how to improve the text (output) facilities of
> Ada. The abstract "Text" structure is one suggestion. But it should
> perhaps be called something else, to avoid confusing Ada.Text_IO with
> Ada.Text.IO :-) Anyway, I'm not suggesting "Text" input, only "Text" output.

Understood.

- Bob

Re: Text_IO, was: Re: Something I don't understand

[Jeffrey Carter]

On 02/19/2014 02:46 PM, Robert A Duff wrote:
>
> Put("There were \1 warnings and \2 errors.\n",
>      Image(Warning_Count), Image(Error_Count));

And then you end up with

There were 1 warnings and 1 errors.

I suppose you could have

Put ("There were \1 \2 and \3 \4.\n",
      Image (Warning_Count),
      (if Warning_Count = 1 then "warning" else "warnings"),
      Image (Error_Count),
      (if Error_Count = 1 then "error" else "errors") );

but then the Template is essentially unreadable.


Put ("There were \1 warning\2 and \3 error\4.\n",
      Image (Warning_Count),
      (if Warning_Count = 1 then "" else "s"),
      Image (Error_Count),
      (if Error_Count = 1 then "" else "s") );

but then you can't use "" to indicate the end of the strings to include in the 
output.

Any way you approach it is ugly. There should be some way to deal with this that 
is simpler and easier than what we have.

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-19, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> And voila, C printf templates in a fully Ada type safe manner.
>
> Note that C printf templates are type safe (statically!) if you use
> gcc, and if you always use statically-known templates (which in my
> experience is true approximately 100% of the time).
>

Note to self: Next time, don't use the phrase "And voila" as a casual
afterthought without actually thinking things through a bit more. :-)

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-19, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 02/19/2014 02:46 PM, Robert A Duff wrote:
>>
>> Put("There were \1 warnings and \2 errors.\n",
>>      Image(Warning_Count), Image(Error_Count));
>
> And then you end up with
>
> There were 1 warnings and 1 errors.
>
> I suppose you could have
>
> Put ("There were \1 \2 and \3 \4.\n",
>       Image (Warning_Count),
>       (if Warning_Count = 1 then "warning" else "warnings"),
>       Image (Error_Count),
>       (if Error_Count = 1 then "error" else "errors") );
>
> but then the Template is essentially unreadable.
>

Are you familiar with the VMS $FAO directive (which is the way VMS does
template formatting) ?

Background material on $FAO is at:

	http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html

The table of formatting directives are at the bottom of that page.

Of interest is the directive "!%S" which inserts either "S" or "s" if
the most recent numeric value was not one, the directive "!n%C" which
inserts a specific string if the previous numeric field value matches
the "n" condition and the "!%E" directive which inserts a string if the
previous numeric field value did _not_ match a previous "!n%C" test.

Something like that would handle this problem rather cleanly.

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[Dennis Lee Bieber]

On Wed, 19 Feb 2014 16:37:42 +0100, Georg Bauhaus
<rm.dash-bauhaus@futureapps.de> declaimed the following:

>
>The normal use case for HTML is when there are at least
>two computer systems involved:
>
>(1)  one sending documents (->), and receiving requests (<-),
>   ??????????????????????????? ???????????????????????????
>(2)  one receiving documents (<-), and sending requests (->),
>
>such that each of them is controlled exclusively by
>different parties. There is no dispatching, because
>a common dispatcher is an impossible part of the setup.
>(IOW, the possibility is only a mathematical one, whenever
>it refuses to include earthly constraints of the setup.)
>
	Uhm... That defines HTTP.

>The media types of CSS will allow an HTML processor to render
>the same HTML on a number of different devices. Still, no MD.
>

	And I still prefer the original concept of HTML -- being a mark-up
language defining /what/ was provided, but the rendering was totally up to
the browser. My first graphical browser actually allowed the user to set
font specifications for /each/ HTML element (H1 could be rendered in Gothic
Blackletter, H2 in an Uncial, H3 in san serif italic, H4 in serif, ...).

	CSS is an evil trying to turn HTML into a page-layout language... If
one really needs that much control over the document -- ship it as a PDF
<G>

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-20 03:09 , Simon Clubley wrote:
> On 2014-02-19, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
>> On 02/19/2014 02:46 PM, Robert A Duff wrote:
>>>
>>> Put("There were \1 warnings and \2 errors.\n",
>>>      Image(Warning_Count), Image(Error_Count));
>>
>> And then you end up with
>>
>> There were 1 warnings and 1 errors.
>>
>> I suppose you could have
>>
>> Put ("There were \1 \2 and \3 \4.\n",
>>       Image (Warning_Count),
>>       (if Warning_Count = 1 then "warning" else "warnings"),
>>       Image (Error_Count),
>>       (if Error_Count = 1 then "error" else "errors") );
>>
>> but then the Template is essentially unreadable.
>>
> 
> Are you familiar with the VMS $FAO directive (which is the way VMS does
> template formatting) ?
> 
> Background material on $FAO is at:
> 
> 	http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html
> 
> The table of formatting directives are at the bottom of that page.
> 
> Of interest is the directive "!%S" which inserts either "S" or "s" if
> the most recent numeric value was not one, the directive "!n%C" which
> inserts a specific string if the previous numeric field value matches
> the "n" condition and the "!%E" directive which inserts a string if the
> previous numeric field value did _not_ match a previous "!n%C" test.
> 
> Something like that would handle this problem rather cleanly.

Cleanly? I would call those directives "line-noise formatting". Trying
to embed logical decisions into the template string is yucky.

Concatenating conditional string expressions in Ada is a lot cleaner IMO.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Wed, 19 Feb 2014 17:01:45 -0500, Robert A Duff wrote:

> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> No, dynamic type safety is not fully "Ada type safe". Ada is (mainly)
>> statically type safe; dynamism only enters in subtype safety.
> 
> Well, if you take the view that "types" are "those things that can be
> checked statically", then all programming languages are statically type
> safe, rendering the notion meaningless.  Even something like 'bash',
> which has only one (static) type.  In this view, 'bash' does zero static
> type checking, yet all the type checking it does is static.

Yes, there is no such thing as a truly untyped language because a type can
always be added afterwards. [However I wonder you supporting that kind
argument, for second time, actually, after you said (rightfully) that there
is written Ada and Reference Manual's Ada.]

The question is how much of the language semantics is mapped on the types,
explicit or implied no matter. That amount makes Ada strongly typed and
bash "untyped."

> In other words, the term "subtype" in Ada is a cheat, deliberately used
> to enable bogus claims about static type safety in Ada, as if the
> run-time checks associated with subtypes somehow don't count.

Yes, they do not count. Constraint_Error is not a failed check, it is a
contracted behavior.

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

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Wed, 19 Feb 2014 23:45:47 +0200, Niklas Holsti wrote:

> On 14-02-19 16:13 , Dmitry A. Kazakov wrote:
>> On Wed, 19 Feb 2014 15:20:18 +0200, Niklas Holsti wrote:
>> 
>>> On 14-02-19 11:40 , Dmitry A. Kazakov wrote:
>>>> On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote:
>>>>
>>>>> On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
>>>>>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:
>>>>
>>>>>> To me text buffer, stream, file, string are all instances of the class of
>>>>>> types over which Put dispatches. OK, we can call the abstract root type of
>>>>>> the class "Text."
>>>
>>> My notion of type "Text" is an internal representation of text meant for
>>> human reading and viewing. I don't see any logical need for making this
>>> type a class; there would be only one predefined (and private) type.
>> 
>> Class is needed because there must be more than one implementation of the
>> interface
> 
> Why? It is not expected that there should be more than one
> implementation, in the same Ada program, of Ada.Containers.Vectors, for
> example.

Ada.Containers.Vectors is generic and suffers same issues as Text_IO.

How are you going to handle encoding using single implementation?

> The "Text" type I am talking about is kind of a container for structured
> text ("text" as in meaning (2) below).

What are you going to do when

1. the structure does not match?

2. the content itself varies?

>> and because the interface itself need to be extended in order to
>> have Ada library implementations of reasonable size and complexity.
> 
> That does not convince me. Mere volume (e.g. number of operations) is
> not, to me, a reason for splitting a coherent interface into different
> packages.

It is not the number but ability to add new unknown to language designers
operations.

>>> (2) a text meant only for human reading/viewing and therefore to be
>>> rendered as nicely and readably as the chosen viewing device allows.
>>> That some parts of the text can be seen as sequences of characters is
>>> secondary, and the specific characters and their sequence can change
>>> according to the rendering.
>> 
>> Rendered text is a text so long the reader can reconstruct (1) from (2). So
>> in effect (1) and (2) are equivalent in the sense that both are (1).
> 
> No, text (2) is *not* the result of rendering text (1). Text (2) is
> logically structured text (probably some kind of tree) that has been
> deliberately constructed to have structure.

Whatever. It can have hyperlinks, embedded video and casual games in it.
How are you going to pack this into the RM? How do you find a consensus
what belong to text and what does not? It is just bad design.

> To make it very concrete: under Windows you use Notepad to create text
> (1), but MS-Word to create text (2).

And I dispatch to Notepad, Word, GPS, and other implementations of text
processing and text formats, while it is all text to me.
 
>>> Ada.Text_IO implements mainly (1), with some basic support for
>>> typewriter-style formatting (column spacing, line spacing, page tracking).
>>>
>>> The "Text" type I am talking about aims to be the internal
>>> representation of (2), before rendering on some viewing device.
>> 
>> Why should anybody care about (2)?
> 
> Because users want to see nicely formatted output,

That alone does not justify the architecture of the text formatting library
you propose. It could if you demonstrated that other architectures are
unable to produce nicely formatted output. But they are well capable of. 

But my question was about the internal representations of a certain narrow
subclass of texts you propose to be the universal description of all texts
Ada should support.

>> Why Text_IO should have anything to do with (1)?
> 
> Text (1) can also be processed with Sequential_IO, but usually text (1)
> is divided into syntactical, meaningful tokens, such as keywords or
> decimal numbers, and Text_IO provides (rudimentary) facilities for
> generating such tokens on output, and lexically scanning and evaluating
> such tokens on input.

That is not a property of text. It is of a container of objects of assorted
types.

> The situation is the same in other programming languages, which all
> provide such token-oriented input-output for text (1) files. For example
> printf/scanf in C.

Sequential text processing is not what text is. Nobody argues against
sequential processing, though there are cases where it is not sequential
(e.g. syntax highlighting). But that has little to do with viewing a text
as a sequence of lines or pages or paragraphs etc. Furthermore, there is no
single preferred view of a text medium. Some application might wish to view
it as lines, like compiler do, others might prefer other views. This is why
a class is needed to decouple views from formatting actions and the medium.

>>>> This was attempted before, many many times, actually. From PostScript to
>>>> HTML, an intermediate language that would take care of separating higher
>>>> level formatting from lower level rendering. It never worked how many times
>>>> tried.
>>>
>>> Uh... surely PostScript and HTML "work". I'm pretty sure that a large
>>> fraction, perhaps even a majority of programs today generate most of
>>> their human-readable output as HTML.
>> 
>> Which is why quality of text is so miserable and why the modern OS makes a
>> i486 out of whatever many cores, gigahertz and terabytes monster you run it
>> on.
> 
> You are changing the issue from "works" to "needs a lot of resources and
> is misused". So you lose the argument :-)

But we agreed on the point about resources. So what justifies the orgy?
Ease of use? HTML is very poor on that. Safety? HTML is a joke regarding
it. Maintainability? etc.

>> And of course generating HTML or parsing it is no way simpler than
>> traditional formatting in any sense of that.
> 
> What do you mean by "traditional formatting"?

Without an intermediate layer.

How

   Put (File, "&");

is better than

   Put (File, ''');

?

> I'm not suggesting that the Ada programer would write code to generate
> HTML. The Ada programmer's code would create a "Text" (i.e. a text (2)),
> which can be output as HTML, if it is emitted to a device/file/channel
> which wants HTML.

To put it simple, you don't want HTML. But that was the point I made, HTML
does not work as a middleman. Yet you want to introduce one of your own
hoping it would work better than HTML. It will not.

> I'm not suggesting that Text_IO should be removed. Of course Ada
> programs must be able to read and write files of text (1). It may even
> be desirable to extend the token-level formatting abilities of Text_IO
> or the Image functions, either by more parameters or by templates or
> pictures.

So Text_IO remains a mess, and we add more mess to it.

> But my main point is that if our goal is text formatted to modern
> standards of appearance (with proportional fonts et cetera) then the
> rendering cannot be made token by token, or Put (item) by Put (item);
> the renderer must work on a whole text (2).

It is not "modern", it is simply bad. Bad standards existed in the past and
will appear in the future. It is not Ada's concern, IMO.

>>> If the need is to generate nicely formatted
>>> output, rendered in device-specific ways, and typewriter formatting is
>>> not enough, what is the alternative?
>> 
>> I don't understand the question. It is not about alternatives, the
>> formatting must be done. It is about decomposition of the task into
>> software components. I don't want any middlemen especially such that in
>> order of magnitude more complex than direct formatting.
> 
> Can you give an example of what you mean by "direct formatting"?

Without intermediate objects representing items sufficiently larger than
the things being processed. I want keep formatting "imperative", if you
will.

>> syntax highlighting, WYSIWYG text processing etc.
> 
> If you are talking about interactive applications, at most a screenful
> of text is shown at a time, therefore Text_IO overheads would be
> insignificant.

The design you propose, as you are replacing local operations with ones
dealing with the text as a whole.

> But I think that this kind of application would not use
> Text_IO anyway, because the formatting capabilities of Text_IO would not
> be sufficient.

See? That is because of monolithic design putting imaginary requirements
ahead. This is a wrong way.

>>> I don't see any need for converting a File/Stream *into* Text, unless
>>> the File/Stream is a serialized representation of the full internal
>>> structure of a Text object, in which case the File/Stream structure is
>>> private and normal serialization/deserialization methods apply.
>> 
>> But your proposal was:
>> 
>>    procedure Get (From : in out Text; Value : out Integer);
>>    procedure Get (From : in out File_Type; Item : out Text);
> 
> No, I proposed Put operations, not Get operations. "Text" (that is, text
> (2)) is meant only for output, not for input. For input, use text (1).

Only Text_O? No Text_I at all?

>>> I don't intend that the type "Text" should be so fancy and complete that
>>> it could be used as such to implement an advanced word processor.
>>> Following the same rationale as Ada.Containers, "Text" should provide as
>>> much functionality as can be expected to be useful for (and used by)
>>> many Ada programs and programmers, but programmers requiring high
>>> performance or high/specific functionality would have to implement more
>>> advanced "text" representations themselves.
>> 
>> And so you need it extensible, ergo, a class.
> 
> Not so, if we accept the same rationale as for Ada.Containers: they are
> meant for use in applications without extreme or special demands on the
> performance of the containers.

Ada container library was wrong design from the start. But that is another
story for another day.

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

Re: Text_IO, was: Re: Something I don't understand

[G.B.]

On 20.02.14 03:39, Dennis Lee Bieber wrote:
> On Wed, 19 Feb 2014 16:37:42 +0100, Georg Bauhaus
> <rm.dash-bauhaus@futureapps.de> declaimed the following:
>
>>
>> The normal use case for HTML is when there are at least
>> two computer systems involved:
>>
>> (1)  one sending documents (->), and receiving requests (<-),
>>    ??????????????????????????? ???????????????????????????
>> (2)  one receiving documents (<-), and sending requests (->),
>> (...)
> 	Uhm... That defines HTTP.

Yes, hypertext, by design, is for being transported. An Ada
program will produce a document, and, as part of this normal
use case, will send it. Done. Whereas dispatching that involves
rendering is not part of the same Ada program.

> 	CSS is an evil trying to turn HTML into a page-layout language... If
> one really needs that much control over the document -- ship it as a PDF

Real world HTML adapts to the needs of those financing its
use. The two most important adaptations are defined by the
powers that be:

1. graphics designers, who just cannot work without a fixed
    2D canvas. (They turn everything into fliers.)

2. Big Data monetizers (Ads & Co.; The Media), who need
    Javascript attachments; Javascript functions are triggered
    by events bound to DOM elements. PDF does not deliver, by
    comparison.

Neither of them is anywhere near the requirements of template
based Text I/O, I think. But there might be some financing for
the latter.

Re: Text_IO, was: Re: Something I don't understand

[G.B.]

On 20.02.14 02:09, Simon Clubley wrote:

> Are you familiar with the VMS $FAO directive (which is the way VMS does
> template formatting) ?
>
> Background material on $FAO is at:
>
> 	http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html
> [... !%S]
> Something like that would handle this problem rather cleanly.

Would this address the needs of international language processing?
Even English has plural words without 's'; other grammars might
need different ways of representing plurals altogether; I understand
that doubling a word or syllable or symbol is a scheme for expressing
plurals in East Asia, for example.

Handling natural language issues is a bit too tricky
to be part of a regular programming formalism, I think.

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-20, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
> On 20.02.14 02:09, Simon Clubley wrote:
>
>> Are you familiar with the VMS $FAO directive (which is the way VMS does
>> template formatting) ?
>>
>> Background material on $FAO is at:
>>
>> 	http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html
>> [... !%S]
>> Something like that would handle this problem rather cleanly.
>
> Would this address the needs of international language processing?
> Even English has plural words without 's'; other grammars might
> need different ways of representing plurals altogether; I understand
> that doubling a word or syllable or symbol is a scheme for expressing
> plurals in East Asia, for example.
>

That's why VMS Engineering added the option to $FAO which allows a
application specified word to be inserted based on the value of the
previous number.

I'm not saying we should duplicate this exactly. I just mentioned it as
a real world example of a template formatting system which has conditional
formatting built into it.

> Handling natural language issues is a bit too tricky
> to be part of a regular programming formalism, I think.
>

It's certainly not easy. I wonder how something like gettext would
handle this problem ? (I've never had to support foreign languages
in my code so I don't know the answer to that question.)

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley]

On 2014-02-20, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 14-02-20 03:09 , Simon Clubley wrote:
>> 
>> Are you familiar with the VMS $FAO directive (which is the way VMS does
>> template formatting) ?
>> 
>> Background material on $FAO is at:
>> 
>> 	http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html
>> 
>> The table of formatting directives are at the bottom of that page.
>> 
>> Of interest is the directive "!%S" which inserts either "S" or "s" if
>> the most recent numeric value was not one, the directive "!n%C" which
>> inserts a specific string if the previous numeric field value matches
>> the "n" condition and the "!%E" directive which inserts a string if the
>> previous numeric field value did _not_ match a previous "!n%C" test.
>> 
>> Something like that would handle this problem rather cleanly.
>
> Cleanly? I would call those directives "line-noise formatting". Trying
> to embed logical decisions into the template string is yucky.
>

Actually, when I said "cleanly", I meant the general approach of using
conditional formatting directives, not the specific $FAO syntax.

> Concatenating conditional string expressions in Ada is a lot cleaner IMO.
>

That works in some cases, but it doesn't work when you are trying to
produce formatted reports with lots of columns with specific widths and
formatting required.

It also depends on what you are wanting to do with the template capability.
Are you wanting to output free-form text with various parameters inserted
or are you trying to format a detailed report ?

I could see myself using it to do both. What about everyone else here ?

Simon.

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

Re: Text_IO, was: Re: Something I don't understand

[Robert A Duff]

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

> Yes, they do not count. Constraint_Error is not a failed check, it is a
> contracted behavior.

It's usually a bug.  And when I see "warning: C_E will be raised..."
I am happy for that static check.

- Bob

Re: Text_IO, was: Re: Something I don't understand

[Dmitry A. Kazakov]

On Thu, 20 Feb 2014 10:54:37 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Yes, they do not count. Constraint_Error is not a failed check, it is a
>> contracted behavior.
> 
> It's usually a bug.  And when I see "warning: C_E will be raised..."
> I am happy for that static check.

I am not.

A proper check would be:

"error: procedure Foo is contracted not to raise C_E, but its declaration
region contains a declaration that raises C_E..."

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

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-20 11:52 , Dmitry A. Kazakov wrote:
> On Wed, 19 Feb 2014 23:45:47 +0200, Niklas Holsti wrote:

>>>> I don't see any need for converting a File/Stream *into* Text, unless
>>>> the File/Stream is a serialized representation of the full internal
>>>> structure of a Text object, in which case the File/Stream structure is
>>>> private and normal serialization/deserialization methods apply.

Dmitry wrote:

>>> But your proposal was:
>>>
>>>    procedure Get (From : in out Text; Value : out Integer);
>>>    procedure Get (From : in out File_Type; Item : out Text);

Niklas wrote:

>> No, I proposed Put operations, not Get operations. "Text" (that is, text
>> (2)) is meant only for output, not for input. For input, use text (1).
> 
> Only Text_O? No Text_I at all?

Exactly. That is, for text in the meaning (2), structured text intended
for human viewing. Text data files (sequences of characters) of course
need both input and output, as provided today by Text_IO.

All your other points just take us further from a common understanding
(as usual when I discuss something with you, unfortunately).

>>> And so you need it extensible, ergo, a class.
>>
>> Not so, if we accept the same rationale as for Ada.Containers: they are
>> meant for use in applications without extreme or special demands on the
>> performance of the containers.
> 
> Ada container library was wrong design from the start. But that is another
> story for another day.

Yeah, I know you want to start over on Ada. Feel free, I will certainly
read your novo-Ada language proposal with interest (seriously, not
joking at all). But it needs to have a concrete rationale and
motivation, not philosophical abstractions.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-19 23:46 , Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> I disagree, but then I don't understand how Robert would make C's
>> template idea type-safe -- might Robert expand on his ideas?
> 
> Most people call me "Bob".  Yeah, I know my "From:" line say "Robert".  ;-)

Apologies. I did remember your preference, but only after clicking
"Send" :-(

> My answer depends on if (or how much) I'm allowed to change Ada's type
> system.  I've done this in pure standard Ada.  Something like:
> 
>     type Template is new String;
>     procedure Put(T: Template; X1, X2, X3, X4, X5, X6, X7, X8: String := "");
> 
> Put("There were \1 warnings and \2 errors.\n",
>     Image(Warning_Count), Image(Error_Count));
> 
> prints the template as is to standard output, except it replaces \1 with
> X1, and \2 with X2, and the "\n" is new-line.  You can have multi-line
> templates.  "\\" represents "\".
> 
> Note my use of X1...X8 to simulate C's variable-length parameter
> lists.  This is a kludge.

That is where I think this breaks down for current Ada. To really add
this to Ada, you need variable-length parameter lists, or the ability to
aggregate strings of various lengths into a vector of strings.

> Note that Template is a different type from String.  This prevents
> a bug that can happen in C, where you say printf(blah), and blah
> is some data read off the internet.  That can be a security hole!

But Template objects can still be variable, so they can still be
constructed at run-time from external data (say, some application
configuration file). Or do you intend to define Template as a type that
forbids variable objects and allows only static constants?

But even with variable Templates, this is clearly less risky than the
case in C, where AIUI the risk comes from malicious type breaking where
the format conversion character misuses the corresponding parameter.
That cannot happen in your proposal because all parameters are Strings
and there are no format conversion characters in the Template.

> The user is responsible for writing suitable Image functions
> for their data types, and they can take whatever formatting
> parameters you like.  This seems much more readable than C's
> way of encoding the field widths and whatnot in the template.

Yes indeed, I agree fully with that.

> For localization/internationalization, you can have a table
> mapping "There were \1 warnings and \2 errors.\n" to the
> corresponding template in (say) French.  Different languages
> have different word orders, so you might have:
> 
>     "... \2 ... \1 ... \n"
> 
> to reverse the order of insertion.

So here the templates would be run-time variable, according to the
locale, and not compile-time constants?

I have little experience of multi-language output, but I have not been
impressed by the tools and methods I've seen. I think it is another
problem and won't be solved by such simple template-based tricks.

> This is all 100% type safe.  Most of the checking is static.
> It checks at run time that the number of \1, \2, \3, ... escapes
> matches the number of non-empty Xn parameters passed.

Why should only non-empty Xn be counted? I think it must be permitted
for some Xn to be empty, without this meaning "end of the Xn list", but
just making the corresponding escape produce an empty output string. But
ok, this is a consequence of the kludge with a fixed number of Xn
parameters in the profile.

> Now, if you let me change Ada,

Apart from the type-safe variable-length parameter lists, you mean? ;-)

> I'd allow user-defined literals.
> Any type derived from the Has_Literals interface allows
> literal syntax, and it overrides the Literal_Value function
> to convert the sequence of characters to that type.

Not a bad idea. Would only string literals qualify, not character or
numeric ones? To avoid ambiguities, this should be forbidden for any
type that already allows string literals, right?

But this is beginning to look a bit like C++ parametrized constructors,
called implicitly... slippery slope?

> Template would no longer need to be derived from String; it
> could be a private extension of Has_Literals, and the Literal_Value
> function could "precompile" the template into some convenient/efficient
> internal form.
> 
> The Literal_Value call is evaluated at compile time, so the
> above-mentioned run-time check can now be static.

If the Template is defined by a literal, yes. But I assume Templates
could still be variable objects, too, forcing a run-time check.

> Change the types of the Xn parameters to Has_Image'Class,
> so you can pass Warning_Count, and it automatically dispatches
> to Image(Warning_Count). If you want to use extra formatting
> options you'd call your own Image function explicitly.

But then you get a parameter list which mixes Has_Image'Class and
Strings from Image functions. Or do you mean that String is in
Has_Image'Class, with an Image function that is the identity function?
That would work... sneaky!

> Integer types are derived from Has_Image, and the Image function
> is not an attribute, and (most importantly of all! ;-))
> it doesn't insert an annoying extra blank.

I second that change to the Image function. That is, omit the extra blank.

> I'd also allow variable-length argument lists and/or arrays of strings.

Do you mean polymorphic variable-length parameter lists? Or only lists
that are declared as monomorphic using some 'Class, such as Has_Image'Class?

>> I think that the present method of concatenating strings or using
>> several Puts is good; 
> 
> I think Put (at least to standard output/error) should be task safe.
> That is, it should be atomic with respect to other tasks doing Put.
> Puts from different tasks would be interspersed, but you wouldn't
> get character-by-character interspersal, and you certainly wouldn't
> get the Ada rule ("erroneous and therefore unpredictable behavior").

Hmm yes. I don't know the history behind the non-task-safe choice.
Perhaps there was a fear of unnecessary distributed overhead for
non-tasking programs on operating systems where the OS I/O system is not
task safe.

> That rules out the "series of Puts" method.  You need to build up
> your whole message (possibly multi-line) and then Put it in one
> fell swoop.

Yes, certainly, if you have multiple tasks which output to the same device.

> The concatenating strings method just looks ugly to me -- I can't easily
> see what the message is going to look like.  With a template, I see
> the whole message, with marks for where variable data is inserted.

I can understand this feeling, but the template method has its own
ugliness -- the need for escapes and the need to count and match up
escapes with parameters to understand what text will replace each escape.

> It is odd that in Ada, 'Image doesn't support the same formatting
> control as Text_IO.

Yes indeed.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti]

On 14-02-20 00:01 , Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> No, dynamic type safety is not fully "Ada type safe". Ada is (mainly)
>> statically type safe; dynamism only enters in subtype safety.
> 
> Well, if you take the view that "types" are "those things that can be
> checked statically", then all programming languages are statically type
> safe, rendering the notion meaningless. 

Type safety to me means that code reading a datum interprets the datum's
representation correctly, using the same type/representation as the code
that wrote the datum. The value read is the value written, not some
unpredictable reinterpretation of the bits in memory.

This notion has nothing to do with what is statically checked or not
checked, and even less with what *can* be checked statically. Type
safety could be implemented by dynamically tagging each datum with its
type and checking tags at run time.

But "Ada type safety" to me means that type safety is checked
statically. Perhaps I am being too pedantic and strict about this, but I
think I'm not alone in this view.

> In other words, the term "subtype" in Ada is a cheat, deliberately used
> to enable bogus claims about static type safety in Ada, as if the
> run-time checks associated with subtypes somehow don't count.

Subtype checking deals with permitted values, not with correct use of
the machine representation. I don't see any cheating, it is well
understood that such constraints or assertions on values need run-time
checks, although more and more of them can also be proved with SPARK or
other such tools.

Consequently, when I program in Ada, and subprogram Foo signals a
Constraint_Error because its parameter X (type Integer) has the value
105, while the subtype of X permits only 1..10, I can be sure that the
caller of Foo really provided the parameter value 105 (type Integer). I
don't need to worry that the caller provided a Float parameter which Foo
tried to interpret as Integer.

Simon's proposal for printf-like formatting in Ada is not, IMO, "Ada
type safe", because it needs a run-time check to verify that the type of
a parameter is correct, and this is because the correct type depends on
the *value* of the format string. But I admit that one can take the
other view, that the type of the parameter is always correct, and any
run-time problems are "subtype" errors in the value of the format string.

Clearly, however, Simon's proposal (and any proposal that depends on a
potentially dynamic format or template value) reduces the level of
static type checking, which IMO is bad.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Text_IO, was: Re: Something I don't understand

[Brian Drummond]

On Thu, 20 Feb 2014 01:09:27 +0000, Simon Clubley wrote:

> On 2014-02-19, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>

> Background material on $FAO is at:
> 
> 	http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html
> 
> The table of formatting directives are at the bottom of that page.
> 
> Of interest is the directive "!%S" which inserts either "S" or "s" if
> the most recent numeric value was not one, the directive "!n%C" which
> inserts a specific string if the previous numeric field value matches
> the "n" condition and the "!%E" directive which inserts a string if the
> previous numeric field value did _not_ match a previous "!n%C" test.
> 
> Something like that would handle this problem rather cleanly.

the best laid plans,
of mouses and mans
gang aft agley...

- Brian

Re: Text_IO, was: Re: Something I don't understand

[AdaMagica]

> the best laid plans,
> of mouses and mans
> gang aft agley...

I don't know Scottish dialect, but I know Robert Burns's lines as

... of mice and men ...

which is proper English. Is yours the original?

Re: Text_IO, was: Re: Something I don't understand

[Bill Findlay]

On 23/02/2014 21:37, in article
3862580c-e5be-4b8a-8358-07ea61372957@googlegroups.com, "AdaMagica"
<christ-usch.grein@t-online.de> wrote:

>> the best laid plans,
>> of mouses and mans
>> gang aft agley...
> 
> I don't know Scottish dialect, but I know Robert Burns's lines as
> 
> ... of mice and men ...
> 
> which is proper English. Is yours the original?

Wheech!
(That's Scots for whoosh! 8-)

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Text_IO, was: Re: Something I don't understand

[AdaMagica]

On Sunday, February 23, 2014 10:37:20 PM UTC+1, AdaMagica wrote:
> > the best laid plans,
> > of mouses and mans
> > gang aft agley...

To A Mouse, On Turning Her Up In Her Nest With The Plough
http://www.robertburns.org/works/75.shtml

Re: Text_IO, was: Re: Something I don't understand

[Brian Drummond]

On Sun, 23 Feb 2014 13:37:20 -0800, AdaMagica wrote:

>> the best laid plans,
>> of mouses and mans gang aft agley...
> 
> I don't know Scottish dialect, but I know Robert Burns's lines as
> 
> ... of mice and men ...
> 
> which is proper English. Is yours the original?

eh, no, the context (snipped) was discussing the generation of plural 
forms as part of text I/O, and so...

apologies for any confusion so caused.

- Brian

Re: Text_IO, was: Re: Something I don't understand

[AdaMagica]

Ah - I see. Yes, plurals are awkward in all languages.

An Ada issue about Physical Units Checking also tried to solve this problem, on an international base.
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00324.txt?rev=1.3

Christoph