for S'Image use Func??

for S'Image use Func??

[Warren]

I have tried to google for this and have not yet found
a suitable answer, so I'll troll, er, poll for an
answer here..

Is there the ability to substitute your own S'Image
function? For example, a basic interpreter might
define:

 type LNumber_Type is range 0..99_999;

Can I declare..

 for LNumber_Type'Image use LNumber_To_String;

If so, then the question is what the signature of 
the S'Image function looks like-- is it:

 function LNumber_To_String(LNO : LNumber_Type) return String;

Finally, there is actually a third question- more along
the lines of "Should this language feature be used
in this manner?", or is it preferable to just code your 
own along the lines of (which is what I presently use):

 function To_String(LNO : LNumber_Type) return String;

Inquiring minds need to know,

Warren

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Thu, 6 May 2010 17:10:20 +0000 (UTC), Warren wrote:

> I have tried to google for this and have not yet found
> a suitable answer, so I'll troll, er, poll for an
> answer here..
> 
> Is there the ability to substitute your own S'Image
> function? For example, a basic interpreter might
> define:
> 
>  type LNumber_Type is range 0..99_999;
> 
> Can I declare..
> 
>  for LNumber_Type'Image use LNumber_To_String;
> 
> If so, then the question is what the signature of 
> the S'Image function looks like-- is it:
> 
>  function LNumber_To_String(LNO : LNumber_Type) return String;

I am not sure what do you mean, but the following is legal Ada:

   generic
      type T is private;
      with function Image (X : T) return String;   
   package P is
      ...
   end P;

   type LNumber_Type is range 0..99_999;   

   package PI is new P (LNumber_Type, LNumber_Type'Image);

So attribute is a "plain" function with a clumsy name.

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

Re: for S'Image use Func??

[Adam Beneschan]

On May 6, 10:10 am, Warren <ve3...@gmail.com> wrote:
> I have tried to google for this and have not yet found
> a suitable answer, so I'll troll, er, poll for an
> answer here..
>
> Is there the ability to substitute your own S'Image
> function? For example, a basic interpreter might
> define:
>
>  type LNumber_Type is range 0..99_999;
>
> Can I declare..
>
>  for LNumber_Type'Image use LNumber_To_String;

No.

Broadly, you can't use a FOR attribute specification on every
attribute, just a few select ones that the language specifically says
you can.  'Image isn't one of those.

I think it's been mentioned a few times on this newsgroup that it
might be nice to have this ability, but I don't see that anyone has
submitted an actual language change proposal.

                                -- Adam

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Thu, 06 May 2010 19:10:20 +0200, Warren <ve3wwg@gmail.com> a écrit:

> I have tried to google for this and have not yet found
> a suitable answer, so I'll troll, er, poll for an
> answer here..
>
> Is there the ability to substitute your own S'Image
> function? For example, a basic interpreter might
> define:
>
>  type LNumber_Type is range 0..99_999;
>
> Can I declare..
>
>  for LNumber_Type'Image use LNumber_To_String;
>
> If so, then the question is what the signature of
> the S'Image function looks like-- is it:
As far as I could tell, your intuition is good, as there is indeed such  
things in Ada, called either representation clauses or operational  
clauses. See [ARM 2005 13.3] for more about it.

An excerpt to be kind:

[ARM 2005 13.3 (2)]
attribute_definition_clause ::=
       for local_name'attribute_designator use expression;
     | for local_name'attribute_designator use name;


[ARM 2005 13.3 (4)]
For an attribute_definition_clause that specifies an attribute that  
denotes a subprogram, the expected profile for the name is the profile  
required for the attribute.

However, it later says:

[ARM 2005 13.3 (5/1)]
An attribute_designator is allowed in an attribute_definition_clause only  
if this International Standard explicitly allows it

Comes with a tiny example:


[AARM 2005 13.3 (6a)]
Ramification: This implies, for example, that if one writes:
for T'Read use R;
R has to be a procedure with two parameters with the appropriate subtypes  
and modes as shown in

Finally, it should be checked if Image is explicitely allowed as an  
attribute designator for an operational clause (I may check later to give  
you a more formal answer to this one question).

I use representation clauses from time to time, but I've never used this  
kind of one, for the reason I give you right after now.

>  function LNumber_To_String(LNO : LNumber_Type) return String;
>
> Finally, there is actually a third question- more along
> the lines of "Should this language feature be used
> in this manner?", or is it preferable to just code your
> own along the lines of (which is what I presently use):
>
>  function To_String(LNO : LNumber_Type) return String;
>
> Inquiring minds need to know,
>
> Warren
I would say, it is more handy to define a function, because a function  
would be able to hold the exact formatting parameter your application  
requires, it would be able to hold the exact optional defaults for those  
parameters and it would better integrates with the overall general design  
of an Ada application, that, “withing” package and using renames clause.  
Using attribute, you are require to always use thye type name as a prefix  
for such things as ’Image. With function, you may “withed” the package  
defining this function, and make it part of the local scope using  
something like “function F (...) ... renames My_Package.F ...”.

More handy IMHO.

All of this providing I've understood what you were requesting for.

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Jeffrey R. Carter]

Warren wrote:
> 
>  type LNumber_Type is range 0..99_999;
> 
> Can I declare..
> 
>  for LNumber_Type'Image use LNumber_To_String;

No. Nor can I see why you'd want to. Once you declare

function Image (Value : Lnumber_Type) return String;

why would you want to write

Lnumber_Type'Image (I)

rather than

Image (I)

?

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

Re: for S'Image use Func??

[Warren]

Jeffrey R. Carter expounded in news:hrv32p$nnu$1@tornado.tornevall.net:

> Warren wrote:
>> 
>>  type LNumber_Type is range 0..99_999;
>> 
>> Can I declare..
>> 
>>  for LNumber_Type'Image use LNumber_To_String;
> 
> No. Nor can I see why you'd want to. Once you declare
> 
> function Image (Value : Lnumber_Type) return String;
> 
> why would you want to write
> 
> Lnumber_Type'Image (I)
> 
> rather than
> 
> Image (I)
> 
> ?

I agree that it is indeed clumsier. It's just that
I tend to use it a lot in debug output, rather than
chasing down the package prefix for the To_String()
function. I know I can always get away with:

Put_Line("The value V=" & T'Image(V));

But everyone has convinced me that it is not a good
practice, even if it were allowed. :)

Warren

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

Adam Beneschan expounded in news:2318cabb-080c-42a0-8219-21c347abe172
@o11g2000yqj.googlegroups.com:

>> �type LNumber_Type is range 0..99_999;
>>
>> Can I declare..
>>
>> �for LNumber_Type'Image use LNumber_To_String;
> 
> No.
> 
> Broadly, you can't use a FOR attribute specification on every
> attribute, just a few select ones that the language specifically says
> you can.  'Image isn't one of those.
> 
> I think it's been mentioned a few times on this newsgroup that it
> might be nice to have this ability, but I don't see that anyone has
> submitted an actual language change proposal.
> 
>                                 -- Adam

There's probably bigger fish to fry, I suppose. 

I'm just being a typical lazy programmer (not always 
wanting to lookup the correct package prefix for
the To_String() function to use).

Warren

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

=?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in
news:op.vcaqajn0ule2fv@garhos: 

> Le Thu, 06 May 2010 19:10:20 +0200, Warren <ve3wwg@gmail.com> a
> écrit: 
> 
>> I have tried to google for this and have not yet found
>> a suitable answer, so I'll troll, er, poll for an
>> answer here..
>>
>> Is there the ability to substitute your own S'Image
>> function? For example, a basic interpreter might
>> define:
>>
>>  type LNumber_Type is range 0..99_999;
>>
>> Can I declare..
>>
>>  for LNumber_Type'Image use LNumber_To_String;

> However, it later says:
> 
> [ARM 2005 13.3 (5/1)]
> An attribute_designator is allowed in an attribute_definition_clause
> only  if this International Standard explicitly allows it
...
> Finally, it should be checked if Image is explicitely allowed as an  
> attribute designator for an operational clause (I may check later to
> give  you a more formal answer to this one question).

As others have suggested, probably not, or at best on
an implementation basis only. At best, this suggests
that this approach is unportable.

>> Finally, there is actually a third question- more along
>> the lines of "Should this language feature be used
>> in this manner?", or is it preferable to just code your
>> own along the lines of (which is what I presently use):
>>
>>  function To_String(LNO : LNumber_Type) return String;

> I would say, it is more handy to define a function, because a function
>  would be able to hold the exact formatting parameter your application
>  requires, it would be able to hold the exact optional defaults for
> those  parameters and it would better integrates with the overall
> general design  of an Ada application, that, “withing” package and
> using renames clause.  Using attribute, you are require to always use
> thye type name as a prefix  for such things as ’Image. 

True, but in my case I just needed the leading zeros, sans
any sign:

900 to be displayed as "00900" (vs " 900").

> All of this providing I've understood what you were requesting for.

Yep, you got it.

Warren

Re: for S'Image use Func??

[Warren]

Dmitry A. Kazakov expounded in news:10yarz51f24i9$.k5ouloeombf2$.dlg@
40tude.net:

> On Thu, 6 May 2010 17:10:20 +0000 (UTC), Warren wrote:
> 
>> I have tried to google for this and have not yet found
>> a suitable answer, so I'll troll, er, poll for an
>> answer here..
>> 
>> Is there the ability to substitute your own S'Image
>> function? For example, a basic interpreter might
>> define:
>> 
>>  type LNumber_Type is range 0..99_999;
>> 
>> Can I declare..
>> 
>>  for LNumber_Type'Image use LNumber_To_String;
>> 
>> If so, then the question is what the signature of 
>> the S'Image function looks like-- is it:
>> 
>>  function LNumber_To_String(LNO : LNumber_Type) return String;
> 
> I am not sure what do you mean, but the following is legal Ada:
> 
>    generic
>       type T is private;
>       with function Image (X : T) return String;   
>    package P is
>       ...
>    end P;
> 
>    type LNumber_Type is range 0..99_999;   
> 
>    package PI is new P (LNumber_Type, LNumber_Type'Image);
> 
> So attribute is a "plain" function with a clumsy name.

I would never have though along those lines, but agree
this isn't the "Right Thing"(T).

Thanks

Re: for S'Image use Func??

[Robert A Duff]

Warren <ve3wwg@gmail.com> writes:

> As others have suggested, probably not, or at best on
> an implementation basis only. At best, this suggests
> that this approach is unportable.

Definitely not, and not on an implementation-defined basis.
An implementation may define its own attributes, and it
can choose to make those user-specifiable, or not.
But an implementation cannot make 'Image user-specifiable.

Of course, an implementation can have a non-standard mode in
which 'Image is user-specifiable.  But in that mode, it's not
an Ada implementation.

> True, but in my case I just needed the leading zeros, sans
> any sign:
>
> 900 to be displayed as "00900" (vs " 900").

So create a function called Image that does that.
I think Image is a better name than To_String, by the way
-- it's a common convention to use Image.

The leading blank produced by T'Image is indeed annoying!
What were they thinking?!  Never mind, that's been discussed
to death.  It's not a huge problem, but it's one of the
first things new Ada programmers notice, and it's a real
turn-off.

- Bob

Re: for S'Image use Func??

[Robert A Duff]

Warren <ve3wwg@gmail.com> writes:

> I agree that it is indeed clumsier. It's just that
> I tend to use it a lot in debug output, rather than
> chasing down the package prefix for the To_String()
> function. I know I can always get away with:
>
> Put_Line("The value V=" & T'Image(V));

I don't understand that.  You need to chase down the package
in which T is declared, which is the same package in which
To_String (or better, Image) is declared.  Or use use clauses.

- Bob

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Thu, 06 May 2010 22:19:15 +0200, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:

> The leading blank produced by T'Image is indeed annoying!
> What were they thinking?!  Never mind, that's been discussed
> to death.  It's not a huge problem, but it's one of the
> first things new Ada programmers notice, and it's a real
> turn-off.
>
> - Bob
I'm sometime lazy too, so I did not check the reference about it, however,  
I can say today I used 'Image on a "mod type", and there was no heading  
blank, while that's true I have one with with kinds of Integer or Natural.

What there were thinking about ? Perhaps proper display when different  
numbers are displayed on a column and some are Integer, others Natural. By  
the way, Natural is a subset of Integer, so these are numbers which are  
always positive, not numbers without a sign.

A quick work around (for more serious stuff, it's good any way to write a  
custom Image function) : one typically wish to output numbers preceded by  
a text or label, so just don't put any trailing blank on the latter.

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Robert A Duff]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> What there were thinking about ? Perhaps proper display when different
> numbers are displayed on a column and some are Integer, others
> Natural.

But for "columns" you want something like:

    1
   -3
  123
 -123

But 'Image gives you:

 1
-3
 123
-123

I don't get it.  'Image isn't particularly helpful in producing
columnar output.

>... By  the way, Natural is a subset of Integer, so these are
> numbers which are  always positive, not numbers without a sign.

Sure, but the vast majority of integers I want to do 'Image on
are nonnegative.  For example, if you print the length of a
String, there is zero chance that it's negative, so leaving
an extra blank in case it might be negative makes no sense.

- Bob

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Thu, 06 May 2010 22:56:51 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Thu, 06 May 2010 22:19:15 +0200, Robert A Duff  
> <bobduff@shell01.theworld.com> a �crit:
> 
>> The leading blank produced by T'Image is indeed annoying!
>> What were they thinking?!  Never mind, that's been discussed
>> to death.  It's not a huge problem, but it's one of the
>> first things new Ada programmers notice, and it's a real
>> turn-off.
>>
> I'm sometime lazy too, so I did not check the reference about it, however,  
> I can say today I used 'Image on a "mod type", and there was no heading  
> blank, while that's true I have one with with kinds of Integer or Natural.

Not always. Blank is actually '+'. Integer'Image (-1) is "-1", no blanks.
Integer'Image (1) is " 1".

(In almost unlikely case if you printed integers in columns and these
integers were of same length, you would get columns aligned! (:-))

> What there were thinking about ?

punched cards? (:-))

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

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Thu, 06 May 2010 16:22:03 -0400, Robert A Duff wrote:

> Warren <ve3wwg@gmail.com> writes:
> 
>> I agree that it is indeed clumsier. It's just that
>> I tend to use it a lot in debug output, rather than
>> chasing down the package prefix for the To_String()
>> function. I know I can always get away with:
>>
>> Put_Line("The value V=" & T'Image(V));
> 
> I don't understand that.  You need to chase down the package
> in which T is declared, which is the same package in which
> To_String (or better, Image) is declared.

I always declare I/O/formatting stuff in a child package. So, T'Image has
some minor advantages. (The argument would really work if it were V'Image
or V.Image)

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

Re: for S'Image use Func??

[Jeffrey R. Carter]

Warren wrote:
> 
> True, but in my case I just needed the leading zeros, sans
> any sign:
> 
> 900 to be displayed as "00900" (vs " 900").

In my job we make extensive use of the image functions from PragmARC.Images. 
These have optional Width, Base, and Zero_Filled parameters. So we'd use

function Image is new PragmARC.Images.Signed_Image (Your_Signed_Integer_Type_Here);

Image (V, Width => 5, Zero_Filled => True)

to get your "00900". (There's also Modular_Image for modular integer types.) We 
use them a lot just to avoid the leading blank from 'Image, but also for this.

The PragmARCs are Ada 95, and many of the packages won't compile with a compiler 
for the current language, but this one will.

http://pragmada.x10hosting.com/

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

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 00:33:00 +0200, Jeffrey R. Carter  
<spam.jrcarter.not@spam.acm.org> a écrit:
> The PragmARCs are Ada 95, and many of the packages won't compile with a  
> compiler for the current language, but this one will.
>
> http://pragmada.x10hosting.com/
>
Although the style is not compatible with mine, so I will not use this for  
my stuff, I wanted to say these sources are nice reading.

Just a question : why the Assert procedure (in PragmARC.Assertion_Handler)  
? What was the intent as there is already the Assert pragma ? As far as I  
know, the Assert pragma was already there with Ada 95. Am I wrong with  
this point ?

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:2318cabb-080c-42a0-8219-21c347abe172@o11g2000yqj.googlegroups.com...
On May 6, 10:10 am, Warren <ve3...@gmail.com> wrote:
...
>Broadly, you can't use a FOR attribute specification on every
>attribute, just a few select ones that the language specifically says
>you can.  'Image isn't one of those.
>
>I think it's been mentioned a few times on this newsgroup that it
>might be nice to have this ability, but I don't see that anyone has
>submitted an actual language change proposal.

I believe we looked at it semi-seriously back during the Ada 2005, but we 
ran into some problems (I don't recall the details - might have been 
visibility) and decided it wasn't worth the headache.

It would probably be possible with some work.

                                     Randy.

Re: for S'Image use Func??

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.vca4jlxbxmjfy8@garhos...
...
>Just a question : why the Assert procedure (in PragmARC.Assertion_Handler) 
>? What was the intent as there is already the Assert pragma ? As far as I 
>know, the Assert pragma was already there with Ada 95. Am I wrong with 
>this point ?

A lot of Ada 95 implementations had an Assert pragma, but it was not part of 
the language until Ada 2005. So if you wanted to be 100% portable, you 
didn't use it. (I've still never written an Assert pragma.)

I actually don't buy the need for the Assert pragma in the first place: such 
checks are rarely expensive and thus should simply be part of the code 
always. (And the ones that are expensive need a lot more control than simply 
on or off: Janus/Ada uses trace switches that can be controlled on a 
per-unit basis.)

But it is so simple that it is harmless even if not very valuable. Thus I 
didn't oppose adding it to the language.

                  Randy.

Re: for S'Image use Func??

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1ojboulapml8w$.1w5gfpk45kh72.dlg@40tude.net...
> On Thu, 06 May 2010 16:22:03 -0400, Robert A Duff wrote:
>
>> Warren <ve3wwg@gmail.com> writes:
>>
>>> I agree that it is indeed clumsier. It's just that
>>> I tend to use it a lot in debug output, rather than
>>> chasing down the package prefix for the To_String()
>>> function. I know I can always get away with:
>>>
>>> Put_Line("The value V=" & T'Image(V));
>>
>> I don't understand that.  You need to chase down the package
>> in which T is declared, which is the same package in which
>> To_String (or better, Image) is declared.
>
> I always declare I/O/formatting stuff in a child package. So, T'Image has
> some minor advantages. (The argument would really work if it were V'Image
> or V.Image)

Except that you can't specify an attribute of a type after it is frozen. So 
if you could specify T'Image, you couldn't define the Image function that 
you specified in a child package. Thus Bob is right: the type and the 
function has to be in the same package.

(Well, I guess you could use some other subtype that is declared somewhere 
else as the prefix. Not sure that helps much.)

                      Randy.

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Thu, 6 May 2010 21:20:46 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1ojboulapml8w$.1w5gfpk45kh72.dlg@40tude.net...
>> On Thu, 06 May 2010 16:22:03 -0400, Robert A Duff wrote:
>>
>>> Warren <ve3wwg@gmail.com> writes:
>>>
>>>> I agree that it is indeed clumsier. It's just that
>>>> I tend to use it a lot in debug output, rather than
>>>> chasing down the package prefix for the To_String()
>>>> function. I know I can always get away with:
>>>>
>>>> Put_Line("The value V=" & T'Image(V));
>>>
>>> I don't understand that.  You need to chase down the package
>>> in which T is declared, which is the same package in which
>>> To_String (or better, Image) is declared.
>>
>> I always declare I/O/formatting stuff in a child package. So, T'Image has
>> some minor advantages. (The argument would really work if it were V'Image
>> or V.Image)
> 
> Except that you can't specify an attribute of a type after it is frozen. So 
> if you could specify T'Image, you couldn't define the Image function that 
> you specified in a child package. Thus Bob is right: the type and the 
> function has to be in the same package.

Right. Primitive operations are somewhat incompatible with modularity (and
multiple dispatch as well). There must be something wrong with that, though
I cannot figure out what.

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

Re: for S'Image use Func??

[stefan-lucks]

On Thu, 6 May 2010, Warren wrote:

> I'm just being a typical lazy programmer (not always 
> wanting to lookup the correct package prefix for
> the To_String() function to use).

How about overloading the &-operator:

  function "&"(S: String; Item: T) return String;

if X is of type T and you "use type T", you can replace the expression 

  T'Image(X)

by 

   "" & X

If your T'Image(X) is part of a larger string expression, overloading & 
appears to be very convenient (for the "typical lazy programmer", as you 
put it):

  Ada.Text_IO.Put_Line("The first result is " & X & 
                       " the second result is " & Y & ".");

So long

Stefan


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: for S'Image use Func??

[J-P. Rosen]

Robert A Duff a �crit :
> "Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> But for "columns" you want something like:
> 
>     1
>    -3
>   123
>  -123
> 
> But 'Image gives you:
> 
>  1
> -3
>  123
> -123
> 
> I don't get it.  'Image isn't particularly helpful in producing
> columnar output.
> 
	
'Image is just for quick, debug-like output. If you want nice formatted
output, by all means use the IO packages, that's what they are for.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: for S'Image use Func??

[Georg Bauhaus]

On 5/6/10 7:10 PM, Warren wrote:

> Finally, there is actually a third question- more along
> the lines of "Should this language feature be used
> in this manner?", or is it preferable to just code your
> own along the lines of (which is what I presently use):

Apologies for the length of the following. In short:
not in this manner, use Ada instead, don't tweak
the language, no need.

[1. mislead assumptions].
If, as Bob has said, programmers discover 'Image before
they discover Text_IO.*_IO and Text_IO.Editing, then there
is something wrong, indeed---with Ada's appearance before
them!  If you want them to be able to write an output
line quickly, give them a package! Don't misuse 'Image.
They may be quite used to industry standard logging packages
and such, no hurdle there.

[2. 'Image *and* 'Value are paired and have a purpose,
or contract].
Is 'Image a formatting function? I don't think so.
Is it intended to be one? I can't imagine that, not in any
non-trivial sense of the word "formatting".
  'Value is its counter part. Is it a scanning function?
I don't think that, either, for the same reason.
And if 'Image and 'Value come in pairs, redefining
one without the other seems wrong. So what should a user-
defined 'Value be? Shouldn't it agree with what the LRM
implies?  Should not the new Generic_Dispatching_Constructor
be its equivalent?
   Should we, in spite of all this, deprive ourselves of
what we routinely do in other cases? That is, ideally we
express the purpose of a function call with suitably and
freely chosen names for an implementation that meets our
needs.

You said you were too lazy to ... and therefore wanted
to adapt something half related to your purpose.
You might be doing yourself (and your readers) a disservice.
To see this: What is the contract if 'Image, expressed
as pre- and post-conditions?  What could this description
be in the standard if programmers we invited to dismiss
printing packages in favor of user defined 'Image, thereby
manipulating the contract of 'Image?

[3. Use normal Ada for polymorphism].
If I wanted polymorphic behavior of numbers,
I'd make them have a suitable type. Or wrap them in
one where necessary, e.g. during I/O. Or mix them with
a package that provides "polymorphic appearance" like
Dmitry's or, IIUC, PragmAda.

You can say

   type Derived_Num_Type is new <some number type>;

   overriding
   function Image (X: Derived_Num_Type) return String;

where Derived_Num_Type is both tag-less and has an
Image operation that makes strings the way you want
them.

[4. no need].
Why do Ada programmers forget Ada language
principles whenever it comes to basic values? :o(
Is it not obvious that using 'Image in ways it was not
intended to be used makes the program text misleading?

I can understand that the customer is always right
and that Ada vendors would quite naturally consider
tweaking 'Image.  But I also hope they have ways to
provide alternatives based on existing Ada that will
serve both their customers and Ada. Certainly you know
what your image functions should do.  So write them.


-- Georg

Re: for S'Image use Func??

[Stephen Leake]

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

> On Thu, 06 May 2010 16:22:03 -0400, Robert A Duff wrote:
>
>> Warren <ve3wwg@gmail.com> writes:
>> 
>>> I agree that it is indeed clumsier. It's just that
>>> I tend to use it a lot in debug output, rather than
>>> chasing down the package prefix for the To_String()
>>> function. I know I can always get away with:
>>>
>>> Put_Line("The value V=" & T'Image(V));
>> 
>> I don't understand that.  You need to chase down the package
>> in which T is declared, which is the same package in which
>> To_String (or better, Image) is declared.
>
> I always declare I/O/formatting stuff in a child package. 

Me, to. And the childe package is named Images.

> So, T'Image has some minor advantages. (The argument would really work
> if it were V'Image or V.Image)

It's Foo.Bar.T'Image vs Foo.Bar.Images.Image. No problem.

-- 
-- Stephe

Re: for S'Image use Func??

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Robert A Duff a �crit :
>> But for "columns" you want something like:
>> 
>>     1
>>    -3
>>   123
>>  -123
>> 
>> But 'Image gives you:
>> 
>>  1
>> -3
>>  123
>> -123
>> 
>> I don't get it.  'Image isn't particularly helpful in producing
>> columnar output.
> 	
> 'Image is just for quick, debug-like output.

So that's why it's broken?!

I'm imagining the Ada 83 design team saying, "This feature is
only for quick, debug-like output, so let's make it do
something annoying, so folks won't be able to use it
for serious work, MWAHAHAH."  ;-)
Sorry, I don't buy that -- I think they just made a mistake.

And it's too late to fix it.

>...If you want nice formatted
> output, by all means use the IO packages, that's what they are for.

I don't want nice formatted output.  I want the human-readable
string image of the number, and for 123, that's "123",
not " 123".  In other words, I want:

Put_Line (Error_Count'Image (Num_Errors) & " errors detected.");

to print:

123 errors detected.

All this talk about formatting came from folks asking
why does 'Image produce an annoying blank, and the
proposed answer was "for columnar formatted output",
and the response is "no, that doesn't explain it,
because an annoying blank doesn't do columnar output".

- Bob

Re: for S'Image use Func??

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> I actually don't buy the need for the Assert pragma in the first place: such 
> checks are rarely expensive and thus should simply be part of the code 
> always.

If they're not expensive, then you're not using it enough.  ;-)

Also, the other advantage of pragma Assert over an Assert
procedure is that you can put the pragma in declarative parts
and package specs.

>... (And the ones that are expensive need a lot more control than simply 
> on or off: Janus/Ada uses trace switches that can be controlled on a 
> per-unit basis.)

Sorry, I don't buy that sort of argument in general: If you want to
do (simple) X, you probably also want (complicated) Y, so we're
not going to allow X.

- Bob

Re: for S'Image use Func??

[Georg Bauhaus]

On 07.05.10 14:21, Robert A Duff wrote:
> "J-P. Rosen" <rosen@adalog.fr> writes:

>>> I don't get it.  'Image isn't particularly helpful in producing
>>> columnar output.
>> 	
>> 'Image is just for quick, debug-like output.
> 
> So that's why it's broken?!
> 
> I'm imagining the Ada 83 design team saying, "This feature is
> only for quick, debug-like output, so let's make it do
> something annoying, so folks won't be able to use it
> for serious work, MWAHAHAH."  ;-)
> Sorry, I don't buy that -- I think they just made a mistake.

With 'Width given, and with 'Value reading "+123" like
" 123", WRT to what is there a mistake?
Would there be a discussion at all if "+123" had
been chosen as the result of 'Image (123)?


> I don't want nice formatted output.  I want the human-readable
> string image of the number, and for 123, that's "123",
> not " 123".

"123" to be the only representation ever wanted for 123 seems
like a far reaching assumption to me.  Others may want "+123" for
positive, "#123" for negative etc.   And "123" just *happens* to
be what one might want in this or that case.

I imagine that writing two statements for "just a number
and a string" makes some programmers feel annoyed because two
statements instead of one---though involving two functions---seems
verbose.

  Put (Num_Errors);
  Put_Line (" errors detected.");

"You never do such complicated things in Javascript's alert()"...
A way out:

  Put (Num_Errors); Put_Line (" errors detected.");

Re: for S'Image use Func??

[Robert A Duff]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> With 'Width given, and with 'Value reading "+123" like
> " 123", WRT to what is there a mistake?

I don't think I've ever used 'Width in my entire life.
Anyway, 'Width has little to do with 'Image,
since 'Image doesn't have a Width parameter.

And 'Value also accepts "                123    ",
which is not an argument for putting in a whole
bunch of blanks.

> Would there be a discussion at all if "+123" had
> been chosen as the result of 'Image (123)?

Then there'd be a different discussion, about the
"annoying plus sign".  ;-)

Num_Errors, like most integer subtypes, doesn't have
any negative numbers.  Putting in a "+" sign makes
even less sense than putting in a blank.

>> I don't want nice formatted output.  I want the human-readable
>> string image of the number, and for 123, that's "123",
>> not " 123".
>
> "123" to be the only representation ever wanted for 123 seems
> like a far reaching assumption to me.  Others may want "+123" for
> positive, "#123" for negative etc.   And "123" just *happens* to
> be what one might want in this or that case.

"123" is by far the most common representation wanted.
And if you want to stick in a blank or a "+",
it's easy to concatenate that, whereas removing such
junk is verbose and error prone.

Sometimes, you want ", and" after the number -- but
you don't want 'Image to stick that in for you!

> I imagine that writing two statements for "just a number
> and a string" makes some programmers feel annoyed because two
> statements instead of one---though involving two functions---seems
> verbose.
>
>   Put (Num_Errors);
>   Put_Line (" errors detected.");

The problem with the Text_IO design is that it mixes
I/O with formatting.  It would be cleaner to separate these.

It would also be cleaner to separate I from O, but that's
another story.

Anyway, the question was, "Why on Earth would they put
in that annoying blank?"  As far as I can tell, the
correct answer is "No reason -- they did it by mistake."
You can't answer the question by pointing out various
workarounds.

And teaching beginners how to instantiate generics,
when there's a simple 'Image feature, is not a good idea.

- Bob

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 12:15:11 +0200, Stephen Leake  
<stephen_leake@stephe-leake.org> a écrit:
>> I always declare I/O/formatting stuff in a child package.
>
> Me, to. And the childe package is named Images.
Are you talking about packages defining multiple types ?

I had to ask this question to be sure, as I can't so much easily figure  
out what's the layout of what you are talking about (although this is  
probably simple).

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 14:27:35 +0200, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> I actually don't buy the need for the Assert pragma in the first place:  
>> such
>> checks are rarely expensive and thus should simply be part of the code
>> always.
>
> If they're not expensive, then you're not using it enough.  ;-)
Hihi, nice

> Also, the other advantage of pragma Assert over an Assert
> procedure is that you can put the pragma in declarative parts
> and package specs.
That's what I like to do too : define Assert pragmas in package spec, so  
that it can be used to derive some property in the implementation or in  
some other part of the specification. This express coherence between some  
elements or other things (there are things which cannot be expressed with  
type properties), on which you can rely to say “this and this, is valid,  
because of that (the Assert pragma somewhere)”. I find it useful to safely  
drop some runtime check whenever something must be fast or is looped  
thousands of times, or even simply to be sure something is OK (no need for  
execution speed requirements to wish that). If the assumptions are wrong  
and so what is derived from these too, well, the package simply raise an  
exception at elaboration instead of behaving oddly.

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 04:17:41 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> always. (And the ones that are expensive need a lot more control than  
> simply
> on or off: Janus/Ada uses trace switches that can be controlled on a
> per-unit basis.)
There was something similar with an Eiffel compiler (I don't remember if  
it was part of the Eiffel standard).

That sounds interesting (thanks for explaining what is your compiler from  
times to times)

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 15:37:55 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
>   Put (Num_Errors);
>   Put_Line (" errors detected.");
Here is, that's also my preferred way to do to output execution logs.

That's not so much annoying, while this is a written-once-used-many-times.

However, I'm not so much sure the reason must be something like  
JavaScript's alert boxes leaking in Ada ; this may simply be a question  
coming from inquisitive peoples.

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 16:25:37 +0200, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:
> And teaching beginners how to instantiate generics,
> when there's a simple 'Image feature, is not a good idea.
Mhhhh... don't agree. 'Image is a kind of hidden genericity, and students  
would get more benefit in learning the explicit one. Student will get more  
learning to instantiate generics which are used every-where, better than  
thinking the purpose of the language is to provide them tricky candies to  
quickly do this and that and that using Ada there are expected to play  
with or think about such tricky things.

Generic instantiation (or user defined functions for user defined types)  
is a more proper way to reach the OP's given expectation than using an  
'Image, which as Jean-Pierre said, should be reserved for quick and dirty  
stuff. 'Image is not a big deal of the language, that's its purpose.

Forgive me for these wording I don't like : starting to have heavy  
requirement on the 'Image attribute would be the start of bloating and the  
start of Ada as a library instead of Ada as a language and as a design  
language..

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Fri, 07 May 2010 17:46:09 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Fri, 07 May 2010 16:25:37 +0200, Robert A Duff  
> <bobduff@shell01.theworld.com> a �crit:
>> And teaching beginners how to instantiate generics,
>> when there's a simple 'Image feature, is not a good idea.
> Mhhhh... don't agree. 'Image is a kind of hidden genericity,

Polymorphism. Genericity is a kind of polymorphism (static), but not all
polymorphism is genericity. If you consider image statically polymorphic,
then it is more the C++ way than the Ada's one. Compare:

   T'Image(X)      image<T>(x)

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

Re: for S'Image use Func??

[Keith Thompson]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> "Adam Beneschan" <adam@irvine.com> wrote in message 
> news:2318cabb-080c-42a0-8219-21c347abe172@o11g2000yqj.googlegroups.com...
> On May 6, 10:10 am, Warren <ve3...@gmail.com> wrote:
> ...
>>Broadly, you can't use a FOR attribute specification on every
>>attribute, just a few select ones that the language specifically says
>>you can.  'Image isn't one of those.
>>
>>I think it's been mentioned a few times on this newsgroup that it
>>might be nice to have this ability, but I don't see that anyone has
>>submitted an actual language change proposal.
>
> I believe we looked at it semi-seriously back during the Ada 2005, but we 
> ran into some problems (I don't recall the details - might have been 
> visibility) and decided it wasn't worth the headache.
>
> It would probably be possible with some work.

The interaction with 'Value and 'Width, and with the Wide_ and
Wide_Wide_ variants of all three attributes, would be ... interesting.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: for S'Image use Func??

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

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

>> So, T'Image has some minor advantages. (The argument would really work
>> if it were V'Image or V.Image)
>
> It's Foo.Bar.T'Image vs Foo.Bar.Images.Image. No problem.

I know it's an implementation-defined attribute, but for non-operational
quick-and-dirty code that doesn't need to be portable I use GNAT's V'Img
(shame it still has the leading space for positive numbers!)

Sometimes the 'Image way is useful even in that sort of context:
   Duration'Image (Finish_Time - Start_Time)
avoids the need for a local variable which 'Img would require.

Re: for S'Image use Func??

[Georg Bauhaus]

Robert A Duff wrote:
> Simon Wright <simon@pushface.org> writes:
> 
>> Sometimes the 'Image way is useful even in that sort of context:
>>    Duration'Image (Finish_Time - Start_Time)
>> avoids the need for a local variable which 'Img would require.
> 
> By the way, I think this:
> 
>     Put_Line (Duration'(Finish_Time - Start_Time)'Img);
> 
> will be legal in Ada 2012.  Well, the 'Img is still a
> GNAT-specific thing, but I'm talking about the ability to
> use a qualified expression as the prefix of an attribute.
> 
> Now why isn't this:
> 
>     Put_Line ((Finish_Time - Start_Time)'Img);
> 
> legal?  I don't know, but the language is moving in
> that direction -- maybe by 2099,  the syntactic distinction between
> expression and name (and the semantic distinction between
> value and object) will disappear entirely.

This move towards expressions is not one of SPARK?
Lifting expressions into the rank of named entities
will inevitably give way to the temptation of not saying
(naming) what you mean. (Like anonymous access is reportedly
doing already in all sorts of places, giving rise
to another naming lasso, 'Ref IIRC.)

If this move favors placing the semantically first part of an
expression last, at the end, in the "by the way" position,
will Ada at last become a writer's favorite?

  - ((71)'Val & 'e' & TLD (3221233671))'Img

Re: for S'Image use Func??

[J-P. Rosen]

Robert A Duff a �crit :
> "J-P. Rosen" <rosen@adalog.fr> writes:
> 
>> Robert A Duff a �crit :
>>> But for "columns" you want something like:
>>>
>>>     1
>>>    -3
>>>   123
>>>  -123
>>>
>>> But 'Image gives you:
>>>
>>>  1
>>> -3
>>>  123
>>> -123
>>>
>>> I don't get it.  'Image isn't particularly helpful in producing
>>> columnar output.
>> 	
>> 'Image is just for quick, debug-like output.
> 
> So that's why it's broken?!
I was just responding that 'Image is not for columns, and of course I
agree that the extra space was a mistake - just like making Priority a
subtype of Integer.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: for S'Image use Func??

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> Sometimes the 'Image way is useful even in that sort of context:
>    Duration'Image (Finish_Time - Start_Time)
> avoids the need for a local variable which 'Img would require.

By the way, I think this:

    Put_Line (Duration'(Finish_Time - Start_Time)'Img);

will be legal in Ada 2012.  Well, the 'Img is still a
GNAT-specific thing, but I'm talking about the ability to
use a qualified expression as the prefix of an attribute.

Now why isn't this:

    Put_Line ((Finish_Time - Start_Time)'Img);

legal?  I don't know, but the language is moving in
that direction -- maybe by 2099, the syntactic distinction between
expression and name (and the semantic distinction between
value and object) will disappear entirely.

- Bob

Re: for S'Image use Func??

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Robert A Duff a �crit :
>> So that's why it's broken?!
> I was just responding that 'Image is not for columns, and of course I
> agree that the extra space was a mistake

Oh, OK, then we agree.  That was my point, too: 'Image is not for
columns, so "for columns" can't explain the extra blank.

>... - just like making Priority a
> subtype of Integer.

I agree, but students won't run into that one in the
first week of the beginner's class.

First impressions matter.

- Bob

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 19:38:12 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Polymorphism. Genericity is a kind of polymorphism (static), but not all
> polymorphism is genericity.
You're right Dmitry, I miss-used the word “generic” here. Happy to read  
this re-rewording ;)

> If you consider image statically polymorphic,
> then it is more the C++ way than the Ada's one. Compare:
>
>    T'Image(X)      image<T>(x)
I could not tell anything about this, as I've forgotten too much about C++  
(and especially concerning area).


-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 21:56:19 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
>>> 'Image is just for quick, debug-like output.
>>
>> So that's why it's broken?!
> I was just responding that 'Image is not for columns, and of course I
> agree that the extra space was a mistake - just like making Priority a
> subtype of Integer.
Is there an existing list somewhere compiling this kind of “tiny” errors  
in the standard's choices ?

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Robert A Duff]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Fri, 07 May 2010 14:27:35 +0200, Robert A Duff
> <bobduff@shell01.theworld.com> a �crit:
>
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>
>>> I actually don't buy the need for the Assert pragma in the first
>>> place:  such
>>> checks are rarely expensive and thus should simply be part of the code
>>> always.
>>
>> If they're not expensive, then you're not using it enough.  ;-)
> Hihi, nice
>
>> Also, the other advantage of pragma Assert over an Assert
>> procedure is that you can put the pragma in declarative parts
>> and package specs.
> That's what I like to do too : define Assert pragmas in package spec,
> ...

Then you will probably like some of the new proposals for Ada 2012 --
take a look at preconditions, postconditions, subtype predicates,
and type invariants.

I am particularly fond of subtype predicates, but I'm afraid
many ARG members do not (yet?!) agree with me on that.

GNAT's pragmas Compile_Time_Error and Compile_Time_Warning
can also be useful in this general area.

- Bob

Re: for S'Image use Func??

[Jeffrey R. Carter]

Yannick Duchêne (Hibou57) wrote:
> I could not tell anything about this, as I've forgotten too much about 
> C++ (and especially concerning area).

You can never forget too much about C++.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: for S'Image use Func??

[Robert A Duff]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Fri, 07 May 2010 16:25:37 +0200, Robert A Duff
> <bobduff@shell01.theworld.com> a �crit:
>> And teaching beginners how to instantiate generics,
>> when there's a simple 'Image feature, is not a good idea.
> Mhhhh... don't agree.

Note that I said "beginners", not "students".

A beginner needs to learn how to write a "Hello, world" program
first, and soon thereafter, some simple thing that involves
printing out integer values.  I think one of my first assignments
way back when was to write a program to add up two numbers
and print out the answer.  If that's hard, it gives a bad
first impression.  (In fact, it WAS hard -- it involved
horsing around with Fortran FORMAT statements and Hollerith codes,
which is worse than horsing around with Ada generics.)

>... 'Image is a kind of hidden genericity, and
> students  would get more benefit in learning the explicit one.

Yes, Ada students need to learn about generics -- eventually,
not in the first week of class.  There's just no way a
beginning programmer can understand generics in the first week.

Simple things should be simple.

> Forgive me for these wording I don't like : starting to have heavy
> requirement on the 'Image attribute would be the start of bloating and
> the  start of Ada as a library instead of Ada as a language and as a
> design  language..

I disagree.  Certainly removing the extra blank would not introduce
bloat.  And in fact, giving 'Image the exact same functionality
as Integer_Text_IO would _simplify_ the language, by making
it more uniform.

- Bob

Re: for S'Image use Func??

[Robert A Duff]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Fri, 07 May 2010 15:37:55 +0200, Georg Bauhaus
> <rm.dash-bauhaus@futureapps.de> a �crit:
>>   Put (Num_Errors);
>>   Put_Line (" errors detected.");
> Here is, that's also my preferred way to do to output execution logs.
>
> That's not so much annoying, while this is a written-once-used-many-times.

Well, that "Put (Num_Errors);" is hiding something.  You have to
instantiate Text_IO.Integer_IO for all the integer types you
need to output.  That's annoying.

- Bob

Re: for S'Image use Func??

[Robert A Duff]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Fri, 07 May 2010 21:56:19 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
>>>> 'Image is just for quick, debug-like output.
>>>
>>> So that's why it's broken?!
>> I was just responding that 'Image is not for columns, and of course I
>> agree that the extra space was a mistake - just like making Priority a
>> subtype of Integer.
> Is there an existing list somewhere compiling this kind of “tiny” errors
> in the standard's choices ?

I have such a list -- in my head.  ;-)

Sorry, there's no room in the margin of this document to list them
all, so I'll just mention one:  lack of zero-element and one-element
positional array aggregates.  Not a big problem, just a minor
annoyance.

And I also have such lists in my head for many other
programming languages.  ;-)

- Bob

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 22:31:47 +0200, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:
> Note that I said "beginners", not "students".
>
> [...]
>
> A beginner needs to learn how to write a "Hello, world" program
> first, and soon thereafter, some simple thing that involves
> printing out integer values.  I think one of my first assignments
> way back when was to write a program to add up two numbers
> and print out the answer.  If that's hard, it gives a bad
> first impression.  (In fact, it WAS hard -- it involved
> horsing around with Fortran FORMAT statements and Hollerith codes,
> which is worse than horsing around with Ada generics.)
>
> [...]
>
> Yes, Ada students need to learn about generics -- eventually,
> not in the first week of class.  There's just no way a
> beginning programmer can understand generics in the first week.
>
> Simple things should be simple.
>

So (especially if you're a teacher), just provide them a package with  
useful stuffs of the like. This is how I first switched from a Pascal  
dialect to Ada 95 : I could understand somethings, found it was not so  
much easy at first glance, but still could create a package with  
functionalities inspired from what's provided with typical Pascal program  
; then later just dropped this.

The pending question may be now : when should students or beginners be  
able to understand the concept of using an “external” component ? Perhaps  
they should not start typing anything prior to that, and should start  
learning, at the very beginning, listening someone recounting them nice  
and happy stories involving basic abstraction principles :)

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Robert A Duff]

Georg Bauhaus <see.reply.to@maps.futureapps.de> writes:

> If this move favors placing the semantically first part of an
> expression last, at the end, in the "by the way" position,
> will Ada at last become a writer's favorite?
>
>  - ((71)'Val & 'e' & TLD (3221233671))'Img

Well, that's a good point.  I guess I agree
that Image(...) is more readable than (...).Image
or something like that.

- Bob

Re: for S'Image use Func??

[Robert A Duff]

"Yannick DuchÔøΩne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> So (especially if you're a teacher), ...

(I'm not a teacher, although I've done some teaching of
programming.  I like to think of myself as a language designer,
and part of my job as a language designer is to make
the language easy to learn.)

>...just provide them a package with
> useful stuffs of the like.

Yes, that can work.  But it can also be confusing: the student
wonders why Simple_IO is not available when they move to a
different environment.

>...This is how I first switched from a Pascal
> dialect to Ada 95 : I could understand somethings, found it was not so
> much easy at first glance, but still could create a package with
> functionalities inspired from what's provided with typical Pascal
> program  ; then later just dropped this.
>
> The pending question may be now : when should students or beginners be
> able to understand the concept of using an ÔøΩexternalÔøΩ component ?
> Perhaps  they should not start typing anything prior to that, and should
> start  learning, at the very beginning, listening someone recounting
> them nice  and happy stories involving basic abstraction principles :)

Interesting question.  I think beginners need to learn a few
basic things (like how to use an 'if' statement) before
getting into "abstraction principles".

Dijkstra took it to an extreme: students have to spend a year
doing mathematical proofs about programs, before they're
allowed to compile or run their programs.  I don't recommend that.  ;-)

- Bob

Re: for S'Image use Func??

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccd3x7lww8.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> I actually don't buy the need for the Assert pragma in the first place: 
>> such
>> checks are rarely expensive and thus should simply be part of the code
>> always.
>
> If they're not expensive, then you're not using it enough.  ;-)

If they're expensive, they have to be programmed and debugged like any other 
code. That causes extra work, which is the exact opposite of what an agile 
programmer would do. (And I've been an agile programmer long before anybody 
defined the technique or made lots of money selling seminars about it.)

> Also, the other advantage of pragma Assert over an Assert
> procedure is that you can put the pragma in declarative parts
> and package specs.

True, although I have sometimes used functions and dummy constants for that 
purpose. (They'd have to be declared "volatile" in order to be portable, I 
guess; it doesn't matter for Janus/Ada since we never eliminate objects or 
their last write.)

>>... (And the ones that are expensive need a lot more control than simply
>> on or off: Janus/Ada uses trace switches that can be controlled on a
>> per-unit basis.)
>
> Sorry, I don't buy that sort of argument in general: If you want to
> do (simple) X, you probably also want (complicated) Y, so we're
> not going to allow X.

No, that's not my argument at all. "Simple X" in this case is useless or 
even harmful. You *have to* do compilacated Y, otherwise you are are only 
using the seat belts in the garage. It almost never makes sense to turn 
these things off, so why even have the capability? It's like giving everyone 
a shotgun but telling them never to use it.

Anyway, I realize that you have said that you don't believe in the "seat 
belt" analogy. As such, there is really no point in arguing with you on this 
topic: we don't even agree on the arena of discourse.

                          Randy.

Re: for S'Image use Func??

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> wrote in message 
news:hs1t6h$kj2$1@tornado.tornevall.net...
> Yannick Duch�ne (Hibou57) wrote:
>> I could not tell anything about this, as I've forgotten too much about 
>> C++ (and especially concerning area).
>
> You can never forget too much about C++.

If I actually used a signature line, I think I'd be using that one!!

               Randy.

You can never forget too much about C++. - Jeffrey Carter

Re: for S'Image use Func??

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcctyqjh2rw.fsf@shell01.TheWorld.com...
...
> I disagree.  Certainly removing the extra blank would not introduce
> bloat.  And in fact, giving 'Image the exact same functionality
> as Integer_Text_IO would _simplify_ the language, by making
> it more uniform.

Humm, I could see giving 'Image more functionality, but the entrety of 
Integer_Text_IO would be way too much. The formatter for Integer Put is 
*huge* (about 300 lines in Janus/Ada). I could see adding a Width parameter, 
but not the base stuff. Keep in mind that the code for 'Image is part of 
every program (it's written in assembler in Janus/Ada to keep it as small as 
possible); I would not want to bloat up every program that much.

                            Randy.

Re: for S'Image use Func??

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccpr17h2od.fsf@shell01.TheWorld.com...
> "Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>
>> Le Fri, 07 May 2010 15:37:55 +0200, Georg Bauhaus
>> <rm.dash-bauhaus@futureapps.de> a �crit:
>>>   Put (Num_Errors);
>>>   Put_Line (" errors detected.");
>> Here is, that's also my preferred way to do to output execution logs.
>>
>> That's not so much annoying, while this is a 
>> written-once-used-many-times.
>
> Well, that "Put (Num_Errors);" is hiding something.  You have to
> instantiate Text_IO.Integer_IO for all the integer types you
> need to output.  That's annoying.

It doesn't work very well, either, if you are outputting to a message box or 
to a log manager: in both cases the entire message string has to be passed 
at once. (That's the case in virtually all of my newer programs.) Not many 
real programs do much output to Standard Output.

                                Randy.

Re: for S'Image use Func??

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> It doesn't work very well, either, if you are outputting to a message box or 
> to a log manager: in both cases the entire message string has to be passed 
> at once. (That's the case in virtually all of my newer programs.) Not many 
> real programs do much output to Standard Output.

Right, that's exactly what I meant when I said elsewhere in this
thread that it's a good idea to separate formatting from output.
Sometimes you want "format some stuff and dump it immediately
to a file".  Other times you want "format some stuff" (and then
sort the messages and grind upon them etc.) and then much later
"send to log manager" or whatever.

- Bob

Re: for S'Image use Func??

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Now why isn't this:
>
>     Put_Line ((Finish_Time - Start_Time)'Img);
>
> legal?

Can the compiler be expected to work out what that function "-" is?

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Fri, 07 May 2010 23:27:55 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
>> Well, that "Put (Num_Errors);" is hiding something.  You have to
>> instantiate Text_IO.Integer_IO for all the integer types you
>> need to output.  That's annoying.
>
> It doesn't work very well, either, if you are outputting to a message  
> box or
> to a log manager: in both cases the entire message string has to be  
> passed
> at once. (That's the case in virtually all of my newer programs.) Not  
> many
> real programs do much output to Standard Output.
>
>                                 Randy.

Le Fri, 07 May 2010 23:36:04 +0200, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> Right, that's exactly what I meant when I said elsewhere in this
> thread that it's a good idea to separate formatting from output.
> Sometimes you want "format some stuff and dump it immediately
> to a file".  Other times you want "format some stuff" (and then
> sort the messages and grind upon them etc.) and then much later
> "send to log manager" or whatever.
>
> - Bob

There are alternatives, and here are two.

The first one : the log manager could have an open/close logic to output a  
log line.

    Open
    Write chunk
    Write next chunk
    ...
    Close

Another alternative I have used some months ago, was to use an abstraction  
of what a text is : I was passing procedure writing text instead of  
strings (to be exact, this was not access to procedures, this was tagged  
types with a single method). I though about it when I faced a brick-wall  
where I could not figure what could be the good minimum and maximum length  
for a particular string index type range. Then I though what was relevant,  
was not so much the strings, instead, this was what was written (that's  
not the same). So I decided to pass procedure writing strings instead of  
strings, so I could drop the trouble with strings allocation I was needed  
for formating purpose. There was no more strings, just writing of chunks  
of text each one after the other in turn.

I'm not to say this is an easy suitable for beginners (as we were also  
talking about ease of access for beginners), I'm just exposing this as  
example alternatives to the one-string-bulk way.

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> A beginner needs to learn how to write a "Hello, world" program
> first, and soon thereafter, some simple thing that involves
> printing out integer values.  I think one of my first assignments
> way back when was to write a program to add up two numbers
> and print out the answer.  If that's hard, it gives a bad
> first impression.  (In fact, it WAS hard -- it involved
> horsing around with Fortran FORMAT statements and Hollerith codes,
> which is worse than horsing around with Ada generics.)

Ah, the Good Old Days. FORTRAN 66, punched cards, FORMAT statements, 5HHELLO, 
and the like. Am I glad that's changed.

> I disagree.  Certainly removing the extra blank would not introduce
> bloat.  And in fact, giving 'Image the exact same functionality
> as Integer_Text_IO would _simplify_ the language, by making
> it more uniform.

Yes, I was thinking along similar lines: a language with a decent 'Image would 
not need the I/O generics, just 'Image and text I/O.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: for S'Image use Func??

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> If I actually used a signature line, I think I'd be using that one!!
> 
>                Randy.
> 
> You can never forget too much about C++. - Jeffrey Carter

Thanks. Why not use a signature line?

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: for S'Image use Func??

[Stephen Leake]

stefan-lucks@see-the.signature writes:

> On Thu, 6 May 2010, Warren wrote:
>
>> I'm just being a typical lazy programmer (not always 
>> wanting to lookup the correct package prefix for
>> the To_String() function to use).
>
> How about overloading the &-operator:
>
>   function "&"(S: String; Item: T) return String;
>
> if X is of type T and you "use type T", you can replace the expression 
>
>   T'Image(X)
>
> by 
>
>    "" & X
>
> If your T'Image(X) is part of a larger string expression, overloading & 
> appears to be very convenient (for the "typical lazy programmer", as you 
> put it):
>
>   Ada.Text_IO.Put_Line("The first result is " & X & 
>                        " the second result is " & Y & ".");

+1

-- 
-- Stephe

Re: for S'Image use Func??

[Stephen Leake]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Fri, 07 May 2010 12:15:11 +0200, Stephen Leake
> <stephen_leake@stephe-leake.org> a écrit:
>>> I always declare I/O/formatting stuff in a child package.
>>
>> Me, to. And the childe package is named Images.

> Are you talking about packages defining multiple types ?

Yes, but I don't see why that matters.

Sometimes I need Image to be dispatching; then it has to be in the main
package, not a child. 

-- 
-- Stephe

Re: for S'Image use Func??

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> wrote in message 
news:hs23ks$8vq$2@tornado.tornevall.net...
> Randy Brukardt wrote:
>>
>> If I actually used a signature line, I think I'd be using that one!!
>
> Thanks. Why not use a signature line?

I'm an antique: I still type all of my message (other than part I'm replying 
to) by hand. That includes the signature. "Randy." is easy enough to type; a 
complex signature isn't.

                        Randy.

Re: for S'Image use Func??

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.vccvt1ybxmjfy8@garhos...
Le Fri, 07 May 2010 23:27:55 +0200, Randy Brukardt <randy@rrsoftware.com>
a �crit:
...
>> It doesn't work very well, either, if you are outputting to a message box 
>> or
>> to a log manager: in both cases the entire message string has to be 
>> passed
>> at once. (That's the case in virtually all of my newer programs.) Not 
>> many
>> real programs do much output to Standard Output.
>
>There are alternatives, and here are two.
>
>The first one : the log manager could have an open/close logic to output a 
>log line.

That's what mine does, but its purpose is to serialize logging from all of 
the tasks in the system, all of which are doing their own thing without any 
special synchronization. If we tried to write parts of each message, we'd 
get a bunch of interspersed parts (or we'd have to have a very complex 
system of saving the parts inside the manager until the entire line is 
available). The other purpose is to make the logs available for inspection 
at any time (the programs in question are Windows services, so they run for 
months at a time); that's why they aren't just held open all the time.

...
> Another alternative I have used some months ago, was to use an abstraction 
> of what a text is : I was passing procedure writing text instead of 
> strings (to be exact, this was not access to procedures, this was tagged 
> types with a single method).

Interestingly, that's how the tasks find out which particular log they are 
supposed to be writing to: I pass an access-to-logging-routine.

It's also a way to do I/O from Pure/Preelaborated packages.

But you need two such routines if you plan to allow separating basic writing 
and ending of a line: New_Line is not a character, you know! (At least not 
if you are writing a portable Ada program, and want to work on many 
different targets.)

> I'm not to say this is an easy suitable for beginners (as we were also 
> talking about ease of access for beginners), I'm just exposing this as 
> example alternatives to the one-string-bulk way.

But none work very well, because you still have to identify the end of the 
line. Either you have to designate a magic character for that purpose, 
leaving Ada far behind (and also requiring scanning each string as well), or 
you need multiple routines (as Text_IO does). Whole line at a time is 
easiest, IMHO, and matches what you want to do enough of the time that there 
isn't much advantage to doing anything else. YMMV.

                   Randy.

Re: for S'Image use Func??

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2k4rfjruq.fsf@pushface.org...
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>
>> Now why isn't this:
>>
>>     Put_Line ((Finish_Time - Start_Time)'Img);
>>
>> legal?
>
> Can the compiler be expected to work out what that function "-" is?

Well, the prefix of an attribute is almost always an "any type" context. (It 
surely is for this attribute). So the answer depends on whether Start_Time 
and Finish_Time and "-" are overloaded. If these are two objects, probably 
there is only one matching "-". If they are overloaded functions, all bets 
are off. So this probably would work *some* of the time. Hard to say if it 
is worth it to make it work.

                                             Randy.

Re: for S'Image use Func??

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> I'm an antique: I still type all of my message (other than part I'm replying 
> to) by hand. That includes the signature. "Randy." is easy enough to type; a 
> complex signature isn't.

I gather that I'm older than you; there's hope for you yet.

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

Re: for S'Image use Func??

[Charmed Snark]

 expounded in news:Pine.LNX.4.64.1005071004460.24406@medsec1.medien.uni-
weimar.de:

> On Thu, 6 May 2010, Warren wrote:
> 
>> I'm just being a typical lazy programmer (not always 
>> wanting to lookup the correct package prefix for
>> the To_String() function to use).
> 

> How about overloading the &-operator:
> 
>   function "&"(S: String; Item: T) return String;
> 
> if X is of type T and you "use type T", you can replace the expression 
> 
>   T'Image(X)
> 
> by 
> 
>    "" & X
> 
> If your T'Image(X) is part of a larger string expression, overloading & 
> appears to be very convenient (for the "typical lazy programmer", as 
> you put it):
> 
>   Ada.Text_IO.Put_Line("The first result is " & X & 
>                        " the second result is " & Y & ".");
> 
> So long
> 
> Stefan

That's not a bad idea- thanks.

Warren

Re: Ada & gdb (was: for S'Image use Func??)

[Warren]

Robert A Duff expounded in news:wccmxwcu6kc.fsf@shell01.TheWorld.com:

..
>> True, but in my case I just needed the leading zeros, sans
>> any sign:
>>
>> 900 to be displayed as "00900" (vs " 900").
> 
> So create a function called Image that does that.
> I think Image is a better name than To_String, by the way
> -- it's a common convention to use Image.

I see.

> The leading blank produced by T'Image is indeed annoying!
> What were they thinking?!  Never mind, that's been discussed
> to death.  It's not a huge problem, but it's one of the
> first things new Ada programmers notice, and it's a real
> turn-off.
> 
> - Bob

I've since just created a Trim function to strip that off.
That saves me from having to create Image() functions for
those types that don't have special formatting requirements
(except for trimming the leading blank of course).

GDB:

One thing that I really miss in gdb, is the ability to 
set breakpoints. Often what I need to step through is
buried deep inside the interpreter at a particular method,
or "procedure". While gdb seems to know about Ada (mostly), 
I cannot seem to set qualified breakpoints where I need them.

Is there some secret gdb voodoo for that?  It's "help"
doesn't seem to hint at this. It works for simple names,
but if I need to qualify the "name" in any way, it rejects
the request. I'm using cygwin's gdb:

$ gdb --version
GNU gdb 6.8.0.20080328-cvs (cygwin-special)

Warren

Re: for S'Image use Func??

[Warren]

Robert A Duff expounded in news:wccpr17yeji.fsf@shell01.TheWorld.com:

> And teaching beginners how to instantiate generics,
> when there's a simple 'Image feature, is not a good idea.
> 
> - Bob

I know how to "instantiate generics". The problem is
that they don't always do what I want. Add to that, 
the reluctance to add bloat when there are many types 
involved. 

My biggest gripe though is with it's handling of
hexadecimal.

In C, I can write:

  sprintf(buf,"%08lX",lngval);

and get my 8 digit hex value, with leading zeros (if
I want it). But with the Ada supplied generics, 
I have to remove the "16#" and "#" from
the result.  So that always has me thinking, 
"what were they thinking?" as well.  It sometimes seems 
that I'm always having to wrap something that the Ada 
standard library gives me.

Another thing that bugs me is that the Ada.Text_IO
will not return a LF character (like getchar() in C).

IMO, there needs to be a "modernized" Ada text I/O
facility. IOW something like a thick binding for the C 
I/O facilities but designed in Ada terms - not C terms.

I know there are different flavours of C bindings for 
this, but without recalling the specific issues involved, 
I've never been real keen about using them, except as
a last resort.

Warren

Re: for S'Image use Func??

[Warren]

Jeffrey R. Carter expounded in news:hrvg3i$2b3$1@tornado.tornevall.net:

> Warren wrote:
>> 
>> True, but in my case I just needed the leading zeros, sans
>> any sign:
>> 
>> 900 to be displayed as "00900" (vs " 900").
> 
> In my job we make extensive use of the image functions from
> PragmARC.Images. These have optional Width, Base, and Zero_Filled
> parameters. So we'd use 

Thanks for the pointer. But for my own Open Sourced
project, which other folks will have to compile, I
would need a very compelling reason to bring in
any third party packages. 

This is why I am wildly enthusiastic about 
Ada.Containers. In the past I had to depend upon
the Booch components. But then there were issues for
the end user depending upon the version they chose
to download and install, etc.

Having Ada.Containers included, presumably means
they are well supported with the compiler they 
have installed. So far, that has been my experience.
I depend quite heavily on them for this project.

So for something trivial like adding leading zeros,
I won't add a "project dependency".  If I further
have to include patches and install instructions for
same said third party packages, then that pretty
much kills any interest in doing so. ;-)

I vaguely remember looking at them however, back in
my Ada-95 days.

Warren

Re: for S'Image use Func??

[Warren]

Robert A Duff expounded in news:wccd3x7lww8.fsf@shell01.TheWorld.com:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> I actually don't buy the need for the Assert pragma in the first
>> place: such checks are rarely expensive and thus should simply be
>> part of the code always.
> 
> If they're not expensive, then you're not using it enough.  ;-)
> 
> Also, the other advantage of pragma Assert over an Assert
> procedure is that you can put the pragma in declarative parts
> and package specs.

What I liked is the added convenience of having the
source module and line number reported, without me 
having to code for that.

Warren

Re: for S'Image use Func??

[Warren]

Georg Bauhaus expounded in news:4be3d4fb$0$7651$9b4e6d93
@newsspool1.arcor-online.net:

..
> [1. mislead assumptions].
> If, as Bob has said, programmers discover 'Image before
> they discover Text_IO.*_IO and Text_IO.Editing, then there
> is something wrong, indeed---with Ada's appearance before
> them!  

I know all about the instantiated Text_IO stuff. The
prevailing thing here is that I use S'Image for debugging
a lot (saves me from also having to track down instantiated
packages when I want to remove it). Then there's the
lazy part of me, that wanted to capitalize on what was
already there.

Shoot me for those reasons. I've forgotten some Ada,
but I'm not a newb either. Although no super human
effort by any means, I wrote the initial APQ
binding, which I trust is now in good hands.

> [2. 'Image *and* 'Value are paired and have a purpose,
> or contract].
> Is 'Image a formatting function? I don't think so.

It's convenient. I now often use:

   Put(Trim(My_Int'Image(I)));

when necessary, where trim removes the blank. You
can shoot me for that too. ;-)

> You said you were too lazy to ... and therefore wanted
> to adapt something half related to your purpose.

Yep, that's me.

> You might be doing yourself (and your readers) a disservice.

Maybe, maybe not.  I'm trying to strike a balance.

> [3. Use normal Ada for polymorphism].
> If I wanted polymorphic behavior of numbers,

Again, I need to avoid bloat. I have several numeric
types involved. Many do not need I/O, but S'Image
does get used a lot in debug code.

> [4. no need].
> Why do Ada programmers forget Ada language
> principles whenever it comes to basic values? :o(
> Is it not obvious that using 'Image in ways it was not
> intended to be used makes the program text misleading?
> -- Georg

From the reader's pov, S'Image(I) is pretty obvious
what it's going to do, including that extra blank! ;-)

Thanks for your comments.

Warren

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Mon, 10 May 2010 15:48:19 +0000 (UTC), Warren wrote:

> Another thing that bugs me is that the Ada.Text_IO
> will not return a LF character (like getchar() in C).

Why should it? It is a text I/O not a stream I/O.
 
> IMO, there needs to be a "modernized" Ada text I/O
> facility. IOW something like a thick binding for the C 
> I/O facilities but designed in Ada terms - not C terms.

Shudder. I am programming both in Ada and C. C's I/O is a disaster, I do
prefer Ada packages for I/O. Formatting/serialization is a totally
unrelated issue. I wonder why people paying so much attention to admittedly
broken and misplaced formatting of Ada.Text_IO in the times of GUIs. It
won't work anyway. It is not a text anymore.

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

Re: for S'Image use Func??

[Warren]

Dmitry A. Kazakov expounded in
news:zvtps4jzmo1z$.mzhapf4p7b4a.dlg@40tude.net: 

> On Mon, 10 May 2010 15:48:19 +0000 (UTC), Warren wrote:
> 
>> Another thing that bugs me is that the Ada.Text_IO
>> will not return a LF character (like getchar() in C).
> 
> Why should it? It is a text I/O not a stream I/O.

But if I recall correctly, I also cannot get an
empty string as input. An empty string is still
valid input.

>> IMO, there needs to be a "modernized" Ada text I/O
>> facility. IOW something like a thick binding for the C 
>> I/O facilities but designed in Ada terms - not C terms.
> 
> Shudder. I am programming both in Ada and C. 

You're not the only one.

> C's I/O is a disaster, 

You have only listed an opinion when you don't 
list specifics.

> I
> do prefer Ada packages for I/O. Formatting/serialization is a totally
> unrelated issue. 

The problem is that Ada should have separated formatting
from I/O (as someone else here has said). C of course did
the same thing, except that they made formatting a string
easier.

> I wonder why people paying so much attention to
> admittedly broken and misplaced formatting of Ada.Text_IO in the times
> of GUIs. It won't work anyway. It is not a text anymore.

Do you enter a picture when login to your favourite GUI
system? A wave file for your password?  We still depend 
a lot on Text. Look at any database- it's not all about
blobs.

Warren

Re: for S'Image use Func??

[Georg Bauhaus]

On 10.05.10 18:18, Warren wrote:
> Georg Bauhaus expounded in news:4be3d4fb$0$7651$9b4e6d93
> @newsspool1.arcor-online.net:
> 
> ..
>> [1. mislead assumptions].
>> If, as Bob has said, programmers discover 'Image before
>> they discover Text_IO.*_IO and Text_IO.Editing, then there
>> is something wrong, indeed---with Ada's appearance before
>> them!  
> 
> I know all about the instantiated Text_IO stuff. The
> prevailing thing here is that I use S'Image for debugging
> a lot (saves me from also having to track down instantiated
> packages when I want to remove it). Then there's the
> lazy part of me, that wanted to capitalize on what was
> already there.

(I have "with Debugging;" in many context clauses.)

> Shoot me for those reasons. I've forgotten some Ada,
> but I'm not a newb either.

APQ is not forgotten ...  The point is that, like J.-P. Rosen
said, and like you said, 'Image is for debugging.

Since I/O is important, I guess there has to be some code
that clearly states intentions; almost necessarily this
cannot be a one liner if intentions are specific.

Can the type system help with correctly formatted
numbers? I'm not sure.  Such that construction of formatted
text strings does not have to rely on pattern substitution like
C's in printf strings etc.
C formatting patterns have been shown to be very flexible and
very dangerous. Hence extra circuits put into C compilers for
printf patterns. Python has similar pitfalls, though there
are some checks. E.g.

  if condition:
   result = "%s: bla bla %d" % (this)

This crashes your program at run time if condition == False
at compile time but becomes True at run time.


I don't buy the ``GUI = 1*String therefore just a chain
of string-producing functions'' argument (IIUC what has been
said):

- From a technical point of view, a GUI dialog is a composite
thing anyway, so construction may need to address its structure.
An object's protocol might offer guidance and checking whereas
the language cannot relate the results of string functions
to anything but strings (concatenate them). In a nest of string
functions, the programmer has full control of the strings but does
not mention the GUI item to be filled or constructed. The GUI looses,
the reader looses.  (Overloading "&" as seen needs to be done
somewhere, as seen; how can this be standardized, if at all?)

- From a design point of view, saying GUI frequently means structured
text, doesn't it?  Even forgetting that GUIs are in flux, see iPad,
much of I/O in "GUIs" is really lines of text
consisting of numbers, addresses, and phrases, possibly placed
in some table if there is enough uniformity of texts. See the Windows
mmc, the X console, Apples log views, settings, or plist editors,
TODO list management, Excel for everything, ... or some average
dialog window.
Truly graphical representations of information will be mostly non-textual.
This has yet to become mainstream in so-called GUIs, and 'Image
can't do that.

Consider writing log entries into an SQL db.  Grep is fine for logs
but an RDB lets you analyze logs with your programmer's mind
turned on.  And lets you throw log lines away systematically.  Wait.
There are tools that transfer semi-formatted log lines into
analyzable (record) structure ... :-)
So why put pieces of information into one single line of characters
with only implicit structure? (Not that I'd be doing anything else,
but it worthwhile thinking this through, it seems. :-)

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:zvtps4jzmo1z$.mzhapf4p7b4a.dlg@40tude.net: 
> 
>> On Mon, 10 May 2010 15:48:19 +0000 (UTC), Warren wrote:
>> 
>>> Another thing that bugs me is that the Ada.Text_IO
>>> will not return a LF character (like getchar() in C).
>> 
>> Why should it? It is a text I/O not a stream I/O.
> 
> But if I recall correctly, I also cannot get an
> empty string as input. An empty string is still
> valid input.

Hmm, try this:

with Ada.Text_IO; use Ada.Text_IO;
procedure Test_In is
begin
   loop
      declare
         Input : String := Get_Line;
      begin
         exit when Input'Length = 0;
      end;
   end loop;
end Test_In;
 
>> C's I/O is a disaster, 
> 
> You have only listed an opinion when you don't 
> list specifics.

Did you used it? Character input returns integer, file is a number,
sometimes a pointer, do you use  fseek or lseek? Is errno thread safe in
UNIX? (What does C say about threads?)
 
>> I
>> do prefer Ada packages for I/O. Formatting/serialization is a totally
>> unrelated issue. 
> 
> The problem is that Ada should have separated formatting
> from I/O (as someone else here has said).

Yes, but back in 80's nobody did. FORTRAN, PL/1, C all had it conflated.

> C of course did
> the same thing, except that they made formatting a string
> easier.

Easier? It is untyped! There is no thing worse than that. We constantly
fight with catching:

   printf ("%s", X);

X is an object of the type having implicit conversion to const * for output
purpose.

>> I wonder why people paying so much attention to
>> admittedly broken and misplaced formatting of Ada.Text_IO in the times
>> of GUIs. It won't work anyway. It is not a text anymore.
> 
> Do you enter a picture when login to your favourite GUI
> system? A wave file for your password?  We still depend 
> a lot on Text. Look at any database- it's not all about
> blobs.

No, it is, for instance, about columned output of fixed point numbers in
proportional font aligned along the decimal point...

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

Re: Ada & gdb (was: for S'Image use Func??)

[John B. Matthews]

In article <Xns9D74746DECC90WarrensBlatherings@188.40.43.245>,
 Warren <ve3wwg@gmail.com> wrote:

> GDB:
> 
> One thing that I really miss in gdb, is the ability to 
> set breakpoints. Often what I need to step through is
> buried deep inside the interpreter at a particular method,
> or "procedure". While gdb seems to know about Ada (mostly), 
> I cannot seem to set qualified breakpoints where I need them.
> 
> Is there some secret gdb voodoo for that?  It's "help"
> doesn't seem to hint at this. It works for simple names,
> but if I need to qualify the "name" in any way, it rejects
> the request. I'm using cygwin's gdb:
> 
> $ gdb --version
> GNU gdb 6.8.0.20080328-cvs (cygwin-special)

(gdb) help break
Set breakpoint at specified line or function.
...

Here's a lengthier transcript:

http://sites.google.com/site/trashgod/adagdb

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: for S'Image use Func??

[Warren]

Dmitry A. Kazakov expounded in
news:1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net: 

> On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote:
> 
>> Dmitry A. Kazakov expounded in
>> news:zvtps4jzmo1z$.mzhapf4p7b4a.dlg@40tude.net: 
>> 
>>> On Mon, 10 May 2010 15:48:19 +0000 (UTC), Warren wrote:
>>> 
>>>> Another thing that bugs me is that the Ada.Text_IO
>>>> will not return a LF character (like getchar() in C).
>>> 
>>> Why should it? It is a text I/O not a stream I/O.
>> 
>> But if I recall correctly, I also cannot get an
>> empty string as input. An empty string is still
>> valid input.
> 
> Hmm, try this:

Ok, good- that at least works. 

But you have no way to know when you've read 
a empty line in a lexer routine that is reading 
character by character. 

What you end up having to do is to
test for line number changes instead-- yuk.
Then if you need that null line, you have to
back fill it with extra code. More guk.

But your point about "stream i/o" is a good
one. Perhaps it is just my bad for using the
wrong tool.

>>> C's I/O is a disaster, 
>> 
>> You have only listed an opinion when you don't 
>> list specifics.
> 
> Did you used it? 

For at least a few decades. ;-)

> Character input returns integer

In C, that is a feature. The macro EOF is
defined as (int)(-1), which is something that
is never read into a char (unless perhaps
you use a silly signed char type).

> , file is a number,

Ever heard of stdin (0), stdout (1) or stderr (2)?
Of course you have.  From the shell, you can also
do:

  ./myprog 7<my_input 8>aux_output

and from within a C program, you would intuitively
do I/O with units 7 and 8 (in addition to the "standard"
0, 1 and 2 units). Not many people think past the
"standard units", but they are usable when required.

They're not Ada type safe obviously (as int), but
is otherwise "in C terms" just fine.

> sometimes a pointer, 

If you do buffered I/O, you use an "object". Ada 
supports objects too - but you know that already.

> do you use  fseek or lseek? 

That is easy-- if you look at the parameters. Oh and
there is another giveaway -- most of those FILE * 
routines start with the letter "f".  Not a perfect
convention, but effective all the same.

> Is errno thread safe

It wasn't when threads first came on the scene, but 
is definitely so now. That is precisely why you must:

  #include <errno.h>

instead of the old fashioned:

  extern int errno;

So there was a technology change. That doesn't render the
C I/O system as a "disaster". If you want to say that you
"don't like it", then I can accept that.  That's different ;-)

As a design foundation for all those Unix, Linux and *BSD 
platforms, I don't think you can call it a disaster. In fact 
even MS o/s's (and IBM's O/S2) have implimented their own 
versions of this posix paradyme.

>> C of course did
>> the same thing, except that they made formatting a string
>> easier.
> 
> Easier? It is untyped! 

No, no, no "said the fish as he lit to the Cat in the Hat".

You exaggerate. It is not strongly typed like Ada, but
by George, there are "types" in C.  You can think of C
differentiating on the basis of "base" types. 

I once programmed in "B" a very long time ago. Everything 
was a "word" or a float type (2 types). That just is about 
as close to "untyped" as you can get AFAIK.

> There is no thing worse than that. We
> constantly fight with catching:
> 
>    printf ("%s", X);
> 
> X is an object of the type having implicit conversion to const * for
> output purpose.

Modern versions of gcc does catch most of these abuses.
But I agree that lacks the strengths that Ada does have.

But you've taken my point to the rediculous instead of 
discussing my point about formatting data. I just cited
one common and concrete formatting instance that gets 
used in C frequently, that you cannot do in Ada "out 
of the box".

>>> I wonder why people paying so much attention to
>>> admittedly broken and misplaced formatting of Ada.Text_IO in the
>>> times of GUIs. It won't work anyway. It is not a text anymore.
>> 
>> Do you enter a picture when login to your favourite GUI
>> system? A wave file for your password?  We still depend 
>> a lot on Text. Look at any database- it's not all about
>> blobs.
> 
> No, it is, for instance, about columned output of fixed point numbers
> in proportional font aligned along the decimal point...

And what goes into that font drawing call? Text. Yes, you
can mess with proportional fonts if you like, but it isn't 
always that way.  In fact, there are many instances where
proportional fonts are a curse. I frequently look for ways
to undo this "modern feature".

Warren

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Mon, 10 May 2010 18:18:47 +0200, Warren <ve3wwg@gmail.com> a écrit:

> I wrote the initial APQ
> binding, which I trust is now in good hands.
What's APQ please ?

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Niklas Holsti]

Warren wrote:
> Dmitry A. Kazakov expounded in
> news:1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net: 
> 
>> On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote:
>>> But if I recall correctly, I also cannot get an
>>> empty string as input. An empty string is still
>>> valid input.
>> Hmm, try this:
> 
> Ok, good- that at least works. 
> 
> But you have no way to know when you've read 
> a empty line in a lexer routine that is reading 
> character by character. 

Yes you do...

> What you end up having to do is to
> test for line number changes instead-- yuk.

... if you read character by character, use the function 
Text_IO.End_Of_Line  to detect the end of an input line. This works the 
same way in all systems, whatever line termination character (sequence), 
if any, is used. Follow with Skip_Line to go to the start of the next line.

To return to the subject: I too often use 'Image for normal output, not 
just for debugging. And I find the extra blank annoying. But it is a 
very small annoyance, considering what else life offers :-)

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

Re: Ada & gdb (was: for S'Image use Func??)

[Warren]

John B. Matthews expounded in news:nospam-813426.14024410052010
@news.aioe.org:

> In article <Xns9D74746DECC90WarrensBlatherings@188.40.43.245>,
>  Warren <ve3wwg@gmail.com> wrote:
> 
>> GDB:
>> 
>> One thing that I really miss in gdb, is the ability to 
>> set breakpoints. Often what I need to step through is
>> buried deep inside the interpreter at a particular method,
>> or "procedure". While gdb seems to know about Ada (mostly), 
>> I cannot seem to set qualified breakpoints where I need them.
>> 
>> Is there some secret gdb voodoo for that?  It's "help"
>> doesn't seem to hint at this. It works for simple names,
>> but if I need to qualify the "name" in any way, it rejects
>> the request. I'm using cygwin's gdb:
>> 
>> $ gdb --version
>> GNU gdb 6.8.0.20080328-cvs (cygwin-special)
> 
> (gdb) help break
> Set breakpoint at specified line or function.
> ...

Heh heh, I know about that one.  

But I think I've located the problem-- libtool
seems to be doing a link as -O2 and no debug 
symbols.  Harumph...

That explains why I was able to debug up to a 
point in this project. After I switched over to 
the "autocrap", this gdb hasn't been working
right. 

Don't bother saying it... (about autocrap)  ;-)

Warren

Re: for S'Image use Func??

[Warren]

Georg Bauhaus expounded in
news:4be84851$0$6891$9b4e6d93@newsspool2.arcor-online.net: 

> On 10.05.10 18:18, Warren wrote:
>> Georg Bauhaus expounded in news:4be3d4fb$0$7651$9b4e6d93
>> @newsspool1.arcor-online.net:
>> 
>> ..
>>> [1. mislead assumptions].
>>> If, as Bob has said, programmers discover 'Image before
>>> they discover Text_IO.*_IO and Text_IO.Editing, then there
>>> is something wrong, indeed---with Ada's appearance before
>>> them!  
>> 
>> I know all about the instantiated Text_IO stuff. The
>> prevailing thing here is that I use S'Image for debugging
>> a lot (saves me from also having to track down instantiated
>> packages when I want to remove it). Then there's the
>> lazy part of me, that wanted to capitalize on what was
>> already there.
> 
> (I have "with Debugging;" in many context clauses.)
> 
>> Shoot me for those reasons. I've forgotten some Ada,
>> but I'm not a newb either.
> 
> APQ is not forgotten ...  The point is that, like J.-P. Rosen
> said, and like you said, 'Image is for debugging.

Yep. Up until this point, I've used To_String() functions,
but I do like the suggested "Image" for the function name.

Thanks for the lively discussion,
Warren

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

=?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= expounded in 
news:op.vch7hze9xmjfy8@garhos:

> Le Mon, 10 May 2010 18:18:47 +0200, Warren <ve3wwg@gmail.com> a �crit:
> 
>> I wrote the initial APQ
>> binding, which I trust is now in good hands.
> What's APQ please ?

Originally was here:
http://sourceforge.net/projects/apq

But now is hosted here now (AFAIK):

http://framework.kow.com.br/projects/show/apq

and gratiously maintained by Marcelo Cora�a de Freitas.

Warren

Re: for S'Image use Func??

[Warren]

Niklas Holsti expounded in news:84r4k5Ftk8U1@mid.individual.net:

> Warren wrote:
>> Dmitry A. Kazakov expounded in
>> news:1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net: 
>> 
>>> On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote:
>>>> But if I recall correctly, I also cannot get an
>>>> empty string as input. An empty string is still
>>>> valid input.
>>> Hmm, try this:
>> 
>> Ok, good- that at least works. 
>> 
>> But you have no way to know when you've read 
>> a empty line in a lexer routine that is reading 
>> character by character. 
> 
> Yes you do...
> 
>> What you end up having to do is to
>> test for line number changes instead-- yuk.
> 
> ... if you read character by character, use the function 
> Text_IO.End_Of_Line  to detect the end of an input line. This works
> the same way in all systems, whatever line termination character
> (sequence), if any, is used. Follow with Skip_Line to go to the start
> of the next line. 

I assume that is true before you read the next "char". If I
then Skip_Line as you say, will I also get End_Of_Line true
if the next line is empty (null)?

If true, then it may be time for me to reconsider how my
current lexer works.

> To return to the subject: I too often use 'Image for normal output,
> not just for debugging. And I find the extra blank annoying. But it is
> a very small annoyance, considering what else life offers :-)

I just now use:

    function Trim(S : String) return String is
    begin
        for X in S'Range loop
            if S(X) /= ' ' then
                return S(X..S'Last);
            end if;
        end loop;
        return "";
    end;

to trim off leading the blanks. This could be simpler, if
you only use it for S'Image. ;-)

Thanks for the tip,
Warren

Re: for S'Image use Func??

[Georg Bauhaus]

Maciej Sobczak wrote:

> Coming back to I/O - what I miss in Ada is the equivalent of fread in
> C - that is, an operation that reads *up to* the given number of
> bytes. Or maybe there is something that I didn't notice? Such an
> operation is an important basis for custom buffered input. Without it
> the only way to reinvent a proper I/O is via direct bindings to system-
> level API.

Streams.Read and overridings should achieve this?
Read fills an array of a given size with up to at most
the array's length stream_elements.

Re: for S'Image use Func??

[Simon Wright]

Warren <ve3wwg@gmail.com> writes:

>     function Trim(S : String) return String is
>     begin
>         for X in S'Range loop
>             if S(X) /= ' ' then
>                 return S(X..S'Last);
>             end if;
>         end loop;
>         return "";
>     end;

I've used a renaming of Ada.Strings.Fixed.Trim with Side defaulted to
Ada.Strings.Both.

Re: for S'Image use Func??

[Warren]

Simon Wright expounded in news:m2bpcnjxuw.fsf@pushface.org:

> Warren <ve3wwg@gmail.com> writes:
> 
>>     function Trim(S : String) return String is
>>     begin
>>         for X in S'Range loop
>>             if S(X) /= ' ' then
>>                 return S(X..S'Last);
>>             end if;
>>         end loop;
>>         return "";
>>     end;
> 
> I've used a renaming of Ada.Strings.Fixed.Trim with Side defaulted to
> Ada.Strings.Both.

Hi Simon:

I was aware of that, and not really sure if I saved anything
(I didn't check) by doing it myself. But I knew I didn't 
care about the right trim etc.  I wouldn't be surprised 
if something buried in the libraries uses it anyway, so 
perhaps I should use it also. 

Warren

Re: for S'Image use Func??

[Maciej Sobczak]

On 10 Maj, 19:55, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >> C's I/O is a disaster,
>
> > You have only listed an opinion when you don't
> > list specifics.
>
> Did you used it? Character input returns integer,

Interestingly, same as in Java.
I believe that they should have done it with a separate flag instead
of inflating the state space by using bigger type.

> file is a number,

The C programming language does not define files as numbers.

> sometimes a pointer,

In C files are designated by pointers *always*, not sometimes.

> do you use  fseek or lseek?

Again confusion - lseek is not part of C.

> Is errno thread safe in
> UNIX? (What does C say about threads?)

C says nothing about threads. But that's OK, because you do not ask
about C in isolation, but about its interaction with Unix. That is,
the thread-safety of errno in Unix is defined by appropriate Unix
standards:

http://www.unix.org/whitepapers/reentrant.html

(see "Redefinition of errno")

> We constantly
> fight with catching:
>
>    printf ("%s", X);
>
> X is an object of the type having implicit conversion to const * for output
> purpose.

Then wait until your programmers start learning C++ and begin to
delete such objects... :-)


Coming back to I/O - what I miss in Ada is the equivalent of fread in
C - that is, an operation that reads *up to* the given number of
bytes. Or maybe there is something that I didn't notice? Such an
operation is an important basis for custom buffered input. Without it
the only way to reinvent a proper I/O is via direct bindings to system-
level API.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Ludovic Brenta]

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> Coming back to I/O - what I miss in Ada is the equivalent of fread in
> C - that is, an operation that reads *up to* the given number of
> bytes. Or maybe there is something that I didn't notice? Such an
> operation is an important basis for custom buffered input. Without it
> the only way to reinvent a proper I/O is via direct bindings to
> system- level API.

Ada.Streams.Read (ARM 13.13.1(5)) does just that.
So does Ada.Text_IO.Get_Line (ARM A.10.1(49)).

-- 
Ludovic Brenta.

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:
> In C files are designated by pointers *always*, not sometimes.
Only as long as you only rely on fopen ; there is also an "int open(char *  
filename, int flags)" which is widely used. Weither or not this "int"  
actually stands for a pointer is another story (as in C one will always be  
able to cast from int to void*, this may be true indeed).

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:
> Coming back to I/O - what I miss in Ada is the equivalent of fread in
> C - that is, an operation that reads *up to* the given number of
> bytes. Or maybe there is something that I didn't notice?
It's there : look at [ARM 2005 13.13.1] which defines the package  
Ada.Streams, which in turn contains the following :

    type Root_Stream_Type is abstract tagged limited private;
    ...
    type Stream_Element is mod implementation-defined;
    ...

    procedure Read
      (Stream : in out Root_Stream_Type;
       Item   : out Stream_Element_Array;
       Last   : out Stream_Element_Offset)
       is abstract;

    procedure Write
      (Stream : in out Root_Stream_Type;
       Item   : in Stream_Element_Array)
       is abstract;


So, these are abstract. Now the question is : “where are the concret  
implementation” ? The answer is “in derived types”.

Here is one, as a quick and one of the most useful example (see [ARM 2005  
1.12.2]) :


    with Ada.Streams;
    package Ada.Text_IO.Text_Streams is
       type Stream_Access is access all Streams.Root_Stream_Type'Class;
       function Stream (File : in File_Type) return Stream_Access;
    end Ada.Text_IO.Text_Streams;

This re-define Stream_Access (why this access type is redefined here, is  
another story previously discussed with an answer from Randy), and define  
a function which returns a Stream_Access from a File_Type. This File_Type  
is the one defined in the parent package, that is, Ada.Text_IO.

In Ada.Text_IO, you have (see [ARM 2005 A.10.1]) some other interesting  
definitions, which will close the list of required stuff :


    function Standard_Input  return File_Access;
    function Standard_Output return File_Access;
    function Standard_Error  return File_Access;

Summary : in Ada.Text_IO, you have Standard_XXXX or other File_Type. You  
can use this (using an XXX.all to get a File_Type from a File_Access) as  
an argument to the Ada.Text_IO.Text_Streams.Stream function, which will  
return you a Stream_Access which will dispatch to an implementation of   
Ada.Streams.Read and Ada.Streams.Write.

Well, to be honest, this is not exactly the same as with C, as  
Ada.Streams.Stream_Element is implementation defined (which is good,  
because this is indeed platform dependent), so you will need an Assert  
pragma somewhere is your application, which ensures  
Ada.Streams.Stream_Element is 8 bits or at least 8 bits (this is, in most  
of case), and then convert from Ada.Streams.Stream_Element to your  
Byte_Type or anything your application defined as such.

Sorry for being long, I just wanted to give all the details. However, this  
is not so much complicated as all those explanations seems to suggest.

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Niklas Holsti]

Warren wrote:
> Niklas Holsti expounded in news:84r4k5Ftk8U1@mid.individual.net:
>> ... if you read character by character, use the function 
>> Text_IO.End_Of_Line  to detect the end of an input line. This works
>> the same way in all systems, whatever line termination character
>> (sequence), if any, is used. Follow with Skip_Line to go to the start
>> of the next line. 
> 
> I assume that is true before you read the next "char". If I
> then Skip_Line as you say, will I also get End_Of_Line true
> if the next line is empty (null)?

Yes, with one problem, which is that it is hard (that is, I don't know 
how) to detect when the very last line in the input file is null. This 
is because End_Of_Line returns true also at end of file, and End_Of_File 
returns true also when the data remaining in the file is an end-of-line 
(and end-of-page) before the true end of file. One consequence is that a 
truly empty file (like /dev/null) looks the same as a file with one null 
line (like echo "").

Try this program on a file with some empty lines:

with Ada.Text_IO;
use  Ada.Text_IO;

procedure Linelen
is
    K   : Character;
    Len : Natural;
begin
    while not End_Of_File loop
       Len := 0;
       while not End_Of_Line loop
          Get (K);
          Len := Len + 1;
       end loop;
       Put_Line (
            "Line" & Count'Image (Line)
          & " has" & Natural'Image (Len)
          & " characters.");
       Skip_Line;
    end loop;
end Linelen;


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

Re: for S'Image use Func??

[Maciej Sobczak]

On 10 Maj, 22:24, Georg Bauhaus <see.reply...@maps.futureapps.de>
wrote:

> > Coming back to I/O - what I miss in Ada is the equivalent of fread in
> > C - that is, an operation that reads *up to* the given number of
> > bytes. Or maybe there is something that I didn't notice?

> Streams.Read and overridings should achieve this?

That's right. Thank you (and others) for reminding me of this. Of
course the overridings are the most crucial here and Streams.Stream_IO
should do the job.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 09:34:42 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:
> Yes, with one problem, which is that it is hard (that is, I don't know  
> how) to detect when the very last line in the input file is null. This  
> is because End_Of_Line returns true also at end of file, and End_Of_File  
> returns true also when the data remaining in the file is an end-of-line  
> (and end-of-page) before the true end of file. One consequence is that a  
> truly empty file (like /dev/null) looks the same as a file with one null  
> line (like echo "").
This may be "hard" only with the Standard_Input file, which is a  
Text_IO.File_Type, and Text_IO, as previously said, is a file of lines. A  
file of line, as you shown you know, is a file where each is line strictly  
delimited in platform dependent manner (with LF on UNIX, CR+LF on Windows  
and CR on Mac, or with specific chunks or records on some other systems).  
So obviously, each line is expected to have an end, just like each file  
have an end, and the end of the last line is also the end of a file, if  
the file is a file of line. Just like a file of some kind of records ends  
with the end of the last record.

I was to say this is a matter only with Standard_Input, and in the context  
of "/dev/null" which you gave, you have no need to open "/dev/null" as a  
file of lines if have no reason to think "/dev/null" is indeed a file of  
lines.

To talk about text files now : let say most of them are just  
inconsistently formated, as many text files as produced by text editors,  
are not formated in the constant way : the last line oftenly lacks a  
delimiter for the last line. This files are either invalid files of lines  
or else are not files of lines, depending on your requirement.

If your requirements states that a line is a sequence of character  
terminated by a CR+LF or an LF or a CR, then, the file you need is a file  
of characters, so don't open these files as file of lines, better as file  
of characters instead.

The only remaining case is the one of the standard input.

-- 
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just  
not lucky

Re: for S'Image use Func??

[Maciej Sobczak]

On 11 Maj, 00:24, Yannick Duchêne (Hibou57) <yannick_duch...@yahoo.fr>
wrote:

> Only as long as you only rely on fopen ;

This function is defined in the C standard.

> there is also an "int open(char *  
> filename, int flags)" which is widely used.

This one is not defined in the C standard and as such is not part of
the C language.

> Weither or not this "int"  
> actually stands for a pointer is another story (as in C one will always be  
> able to cast from int to void*, this may be true indeed).

No this is not true either - assuming that you mean the "open"
function defined in the POSIX standard, the return value is the lowest
*numbered* unused file descriptor. This is aligned with the semantics
of other functions like select.

Another reason for why this cannot be a pointer is that NULL is
defined to be a pointer value that does *not* point to any object; at
the same time STDIN_FILENO, denoting a file descriptor for standard
input, has a value 0, which is equivalent to NULL.
Since standard input cannot exist and not exist at the same time
(quantum computers might change this...), the descriptor value cannot
be a pointer.

Interestingly, Unix file descriptors are *much safer* than standard
C's FILE pointers in that they are free from undefined behavior. Of
course, it would be even better to have a distinct type for them.

(OK, that's enough for off-topic confusions, I duck away to reinvent
My_Better.Text_IO on top of Ada.Streams ;-) )

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote:

> But you have no way to know when you've read 
> a empty line in a lexer routine that is reading 
> character by character. 

A lexer routine shall never do that. You either read lines and then parse
them, or else you do stream input and the line end is to be determined by
the lexer (i.e. by the language being parsed).

Here is the way I do it:

http://www.dmitry-kazakov.de/ada/components.htm#Parsers_etc

I never had any problems with line ends.

> What you end up having to do is to
> test for line number changes instead-- yuk.

That is because you mix encoding and language lexis. Do not mix these two
and everything will become simple.

> In C, that is a feature.

Yes, disaster is a C feature. (:-))

> So there was a technology change. That doesn't render the
> C I/O system as a "disaster". If you want to say that you
> "don't like it", then I can accept that.  That's different ;-)

OK, it was a technology change. We do not ride horses, we drive cars. So if
anybody asks me to feed a beast, clean its droppings etc, it a disaster to
me, a lazy, decadent man. Yes, I know, "real programmers do not use
Pascal". (:-))

>>> C of course did
>>> the same thing, except that they made formatting a string
>>> easier.
>> 
>> Easier? It is untyped! 
> 
> No, no, no "said the fish as he lit to the Cat in the Hat".
> 
> You exaggerate. It is not strongly typed like Ada, but
> by George, there are "types" in C.  You can think of C
> differentiating on the basis of "base" types. 

I meant formatted I/O. That is strictly untyped, not weakly typed. If you
use dynamic lists of arguments, you have to be dynamically typed or else
untyped. C chose the latter.

> I just cited
> one common and concrete formatting instance that gets 
> used in C frequently, that you cannot do in Ada "out 
> of the box".

Luckily. As others already suggested, you should use type specific
operations like "&" for that.

Note that C++ chose that path too. I mean the operator <<.

Surely there is a better way, that is what Ada stream I/O attributes are.
Unfortunately they are hard-coded, because the language lacks multiple
dispatch. So if Ada needed formatted I/O, there should be similar
attributes, e.g. S'Format(Output, X), S'Scan(Output). But it does not worth
the efforts.

>>>> I wonder why people paying so much attention to
>>>> admittedly broken and misplaced formatting of Ada.Text_IO in the
>>>> times of GUIs. It won't work anyway. It is not a text anymore.
>>> 
>>> Do you enter a picture when login to your favourite GUI
>>> system? A wave file for your password?  We still depend 
>>> a lot on Text. Look at any database- it's not all about
>>> blobs.
>> 
>> No, it is, for instance, about columned output of fixed point numbers
>> in proportional font aligned along the decimal point...
> 
> And what goes into that font drawing call? Text.

No, strings + lots of commands. The point is that you do not need features
like alignment and filling anymore. These were issues specific for computer
peripherals of 50's-80's, when formatting instructions could be encoded as
ASCII characters. It does not work anymore, unless you want to mess up with
PCL, HTML, PostScript, XML, which are *languages*.

> Yes, you
> can mess with proportional fonts if you like, but it isn't 
> always that way.

Nobody want to see fixed font output.

> In fact, there are many instances where
> proportional fonts are a curse.

Only if the output is improperly formatted. There is no application for
fixed point fonts other than for source code of a machine language.

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

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Mon, 10 May 2010 23:30:28 +0200, Ludovic Brenta wrote:

> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>> Coming back to I/O - what I miss in Ada is the equivalent of fread in
>> C - that is, an operation that reads *up to* the given number of
>> bytes. Or maybe there is something that I didn't notice? Such an
>> operation is an important basis for custom buffered input.

It is a basis for creating inefficient time and space consuming programs.
But we had this discussion before.

>> Without it
>> the only way to reinvent a proper I/O is via direct bindings to
>> system- level API.
> 
> Ada.Streams.Read (ARM 13.13.1(5)) does just that.
> So does Ada.Text_IO.Get_Line (ARM A.10.1(49)).

I would like to add that "read a byte" is a property of a stream. Not all
files ("everything") are streams. Stream is an interface to an object,
which can be supported by the object or not. But if I have an object like
text buffer, I want an interface of a text buffer, rather than of a stream.
If the object is a data base, I want to stream it even less.

The bottom line is, Ada does it right (tm).

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

Re: for S'Image use Func??

[J-P. Rosen]

Dmitry A. Kazakov a �crit :
> On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote:
> 
>> But you have no way to know when you've read 
>> a empty line in a lexer routine that is reading 
>> character by character. 
> 
Come on, here is the magic function:

function Empty_Line return Boolean is
begin
   return Col=1 and End_Of_Line;
end Empty_Line;
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: for S'Image use Func??

[Maciej Sobczak]

On 11 Maj, 10:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >> Coming back to I/O - what I miss in Ada is the equivalent of fread in
> >> C - that is, an operation that reads *up to* the given number of
> >> bytes. Or maybe there is something that I didn't notice? Such an
> >> operation is an important basis for custom buffered input.
>
> It is a basis for creating inefficient time and space consuming programs.
> But we had this discussion before.

No, we didn't. The discussion we had before was about buffered
*output*, not input. Somebody called "Steve" jumped in and suggested
that "Either you are miscommunicating or you are just plain
wrong" (these words can be used to find that thread).

Now we might have a different discussion about *input*. :-)

OK, really - what's exactly being inefficient in buffered input?

> I would like to add that "read a byte" is a property of a stream. Not all
> files ("everything") are streams.

I don't want to read all files. In particular, I don't want to read
database files.
What I want is a stream interface to the blobs that my filesystem is
storing for me, so that I can build higher-level constructs on top of
it.
Oh, wait - we had that discussion already. ;-)

> The bottom line is, Ada does it right (tm).

If it did it right (tm), I would not have to reinvent
My_Better.Text_IO.
With all due respect to some of the engineering pearls that are
related to Ada, the standard Text_IO package sucks, terribly.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Tue, 11 May 2010 06:35:39 -0700 (PDT), Maciej Sobczak wrote:

> OK, really - what's exactly being inefficient in buffered input?

You said it, it is buffering.

> What I want is a stream interface to the blobs that my filesystem is
> storing for me, so that I can build higher-level constructs on top of
> it.

But if my file system already has get-line-as-an-array-of-code-points. Why
should I go deeply down to the representation layer, to a stream of octets?

>> The bottom line is, Ada does it right (tm).
> 
> If it did it right (tm), I would not have to reinvent
> My_Better.Text_IO.

You should not. The question was about formatting, I/O is OK.

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

Re: for S'Image use Func??

[Robert A Duff]

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

> Nobody want to see fixed font output.

> Only if the output is improperly formatted. There is no application for
> fixed point fonts other than for source code of a machine language.

Hmm.  Why do you exempt "source code" from your "Nobody..." above?

(I assume by "machine language" you mean "programming language",
not machine language as in ones-and-zeros with op-codes and
all that.)

- Bob

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Tue, 11 May 2010 10:27:27 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Nobody want to see fixed font output.
> 
>> Only if the output is improperly formatted. There is no application for
>> fixed point fonts other than for source code of a machine language.
> 
> Hmm.  Why do you exempt "source code" from your "Nobody..." above?

I feel it difficult to read sources in proportional font. Maybe I am
getting too old...

> (I assume by "machine language" you mean "programming language",
> not machine language as in ones-and-zeros with op-codes and
> all that.)

Yes.

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

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 10:26:02 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> But you have no way to know when you've read
>> a empty line in a lexer routine that is reading
>> character by character.
>
> A lexer routine shall never do that. You either read lines and then parse
> them, or else you do stream input and the line end is to be determined by
> the lexer (i.e. by the language being parsed).
With all due respect, really don't agree with that. A lexer is not  
required to be line oriented.

-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 17:03:28 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Tue, 11 May 2010 10:27:27 -0400, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> Nobody want to see fixed font output.
>>
>>> Only if the output is improperly formatted. There is no application for
>>> fixed point fonts other than for source code of a machine language.
>>
>> Hmm.  Why do you exempt "source code" from your "Nobody..." above?
>
> I feel it difficult to read sources in proportional font. Maybe I am
> getting too old...
A way to try to handle this question may be this one : could their be any  
formatting language applicable to typical application source ? This would  
require to have two sides, one for the formatting and one for the text.  
This would not be applicable, this would clutter the application source  
too much.

The only thing which is near to that, is automatic formating (no perfect  
by the way). And how it does formatting ? ... with blanks, tabs and new  
line. So back to the initial point.

Could the automatic formating tool use other things to render source  
layout ? This would require either, again to have the formating language  
embedded in the source (not acceptable as suggested above) or to have a  
way to link/anchor formating instruction to each part of the source it is  
to be applied ; which in turn would require either something embedded in  
the language to allow that or some complicated external third files which  
would try to keep track of some (many) marks in the source while you edit  
it. Not good, ... not portable.

There is still a last other way : editor specific formating. Some do that,  
except that it goes wrong as soon as you switch to another editor, and  
others are unlikely to use the same editor as yours.

Natural language texts did not have the same requirement, they are “in  
flow”. Computer language are not most of time.

This is not a matter of being old or a matter of fashion. There is no real  
other way of doing formating with this special kind of texts. Some one  
already try to imagine new ways for that, but either failed or just  
proposed editor specific formating.

-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 09:58:16 +0200, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:

> On 11 Maj, 00:24, Yannick Duchêne (Hibou57) <yannick_duch...@yahoo.fr>
> wrote:
>
>> Only as long as you only rely on fopen ;
>
> This function is defined in the C standard.
>
>> there is also an "int open(char * filename, int flags)" which is widely  
>> used.
>
> This one is not defined in the C standard and as such is not part of
> the C language.
So C writers do not enforce standards. This "open" is even more widely  
used than "fopen", I use to see it every-where.

Note : I knew open is not part of ISO/ANSI C, I was teasing you about a  
trouble with C sources.

>> Weither or not this "int" actually stands for a pointer is another  
>> story (as in C one will always be able to cast from int to void*, this  
>> may be true indeed).
>
> No this is not true either - assuming that you mean the "open"
> function defined in the POSIX standard, the return value is the lowest
> *numbered* unused file descriptor. This is aligned with the semantics
> of other functions like select.
>
> Another reason for why this cannot be a pointer is that NULL is
> defined to be a pointer value that does *not* point to any object; at
> the same time STDIN_FILENO, denoting a file descriptor for standard
> input, has a value 0, which is equivalent to NULL.
True, clever notice

> Interestingly, Unix file descriptors are *much safer* than standard
> C's FILE pointers in that they are free from undefined behavior. Of
> course, it would be even better to have a distinct type for them.
>
> (OK, that's enough for off-topic confusions, I duck away to reinvent
> My_Better.Text_IO on top of Ada.Streams ;-) )
Please, what does mean “to duck away” ?


-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 10:35:24 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Mon, 10 May 2010 23:30:28 +0200, Ludovic Brenta wrote:
>
>> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>>> Coming back to I/O - what I miss in Ada is the equivalent of fread in
>>> C - that is, an operation that reads *up to* the given number of
>>> bytes. Or maybe there is something that I didn't notice? Such an
>>> operation is an important basis for custom buffered input.
>
> It is a basis for creating inefficient time and space consuming programs.
> But we had this discussion before.
Can you tell more please ?

-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Warren]

Niklas Holsti expounded in news:84sfkjF3btU1@mid.individual.net:

> Warren wrote:
>> Niklas Holsti expounded in news:84r4k5Ftk8U1@mid.individual.net:
>>> ... if you read character by character, use the function 
>>> Text_IO.End_Of_Line  to detect the end of an input line. This works
>>> the same way in all systems, whatever line termination character
>>> (sequence), if any, is used. Follow with Skip_Line to go to the start
>>> of the next line. 
>> 
>> I assume that is true before you read the next "char". If I
>> then Skip_Line as you say, will I also get End_Of_Line true
>> if the next line is empty (null)?
> 
> Yes, with one problem, which is that it is hard (that is, I don't know 
> how) to detect when the very last line in the input file is null. This 
> is because End_Of_Line returns true also at end of file, and 
End_Of_File 
> returns true also when the data remaining in the file is an end-of-line 
> (and end-of-page) before the true end of file. One consequence is that 
a 
> truly empty file (like /dev/null) looks the same as a file with one 
null 
> line (like echo "").

I see. In my current app, that's not a big deal, but it
is good to be aware of that.

One thing that comes up in C based streams is that sometimes
the last line does not end in a LF (and/or CR). So then
you get EOF, but no indication of a line ending. So 
usually you code it to "fix the line" when you see that.

> Try this program on a file with some empty lines:

I see. With 2 null input lines, it reports:

$ ./linelen <t.t
Line 1 has 0 characters.

Well, it seems that just about everything has a
wart somewhere.

Warren

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

=?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= expounded in
news:op.vci60tiexmjfy8@garhos: 

> Le Tue, 11 May 2010 09:34:42 +0200, Niklas Holsti  
> <niklas.holsti@tidorum.invalid> a �crit:
>> Yes, with one problem, which is that it is hard (that is, I don't
..
> I was to say this is a matter only with Standard_Input, and in the
> context  of "/dev/null" which you gave, you have no need to open
> "/dev/null" as a  file of lines if have no reason to think "/dev/null"
> is indeed a file of  lines.

But feed that same program with 2 empty lines,
and the program reports:

$ ./linelen <t.t
Line 1 has 0 characters.

This is clearly defective. It either returns null lines
or it doesn't. Here we have a bit of both (a "Microsoft
solution" ;-)

> The only remaining case is the one of the standard input.

"Standard input" (emphasis on "standard") has nothing to
do with it.  Whether you read it as standard input or
from a "non-standard" source, it behaves the same way.

The file I used above, is a well formed text file. 

$ wc -l t.t
2 t.t

yet the program only sees 1 line. Not a huge problem- 
just a little wart.

But the real question is- is this a design or 
implementation wart?

Warren

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Tue, 11 May 2010 17:23:44 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Tue, 11 May 2010 10:26:02 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>>> But you have no way to know when you've read
>>> a empty line in a lexer routine that is reading
>>> character by character.
>>
>> A lexer routine shall never do that. You either read lines and then parse
>> them, or else you do stream input and the line end is to be determined by
>> the lexer (i.e. by the language being parsed).
> With all due respect, really don't agree with that. A lexer is not  
> required to be line oriented.

Most languages I know are line oriented. Ada is, C++ is. Even bash is. If
the language had no lines, no comments like //, ignored LF, how would you
report errors? As numbers of Unicode code points from the beginning of the
source file?

BTW, a pure stream lacks not only EOL, but also EOF. So a truly
stream-oriented program must be infinite. (:-))

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

Re: for S'Image use Func??

[Warren]

Dmitry A. Kazakov expounded in
news:h1uzhgbbx6hd.1lg6oydcub0re$.dlg@40tude.net: 

> On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote:
> 
>> But you have no way to know when you've read 
>> a empty line in a lexer routine that is reading 
>> character by character. 
> 
> A lexer routine shall never do that. You either read lines and then
> parse them, or else you do stream input and the line end is to be
> determined by the lexer (i.e. by the language being parsed).

Empty lines are significant to my parser, when the 
basic programs are unnumbered. I'm not going to articulate
why here, but they were significant.

I will buy the argument that perhaps I should be using
a stream input. But that'll wait for some other day,
as I have much bigger fish to fry at the moment.

>>>> C of course did
>>>> the same thing, except that they made formatting a string
>>>> easier.
>>> 
>>> Easier? It is untyped! 
>> 
>> No, no, no "said the fish as he lit to the Cat in the Hat".
>> 
>> You exaggerate. It is not strongly typed like Ada, but
>> by George, there are "types" in C.  You can think of C
>> differentiating on the basis of "base" types. 
> 
> I meant formatted I/O. That is strictly untyped, not weakly typed. If
> you use dynamic lists of arguments, you have to be dynamically typed
> or else untyped. C chose the latter.

As I pointed out earlier, those *printf() arguments are 
checked, so it is not strictly untyped. You can lie to
it of course..

>> I just cited
>> one common and concrete formatting instance that gets 
>> used in C frequently, that you cannot do in Ada "out 
>> of the box".
> 
> Luckily. As others already suggested, you should use type specific
> operations like "&" for that.

How does "&" fix the hexadecimal formatting? That is 
what I am discussing.

> Surely there is a better way, that is what Ada stream I/O attributes
> are. Unfortunately they are hard-coded, because the language lacks
> multiple dispatch. So if Ada needed formatted I/O, there should be
> similar attributes, e.g. S'Format(Output, X), S'Scan(Output). But it
> does not worth the efforts.

I'm not complaining about that. I'm complaining that
(for example) the hex conversion is "annoying" in that
I have to "wrap it" to get my "proper" hex output. Ada
gives me the hex, but a bunch of enclosing junk with it.

>> Yes, you
>> can mess with proportional fonts if you like, but it isn't 
>> always that way.
> 
> Nobody want to see fixed font output.

Pardon me?  If you give me a report of my 
investment holdings with columns of numbers,
then those numbers better line in columns as
well.

Have you ever put code in a Word document? You
don't leave them proportional, do you?  Gak!!

> Only if the output is improperly formatted. There is no application
> for fixed point fonts other than for source code of a machine
> language. 

That's just wrong. See above for one more example.

Warren

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

J-P. Rosen expounded in news:hsb97m$tnd$1@news.eternal-september.org:

> Dmitry A. Kazakov a �crit :
>> On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote:
>> 
>>> But you have no way to know when you've read 
>>> a empty line in a lexer routine that is reading 
>>> character by character. 
>> 
> Come on, here is the magic function:
> 
> function Empty_Line return Boolean is
> begin
>    return Col=1 and End_Of_Line;
> end Empty_Line;

There's a wart-- see earlier posts about "end file".

Warren

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Tue, 11 May 2010 17:56:44 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Tue, 11 May 2010 10:35:24 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> On Mon, 10 May 2010 23:30:28 +0200, Ludovic Brenta wrote:
>>
>>> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>>>> Coming back to I/O - what I miss in Ada is the equivalent of fread in
>>>> C - that is, an operation that reads *up to* the given number of
>>>> bytes. Or maybe there is something that I didn't notice? Such an
>>>> operation is an important basis for custom buffered input.
>>
>> It is a basis for creating inefficient time and space consuming programs.
>> But we had this discussion before.

> Can you tell more please ?

Buffering = making copies. A copy is always an overhead. It pays off if you
have asynchronous components (use them in parallel), or components with
high switching overhead, or faster memory (caching, indexing etc). If you
don't have that it is just a loss.

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

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

=?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in
news:op.vcig7go1ule2fv@garhos: 

> Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak  
> <see.my.homepage@gmail.com> a écrit:
>> Coming back to I/O - what I miss in Ada is the equivalent of fread in
>> C - that is, an operation that reads *up to* the given number of
>> bytes. Or maybe there is something that I didn't notice?

> It's there : look at [ARM 2005 13.13.1] which defines the package  
> Ada.Streams, which in turn contains the following :
> 
>     type Root_Stream_Type is abstract tagged limited private;
>     ...
>     type Stream_Element is mod implementation-defined;
>     ...
...
> Well, to be honest, this is not exactly the same as with C, as  
> Ada.Streams.Stream_Element is implementation defined (which is good,  
> because this is indeed platform dependent), so you will need ..

All this is well and good for applications that can work in 
"implementation defined" units of type Stream_Element. A pragma
won't fix the problem should it be different than a byte. Granted,
it will never likely come up on the platforms I have in mind.

But I do believe a POSIX friendly version of this should exist. 
Then the entire issue goes away. Under the hood, if the types work
out the to the same size as a byte, you can capitalize on that
in an implementation dependendant way.

Anything that makes Ada more posix friendly, helps its general
acceptance.

Warren

Re: for S'Image use Func??

[Jeffrey R. Carter]

On May 10, 1:52 pm, Warren <ve3...@gmail.com> wrote:
>
> I was aware of that, and not really sure if I saved anything
> (I didn't check) by doing it myself. But I knew I didn't
> care about the right trim etc.  I wouldn't be surprised
> if something buried in the libraries uses it anyway, so
> perhaps I should use it also.

Did you save anything? Let me pull out my well worn copy of /Software
Tools/, by Brian W. Kernighan and P. J. Plauger, Addison-Wesley, 1976.
(Bear in mind that these are C guys.)

"Most of the time programmers have no real idea where time is being
consumed by a program. Consequently nearly all the effort expended
(...) for 'efficiency' is wasted. We have found that the best way to
avoid too-early optimization is to make a regular practice of
in[s]trumenting code."

"Algorithm and data structure changes are by far the most effective
way to improve performance."

The general rule is not to rewrite existing functionality unless your
system does not meet its timing requirements with the existing
operation, and measurement shows that the existing operation is
causing the failure to meet the timing requirements. It is clear ("I
didn't check") that this is not the case here.

So, did you "save" anything? No, you not only didn't save anything,
you wasted your effort by writing and testing code that duplicates
existing functionality, that you were aware of, for no reason.

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Tue, 11 May 2010 17:05:07 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:h1uzhgbbx6hd.1lg6oydcub0re$.dlg@40tude.net: 
> 
>> On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote:
>> 
>>> But you have no way to know when you've read 
>>> a empty line in a lexer routine that is reading 
>>> character by character. 
>> 
>> A lexer routine shall never do that. You either read lines and then
>> parse them, or else you do stream input and the line end is to be
>> determined by the lexer (i.e. by the language being parsed).
> 
> Empty lines are significant to my parser,

Then Get_Line is what you have to use.

If the language is line-oriented, you read lines. If the language is
character oriented, then lines do not exist.

>> I meant formatted I/O. That is strictly untyped, not weakly typed. If
>> you use dynamic lists of arguments, you have to be dynamically typed
>> or else untyped. C chose the latter.
> 
> As I pointed out earlier, those *printf() arguments are 
> checked, so it is not strictly untyped. You can lie to
> it of course..

Which is precisely what being untyped is.

BTW, printf is fundamentally uncheckable. Proof:

   char * Format = (HALT (p) ? "%d" : "%s");
   printf (Format, 123);

>>> I just cited
>>> one common and concrete formatting instance that gets 
>>> used in C frequently, that you cannot do in Ada "out 
>>> of the box".
>> 
>> Luckily. As others already suggested, you should use type specific
>> operations like "&" for that.
> 
> How does "&" fix the hexadecimal formatting? That is 
> what I am discussing.

Oh, there are so many ways. E.g.

1.
   type Hex_Dump is new String;
   function "&" (Text : Hex_Dump; Value : Integer) return Hex_Dump;

2.
   type Formatted is private; -- Actually String
   function "&" (Text : String; Data : Formatted) return String;
   function "/" (Value : Integer; Base : Base_Number) return Formatted;

      "" & 2456/16

3.    
   type Format_Int is record
      Value : Integer;
      Base : Base_Number;
   end record;
   function "&" (Text : String; Data : Format_Int) return String;

      "" & (2456, 16)

I think you've got the idea.

> I'm not complaining about that. I'm complaining that
> (for example) the hex conversion is "annoying" in that
> I have to "wrap it" to get my "proper" hex output. Ada
> gives me the hex, but a bunch of enclosing junk with it.

It is also annoying that I cannot output the number's base as subscript 16.
Programming is generally annoying.

I don't say that Ada's formatting is OK. Otherwise I would not write a
formatting library of my own. I just don't consider formatting as an
essential part of the language. Even at the standard library level it is
not.

>>> Yes, you
>>> can mess with proportional fonts if you like, but it isn't 
>>> always that way.
>> 
>> Nobody want to see fixed font output.
> 
> Pardon me?  If you give me a report of my 
> investment holdings with columns of numbers,
> then those numbers better line in columns as
> well.

Where is a problem? Fixed point is a relatively new invention, which came
with computers. I have some old mathematical tables, they all use
proportional fonts. Numbers are aligned on either of the margins.
Fractional numbers are aligned on decimal point.

> Have you ever put code in a Word document? You
> don't leave them proportional, do you?  Gak!!

I meant this only case as a legitime use of fixed fonts.

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

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Tue, 11 May 2010 17:17:38 +0000 (UTC), Warren wrote:

> =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in
> news:op.vcig7go1ule2fv@garhos: 
> 
>> Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak  
>> <see.my.homepage@gmail.com> a écrit:
>>> Coming back to I/O - what I miss in Ada is the equivalent of fread in
>>> C - that is, an operation that reads *up to* the given number of
>>> bytes. Or maybe there is something that I didn't notice?
> 
>> It's there : look at [ARM 2005 13.13.1] which defines the package  
>> Ada.Streams, which in turn contains the following :
>> 
>>     type Root_Stream_Type is abstract tagged limited private;
>>     ...
>>     type Stream_Element is mod implementation-defined;
>>     ...
> ...
>> Well, to be honest, this is not exactly the same as with C, as  
>> Ada.Streams.Stream_Element is implementation defined (which is good,  
>> because this is indeed platform dependent), so you will need ..
> 
> All this is well and good for applications that can work in 
> "implementation defined" units of type Stream_Element. A pragma
> won't fix the problem should it be different than a byte. Granted,
> it will never likely come up on the platforms I have in mind.

If you to read a character stream, just do so:

   Item := Character'Read (S);
   Character'Write (S, Item);

For octet streams use Unsigned_8.

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

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 19:38:44 +0200, Jeffrey R. Carter  
<ggsub@pragmada.x10hosting.com> a écrit:
> "Most of the time programmers have no real idea where time is being
> consumed by a program. Consequently nearly all the effort expended
> (...) for 'efficiency' is wasted. We have found that the best way to
> avoid too-early optimization is to make a regular practice of
> in[s]trumenting code."
Sometime, I'm not aware of some terminology : did instrumented code (I  
don't like this word, “code”, but don't bother) means “code with which  
provide runtime statistics” ?

-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 19:15:07 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Buffering = making copies. A copy is always an overhead. It pays off if  
> you
> have asynchronous components (use them in parallel), or components with
> high switching overhead, or faster memory (caching, indexing etc). If you
> don't have that it is just a loss.
As yoi said, there is caching, and even the good old i486 did have a  
cache. If you are to iterate on the X coming items of data and X is not so  
much a big number (otherwise, you may iterate on multiple buffers), then  
you benefit from the cache, which is otherwise loose as soon as you call  
the method which will read one more items and which will load its own  
state into the cache.

This is not so much special, near to all machines have a cache.

Also, on a stream, you will need a cache if you are to walk forward in the  
data stream (a stream is one way only, always forward, not backward).

As you were talking about checking that a particular optimization is  
really efficient or not, I can assert I've checked buffering improve  
performance on DOS running on i486 25 MHz. I remember of assembly or  
Pascal programs getting noticeably better performance as soon as they was  
relying on a buffer of at least 512 bits or more. There was a limit above  
which one increasing the buffer size was not increasing performance any  
more (if my mind is right, this was something like 2 Ki bytes)

On another application I'm working on actually, on Windows XP running on a  
faster machine (1 GHz CPU), better performance can be gain with buffer  
size above the latter : I've check the application is consuming about 30%  
less times for execution with 150 Ki buffer than with a rather small one.  
Giving it some even bigger buffer does not make so much difference.

It seems to me the faster the machine is, the higher you can increase  
buffers size.

Then, I feel you see copies where there are not more copies than with the  
way you suggest.

Given this

    Read one byte in a one byte variable
    Read one byte in a one byte variable
    Read one byte in a one byte variable
    Read one byte in a one byte variable
    Read one byte in a one byte variable

And then that

    Read five bytes in a five bytes buffer

Which one do make more copies than the other ? The answer is None, they  
both copy exactly five bytes.

The second one is not making more copy of anything, it is just using a  
bigger variable to store multiple items at once. So the matter then is  
“which is the best capacity for the buffer”. First answer is “depends on  
memory” (I'm not to say all memory may be used for that, just that there  
is a proportional relation) and the second answer is “check for it playing  
with buffer size and Ada.Calendar”.

There is also another point : it is mostly better, *when possible*, to do

    Batch OP1.1,OP1.2,OP1.3,OP1.4

    Batch OP2.1,OP2.2,OP2.3,OP2.4

instead of

    OP1.1
    OP2.1
    OP1.2
    OP2.2
    etc
    ...

The reason here again, is the CPU cache

This is something which is a bit related to the ability of an application  
or an algorithm to be re-design on top of parallelism. Here, instead of  
getting benefit from simultaneous execution, we get benefit from CPU cache  
(and nearly to all CPU have a cache).

Ah, an occasion to say the CPU cache also have another interesting effect  
peoples should know about : loop unroll is most of time anti-productive.  
If you enable the loop-unrolling “optimization” option of your compiler,  
please, check this is really relevant, don't just believe it (by the way,  
code-cache and data-cache do not exactly apply the same strategy, so don't  
infer code-cache performance beliefs from data-cache performance  
observations).


-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 19:17:38 +0200, Warren <ve3wwg@gmail.com> a écrit:
> All this is well and good for applications that can work in
> "implementation defined" units of type Stream_Element.
“Implementation defined” here, means “platform dependent”. This is not  
“compiler implementation dependent”, this is “platform implementation  
dependent”. So this is not Ada's fault, nor this one or that one compiler  
implementation, this is just the real world.

If you real world is never something else than file storage element of 8  
bits, then the Assert pragma will never fail and that's all (you will even  
do not need the this Assert pragma at all, which is for greater  
trustability)

> A pragma
> won't fix the problem
No language will fix the problem if you need a 8 bits file storage element  
on a platform which uses something else.

> should it be different than a byte. Granted,
> it will never likely come up on the platforms I have in mind.
So, what' wrong ?

> But I do believe a POSIX friendly version of this should exist.
> Then the entire issue goes away. Under the hood, if the types work
> out the to the same size as a byte, you can capitalize on that
> in an implementation dependendant way.
>
> Anything that makes Ada more posix friendly, helps its general
> acceptance.
Ada is POSIX friendly, and there are POSIX bindings to Ada, as well as an  
ISO standard for the POSIX Ada binding. You are formally wrong when you  
suggest Ada is not POSIX friendly.

Ada will simply not be able to be POSIX friendly on platforms which are  
not POSIX.

You know... even Windows XP Pro is very fat to be POSIX compliant ;) (to  
not talk about prior version of Windows)


-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Tue, 11 May 2010 19:05:07 +0200, Warren <ve3wwg@gmail.com> a écrit:
> As I pointed out earlier, those *printf() arguments are
> checked, so it is not strictly untyped. You can lie to
> it of course..
Isn't it checked at the compiler option ?

Does ANSI or ISO C really requires this ?

If so, how is it formalized ?

-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Gautier write-only]

On May 11, 12:39 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:

[...]
> Well, to be honest, this is not exactly the same as with C, as  
> Ada.Streams.Stream_Element is implementation defined (which is good,  
> because this is indeed platform dependent), so you will need an Assert  
> pragma somewhere is your application, which ensures  
> Ada.Streams.Stream_Element is 8 bits or at least 8 bits (this is, in most  
> of case), and then convert from Ada.Streams.Stream_Element to your  
> Byte_Type or anything your application defined as such.

As Dmitry already wrote, you usually don't need to bother about it:
just use the stream attributes: Byte'Read/'Write(stream, b) and don't
worry at all about Stream_Element being 8 bits or not...
There are two exceptions I know:
- the Read in Ada.Streams gives the number of bytes actually read when
a stream reach its end
- in some implementations, Byte_array'Read/'Write are utterly slow
compared to the procedures in Ada.Streams.
Anyway, you don't need to bet or assume that
Ada.Streams.Stream_Element is 8 bits.
You can make a size check (even a compile-time one!). Here, for
arrays:
  subtype Size_test_a is Byte_Array(1..19);
  subtype Size_test_b is Ada.Streams.Stream_Element_Array(1..19);
  --
  is_mapping_possible: constant Boolean:=
    Size_test_a'Size = Size_test_b'Size and then
    Size_test_a'Alignment = Size_test_b'Alignment;
______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/
NB: For a direct answer, e-mail address on the following web site:
http://www.fechtenafz.ethz.ch/wm_email.htm

Re: for S'Image use Func??

[Maciej Sobczak]

On 11 Maj, 16:24, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > OK, really - what's exactly being inefficient in buffered input?
>
> You said it, it is buffering.

OK, next step: what's exactly being inefficient in buffering in
buffered input?

> > What I want is a stream interface to the blobs that my filesystem is
> > storing for me, so that I can build higher-level constructs on top of
> > it.
>
> But if my file system already has get-line-as-an-array-of-code-points. Why
> should I go deeply down to the representation layer, to a stream of octets?

Then you shouldn't. The point is that *my* filesystem does not have it
(it supports only blobs), so I have a valid use-case for stream of
octets.

> >> The bottom line is, Ada does it right (tm).
>
> > If it did it right (tm), I would not have to reinvent
> > My_Better.Text_IO.
>
> You should not. The question was about formatting, I/O is OK.

Unfortunately, in Ada the formatting and I/O are entangled in Text_IO.
They are "separate" in stream I/O (there is no formatting at all
there) and this is what makes stream I/O a valid basis for a custom
solution, like My_Better.Text_IO. That's exactly my point.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Maciej Sobczak]

On 11 Maj, 17:54, Yannick Duchêne (Hibou57) <yannick_duch...@yahoo.fr>
wrote:

> > (OK, that's enough for off-topic confusions, I duck away to reinvent
> > My_Better.Text_IO on top of Ada.Streams ;-) )
>
> Please, what does mean “to duck away” ?

The basis is (3rd meaning):

http://dictionary.cambridge.org/dictionary/british/duck_3

:-)

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Warren]

Jeffrey R. Carter expounded in news:cd1877ca-5342-4b1c-9128-
f74ebe5da93e@o8g2000yqo.googlegroups.com:

> So, did you "save" anything? No, you not only didn't save anything,
> you wasted your effort by writing and testing code that duplicates
> existing functionality, that you were aware of, for no reason.

It's my life ;-)

Warren 

Re: for S'Image use Func??

[Charmed Snark]

Dmitry A. Kazakov expounded in
news:bpz9dud4c9de.1uloiuk912d7t.dlg@40tude.net: 

> On Tue, 11 May 2010 17:05:07 +0000 (UTC), Warren wrote:
>> Empty lines are significant to my parser,
> 
> Then Get_Line is what you have to use.

No I don't. Make me..

> BTW, printf is fundamentally uncheckable. Proof:
> 
>    char * Format = (HALT (p) ? "%d" : "%s");
>    printf (Format, 123);

You get what you asked for there, heh heh... I
don't ask for such silly things.

> Oh, there are so many ways. E.g.
> 
> 1.
>    type Hex_Dump is new String;
>    function "&" (Text : Hex_Dump; Value : Integer) return Hex_Dump;

Right- you have to "code" it. That's not what I'm 
talking about. I'm talking about "library support".

> I think you've got the idea.

You've completely missed the point.

> It is also annoying that I cannot output the number's base as
> subscript 16. Programming is generally annoying.

You completely twist things to keep arguing..
I quit.

> I don't say that Ada's formatting is OK. Otherwise I would not write a
> formatting library of my own. I just don't consider formatting as an
> essential part of the language. Even at the standard library level it
> is not.

That's an opinion that I don't believe is widely held. But
no matter either way, I simply disagree.

>>> Nobody want to see fixed font output.
>> 
>> Pardon me?  If you give me a report of my 
>> investment holdings with columns of numbers,
>> then those numbers better line in columns as
>> well.
> 
> Where is a problem? Fixed point is a relatively 
> new invention, ...

Relatively new? You make me chuckle.

I suppose that old ASR33 teletype I had was 
was ahead of its time with that modern fixed
font!  Playing star trek on a teletype would
have been very interesting in a proportional
font.

I'm signing off.
Warren

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

=?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= expounded in 
news:op.vcj1wgldxmjfy8@garhos:

> Le Tue, 11 May 2010 19:05:07 +0200, Warren <ve3wwg@gmail.com> a �crit:
>> As I pointed out earlier, those *printf() arguments are
>> checked, so it is not strictly untyped. You can lie to
>> it of course..

> Isn't it checked at the compiler option ?
> 
> Does ANSI or ISO C really requires this ?
> 
> If so, how is it formalized ?

It may only be GNU's compiler that checks this. You may
also need compiler options to trigger it (I almost always
turn all but the most troublesome checks as routine 
practice).

The Sun compiler might but I've never checked it.

Warren

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

Dmitry A. Kazakov expounded in news:1qfu2ba65pd63$.asc7m201hi6u$.dlg@
40tude.net:

> On Tue, 11 May 2010 17:17:38 +0000 (UTC), Warren wrote:
> 
>> =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded 
in
>> news:op.vcig7go1ule2fv@garhos: 
>> 
>>> Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak  
>>> <see.my.homepage@gmail.com> a écrit:
>>>> Coming back to I/O - what I miss in Ada is the equivalent of fread 
in
>>>> C - that is, an operation that reads *up to* the given number of
>>>> bytes. Or maybe there is something that I didn't notice?
>> 
>>> It's there : look at [ARM 2005 13.13.1] which defines the package  
>>> Ada.Streams, which in turn contains the following :
>>> 
>>>     type Root_Stream_Type is abstract tagged limited private;
>>>     ...
>>>     type Stream_Element is mod implementation-defined;
>>>     ...
>> ...
>>> Well, to be honest, this is not exactly the same as with C, as  
>>> Ada.Streams.Stream_Element is implementation defined (which is good,  
>>> because this is indeed platform dependent), so you will need ..
>> 
>> All this is well and good for applications that can work in 
>> "implementation defined" units of type Stream_Element. A pragma
>> won't fix the problem should it be different than a byte. Granted,
>> it will never likely come up on the platforms I have in mind.
> 
> If you to read a character stream, just do so:
> 
>    Item := Character'Read (S);
>    Character'Write (S, Item);
> 
> For octet streams use Unsigned_8.

But this has to include seeking in the stream as well.

Can you guarantee seeking to an arbitrary "byte boundary"?
I'm asking because I'm too lazy right now to look it up.
But IIRC, the best you can do is the Ada.Streams.Stream_Element.

Warren

Re: for S'Image use Func??

[Warren]

=?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in
news:op.vcj1lsgkule2fv@garhos: 

>> A pragma
>> won't fix the problem
> No language will fix the problem if you need a 8 bits file storage
> element  on a platform which uses something else.
> 
>> should it be different than a byte. Granted,
>> it will never likely come up on the platforms I have in mind.
> So, what' wrong ?

Why is this so difficult to understand?

POSIX systems do this all the time with the standard I/O
irregardless of what the machines "storage element"
unit is. 

What I'm suggesting is needed is a layer (pkg) that makes it
appear to the application that you can seek to byte
boundaries, get and write bunches of bytes, at arbitrary
byte lengths without a single care of whether the host
machine supports 32, 64, or even 36 bit words (I onced
did C on a Honeywell L66, with 9-bit bytes, 18-bit
half words and 36-bit words).  Yet the C I/O package
gave me the POSIX friendly FILE api to work with.

So I don't buy the "it can't be done" thinking. Move
away from Ada streams for a moment and think about 
what "could be done". 

All it requires is probably a thin layer on
top of Ada streams, except where they two are
one ;-)  The they can appear as two, but have
a common implementation.

> Ada will simply not be able to be POSIX friendly on platforms which
> are  not POSIX.

Have you tried cygwin and gnat? They work rather well in
its simulated POSIX environment. It breaks down in a few
"peculiar" places granted, but overall it's great on the 
company laptop, when the corporation sez "u must have windoze".

Warren

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Tue, 11 May 2010 13:18:39 -0700 (PDT), Maciej Sobczak wrote:

> On 11 Maj, 16:24, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> OK, really - what's exactly being inefficient in buffered input?
>>
>> You said it, it is buffering.
> 
> OK, next step: what's exactly being inefficient in buffering in
> buffered input?

Machine instructions to execute.

>>> What I want is a stream interface to the blobs that my filesystem is
>>> storing for me, so that I can build higher-level constructs on top of
>>> it.
>>
>> But if my file system already has get-line-as-an-array-of-code-points. Why
>> should I go deeply down to the representation layer, to a stream of octets?
> 
> Then you shouldn't. The point is that *my* filesystem does not have it
> (it supports only blobs), so I have a valid use-case for stream of
> octets.

Why an Ada program handling texts need to be aware of your system?
Ada.Text_IO provides an OS-independent abstraction of a text. It is a poor
abstraction of a stream, it is even a poorer abstraction of space travel.
So what?

>>>> The bottom line is, Ada does it right (tm).
>>
>>> If it did it right (tm), I would not have to reinvent
>>> My_Better.Text_IO.
>>
>> You should not. The question was about formatting, I/O is OK.
> 
> Unfortunately, in Ada the formatting and I/O are entangled in Text_IO.

No. See A.10.8(18) and F.3.3. The problem of Text_IO is columns. It was an
important feature back in late 70's, but it is totally useless today.

> They are "separate" in stream I/O (there is no formatting at all
> there) and this is what makes stream I/O a valid basis for a custom
> solution, like My_Better.Text_IO. That's exactly my point.

I am not sure what do you mean here.

1. Formatting is unrelated to either line-oriented (in earlier times one
called it record-oriented) or character-stream oriented I/O.

2. Stream I/O is unsuitable for a custom Text_IO. It simply won't work in a
system deploying native record-oriented files. And it would be just silly
to emulate a stream on top of records, encode it (to escape delimiters) and
then decode back to implement Get_Line!

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

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Tue, 11 May 2010 20:56:11 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in news:1qfu2ba65pd63$.asc7m201hi6u$.dlg@
> 40tude.net:
> 
>> On Tue, 11 May 2010 17:17:38 +0000 (UTC), Warren wrote:
>> 
>>> =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded 
> in
>>> news:op.vcig7go1ule2fv@garhos: 
>>> 
>>>> Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak  
>>>> <see.my.homepage@gmail.com> a écrit:
>>>>> Coming back to I/O - what I miss in Ada is the equivalent of fread 
> in
>>>>> C - that is, an operation that reads *up to* the given number of
>>>>> bytes. Or maybe there is something that I didn't notice?
>>> 
>>>> It's there : look at [ARM 2005 13.13.1] which defines the package  
>>>> Ada.Streams, which in turn contains the following :
>>>> 
>>>>     type Root_Stream_Type is abstract tagged limited private;
>>>>     ...
>>>>     type Stream_Element is mod implementation-defined;
>>>>     ...
>>> ...
>>>> Well, to be honest, this is not exactly the same as with C, as  
>>>> Ada.Streams.Stream_Element is implementation defined (which is good,  
>>>> because this is indeed platform dependent), so you will need ..
>>> 
>>> All this is well and good for applications that can work in 
>>> "implementation defined" units of type Stream_Element. A pragma
>>> won't fix the problem should it be different than a byte. Granted,
>>> it will never likely come up on the platforms I have in mind.
>> 
>> If you to read a character stream, just do so:
>> 
>>    Item := Character'Read (S);
>>    Character'Write (S, Item);
>> 
>> For octet streams use Unsigned_8.
> 
> But this has to include seeking in the stream as well.

Repeat reading n times.

> Can you guarantee seeking to an arbitrary "byte boundary"?

On a machine with 13 bis per character? Can you define "byte boundary"? The
point is that if Stream_Element is not 8 bits, and the environment supports
streams of octets, then I see no reason why Ada vendor would implement
Unsigned_8r'Read incompatible with that.

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

Re: for S'Image use Func??

[J-P. Rosen]

Warren a �crit :
> J-P. Rosen expounded in news:hsb97m$tnd$1@news.eternal-september.org:
> 
>> Dmitry A. Kazakov a �crit :
>>> On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote:
>>>
>>>> But you have no way to know when you've read 
>>>> a empty line in a lexer routine that is reading 
>>>> character by character. 
>> Come on, here is the magic function:
>>
>> function Empty_Line return Boolean is
>> begin
>>    return Col=1 and End_Of_Line;
>> end Empty_Line;
> 
> There's a wart-- see earlier posts about "end file".
> 
Of course, this assumes an well-formed Ada file.
FYI, there /is/ a scanner in AdaControl, and I never had a problem.
The trick is to check End_Of_Line when needed, and never check
End_Of_File, but handle End_Error instead. This works even for
ill-formed files.

And of course, you are welcome to have a look at my scanner in
AdaControl ;-)
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: for S'Image use Func??

[Maciej Sobczak]

On 11 Maj, 23:46, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > OK, next step: what's exactly being inefficient in buffering in
> > buffered input?
>
> Machine instructions to execute.

Yes - by proper use of buffering I can *reduce* the number of machine
instructions to execute and therefore make the program run faster.

Note also that the number of machine instructions is only a partial
problem - another is delays introduced by some of them. Sometimes it
is better to execute more instructions that keep the pipeline full
than to execute less of them, but with delays or blocks.

> Why an Ada program handling texts need to be aware of your system?

Because it is running on my system. It's a pretty good idea to have
some local awareness.

> Ada.Text_IO provides an OS-independent abstraction of a text.

The above is not even wrong. Ada.Text_IO cannot even *name* all the
files that I have on my hard drive.

Even assuming that I can open some file, the whole "abstraction of a
text" is severely limited. I cannot, for example, read the second
paragraph of the third chapter of the book that is in the file.
This "abstraction" is really a stream on steroids, nothing fancy.

> > Unfortunately, in Ada the formatting and I/O are entangled in Text_IO.
>
> No. See A.10.8(18) and F.3.3.

Wrong. They do not relate to Text_IO.

Even assuming wider context, formatting without I/O is trivial, but I
cannot have I/O without formatting. Text_IO gives me both.
But on the other hand, I'm not sure how I/O without formatting would
look like - that would have to be a plain stream. Which means that
your "abstraction of a text" is little more than a bit of formatting
glued on top of a stream.

> The problem of Text_IO is columns.

Not only. It cannot detect the end of stream without blocking, for
example.

> 2. Stream I/O is unsuitable for a custom Text_IO. It simply won't work in a
> system deploying native record-oriented files.

I'm OK with that. The whole thing is so unportable already that
limiting it further to only those systems that I will ever want to use
is not a problem for me.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

Dmitry A. Kazakov expounded in
news:1x8q3p2gvm9fh.aru6nueicagd$.dlg@40tude.net: 

> On Tue, 11 May 2010 20:56:11 +0000 (UTC), Warren wrote:
> 
>> Dmitry A. Kazakov expounded in news:1qfu2ba65pd63$.asc7m201hi6u$.dlg@
>> 40tude.net:
>> 
>>> On Tue, 11 May 2010 17:17:38 +0000 (UTC), Warren wrote:
>>> 
>>>> =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?=
>>>> expounded 
>> in
>>>> news:op.vcig7go1ule2fv@garhos: 
>>>> 
>>>>> Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak  
>>>>> <see.my.homepage@gmail.com> a écrit:
>>>>>> Coming back to I/O - what I miss in Ada is the equivalent of
>>>>>> fread 
>> in
>>>>>> C - that is, an operation that reads *up to* the given number of
>>>>>> bytes. Or maybe there is something that I didn't notice?
>>>> 
>>>>> It's there : look at [ARM 2005 13.13.1] which defines the package 
>>>>> Ada.Streams, which in turn contains the following :
>>>>> 
>>>>>     type Root_Stream_Type is abstract tagged limited private;
>>>>>     ...
>>>>>     type Stream_Element is mod implementation-defined;
>>>>>     ...
>>>> ...
>>>>> Well, to be honest, this is not exactly the same as with C, as  
>>>>> Ada.Streams.Stream_Element is implementation defined (which is
>>>>> good,  because this is indeed platform dependent), so you will
>>>>> need .. 
>>>> 
>>>> All this is well and good for applications that can work in 
>>>> "implementation defined" units of type Stream_Element. A pragma
>>>> won't fix the problem should it be different than a byte. Granted,
>>>> it will never likely come up on the platforms I have in mind.
>>> 
>>> If you to read a character stream, just do so:
>>> 
>>>    Item := Character'Read (S);
>>>    Character'Write (S, Item);
>>> 
>>> For octet streams use Unsigned_8.
>> 
>> But this has to include seeking in the stream as well.
> 
> Repeat reading n times.
> 
>> Can you guarantee seeking to an arbitrary "byte boundary"?
> 
> On a machine with 13 bis per character? Can you define "byte
> boundary"? The point is that if Stream_Element is not 8 bits, and the
> environment supports streams of octets, then I see no reason why Ada
> vendor would implement Unsigned_8r'Read incompatible with that.

On those machines, you're not going to have standard C I/O
either. That's an purely academic case.

But the issue I am taking, are machines that define multiples
of a byte.

Warren

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

Gautier write-only expounded in
news:58bc837c-16b5-4a9d-af74-40417ad538c5@k29g2000yqh.googlegroups.com: 

> On May 11, 12:39�am, Yannick Duch�ne (Hibou57)
> <yannick_duch...@yahoo.fr> wrote:
> 
> [...]
>> Well, to be honest, this is not exactly the same as with C, as �
>> Ada.Streams.Stream_Element is implementation defined (which is good,
>> � because this is indeed platform dependent), so you will need an
>> Assert 
> �
>> pragma somewhere is your application, which ensures �
>> Ada.Streams.Stream_Element is 8 bits or at least 8 bits (this is, in
>> most 
>  �
>> of case), and then convert from Ada.Streams.Stream_Element to your �
>> Byte_Type or anything your application defined as such.
..
> You can make a size check (even a compile-time one!). Here, for
> arrays:
>   subtype Size_test_a is Byte_Array(1..19);
>   subtype Size_test_b is Ada.Streams.Stream_Element_Array(1..19);
>   --
>   is_mapping_possible: constant Boolean:    Size_test_a'Size =
>   Size_test_b'Size and then 
>     Size_test_a'Alignment = Size_test_b'Alignment;

I suspect that Ada.Streams.Stream_Element being > 1 byte,
is probably academic for my purposes.  However, if a posix
platform made a stream element 2 or 4 bytes, then the 
"whole gig is off". Which is what my OP was about.

Should that happen, I'd be forced to look at bindings
to something else. But this is probably academic.

Warren

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Wed, 12 May 2010 15:16:05 +0200, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:
> The above is not even wrong. Ada.Text_IO cannot even *name* all the
> files that I have on my hard drive.
>
> Even assuming that I can open some file, the whole "abstraction of a
> text" is severely limited. I cannot, for example, read the second
> paragraph of the third chapter of the book that is in the file.
> This "abstraction" is really a stream on steroids, nothing fancy.
Talking about names, it happens I myself had troubles on Windows XP with  
some file names too (exceptions on directory iteration, raised when the  
file name contains some characters).

If that can make you happy, some real life projects too, requires no  
dependency at all on Ada.Text_IO and and other File_Type related things  
coming from standard packages. It is even part of some really used control  
file examples which comes with AdaControl
( http://www.adalog.fr/adacontrol1.htm )

If something is not suitable to you, nothing in the standard requires you  
to use it ;) It is really common to use Ada with restrictions to enforce  
some requirements. That does not mean these libraries are not good, just  
that they may not meet some expectations. Ada's standard library set is  
rather tiny (that's what is good) compared to others, so it cannot meet  
every ones expectations.

There is more benefit in being able to create the package you need and  
which is not provided by the standard, and be able to do it well and  
cleanly, than to have standard package to “meet” all requirements (not  
possible).

Perhaps Ada is more “ready to create” than “ready to cosume”

That was my two cents of the day, sorry if that was not so much worthy

-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Yannick Duchêne (Hibou57)]

Le Wed, 12 May 2010 07:00:14 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
> Of course, this assumes an well-formed Ada file.
> FYI, there /is/ a scanner in AdaControl, and I never had a problem.
> The trick is to check End_Of_Line when needed, and never check
> End_Of_File, but handle End_Error instead. This works even for
> ill-formed files.
This is a common given advice or tip indeed, to have a exception handlers  
which catch error at end of text files. I even believe this is the most  
commonly encountered trap with Ada.

> And of course, you are welcome to have a look at my scanner in
> AdaControl ;-)
Lazy programmers, require you gave them the link :
http://www.adalog.fr/adacontrol1.htm

(teasing Warren)

-- 
pragma Asset ? Is that true ? Waaww... great

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Wed, 12 May 2010 06:16:05 -0700 (PDT), Maciej Sobczak wrote:

> On 11 Maj, 23:46, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Why an Ada program handling texts need to be aware of your system?
> 
> Because it is running on my system. It's a pretty good idea to have
> some local awareness.

No, that makes the program non-portable and fragile against system
modifications.

>> Ada.Text_IO provides an OS-independent abstraction of a text.
> 
> The above is not even wrong. Ada.Text_IO cannot even *name* all the
> files that I have on my hard drive.

That has nothing to do with text.

I agree that Ada.Directories is broken. But that is exactly because it
lacks the level of abstraction Ada.Text_IO has.

(BTW, you cannot enumerate all files with C I/O either)

> Even assuming that I can open some file, the whole "abstraction of a
> text" is severely limited. I cannot, for example, read the second
> paragraph of the third chapter of the book that is in the file.

It is necessarily limited here because not every text is a book.

>>> Unfortunately, in Ada the formatting and I/O are entangled in Text_IO.
>>
>> No. See A.10.8(18) and F.3.3.
> 
> Wrong. They do not relate to Text_IO.

That is what you asked for, a not entangled formatting.
 
> Even assuming wider context, formatting without I/O is trivial, but I
> cannot have I/O without formatting.

Why not?

> Text_IO gives me both.
> But on the other hand, I'm not sure how I/O without formatting would
> look like - that would have to be a plain stream. Which means that
> your "abstraction of a text" is little more than a bit of formatting
> glued on top of a stream.

Sure. Stream is unsuitable for text. It does not make sense to format
streams. You do it in UNIX, because it lacks texts, because its file system
is "untyped".

>> The problem of Text_IO is columns.
> 
> Not only. It cannot detect the end of stream without blocking, for
> example.

That is a property of the stream. Don't use streams as texts.

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

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Wed, 12 May 2010 13:27:17 +0000 (UTC), Warren wrote:

> But the issue I am taking, are machines that define multiples
> of a byte.

The compiler vendor will choose an appropriate way to handle that. Whether
it is natively for the system truncating/expanding or packing/unpacking,
which endianness it is, I don't see any reason why the vendor should/could
not follow that.

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

Re: for S'Image use Func??

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

=?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= expounded in
news:op.vclkbjy9xmjfy8@garhos: 

> Le Wed, 12 May 2010 07:00:14 +0200, J-P. Rosen <rosen@adalog.fr> a
> �crit: 
>> Of course, this assumes an well-formed Ada file.
>> FYI, there /is/ a scanner in AdaControl, and I never had a problem.
>> The trick is to check End_Of_Line when needed, and never check
>> End_Of_File, but handle End_Error instead. This works even for
>> ill-formed files.
> This is a common given advice or tip indeed, to have a exception
> handlers  which catch error at end of text files. I even believe this
> is the most  commonly encountered trap with Ada.
> 
>> And of course, you are welcome to have a look at my scanner in
>> AdaControl ;-)
> Lazy programmers, require you gave them the link :
> http://www.adalog.fr/adacontrol1.htm
> 
> (teasing Warren)

Heh heh.. I'm not making any lex changes at this point in time.
I've got bigger fish to fry. When the dust all settles, I can 
then go back and choose my [code] fights then.

Warren

Re: for S'Image use Func??

[Maciej Sobczak]

On 12 Maj, 17:58, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >> Why an Ada program handling texts need to be aware of your system?
>
> > Because it is running on my system. It's a pretty good idea to have
> > some local awareness.
>
> No, that makes the program non-portable and fragile against system
> modifications.

As I already said, I'm OK with this kind of non-portability.
It does not bother me that my program will not work on non-existing
systems (which effectively includes those obscure systems that you can
surely refer to for the sake of example, but that none of us will ever
use anyway).
I am pragmatic here.

> > Even assuming that I can open some file, the whole "abstraction of a
> > text" is severely limited. I cannot, for example, read the second
> > paragraph of the third chapter of the book that is in the file.
>
> It is necessarily limited here because not every text is a book.

Bingo. So what is a text, really?

Ada.Text_IO (similarly to text I/O libraries in other languages)
focuses on lines. This is similarly outdated as focusing on columns
and really belongs to the same era.
When I read the text in my web browser (the most frequently used
application for text consumption nowadays), the "lines" are whatever
the browser cares to display, which depends on how I scale the window
and what font size I select. I can change these properties dynamically
and in particular nothing prevents me from opening the same document
in several windows, each differently scaled.
This means that "lines" is not a property of the data source, it is a
property of the display.

Yet everybody is dead focused on the concept of text files that are
composed of lines. There are no lines, really.
If "text" means anything more than a stream on steroids, then it must
be recognized to have a much richer structure than just a sequence of
lines. Paragraphs, headings, chapters, whatever - these are structural
elements of text. But not lines. Lines and columns are artifacts of
the teletype printers era - gone long ago.

With this in mind, the "text abstraction" as represented by
Ada.Text_IO is really a stream on steroids. That's why I don't
understand why you put so much stress on distinguish the "text" from
the "stream", while the effective distance between them is close to
zero.

(please don't remind me constantly about filesystems that are based on
records - the line-oriented records are long gone with teletype
printers and nowadays "filesystems" will store whole files in single
records instead, so we are back to streams anyway)

> >> The problem of Text_IO is columns.
>
> > Not only. It cannot detect the end of stream without blocking, for
> > example.
>
> That is a property of the stream. Don't use streams as texts.

Translation: Text_IO cannot detect the end of text without blocking.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Wed, 12 May 2010 15:14:59 -0700 (PDT), Maciej Sobczak wrote:

> On 12 Maj, 17:58, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>>> Why an Ada program handling texts need to be aware of your system?
>>
>>> Because it is running on my system. It's a pretty good idea to have
>>> some local awareness.
>>
>> No, that makes the program non-portable and fragile against system
>> modifications.
> 
> As I already said, I'm OK with this kind of non-portability.
> It does not bother me that my program will not work on non-existing
> systems (which effectively includes those obscure systems that you can
> surely refer to for the sake of example, but that none of us will ever
> use anyway).
> I am pragmatic here.

I am too. I know that Windows does exist and that LF /= CR LF. See:

http://en.wikipedia.org/wiki/CR/LF

Al this mess is abstracted away by Ada.Text_IO.

(And OpenVMS exists too)

>>> Even assuming that I can open some file, the whole "abstraction of a
>>> text" is severely limited. I cannot, for example, read the second
>>> paragraph of the third chapter of the book that is in the file.
>>
>> It is necessarily limited here because not every text is a book.
> 
> Bingo. So what is a text, really?

It is not a book.

> Ada.Text_IO (similarly to text I/O libraries in other languages)
> focuses on lines. This is similarly outdated as focusing on columns
> and really belongs to the same era.
> When I read the text in my web browser (the most frequently used
> application for text consumption nowadays), the "lines" are whatever
> the browser cares to display, which depends on how I scale the window
> and what font size I select. I can change these properties dynamically
> and in particular nothing prevents me from opening the same document
> in several windows, each differently scaled.

Browser renders texts. It means that text is not the input, but the output
of. The input of a browser is a program written in some ugly language named
HTML.

> This means that "lines" is not a property of the data source, it is a
> property of the display.

I consider text an ordered set of lines.

> Yet everybody is dead focused on the concept of text files that are
> composed of lines. There are no lines, really.

Of course there are, see //-comments in C++.

> If "text" means anything more than a stream on steroids, then it must
> be recognized to have a much richer structure than just a sequence of
> lines. Paragraphs, headings, chapters, whatever - these are structural
> elements of text.

That was exactly the mistake Ada designers made with Text_IO. They tried to
add more there, pagination etc. They should have stay with lines.

(In software design this type of error is called "fat class")

> With this in mind, the "text abstraction" as represented by
> Ada.Text_IO is really a stream on steroids. That's why I don't
> understand why you put so much stress on distinguish the "text" from
> the "stream", while the effective distance between them is close to
> zero.

Because I used to write compilers and serial communication protocols.

>>> Not only. It cannot detect the end of stream without blocking, for
>>> example.
>>
>> That is a property of the stream. Don't use streams as texts.
> 
> Translation: Text_IO cannot detect the end of text without blocking.

No, the translation is: stream does not have an end. You cannot detect
something that does not exist. Text has an end. Ergo, if you wanted a text
on the stream, you would need an encoding layer. (This layer exists and is
customarily broken in UNIX and Windows.)

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

Re: for S'Image use Func??

[Warren]

Dmitry A. Kazakov expounded in
news:1g82ubkc0t0pf$.nuj3gqp1buh6.dlg@40tude.net: 
> On Wed, 12 May 2010 15:14:59 -0700 (PDT), Maciej Sobczak wrote:
..
>> I am pragmatic here.
> 
> I am too. I know that Windows does exist and that LF /= CR LF. See:
..
> Al this mess is abstracted away by Ada.Text_IO.

Windoze may be a mess, but managing LF and/or CR
is hardly rocket science. I and most other folks
I know have easily dealt with it since the CP/M days.

Warren

Re: for S'Image use Func??

[Niklas Holsti]

J-P. Rosen wrote:
> Warren a �crit :
>> J-P. Rosen expounded in news:hsb97m$tnd$1@news.eternal-september.org:
>>
>>> Dmitry A. Kazakov a �crit :
>>>> On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote:
>>>>
>>>>> But you have no way to know when you've read 
>>>>> a empty line in a lexer routine that is reading 
>>>>> character by character. 
>>> Come on, here is the magic function:
>>>
>>> function Empty_Line return Boolean is
>>> begin
>>>    return Col=1 and End_Of_Line;
>>> end Empty_Line;
>> There's a wart-- see earlier posts about "end file".
>>
> Of course, this assumes an well-formed Ada file.
> FYI, there /is/ a scanner in AdaControl, and I never had a problem.
> The trick is to check End_Of_Line when needed, and never check
> End_Of_File, but handle End_Error instead. This works even for
> ill-formed files.

I don't think that this trick will help with the "wart", which is the 
invisibility of a final null (zero-length) line in a Text_IO file.

As best I understand it, the Text_IO view of a text file as a sequence 
of lines excludes the case of a file with no lines at all, which 
logically would consist of a file terminator, possibly preceded by a 
page terminator, but not preceded by a line terminator.

Text_IO insists that the file terminator is always preceded by line and 
page terminators, logically if not physically, and the Text_IO 
operations are defined to hide the physical presence or absence of a 
final line terminator at the end of the file. Therefore every Text_IO 
file seems to have at least one line terminator, and thus at least one line.

> And of course, you are welcome to have a look at my scanner in
> AdaControl ;-)

I did, and I even compiled and tried it, but since your scanner ignores 
and skips all line terminators (there is no "end of line" token kind), 
its operation does not illuminate the question of the "wart".

But this "wart" is a very small blemish, perhaps just a beauty mark, as 
it has no effect on most uses of Text_IO, for scanners or otherwise.

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

Re: for S'Image use Func??

[Niklas Holsti]

Yannick Duchï¿œne (Hibou57) wrote:
> Le Tue, 11 May 2010 09:34:42 +0200, Niklas Holsti 
> <niklas.holsti@tidorum.invalid> a ï¿œcrit:
>> Yes, with one problem, which is that it is hard (that is, I don't know 
>> how) to detect when the very last line in the input file is null. This 
>> is because End_Of_Line returns true also at end of file, and 
>> End_Of_File returns true also when the data remaining in the file is 
>> an end-of-line (and end-of-page) before the true end of file. One 
>> consequence is that a truly empty file (like /dev/null) looks the same 
>> as a file with one null line (like echo "").

> This may be "hard" only with the Standard_Input file, which is a 
> Text_IO.File_Type, and Text_IO, as previously said, is a file of lines.

We are indeed discussing Text_IO. Whether the program reads 
Standard_Input or some other Text_IO file is irrelevant.

> A file of line, as you shown you know, is a file where each is line 
> strictly delimited in platform dependent manner (with LF on UNIX, CR+LF 
> on Windows and CR on Mac, or with specific chunks or records on some 
> other systems).

The actual line terminators (if any) used in the physical file are 
irrelevant to the problem. The problem is in the logical definition of a 
text file and of the Text_IO operations and the information they give 
about the contents of the file. The problem can perhaps appear in 
different ways, depending on how a particular Text_IO implementation 
maps physical files to Text_IO concepts. My experience is with Gnat on 
Linux and MS Windows.

> So obviously, each line is expected to have an end, just 
> like each file have an end, and the end of the last line is also the end 
> of a file, if the file is a file of line. Just like a file of some kind 
> of records ends with the end of the last record.

I agree that each file has an end, and each line has an end. But Text_IO 
extends this in two weird ways:

- The first problem is that the Text_IO operations require (the 
appearance of) a final line terminator before the end of the file. This 
means that no Text_IO file can be truly empty in the sense of having no 
lines at all; it will always have (or appear to have) at least one line 
terminator, so at least one line, if we count the number of lines by 
counting the number of line terminators. And it seems queer to have an 
"end of a line" with no line that it ends...

- The second problem is that the Text_IO operations are defined to make 
no difference between two line terminators at the end of a file, and one 
line terminator. If the last line in the file is null (zero length), it 
is invisible to Text_IO. As far as I know, at least.

> I was to say this is a matter only with Standard_Input, and in the 
> context of "/dev/null" which you gave, you have no need to open 
> "/dev/null" as a file of lines if have no reason to think "/dev/null" is 
> indeed a file of lines.

An empty file, like /dev/null, seems the only reasonable representation 
of a text file with no lines at all. But such empty text files conflict 
with the Text_IO concepts, which is one of the problems.

> To talk about text files now : let say most of them are just 
> inconsistently formated, as many text files as produced by text editors, 
> are not formated in the constant way : the last line oftenly lacks a 
> delimiter for the last line.

It is up to the Text_IO implementation to decide how to handle such 
files; conceivably, an implementation could raise an exception, or 
behave in some other unexpected way, if the final line terminator is not 
physically represented in the expected way. But the Text_IO operations 
(Get (Character), End_Of_Line, End_Of_File) are defined to let an 
implementation ignore the missing line terminator. For example, 
End_Of_Line is defined to return True if the current position is at the 
end of the file, which makes it appear *as if* the file were correctly 
formatted with a final line terminator before the end of the file. The 
two problems I describe above are unfortunate by-products of these 
definitions.

But again, the "problems" almost never cause any real difficulty, as 
final null lines can be ignored in most uses of Text_IO.

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

Re: for S'Image use Func??

[Maciej Sobczak]

On 13 Maj, 09:31, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > I am pragmatic here.
>
> I am too. I know that Windows does exist and that LF /= CR LF.

<shrug />

This is an added value? I call it a trivial stream filter with barely
one bit of state in the finite-state machine. Nothing to cheer about.

> Al this mess is abstracted away by Ada.Text_IO.

This "abstraction" is peanuts. Like in
Ada.Stream_IO_With_Trivial_Filter. :-)

> (And OpenVMS exists too)

I guess that the Commodore 64 emulator for iPhone has a wider user
base - please do not refer to effectively non-existing systems just to
keep the discussion going. It's wasteful.

> > So what is a text, really?
>
> It is not a book.

A scientific paper, perhaps? Or a CV?

If you stick to the concept of "text" as defined by Text_IO
(completely unstructured sequence of lines), then effectively the only
use-case that you will cover without problems is... config files. Like
in Ada.Config_Files_IO. :-)

> Browser renders texts. It means that text is not the input, but the output
> of. The input of a browser is a program written in some ugly language named
> HTML.

Wrong. I use the browser to read .txt files, too. No HTML is
necessary.

> I consider text an ordered set of lines.

I consider such a set of lines to be a stream on steroids. The problem
is that our definitions are arbitrary and we're not going to conclude
anything.

> > Yet everybody is dead focused on the concept of text files that are
> > composed of lines. There are no lines, really.
>
> Of course there are, see //-comments in C++.

The C++ source code is not a text for me.
I know that it is a text for you due to your arbitrarily chosen
definitions.

> > Translation: Text_IO cannot detect the end of text without blocking.
>
> No, the translation is: stream does not have an end.

That's your arbitrary definition and you did not provide any reference
for it.
I see no reason to accept it.

In particular, /dev/null is a very nice empty stream. It is not a
stream that has no data for infinite amount of time (this can be
emulated) - this is genuinely empty stream which has an end and that
end can be detected immediately.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Fri, 14 May 2010 14:03:17 -0700 (PDT), Maciej Sobczak wrote:

> On 13 Maj, 09:31, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> I am pragmatic here.
>>
>> I am too. I know that Windows does exist and that LF /= CR LF.
> 
> <shrug />
> 
> This is an added value? I call it a trivial stream filter with barely
> one bit of state in the finite-state machine. Nothing to cheer about.

Do you want to say that text files are Turing complete? (:-)) Maybe they
are. Maybe they are not. Consider an experiment. Let us generate random
files containing CRs, LFs and other characters. Show the file to several
people asking them to count lines...

>> Al this mess is abstracted away by Ada.Text_IO.
> 
> This "abstraction" is peanuts. Like in
> Ada.Stream_IO_With_Trivial_Filter. :-)

If it were, there would be no discussions about it.

>> (And OpenVMS exists too)
> 
> I guess that the Commodore 64 emulator for iPhone has a wider user
> base - please do not refer to effectively non-existing systems just to
> keep the discussion going. It's wasteful.

Ada never was popular.

>>> So what is a text, really?
>>
>> It is not a book.
> 
> A scientific paper, perhaps? Or a CV?

A memo, minutes etc.

> If you stick to the concept of "text" as defined by Text_IO
> (completely unstructured sequence of lines), then effectively the only
> use-case that you will cover without problems is... config files.

+ source codes, which nicely covers 90% of my tasks.

I don't need Ada.Document_IO. Especially because it is a far bigger mess
than stupid LFs in UNIX files.

>> Browser renders texts. It means that text is not the input, but the output
>> of. The input of a browser is a program written in some ugly language named
>> HTML.
> 
> Wrong. I use the browser to read .txt files, too. No HTML is
> necessary.

Then some other encoding is used. That changes nothing. Browser renders LFs
according to some rules, the result you see is the text (or one of many
possible).

>>> Yet everybody is dead focused on the concept of text files that are
>>> composed of lines. There are no lines, really.
>>
>> Of course there are, see //-comments in C++.
> 
> The C++ source code is not a text for me.

Then you shall not use text editors with it.

>>> Translation: Text_IO cannot detect the end of text without blocking.
>>
>> No, the translation is: stream does not have an end.
> 
> That's your arbitrary definition and you did not provide any reference
> for it.

It does not mean that no stream may have it. It is only a negation that
every stream does.

Anyway, if you tried to define the stream end, you could not do in terms of
its elements, You will need some "non-functional," "out-of-band" return
codes, exceptions etc. Blocking is just among others. You could say: it
ends when blocked. Not very nice, but, in fact, widely used in network
communication protocols.

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

Re: for S'Image use Func??

[Maciej Sobczak]

On 15 Maj, 10:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Do you want to say that text files are Turing complete? (:-)) Maybe they
> are. Maybe they are not. Consider an experiment. Let us generate random
> files containing CRs, LFs and other characters. Show the file to several
> people asking them to count lines...

Wrong, unless you clearly define the meaning of "show".
People do not have the ability to consume files in their storage form.
The file has to be *rendered* somehow to be accessible to our senses.
For example, it has to be *displayed*, for example using a text editor
or a web browser - and this is when the whole exercise becomes both
trivial and pointless.
And if you give me the freedom to choose my rendering scheme, it will
be:

$ cat -n file.txt


> >>> So what is a text, really?
>
> >> It is not a book.
>
> > A scientific paper, perhaps? Or a CV?
>
> A memo, minutes etc.

Wrong. I happen to attend meetings which are so long and rich, that
their minutes deserve structure.

> > If you stick to the concept of "text" as defined by Text_IO
> > (completely unstructured sequence of lines), then effectively the only
> > use-case that you will cover without problems is... config files.
>
> + source codes, which nicely covers 90% of my tasks.

Fine. You still forgot about log files. :-)

> I don't need Ada.Document_IO.

Me neither. I'm perfectly OK with the stream I/O.

> > The C++ source code is not a text for me.
>
> Then you shall not use text editors with it.

I don't. I use programmer's editors, also known as IDEs, with it.

> >>> Translation: Text_IO cannot detect the end of text without blocking.
>
> >> No, the translation is: stream does not have an end.
>
> > That's your arbitrary definition and you did not provide any reference
> > for it.
>
> It does not mean that no stream may have it. It is only a negation that
> every stream does.

I did not say that every stream has an end. I said that Ada.Text_IO
cannot discover it without blocking. Whether the stream has an end or
not is completely irrelevant to my original statement, but since you
decided to mix it into the discussion...

> Anyway, if you tried to define the stream end, you could not do in terms of
> its elements, You will need some "non-functional," "out-of-band" return
> codes, exceptions etc.

Yes.

> Blocking is just among others.

No. Blocking is not a statement about stream. It tells me nothing
about the stream and it still blocks my program. It is a useless
strategy and not intuitive, as it shows that the stream is being
physically consumed as part of what is a purely predicative operation.

> You could say: it
> ends when blocked. Not very nice, but, in fact, widely used in network
> communication protocols.

Widely? An example or two, please?

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Sat, 15 May 2010 13:50:47 -0700 (PDT), Maciej Sobczak wrote:

> On 15 Maj, 10:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Do you want to say that text files are Turing complete? (:-)) Maybe they
>> are. Maybe they are not. Consider an experiment. Let us generate random
>> files containing CRs, LFs and other characters. Show the file to several
>> people asking them to count lines...
> 
> Wrong, unless you clearly define the meaning of "show".

That is the point! Show is in each other's head. Some would consider single
LF as one empty line, others as two, and some as a broken file.

> And if you give me the freedom to choose my rendering scheme, it will
> be:
> 
> $ cat -n file.txt

It does not work under Windows. As you said about VMS, why should I care
what a non-existent hobbyist's OS does? (:-))

>>> If you stick to the concept of "text" as defined by Text_IO
>>> (completely unstructured sequence of lines), then effectively the only
>>> use-case that you will cover without problems is... config files.
>>
>> + source codes, which nicely covers 90% of my tasks.
> 
> Fine. You still forgot about log files. :-)

I don't use UNIX, remember. Our log files are binary. (Trace files are
texts.)

>> I don't need Ada.Document_IO.
> 
> Me neither. I'm perfectly OK with the stream I/O.

Yes, you stream graphical minutes, as you said...

>>> The C++ source code is not a text for me.
>>
>> Then you shall not use text editors with it.
> 
> I don't. I use programmer's editors, also known as IDEs, with it.

IDE is a front end to a text editor. You still need a text to print, store,
pass to the compiler.

>> You could say: it
>> ends when blocked. Not very nice, but, in fact, widely used in network
>> communication protocols.
> 
> Widely? An example or two, please?

Any. You cannot rely on the remote host always sending you graceful
disconnect. Many devices we are dealing with don't even have such thing.
They just become silent.

As a practical example, load some large text page into the browser. Before
it completes, in the middle, pull the Etherenet jack out. Observe the
stream end!

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

Re: for S'Image use Func??

[Maciej Sobczak]

On 16 Maj, 09:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > Wrong, unless you clearly define the meaning of "show".
>
> That is the point! Show is in each other's head. Some would consider single
> LF as one empty line, others as two, and some as a broken file.

So now we can come back to our original subject - what is the added
value of Text_IO, then? What is the point of abstracting the notion of
text, if it "is in each other's head"? Shouldn't stream I/O be enough
and leave the rest to everybody's head in this case?

> > And if you give me the freedom to choose my rendering scheme, it will
> > be:
>
> > $ cat -n file.txt
>
> It does not work under Windows.

Of course it does. Cygwin is your best friend.

> As you said about VMS, why should I care
> what a non-existent hobbyist's OS does? (:-))

You shouldn't.

> > Fine. You still forgot about log files. :-)
>
> I don't use UNIX, remember. Our log files are binary.

The only thing I can say now is that not only you don't use Unix, but
you also don't use plenty of software packages that exist on Windows.

> >> You could say: it
> >> ends when blocked. Not very nice, but, in fact, widely used in network
> >> communication protocols.
>
> > Widely? An example or two, please?
>
> Any. You cannot rely on the remote host always sending you graceful
> disconnect. Many devices we are dealing with don't even have such thing.
> They just become silent.

This makes the end of stream indistinguishable from arbitrary delays.
Not a good idea. What about the stream of keystrokes? Is the stream
finished just because I'm thinking what to type next?

> As a practical example, load some large text page into the browser. Before
> it completes, in the middle, pull the Etherenet jack out. Observe the
> stream end!

It is not a stream end, it is a communication error. Guess what - some
protocols are wiser than HTTP and can figure that out, which disproves
your universal "any" qualifier.


As in the majority of such discussion, we don't have a converging
thread and we're not likely to come to any conclusion either (and we
are long ago far away from the original problem, too).
Is it OK to suggest that we should somehow finish?

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: for S'Image use Func??

[Dmitry A. Kazakov]

On Sun, 16 May 2010 13:56:57 -0700 (PDT), Maciej Sobczak wrote:

> On 16 Maj, 09:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Wrong, unless you clearly define the meaning of "show".
>>
>> That is the point! Show is in each other's head. Some would consider single
>> LF as one empty line, others as two, and some as a broken file.
> 
> So now we can come back to our original subject - what is the added
> value of Text_IO, then?

That you need not count lines by yourself.

> What is the point of abstracting the notion of
> text, if it "is in each other's head"?

It is not. The notion of stream encoding is.

> Shouldn't stream I/O be enough
> and leave the rest to everybody's head in this case?

No, because we count lines differently. Text_IO provides a way to
standardize encodings in inferior operating systems.

>>> And if you give me the freedom to choose my rendering scheme, it will
>>> be:
>>
>>> $ cat -n file.txt
>>
>> It does not work under Windows.
> 
> Of course it does. Cygwin is your best friend.

Nope, cygwin is a horror. Even much less offending MinGW is.

>>> Fine. You still forgot about log files. :-)
>>
>> I don't use UNIX, remember. Our log files are binary.
> 
> The only thing I can say now is that not only you don't use Unix, but
> you also don't use plenty of software packages that exist on Windows.

Right, for example MFC, ActiveX among others.

>>>> You could say: it
>>>> ends when blocked. Not very nice, but, in fact, widely used in network
>>>> communication protocols.
>>
>>> Widely? An example or two, please?
>>
>> Any. You cannot rely on the remote host always sending you graceful
>> disconnect. Many devices we are dealing with don't even have such thing.
>> They just become silent.
> 
> This makes the end of stream indistinguishable from arbitrary delays.

These systems are more or less real-time. It means that if the delay
exceeds the time of service (which is not necessarily microseconds, it
could be seconds), then the game is out anyway.

> Not a good idea. What about the stream of keystrokes? Is the stream
> finished just because I'm thinking what to type next?

The operators have HMI. They don't encourage streams, they do GUIs!

>> As a practical example, load some large text page into the browser. Before
>> it completes, in the middle, pull the Etherenet jack out. Observe the
>> stream end!
> 
> It is not a stream end, it is a communication error. Guess what - some
> protocols are wiser than HTTP and can figure that out, which disproves
> your universal "any" qualifier.

Error is the reason why the stream is or considered ended. Note that the
browser does not crash. It renders that end, you can see it by scrolling
the page down.

> As in the majority of such discussion, we don't have a converging
> thread and we're not likely to come to any conclusion either (and we
> are long ago far away from the original problem, too).
> Is it OK to suggest that we should somehow finish?

Yes.

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

Re: for S'Image use Func??

[J-P. Rosen]

Niklas Holsti a �crit :
>> And of course, you are welcome to have a look at my scanner in
>> AdaControl ;-)
> 
> I did, and I even compiled and tried it, but since your scanner ignores
> and skips all line terminators (there is no "end of line" token kind),
> its operation does not illuminate the question of the "wart".
> 
Huh? There is an At_EoL boolean, even if it is not a full fledged token...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: for S'Image use Func??

[Randy Brukardt]

"Warren" <ve3wwg@gmail.com> wrote in message 
news:Xns9D747B0528E86WarrensBlatherings@188.40.43.245...
> Robert A Duff expounded in news:wccd3x7lww8.fsf@shell01.TheWorld.com:
>
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>
>>> I actually don't buy the need for the Assert pragma in the first
>>> place: such checks are rarely expensive and thus should simply be
>>> part of the code always.
>>
>> If they're not expensive, then you're not using it enough.  ;-)
>>
>> Also, the other advantage of pragma Assert over an Assert
>> procedure is that you can put the pragma in declarative parts
>> and package specs.
>
> What I liked is the added convenience of having the
> source module and line number reported, without me
> having to code for that.

Janus/Ada reports that for all exception raises (as well as a complete 
traceback of calls), and always has (even back on the Z80 CP/M version in 
1981), so there isn't any advantage to the pragma over plain Ada code that 
raises an exception on failure. The only thing that is even remotely complex 
that the pragma addresses is putting checks in declarative parts (which is 
not usually a problem with judious use of blocks).

                           Randy.

Re: for S'Image use Func??

[Niklas Holsti]

J-P. Rosen wrote:
> Niklas Holsti a �crit :
>>> And of course, you are welcome to have a look at my scanner in
>>> AdaControl ;-)
>> I did, and I even compiled and tried it, but since your scanner ignores
>> and skips all line terminators (there is no "end of line" token kind),
>> its operation does not illuminate the question of the "wart".
>>
> Huh? There is an At_EoL boolean, even if it is not a full fledged token...

Ah yes, there is an At_Eol variable in the package body, and a 
like-named component in the private type Scanner_State, but those are 
not accessible to clients of the scanner.

I modified your package Framework.Language.Scanner, to provide a 
function that queries At_Eol, and made a test program that calls 
Start_Scan and then calls Next_Token repeatedly, until it returns the 
Eof (end of file) token. After each call of Next_Token the program 
prints out the line number of Standard_Input, Current_Token.Kind, and 
the value of At_Eol.

In my experiments, the output is exactly the same for a file that 
consists of just one line of text, as for a file that consists of this 
one line of text followed by a null line.

A client of your scanner thus cannot detect that the input file has a 
final empty line, which is the "wart" that has been discussed in this 
thread.

I have found a work-around for the wart, so it is possible to use 
Text_IO to detect final empty lines. The following program counts the 
number of lines in the input file, and works even for empty files 
(/dev/null) and for files with final null lines. The trick is to use an 
extra call of Skip_Line to see if there is a final line terminator (for 
a null line) before the file terminator:

with Ada.Text_IO; use Ada.Text_IO;
procedure Count_Lines
is
    Lines : Natural := 0;
begin

    while not End_Of_File loop
       -- A non-null line at this point, or a null line
       -- that is not immediately followed by end of file.
       -- Process the line in some way; omitted here.
       Lines := Lines + 1;
       Skip_Line;
    end loop;

    -- Here we are at End_Of_File, but there may
    -- still be a line terminator for a null line
    -- immediately before the true end of the file.

    begin
       Skip_Line;
       -- Skip_Line raises End_Error if there is no line
       -- terminator before the end of the file.
       Lines := Lines + 1;
    exception
    when End_Error => null;
    end;

    Put_Line ("Lines:" & Natural'Image (Lines));

end Count_Lines;


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

Re: for S'Image use Func??

[Niklas Holsti]

I am replying to my own post to show an even simpler solution to the 
"final empty line" problem. I guess this solution is what J-P. Rosen and 
others have suggested, earlier in this thread, but I have been too dense 
to understand.

The "problem" is that the Text_IO functions End_Of_Line and End_Of_File 
give the same result when the input file is positioned at true end of 
file as when the file is positioned at a line terminator preceding the 
true end of file. This means that a reading loop of the form "while not 
End_Of_File loop <read a line> end loop" will ignore a final empty line.

The simple solution is to use a loop that uses Get_Line (or Skip_Line) 
and terminates on the End_Error exception. This program reads and counts 
the lines in the input file and works for /dev/null (zero lines) as well 
as for files that end with empty lines:

with Ada.Text_IO; use Ada.Text_IO;
procedure Count_Lines is
    Lines : Natural := 0;
begin
    loop
       declare
          The_Line : constant String := Get_Line;
       begin
          Lines := Lines + 1;
       end;
    end loop;
exception
when End_Error =>
    Put_Line ("Lines:" & Natural'Image (Lines));
end Count_Lines;

So, with apologies for any confusion about "warts" that I may have 
generated, I will now shut up.

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