Formatted IO - Fortran style or similar.

Formatted IO - Fortran style or similar.

[Mark Murray]

Hi Folks

Is there anyting in the Ada Standard Library (or the language itself)
that acts /in loco/ Fortran's formatted I/O or C's printf()/scanf()?

I know these can be written as required, and I know that there are ways
to call C's printf()/scanf() functions from Ada, but I'm interested to
see if there is not already something "in the box". Yes, I'm aware of
the formatting capabilities of put()/get(), but that's not quite what
I'm wondering about.

I could have sworn I saw a PL/1-style "picture" version of this, but I'm
coming round to believing that this was "customer code", not standard
library.

M

PS: Is it really the case that put(some_integer,16) will _always_
print the '16#9999#' format, and that there is on way _in_the_
_standard_library_ of *not* getting the '16#.....#' wrapper?
Yes, I know there are ways you can get rid of it (eg with a slice), or 
by "rolling your own" - alternatives aren't my question here :-).

M
-- 
Mark "No Nickname" Murray
Notable nebbish, extreme generalist.

Re: Formatted IO - Fortran style or similar.

[Ian Clifton]

Mark Murray <w.h.oami@example.com> writes:

> Is there anyting in the Ada Standard Library (or the language itself)
> that acts /in loco/ Fortran's formatted I/O or C's printf()/scanf()?

> I know these can be written as required, and I know that there are ways
> to call C's printf()/scanf() functions from Ada, but I'm interested to
> see if there is not already something "in the box". Yes, I'm aware of
> the formatting capabilities of put()/get(), but that's not quite what
> I'm wondering about.

I’m not quite sure what facilities you’re after—I don’t know C’s
printf()/scanf(), but presumably they are quite different from Fortran’s
format control—but I suspect the answer is going to be “Ada’s approach
is different” (see below).

> I could have sworn I saw a PL/1-style "picture" version of this, but I'm
> coming round to believing that this was "customer code", not standard
> library.

Here, you could be thinking about “Edited Output for Decimal types”,
described in the ARM Appendix F. 

> PS: Is it really the case that put(some_integer,16) will _always_
> print the '16#9999#' format, and that there is on way _in_the_
> _standard_library_ of *not* getting the '16#.....#' wrapper?
> Yes, I know there are ways you can get rid of it (eg with a slice), or
> by "rolling your own" - alternatives aren't my question here :-).

I believe Ada’s approach is to specify the results of
put(some_integer,16) sufficiently carefully that you can do such
post‐processing with the provided string manipulation packages and be
confident of the final result. In other words, what you are trying to
avoid ARE the language’s facilities for doing this sort of thing. I ought
to mention in passing, the Ada.Text_IO packages are a little
controversial, many dislike them, but I believe they are under‐rated.

-- 
Ian ◎

Re: Formatted IO - Fortran style or similar.

[Michael Rohan]

On Monday, July 30, 2012 2:59:07 AM UTC-7, Ian Clifton wrote:
> Mark Murray <w.h.oami@example.com> writes:
> 
> 
> 
> > Is there anyting in the Ada Standard Library (or the language itself)
> 
> > that acts /in loco/ Fortran's formatted I/O or C's printf()/scanf()?
> 
> 
> 
> > I know these can be written as required, and I know that there are ways
> 
> > to call C's printf()/scanf() functions from Ada, but I'm interested to
> 
> > see if there is not already something "in the box". Yes, I'm aware of
> 
> > the formatting capabilities of put()/get(), but that's not quite what
> 
> > I'm wondering about.
> 
> 
> 
> I’m not quite sure what facilities you’re after—I don’t know C’s
> 
> printf()/scanf(), but presumably they are quite different from Fortran’s
> 
> format control—but I suspect the answer is going to be “Ada’s approach
> 
> is different” (see below).
> 
> 
> 
> > I could have sworn I saw a PL/1-style "picture" version of this, but I'm
> 
> > coming round to believing that this was "customer code", not standard
> 
> > library.
> 
> 
> 
> Here, you could be thinking about “Edited Output for Decimal types”,
> 
> described in the ARM Appendix F. 
> 
> 
> 
> > PS: Is it really the case that put(some_integer,16) will _always_
> 
> > print the '16#9999#' format, and that there is on way _in_the_
> 
> > _standard_library_ of *not* getting the '16#.....#' wrapper?
> 
> > Yes, I know there are ways you can get rid of it (eg with a slice), or
> 
> > by "rolling your own" - alternatives aren't my question here :-).
> 
> 
> 
> I believe Ada’s approach is to specify the results of
> 
> put(some_integer,16) sufficiently carefully that you can do such
> 
> post‐processing with the provided string manipulation packages and be
> 
> confident of the final result. In other words, what you are trying to
> 
> avoid ARE the language’s facilities for doing this sort of thing. I ought
> 
> to mention in passing, the Ada.Text_IO packages are a little
> 
> controversial, many dislike them, but I believe they are under‐rated.
> 
> 
> 
> -- 
> 
> Ian ◎

Hi,

While the intent of my library (ZanyBlue) is currently focused on localization
support, I do support ad hoc in lining of messages (they should be externalized
to a properties file), e.g.,

   Print_Line ("Vector norm is {0,real,10.2f} with rank of {1,integer}",
               +Norm, +Rank);

Note, while type info is given in the in line message string, the library does
not do type checking for these ad hoc strings.  You would need externalized and
use assessors, e.g.,

Summary=Vector norm is {0,real,10.2f} with rank of {1,integer}

with

   Print_Summary (+Norm, +Rank);

in the code and let the compiler do the type checking.

See http://zanyblue.sourceforge.net

Re: Formatted IO - Fortran style or similar.

[Mark Murray]

On 30/07/2012 10:59, Ian Clifton wrote:
> I’m not quite sure what facilities you’re after—I don’t know C’s
> printf()/scanf(), but presumably they are quite different from Fortran’s
> format control—but I suspect the answer is going to be “Ada’s approach
> is different” (see below).

The syntax isn't all that important; its the fine-grained method of
specifying output with a format + list_of_variables.

Fortran separates the format from the read/write statements containing
the list of variables, C's printf/scanf put the format string as the
first argument of the function call. With both, quite detailed I/O
lines can be specified with a reduction in function calling.

I like them because of the compactness:

printf("A=%d B=%6.3f C=0x%04X\n" A, B, C);

... rather than multiple calls.

>> I could have sworn I saw a PL/1-style "picture" version of this, but I'm
>> coming round to believing that this was "customer code", not standard
>> library.
>
> Here, you could be thinking about “Edited Output for Decimal types”,
> described in the ARM Appendix F.

Could be, thanks!

>> PS: Is it really the case that put(some_integer,16) will _always_
>> print the '16#9999#' format, and that there is on way _in_the_
>> _standard_library_ of *not* getting the '16#.....#' wrapper?
>> Yes, I know there are ways you can get rid of it (eg with a slice), or
>> by "rolling your own" - alternatives aren't my question here :-).
>
> I believe Ada’s approach is to specify the results of
> put(some_integer,16) sufficiently carefully that you can do such
> post‐processing with the provided string manipulation packages and be
> confident of the final result. In other words, what you are trying to
> avoid ARE the language’s facilities for doing this sort of thing. I ought
> to mention in passing, the Ada.Text_IO packages are a little
> controversial, many dislike them, but I believe they are under‐rated.

If that is the "Ada way", then so be it. :-)

I held back on that method as it felt "wasteful"; why generate
something if you know you don't need it? ("I want XXXX (hexadecimal),
why do I need to generate 16#XXXX# first?")

I suppose that learning a language's idioms are part of learning the
language. Thanks for the help!

M
-- 
Mark "No Nickname" Murray
Notable nebbish, extreme generalist.

Re: Formatted IO - Fortran style or similar.

[Dmitry A. Kazakov]

On Mon, 30 Jul 2012 23:12:28 +0100, Mark Murray wrote:

> The syntax isn't all that important; its the fine-grained method of
> specifying output with a format + list_of_variables.

Which is the weak point of the method. Typically, when formatting output or
doing parsing, some of the parameters like field size, fill character,
alignment, precision, base etc are dynamic.

In fact my Ada string editing library is a port of a FORTRAN library I
designed in 80's, because FORTRAN formats were unusable. I remember
hacking the Hollerith Format Strings I asked myself why were I doing this.
For the same reason I ported parts of the my Ada library to C++, because
sscanf/sprintf are so uncomfortable to use.

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

Re: Formatted IO - Fortran style or similar.

[Jacob Sparre Andersen]

Dennis Lee Bieber wrote:

> One of the goals for Ada was to put as much checking as possible into
> the compiler... variable argument lists don't support that.

Yes.

How would you handle translatable user visible strings - such as
"Parsing '${file_name}' failed on line ${line_number}." (where "${...}"
identifies parameter substitutions) - in Ada?

The standard library is definitely not (intended to be) the tool for
that job.

Two of the challenges are:

 + How can we (at compile-time) check that the named parameters in the
   translatable string match the parameters passed to the formatting
   routine?

 + How can we (at load-time) check that the parameters used in a
   translated string match those in the translatable string?

Greetings,

Jacob
-- 
"There are two ways of constructing a software design. One way is to
 make it so simple that there are obviously no deficiencies. And the
 other way is to make it so complicated that there are no obvious
 deficiencies."                                    -- C. A. R. Hoare

Re: Formatted IO - Fortran style or similar.

[stefan-lucks]

On Tue, 31 Jul 2012, Jacob Sparre Andersen wrote:

> How would you handle translatable user visible strings - such as
> "Parsing '${file_name}' failed on line ${line_number}." (where "${...}"
> identifies parameter substitutions) - in Ada?

Why do you need to *substitute* the parameters in the string at all? 

Without substitution, the following seems to work fine:

  Ada.Text_IO.Put_Line("Parsing "         & File_Name & 
                       " failed on line " & To_String(Line_Number) & 
                       ".");

Of course, you still have to write your 

  function To_String(Line_Number: Line_Number_Type) return String;

... or you just use Line_Number'Image. 


-- 
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
    <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Formatted IO - Fortran style or similar.

[Adam Beneschan]

On Tuesday, July 31, 2012 8:12:37 AM UTC-7, (unknown) wrote:
> On Tue, 31 Jul 2012, Jacob Sparre Andersen wrote:
> 
> 
> 
> > How would you handle translatable user visible strings - such as
> > "Parsing '${file_name}' failed on line ${line_number}." (where "${...}"
> > identifies parameter substitutions) - in Ada?
> 
> Why do you need to *substitute* the parameters in the string at all? 
> 
> Without substitution, the following seems to work fine:

It's not a question of what anyone "needs" or what "works".  Yes, this works, but I can understand why, for some people, it makes things more readable to have the string that represents what the output is going to look like all in once nice place, rather than split up into fragments with expressions in between.  I find that sometimes doing it that way is a bit more readable, although I don't have a strong preference.

In addition, having a "format" specified as a single entity, with something to indicate where other values will be substituted, makes it easier and cleaner to select between different formats--say you have a table of formats where each format pertains to a different error message but many of them have the same types of information substituted in, or a table where each format represents the same message but in a different language.  Representing a format as a string constant with some special characters in it isn't the only way to do this, but it's an easy way that is readable and produces good results if the substitution syntax is simple enough.

                       -- Adam
 


>   Ada.Text_IO.Put_Line("Parsing "         & File_Name &  
>                        " failed on line " & To_String(Line_Number) & 
>                        ".");
>
> Of course, you still have to write your  
> 
>   function To_String(Line_Number: Line_Number_Type) return String; 
> 
> ... or you just use Line_Number'Image. 

Re: Formatted IO - Fortran style or similar.

[stefan-lucks]

On Tue, 31 Jul 2012, Dennis Lee Bieber wrote:

> On Tue, 31 Jul 2012 17:12:37 +0200, stefan-lucks@see-the.signature
> declaimed the following in comp.lang.ada:
> 
> > ... or you just use Line_Number'Image. 
> 
> 	Shouldn't that be
> 			Line_Number_Type'Image(Line_Number)

Yes. I had been tempted to write Line_Number'Img (which is gnat-specific) 
and then decided for 'Image (which works for all compilers), but forgot to 
care for the details. 

> 	Of course, this all is basically what I'd referred to in the last
> paragraph of my prior response <G>

I don't see the connection to that paragrah ... though I see your <G>. 

-- 
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
    <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Formatted IO - Fortran style or similar.

[stefan-lucks]

On Tue, 31 Jul 2012, Adam Beneschan wrote:

> It's not a question of what anyone "needs" or what "works".  Yes, this 
> works, but I can understand why, for some people, it makes things more 
> readable to have the string that represents what the output is going to 
> look like all in once nice place, rather than split up into fragments 
> with expressions in between.  I find that sometimes doing it that way is 
> a bit more readable, although I don't have a strong preference.

Whenever people ask "why doesn't ada support this language feature from 
language X", I first try to figure out how to solve that the Ada way, 
without using a feature from another language. Sometimes, these people 
manage to give convincing evidence why Ada should support such a new 
language feature. In the current case, I have yet to see any convincing 
evidence ...

-- 
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
    <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Formatted IO - Fortran style or similar.

[Jacob Sparre Andersen]

stefan-lucks@see-the.signature writes:
> On Tue, 31 Jul 2012, Jacob Sparre Andersen wrote:

>> How would you handle translatable user visible strings - such as
>> "Parsing '${file_name}' failed on line ${line_number}." (where
>> "${...}" identifies parameter substitutions) - in Ada?
>
> Why do you need to *substitute* the parameters in the string at all?
>
> Without substitution, the following seems to work fine:
>
>   Ada.Text_IO.Put_Line("Parsing "         & File_Name & 
>                        " failed on line " & To_String(Line_Number) & 
>                        ".");

Yes.  But how do you translate that text without having to recompile
the whole application?

My question was related to _translatable_ user visible strings.  If I
just want to make an all-American program, your proposed solution is
fine, but when I want to make it easy to translate the user visible
strings in an application you proposed solution is unacceptable.

Greetings,

Jacob
-- 
"Those who will not reason, are bigots,
 those who cannot, are fools, and
 those who dare not, are slaves."

Re: Formatted IO - Fortran style or similar.

[Georg Bauhaus]

On 01.08.12 10:09, Jacob Sparre Andersen wrote:

> My question was related to _translatable_ user visible strings.  If I
> just want to make an all-American program, your proposed solution is
> fine, but when I want to make it easy to translate the user visible
> strings in an application you proposed solution is unacceptable.

I have once tried to do this using Ada. The solution was, roughly, to
enumerate messages, and also enumerate (grammatical) parts of a message.
So, there were enum types, and this had some desirable consequences:

(a) I know each of the program's messages. It has a name (and/or number).
(b) There is some flexibility in placing parts of sentences,
    which differ per natural language.
(c) The messages can be transformed from Ada to XML and back,
    so that external, XML based translation tools would assist.
(d) No message can ever be missing.
(e) No external "message extraction tool" is needed.

The mechanism is a bit much for ad-hoc debugging text, I think,
but then debugging messages are not meant for users, and may
not need to be translated.

Don't know if SQL standard error numbers work the same way.

Re: Formatted IO - Fortran style or similar.

[Simon Wright]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> stefan-lucks@see-the.signature writes:
>> On Tue, 31 Jul 2012, Jacob Sparre Andersen wrote:
>
>>> How would you handle translatable user visible strings - such as
>>> "Parsing '${file_name}' failed on line ${line_number}." (where
>>> "${...}" identifies parameter substitutions) - in Ada?
>>
>> Why do you need to *substitute* the parameters in the string at all?
>>
>> Without substitution, the following seems to work fine:
>>
>>   Ada.Text_IO.Put_Line("Parsing "         & File_Name & 
>>                        " failed on line " & To_String(Line_Number) & 
>>                        ".");
>
> Yes.  But how do you translate that text without having to recompile
> the whole application?
>
> My question was related to _translatable_ user visible strings.  If I
> just want to make an all-American program, your proposed solution is
> fine, but when I want to make it easy to translate the user visible
> strings in an application you proposed solution is unacceptable.

Exactly so. From the GNU gettext manual[1],

    Entire sentences are also important because in many languages, the
    declination of some word in a sentence depends on the gender or the
    number (singular/plural) of another part of the sentence. There are
    usually more interdependencies between words than in English. The
    consequence is that asking a translator to translate two
    half-sentences and then combining these two half-sentences through
    dumb string concatenation will not work, for many languages, even
    though it would work for English. That's why translators need to
    handle entire sentences.

[1] http://www.gnu.org/software/gettext/manual/gettext.html#Preparing-Strings

Re: Formatted IO - Fortran style or similar.

[Michael Rohan]

On Wednesday, August 1, 2012 1:09:13 AM UTC-7, Jacob Sparre Andersen wrote:
> stefan-lucks@see-the.signature writes:
> 
> > On Tue, 31 Jul 2012, Jacob Sparre Andersen wrote:
> 
> 
> 
> >> How would you handle translatable user visible strings - such as
> 
> >> "Parsing '${file_name}' failed on line ${line_number}." (where
> 
> >> "${...}" identifies parameter substitutions) - in Ada?
> 
> >
> 
> > Why do you need to *substitute* the parameters in the string at all?
> 
> >
> 
> > Without substitution, the following seems to work fine:
> 
> >
> 
> >   Ada.Text_IO.Put_Line("Parsing "         & File_Name & 
> 
> >                        " failed on line " & To_String(Line_Number) & 
> 
> >                        ".");
> 
> 
> 
> Yes.  But how do you translate that text without having to recompile
> 
> the whole application?
> 
> 
> 
> My question was related to _translatable_ user visible strings.  If I
> 
> just want to make an all-American program, your proposed solution is
> 
> fine, but when I want to make it easy to translate the user visible
> 
> strings in an application you proposed solution is unacceptable.
> 
> 
> 
> Greetings,
> 
> 
> 
> Jacob
> 
> -- 
> 
> "Those who will not reason, are bigots,
> 
>  those who cannot, are fools, and
> 
>  those who dare not, are slaves."

Hi,

The standard way to do this is to externalize all localizable strings.  Since
message snippets are not generally localizable (there's no real context), the
messages must be defined as complete sentences with embedded references to the
application arguments that substituted at run-time.

Using my previous example, the message

Summary=Vector norm is {0,real,10.2f} with rank of {1,integer}

would be defined in a properties file, e.g., myapp.properties, with
localizations in locale specific files, e.g., if folks in GB want to see
the rank first

Summary=Vector rank is {1,integer} with norm of {0,real,10.2f}

in a myapp_en_GB.properties file.  The underlying source code remains
the same

    Print_Summary (+Norm, +Rank);

The ZB compiler, zbmcompile, would generate a package containing the
myapp.properties and myapp_en_GB.properties strings, and accessor routines
for all the message keys defined.  Depending on the run-time locale, the
value of the LANG variable on Unix, the correct localized message is
displayed.  (see http://zanyblue.sourceforge.net).

If you want a globalized application, you need to get the message strings
out of the application and you need to allow localization folks the freedom
to move message arguments around in the localized text.

Take care,
Michael.