for S'Image use Func??
in [ADA]
|
Prev: Question about default discriminants and mutable objects.
Next: Why is not Stream_Access defined Ada.Streams ?
From: Warren on 10 May 2010 12:18 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
From: Dmitry A. Kazakov on 10 May 2010 12:31 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
From: Warren on 10 May 2010 12:52 Dmitry A. Kazakov expounded in news:zvtps4jzmo1z$.mzhapf4p7b4a.dlg(a)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
From: Georg Bauhaus on 10 May 2010 13:54 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. :-)
From: Dmitry A. Kazakov on 10 May 2010 13:55
On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote: > Dmitry A. Kazakov expounded in > news:zvtps4jzmo1z$.mzhapf4p7b4a.dlg(a)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 |