* Something I don't understand @ 2014-02-13 23:57 Laurent 2014-02-14 0:18 ` adambeneschan 0 siblings, 1 reply; 77+ messages in thread From: Laurent @ 2014-02-13 23:57 UTC (permalink / raw) Hi Doing an exercise from the book "Ada 95 Problem Solving and Program Design". I am supposed to make a robust function to read some values. It works so far but there is one thing I don't understand. MaxName : CONSTANT Positive := 30; -- defined in other package SUBTYPE NameType IS String (1 .. MaxName); -- defined in other package Count : Natural RANGE 1.. MaxName; Name : LOOP BEGIN --exception handler block Ada.Text_IO.Put ("Name (1 - "); Ada.Integer_Text_IO.Put (Item => MaxName,Width => 1); Ada.Text_IO.Put(Item => " characters) >"); Ada.Text_IO.Get_Line (Item => S, Last => Count); Item.Name (1 .. Count) := S (1 .. Count); Ada.Text_IO.Skip_Line; EXIT; -- correct Name EXCEPTION WHEN Constraint_Error => Ada.Text_IO.Skip_Line; Ada.Text_IO.Put (Item => "Name too short/long!"); Ada.Text_IO.New_Line; END; -- exception handler END LOOP Name; So when I enter nothing as name I get a Constraint_Error which is handled. That's ok but when the name I enter is longer than 30 chars no exception. Is that normal and if yes/no why? The chars that are to much are just ignored. Thanks Laurent ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-13 23:57 Something I don't understand Laurent @ 2014-02-14 0:18 ` adambeneschan 2014-02-14 7:05 ` Charles H. Sampson 2014-02-15 15:27 ` Laurent 0 siblings, 2 replies; 77+ messages in thread From: adambeneschan @ 2014-02-14 0:18 UTC (permalink / raw) On Thursday, February 13, 2014 3:57:58 PM UTC-8, Laurent wrote: > Hi > > > > Doing an exercise from the book "Ada 95 Problem Solving and Program Design". > > I am supposed to make a robust function to read some values. It works so far but there is one thing I don't > > understand. > MaxName : CONSTANT Positive := 30; -- defined in other package > SUBTYPE NameType IS String (1 .. MaxName); -- defined in other package > > Count : Natural RANGE 1.. MaxName; > > Name : LOOP > BEGIN --exception handler block > Ada.Text_IO.Put ("Name (1 - "); > Ada.Integer_Text_IO.Put (Item => MaxName,Width => 1); > Ada.Text_IO.Put(Item => " characters) >"); > Ada.Text_IO.Get_Line (Item => S, Last => Count); > Item.Name (1 .. Count) := S (1 .. Count); > Ada.Text_IO.Skip_Line; > > EXIT; -- correct Name > > EXCEPTION > WHEN Constraint_Error => > Ada.Text_IO.Skip_Line; > Ada.Text_IO.Put (Item => "Name too short/long!"); > Ada.Text_IO.New_Line; > > END; -- exception handler > > END LOOP Name; > > > > > > So when I enter nothing as name I get a Constraint_Error which is handled. That's ok but when the name I enter is longer than 30 chars no exception. Is that normal and if yes/no why? Yes, because that's how the *procedure* Get_Line is defined. It stops reading when it reaches the end of the string, or the end of the line. (RM A.10.7(18-20)) If you want to check for input that is too long, you can use the *function* Get_Line, which always reads to the end of the line: declare Input : String := Ada.Text_IO.Get_Line; begin if Input'Length <= NameType'Length then Item.Name (1 .. Input'Length) := Input; --Ada.Text_IO.Skip_Line; --you shouldn't need this, Get_Line will --automatically perform this exit Name; -- correct name else Ada.Text_IO.Put_Line (Item => "Name too long!"); -- combination of Put and New_Line end if; end; -- this ends the block starting with "declare" -- Adam ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-14 0:18 ` adambeneschan @ 2014-02-14 7:05 ` Charles H. Sampson 2014-02-15 15:27 ` Laurent 1 sibling, 0 replies; 77+ messages in thread From: Charles H. Sampson @ 2014-02-14 7:05 UTC (permalink / raw) <adambeneschan@gmail.com> wrote: > On Thursday, February 13, 2014 3:57:58 PM UTC-8, Laurent wrote: > > Hi > > > > > > > > Doing an exercise from the book "Ada 95 Problem Solving and Program Design". > > > > I am supposed to make a robust function to read some values. It works so > > far but there is one thing I don't understand. > > > MaxName : CONSTANT Positive := 30; -- defined in other package > > SUBTYPE NameType IS String (1 .. MaxName); -- defined in other package > > > > Count : Natural RANGE 1.. MaxName; > > > > Name : LOOP > > BEGIN --exception handler block > > Ada.Text_IO.Put ("Name (1 - "); > > Ada.Integer_Text_IO.Put (Item => MaxName,Width => 1); > > Ada.Text_IO.Put(Item => " characters) >"); > > Ada.Text_IO.Get_Line (Item => S, Last => Count); > > Item.Name (1 .. Count) := S (1 .. Count); > > Ada.Text_IO.Skip_Line; > > > > EXIT; -- correct Name > > > > EXCEPTION > > WHEN Constraint_Error => > > Ada.Text_IO.Skip_Line; > > Ada.Text_IO.Put (Item => "Name too short/long!"); > > Ada.Text_IO.New_Line; > > > > END; -- exception handler > > > > END LOOP Name; > > > > > > > > > > > > So when I enter nothing as name I get a Constraint_Error which is > > handled. That's ok but when the name I enter is longer than 30 chars no > > exception. Is that normal and if yes/no why? > > Yes, because that's how the *procedure* Get_Line is defined. It stops > reading when it reaches the end of the string, or the end of the line. > (RM A.10.7(18-20)) > > If you want to check for input that is too long, you can use the > *function* Get_Line, which always reads to the end of the line: > > declare > Input : String := Ada.Text_IO.Get_Line; > begin > if Input'Length <= NameType'Length then > Item.Name (1 .. Input'Length) := Input; > --Ada.Text_IO.Skip_Line; --you shouldn't need this, Get_Line will > --automatically perform this > exit Name; -- correct name > else > Ada.Text_IO.Put_Line (Item => "Name too long!"); > -- combination of Put and New_Line > end if; > end; -- this ends the block starting with "declare" It should be mentioned that in the OP's version the extra characters aren't discarded. They're still there to be "gotten" on the next use of Get or Get_Line. As Mr. Beneschan hinted in his comment above, if you want to get rid of them you need to call Skip_Line. Just another example of Ada not doing things behind the scene. Charlie -- Nobody in this country got rich on his own. You built a factory--good. But you moved your goods on roads we all paid for. You hired workers we all paid to educate. So keep a big hunk of the money from your factory. But take a hunk and pay it forward. Elizabeth Warren (paraphrased) ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-14 0:18 ` adambeneschan 2014-02-14 7:05 ` Charles H. Sampson @ 2014-02-15 15:27 ` Laurent 2014-02-15 19:10 ` Laurent 1 sibling, 1 reply; 77+ messages in thread From: Laurent @ 2014-02-15 15:27 UTC (permalink / raw) Hi > Yes, because that's how the *procedure* Get_Line is defined. It stops reading when it reaches the end of >the string, or the end of the line. (RM A.10.7(18-20)) This would explain why an IF condition on Count > MaxName never activated. >It should be mentioned that in the OP's version the extra >characters aren't discarded. They're still there to be "gotten" on the >next use of Get or Get_Line. As Mr. Beneschan hinted in his comment >above, if you want to get rid of them you need to call Skip_Line. Yes I know, thats why I put a Skip_Line to prevent the extra chars from getting catcher from the following input procedure which expects an enumeration. > The chars that are to much are just ignored. I thought that as I get an Constraint_Error for not entering a char at all, Get_Line would also complain if the String entered is too long. Because Strings are 1D Arrays. Thats why I asked. Thanks for the example. I think I will use it, even if it is not really necessary. Could be useful later in my own program. There are still a lot of things I have to learn. Thank you very much. Laurent ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-15 15:27 ` Laurent @ 2014-02-15 19:10 ` Laurent 2014-02-15 20:05 ` Niklas Holsti ` (2 more replies) 0 siblings, 3 replies; 77+ messages in thread From: Laurent @ 2014-02-15 19:10 UTC (permalink / raw) Hi Now it works as I think it should. Name : LOOP BEGIN --exception handler block Ada.Text_IO.Put ("Name (1 - "); Ada.Integer_Text_IO.Put (Item => MaxName, Width => 1); Ada.Text_IO.Put (Item => " characters) >"); DECLARE S : String := Ada.Text_IO.Get_Line; BEGIN IF S'Length = 0 THEN RAISE Name_Too_Short; ELSIF S'Length <= MaxName THEN Item.Name (1 .. S'Length) := S; ELSE RAISE Name_Too_Long; END IF; EXIT; -- correct Name EXCEPTION WHEN Name_Too_Short => Ada.Text_IO.Skip_Line; Ada.Text_IO.Put (Item => "Name too short!"); Ada.Text_IO.New_Line; WHEN Name_Too_Long => Ada.Text_IO.Skip_Line; Ada.Text_IO.Put_Line (Item => "Name too long!"); END; -- exception handler END; END LOOP Name; The only thing which I find annoying is the fact that I have to tape ENTER 2 times. @Adam: Thanks for your example Thanks Laurent ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-15 19:10 ` Laurent @ 2014-02-15 20:05 ` Niklas Holsti 2014-02-15 21:16 ` Laurent 2014-02-15 21:40 ` Jeffrey Carter 2014-02-16 1:39 ` Robert A Duff 2 siblings, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-15 20:05 UTC (permalink / raw) On 14-02-15 21:10 , Laurent wrote: > Hi > > Now it works as I think it should. > > Name : LOOP > BEGIN --exception handler block > Ada.Text_IO.Put ("Name (1 - "); > Ada.Integer_Text_IO.Put (Item => MaxName, Width => 1); > Ada.Text_IO.Put (Item => " characters) >"); You might want to insert Ada.Text_IO.Flush here, to make sure that the preceding Put text appears on the terminal. (I'm not sure if the standard requires an implicit Flush when a Put is followed by a Get.) > DECLARE > S : String := Ada.Text_IO.Get_Line; [snip] > EXCEPTION > > WHEN Name_Too_Short => > Ada.Text_IO.Skip_Line; [snip] > The only thing which I find annoying is the fact that I > have to tape ENTER 2 times. Does that happen only in the exception cases? Then the reason is probably the Skip_Line calls in the exception handlers. They are superfluous because the Get_Line function includes the effect of a Skip_Line (RM 17.2/2) -- it consumes the line terminator. Remove the Skip_Lines. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-15 20:05 ` Niklas Holsti @ 2014-02-15 21:16 ` Laurent 0 siblings, 0 replies; 77+ messages in thread From: Laurent @ 2014-02-15 21:16 UTC (permalink / raw) Hi > Does that happen only in the exception cases? Then the reason is > probably the Skip_Line calls in the exception handlers. They are > superfluous because the Get_Line function includes the effect of a > Skip_Line (RM 17.2/2) -- it consumes the line terminator. Remove the > Skip_Lines. Happened also with a correct name. Probably forgotten to rebuild something. Wouldn't be the first time. After rebuild correct name was processed after one enter. Removed the Skip_Line from the Exception Handler part and a wrong name also needs only one enter. @Niklas: Thanks for your help Laurent ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-15 19:10 ` Laurent 2014-02-15 20:05 ` Niklas Holsti @ 2014-02-15 21:40 ` Jeffrey Carter 2014-02-16 1:39 ` Robert A Duff 2 siblings, 0 replies; 77+ messages in thread From: Jeffrey Carter @ 2014-02-15 21:40 UTC (permalink / raw) On 02/15/2014 12:10 PM, Laurent wrote: > > BEGIN --exception handler block There's no exception handler for this "begin". It does nothing and and the comment is incorrect, so it should be eliminated. > DECLARE This block has the exception handler. -- Jeff Carter "In the frozen land of Nador they were forced to eat Robin's minstrels, and there was much rejoicing." Monty Python & the Holy Grail 70 ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-15 19:10 ` Laurent 2014-02-15 20:05 ` Niklas Holsti 2014-02-15 21:40 ` Jeffrey Carter @ 2014-02-16 1:39 ` Robert A Duff 2014-02-16 9:08 ` Text_IO, was: " Simon Clubley ` (2 more replies) 2 siblings, 3 replies; 77+ messages in thread From: Robert A Duff @ 2014-02-16 1:39 UTC (permalink / raw) Laurent <daemon2@internet.lu> writes: > Now it works as I think it should. Good. FWIW, Text_IO is a poor design, and I don't blame you for having trouble with it! Some stylistic comments on the code below: Exceptions are for dealing with cases where one piece of code detects a (possible) error, and another piece of code decides whether it really is an error, and how to deal with it. That's not the case here, so should be written without any exceptions. No need for a loop name. You should use typical style, so other Ada programmers can read your code more easily: lower case keywords, Max_Name instead of MaxName. (Or Max_Name_Length?) Space after "--". S should declared "constant". You should enable warnings in GNAT that detect this mistake. Why should there be a limit on the length of the name? Maybe you have a good reason, but usually such arbitrary limits are a bad idea. > Name : LOOP > BEGIN --exception handler block > Ada.Text_IO.Put ("Name (1 - "); > Ada.Integer_Text_IO.Put (Item => MaxName, Width => 1); > Ada.Text_IO.Put (Item => " characters) >"); > > DECLARE > S : String := Ada.Text_IO.Get_Line; > > BEGIN > IF S'Length = 0 THEN > RAISE Name_Too_Short; > ELSIF S'Length <= MaxName THEN > Item.Name (1 .. S'Length) := S; > ELSE RAISE Name_Too_Long; > END IF; > > EXIT; -- correct Name > > EXCEPTION > > WHEN Name_Too_Short => > Ada.Text_IO.Skip_Line; > Ada.Text_IO.Put (Item => "Name too short!"); > Ada.Text_IO.New_Line; > WHEN Name_Too_Long => > Ada.Text_IO.Skip_Line; > Ada.Text_IO.Put_Line (Item => "Name too long!"); > > END; -- exception handler > END; > END LOOP Name; ^ permalink raw reply [flat|nested] 77+ messages in thread
* Text_IO, was: Re: Something I don't understand 2014-02-16 1:39 ` Robert A Duff @ 2014-02-16 9:08 ` Simon Clubley 2014-02-16 9:43 ` Dmitry A. Kazakov 2014-02-16 16:17 ` Robert A Duff 2014-02-16 14:50 ` Mike H 2014-02-17 16:09 ` Laurent 2 siblings, 2 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-16 9:08 UTC (permalink / raw) On 2014-02-15, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > > FWIW, Text_IO is a poor design, and I don't blame you for having > trouble with it! > I'm always interested in learning how people would do things differently if they were given a second chance. So, what do you dislike about Text_IO and what design changes would you make if given a second chance ? In a modified Ada, do you still see a role for Text_IO as it stands (with additional I/O package(s) implementing your desired changes) or do you think Text_IO should be outright replaced ? Thanks, Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-16 9:08 ` Text_IO, was: " Simon Clubley @ 2014-02-16 9:43 ` Dmitry A. Kazakov 2014-02-16 16:57 ` Dennis Lee Bieber 2014-02-16 16:17 ` Robert A Duff 1 sibling, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-16 9:43 UTC (permalink / raw) On Sun, 16 Feb 2014 09:08:20 +0000 (UTC), Simon Clubley wrote: > In a modified Ada, do you still see a role for Text_IO as it stands > (with additional I/O package(s) implementing your desired changes) or do > you think Text_IO should be outright replaced ? Text_IO should be replaced because the design of Character/String was wrong. It is wrong to have Character, Wide_Character, Wide_Wide_Character. It is wrong not to separate encoding from characters. The punishment for that is a combinatorial explosion of variants as observed in Text_IO. Other stuff hated by many is the page formatting Text_IO does. This is basically the same problem as above, of not using the language type system properly. When it was finally noted, stream I/O (Text_Stream) was introduced. It was a bit strange that Text_Stream sat on top of Text_IO. Most OSes where this would reflect the reality are gone (e.g. VMS). In Unix it is rather formatting that sits on streams. Anyway again, that should be reflected by type relationships rather than by a patchwork of calls returning access(!) types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-16 9:43 ` Dmitry A. Kazakov @ 2014-02-16 16:57 ` Dennis Lee Bieber 0 siblings, 0 replies; 77+ messages in thread From: Dennis Lee Bieber @ 2014-02-16 16:57 UTC (permalink / raw) On Sun, 16 Feb 2014 10:43:57 +0100, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> declaimed the following: >a bit strange that Text_Stream sat on top of Text_IO. Most OSes where this >would reflect the reality are gone (e.g. VMS). In Unix it is rather Fading, but not gone... I'm currently having to update a test plan (and then perform the tests before SQA) of a program developed under VMS (though -- using a cross compiler for 68xxx processor). VMS is running under an emulator on a Windows box... (granted, they are using a paid support version but... http://www.openvms.org/pages.php?page=Hobbyist http://www.stromasys.com/products/charon-freeware/charon-freeware/ It lives, Igor! -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-16 9:08 ` Text_IO, was: " Simon Clubley 2014-02-16 9:43 ` Dmitry A. Kazakov @ 2014-02-16 16:17 ` Robert A Duff 2014-02-17 12:52 ` Simon Clubley 1 sibling, 1 reply; 77+ messages in thread From: Robert A Duff @ 2014-02-16 16:17 UTC (permalink / raw) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: > On 2014-02-15, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: >> >> FWIW, Text_IO is a poor design, and I don't blame you for having >> trouble with it! > > I'm always interested in learning how people would do things differently > if they were given a second chance. > > So, what do you dislike about Text_IO and what design changes would you > make if given a second chance ? I/O should be separated from processing. In this case, the "processing" I'm talking about is formatting and parsing of data (e.g. turning an integer into a human-readable sequence of characters). See how it's done in Java. Formatting for type T belongs with type T, not in Text_IO. Input should be separate from output. Put(Stream, X), where X is an integer makes sense, because we know X is an integer. Get(X) makes no sense, because we have no idea what the user is going to type. For text input, you need "read the next token, and tell me what it is", not "read an integer token, and blow up if the user typed something else". A simplified and type-safe version of C's printf style (template-based) formatting would be more readable than concatenating a bunch of strings together to print messages, and MUCH better than using a series of Put calls to print a single message. I/O should be task safe, at least for standard output and friends. There are various ways operating systems have chosen to represent text files: lines separated by a single character, lines separated by two characters (CR/LF), record oriented. Obviously, the language design needs to pick one of those models, and the implementation needs to map that model onto whatever the OS does. Any model will work, but Ada chose the least convenient one. Path names (file names with directory names and so on) should be represented using an appropriate type, with structure, properly interoperating with Ada.Directories. String is the wrong type for that. See how it's done in Common Lisp, quite portably. The Get_Line procedure invites people to write broken programs with arbitrary annoying line-length limitations. However long you make that String, it will be either too short or too long, and most likely both. The Get_Line function is better. There should be a convenient way to read an entire file into a String. Similar for writing. String should be a private data type with appropriate operations, representing full Unicode, probably represented in UTF-8. But we can't blame the designers of Ada 83 for choosing 7-bit ASCII. Even that was a bold move, at a time when most languages didn't even define a standard character set, leaving it up to the operating system. There should be a standard way to represent multi-line text in a String. There is no convenient way to open a file in append mode, creating it (empty) if it doesn't exist, atomically. Calling Create followed by Close, with no intervening output, does not create an empty file. That's broken. The line-counting business is largely useless, and somewhat confusing. The page-handling is largely pointless, and gets in the way even when you don't care about pages. Finalization (which didn't exist in Ada 83) should be used to automatically close files. Open should be a build-in-place function (which didn't exist in Ada 83), instead of a procedure. > In a modified Ada, do you still see a role for Text_IO as it stands > (with additional I/O package(s) implementing your desired changes) or do > you think Text_IO should be outright replaced ? You mean if compatibility were not a concern? Yeah, the only reason to keep Text_IO as it is is for compatibility. In a from-scratch language design, I'd do it rather differently. - Bob ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-16 16:17 ` Robert A Duff @ 2014-02-17 12:52 ` Simon Clubley 2014-02-17 15:32 ` G.B. ` (2 more replies) 0 siblings, 3 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-17 12:52 UTC (permalink / raw) On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: > >> On 2014-02-15, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: >>> >>> FWIW, Text_IO is a poor design, and I don't blame you for having >>> trouble with it! >> >> I'm always interested in learning how people would do things differently >> if they were given a second chance. >> >> So, what do you dislike about Text_IO and what design changes would you >> make if given a second chance ? > > I/O should be separated from processing. In this case, the "processing" > I'm talking about is formatting and parsing of data (e.g. turning > an integer into a human-readable sequence of characters). See how > it's done in Java. > > Formatting for type T belongs with type T, not in Text_IO. > Agreed, but it should be a two-way thing. There should be both External_To_Internal and Internal_To_External support to convert between the external (human readable) format and the internal format. You would also need to specify a format when going from internal to external format so the output would fit in the requested field width and obey the requested attributes (for example, number of decimal places). > Input should be separate from output. Put(Stream, X), where X is an > integer makes sense, because we know X is an integer. Get(X) > makes no sense, because we have no idea what the user is going > to type. For text input, you need "read the next token, and tell > me what it is", not "read an integer token, and blow up if the > user typed something else". > While the current input routines need replacing, I don't agree with the Ada RTL trying to work out what the input format is and pass a token type back to the program. The problem is that unless you are careful, you can end up with a Excel type solution in which it works most of the time but fails when it thinks it knows better than you do what you entered. For example, consider the input "123,456". Is the user entering a array of two numbers ? Is the user entering one number but with a thousands seperator ? Is the user in mainland Europe and hence is really entering "123.456" ? Should this input be treated as a string (because it has a comma in it) or should the Ada RTL impose it's idea of a number and convert the input into some standard format even though that may not look anything like what the user meant ? What happens when the final destination is a range limited data type ? You either have to still do the checking manually or take a exception if the input value is outside of the range of the data type. > A simplified and type-safe version of C's printf style > (template-based) formatting would be more readable than > concatenating a bunch of strings together to print messages, > and MUCH better than using a series of Put calls to print > a single message. > _Totally_ agree with this. It would also be nice if one could write something like this (pseudo Fortran style to get the idea across): "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth (in this example) of data cleanly. > > There should be a convenient way to read an entire file into > a String. Similar for writing. > Yes, but you may need two methods. One for binary (unchanged) input and one for text input with end of line conversions. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 12:52 ` Simon Clubley @ 2014-02-17 15:32 ` G.B. 2014-02-17 15:35 ` G.B. 2014-02-17 17:34 ` Mike H 2014-02-17 16:59 ` Niklas Holsti 2014-02-19 21:15 ` Robert A Duff 2 siblings, 2 replies; 77+ messages in thread From: G.B. @ 2014-02-17 15:32 UTC (permalink / raw) On 17.02.14 13:52, Simon Clubley wrote: > On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: >> A simplified and type-safe version of C's printf style >> (template-based) formatting would be more readable than >> concatenating a bunch of strings together to print messages, >> and MUCH better than using a series of Put calls to print >> a single message. >> > > _Totally_ agree with this. It would also be nice if one could write > something like this (pseudo Fortran style to get the idea across): > "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth > (in this example) of data cleanly. I wonder if this feature could be tacked onto the string types? With the help of attribute functions and named bindings, formatting could be handled flexibly, leaving room for internationalization, for example. Formatting could also be handled conveniently, insofar as the language provides "obvious" default formatting. For_Invoice : constant Wide_String := -- not Ada Wide_String'Edited ("A total of %{Sum} %{Currency} for %{Pieces}") with Bindings => (Sum => (Value => <>, Money'Wide_Formatted => Using_Pic_String), Currency => (I18N.CU, Currency'Wide_Formatted => <>), Pieces => (Amount * 2.0, Three_Colums'Access)); Format : constant -- needs to be a static constant Wide_String'Edited := "Process # %{pnum} : %{n}µs"; A <> stands for the default choices, viz. a variable or parameterless function named "Sum" in the first row, and a default "formatter" in the third. When no specialized formatting is needed for an item, write with Bindings => (..., Foo => <>, ...); As an example of a flexible solution, "Using_Pic_string" from the first example above would be a function with a profile like that of 'Wide_Image. (Its body uses existing language features, in this case picture strings from Information Systems Annex.) Also, since the generics of Text_IO already provide for formatting numbers (Putting them into strings), these routines could be borrowed for the meaning of T'[Wide_][Wide_]_Formatted Safety of the template is guaranteed insofar as the number of items (and types, I think) in any actual binding is known at compile time; type checking looks possible. Hence, the simplest formatting would be String'Edited("%{n} bottles of beer on the wall") with Bindings (others => <>); It requires only that there be a variable/function named N. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 15:32 ` G.B. @ 2014-02-17 15:35 ` G.B. 2014-02-17 17:34 ` Mike H 1 sibling, 0 replies; 77+ messages in thread From: G.B. @ 2014-02-17 15:35 UTC (permalink / raw) On 17.02.14 16:32, G.B. wrote: > Currency => (I18N.CU, Currency'Wide_Formatted => <>), Currency => (I18N.CU, Money'Wide_Formatted => <>), Sorry. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 15:32 ` G.B. 2014-02-17 15:35 ` G.B. @ 2014-02-17 17:34 ` Mike H 1 sibling, 0 replies; 77+ messages in thread From: Mike H @ 2014-02-17 17:34 UTC (permalink / raw) In message <53022b7f$0$6661$9b4e6d93@newsspool2.arcor-online.net>, G.B. <rm-dash-bau-haus@dash.futureapps.de> writes >On 17.02.14 13:52, Simon Clubley wrote: >> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > >>> A simplified and type-safe version of C's printf style >>> (template-based) formatting would be more readable than >>> concatenating a bunch of strings together to print messages, >>> and MUCH better than using a series of Put calls to print >>> a single message. >>> >> >> _Totally_ agree with this. It would also be nice if one could write >> something like this (pseudo Fortran style to get the idea across): >> "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth >> (in this example) of data cleanly. > >I wonder if this feature could be tacked onto the string >types? With the help of attribute functions and named >bindings, formatting could be handled flexibly, leaving room >for internationalization, for example. Formatting could also >be handled conveniently, insofar as the language provides >"obvious" default formatting. Albeit, in COBOL, I once worked on a "convertible currency ledger" (e.g. one where the items are recorded in both the currency of the foreign customer and the sterling value derived from the exchange rate in force at the time of the transaction), Ada generics would probably be my first line of investigation. -- Cotswold Mike "Homo sum, humani nihil a me alienum puto" = "I am human, (so) I (should) judge nothing of humanity to be strange." Publius Terentius (195/185–159 BC) ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 12:52 ` Simon Clubley 2014-02-17 15:32 ` G.B. @ 2014-02-17 16:59 ` Niklas Holsti 2014-02-17 17:17 ` Dmitry A. Kazakov ` (2 more replies) 2014-02-19 21:15 ` Robert A Duff 2 siblings, 3 replies; 77+ messages in thread From: Niklas Holsti @ 2014-02-17 16:59 UTC (permalink / raw) On 14-02-17 14:52 , Simon Clubley wrote: > On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: [snip] >> A simplified and type-safe version of C's printf style >> (template-based) formatting would be more readable than >> concatenating a bunch of strings together to print messages, >> and MUCH better than using a series of Put calls to print >> a single message. >> > > _Totally_ agree with this. I disagree, but then I don't understand how Robert would make C's template idea type-safe -- might Robert expand on his ideas? I think that the present method of concatenating strings or using several Puts is good; what is needed is to extend or replace the 'Image attribute with similar value-to-string functions which are more controllable, flexible, and work also for composite types. Perhaps something analogous to the stream attributes, but with the ability to control the output format at each invocation, which is not possible with the stream attributes. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 16:59 ` Niklas Holsti @ 2014-02-17 17:17 ` Dmitry A. Kazakov 2014-02-17 17:42 ` Niklas Holsti 2014-02-17 18:13 ` Simon Clubley 2014-02-19 21:46 ` Robert A Duff 2 siblings, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-17 17:17 UTC (permalink / raw) On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote: > I think that the present method of concatenating strings or using > several Puts is good; what is needed is to extend or replace the 'Image > attribute with similar value-to-string functions which are more > controllable, flexible, and work also for composite types. Except that all these need to be MD primitive operations. There is no way to solve this without MD. Needless to say that templates could solve nothing only add further problems. > Perhaps > something analogous to the stream attributes, but with the ability to > control the output format at each invocation, which is not possible with > the stream attributes. I don't think there is any need in having formats. A few formatting parameters could be passed along to Image or equivalent. Environment settings (e.g. locale) should come from the rendering surface object. No need to specify them at all. This is how stuff like fonts, colors etc is handled in GUI. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 17:17 ` Dmitry A. Kazakov @ 2014-02-17 17:42 ` Niklas Holsti 2014-02-17 19:55 ` Dmitry A. Kazakov 0 siblings, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-17 17:42 UTC (permalink / raw) On 14-02-17 19:17 , Dmitry A. Kazakov wrote: > On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote: > >> I think that the present method of concatenating strings or using >> several Puts is good; what is needed is to extend or replace the 'Image >> attribute with similar value-to-string functions which are more >> controllable, flexible, and work also for composite types. > > Except that all these need to be MD primitive operations. There is no way > to solve this without MD. Why multiple dispatch? Which would be the multiple controlling parameters? I think only the input value should be controlling; perhaps you think that the output channel/device should also be controlling? >> Perhaps >> something analogous to the stream attributes, but with the ability to >> control the output format at each invocation, which is not possible with >> the stream attributes. > > I don't think there is any need in having formats. A few formatting > parameters could be passed along to Image or equivalent. Well, parameters and options is what I meant. For example, the ability to specify blank fill, zero fill, center/left/right alignment, digit group spacing (1 123 456,00 or 1_123_456.00), etc. > Environment settings (e.g. locale) should come from the rendering surface > object. No need to specify them at all. This is how stuff like fonts, > colors etc is handled in GUI. A "rendering surface" is not always available at the point where the string is generated. There could be a private predefined type for such settings. A value of that type could be given as a parameter in the Image call to set the default format (which could then be overridden if the Image call also has some specific format parameters). A GUI toolkit could have a function to to return a suitable value of this type from a "rendering surface" object. I don't see why this, or the output channel, should be a controlling parameter. Something like these flexible Image functions already exists in Annex F (Information Systems), but it is partly template-driven ("picture"-driven). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 17:42 ` Niklas Holsti @ 2014-02-17 19:55 ` Dmitry A. Kazakov 2014-02-18 7:14 ` Niklas Holsti 0 siblings, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-17 19:55 UTC (permalink / raw) On Mon, 17 Feb 2014 19:42:07 +0200, Niklas Holsti wrote: > On 14-02-17 19:17 , Dmitry A. Kazakov wrote: >> On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote: >> >>> I think that the present method of concatenating strings or using >>> several Puts is good; what is needed is to extend or replace the 'Image >>> attribute with similar value-to-string functions which are more >>> controllable, flexible, and work also for composite types. >> >> Except that all these need to be MD primitive operations. There is no way >> to solve this without MD. > > Why multiple dispatch? Print (Display, Shape) is a textbook example of MD. > Which would be the multiple controlling > parameters? File and Value > I think only the input value should be controlling; perhaps > you think that the output channel/device should also be controlling? Certainly so. Consider ASCII_File, UTF8_File, Gtk_Text_Buffer_Record and so on. You cannot convert to string before sending it out, because ASCII will use E for power of 10, UTF8 will use superscript characters for it, and Gtk_Text_Buffer_Record will do the GTK markup language. >>> Perhaps >>> something analogous to the stream attributes, but with the ability to >>> control the output format at each invocation, which is not possible with >>> the stream attributes. >> >> I don't think there is any need in having formats. A few formatting >> parameters could be passed along to Image or equivalent. > > Well, parameters and options is what I meant. For example, the ability > to specify blank fill, zero fill, center/left/right alignment, digit > group spacing (1 123 456,00 or 1_123_456.00), etc. Yes, however, from experience, it quickly gets overcomplicated. I customary use Input_Parameters and Output_Parameters objects as you suggest below. They must be controlled as well because you want to be able to extend them. >> Environment settings (e.g. locale) should come from the rendering surface >> object. No need to specify them at all. This is how stuff like fonts, >> colors etc is handled in GUI. > > A "rendering surface" is not always available at the point where the > string is generated. String itself is such a surface. That is the point of having it controlled. You can replace it with whatever type, e.g. File, Stream etc. And string itself is a Universe of types because of encodings. > There could be a private predefined type for such settings. A value of > that type could be given as a parameter in the Image call to set the > default format (which could then be overridden if the Image call also > has some specific format parameters). Yes of course, but this is usually another set of parameters. Less volatile parameters, such as whether to use '.' or ',' to introduce fraction belong to the surface. > A GUI toolkit could have a > function to to return a suitable value of this type from a "rendering > surface" object. Possible but tedious. > I don't see why this, or the output channel, should be > a controlling parameter. Because you cannot predict all possible combinations of and because it is a huge wasting of human and computational resources as no given application will ever use more than 1% of it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 19:55 ` Dmitry A. Kazakov @ 2014-02-18 7:14 ` Niklas Holsti 2014-02-18 8:40 ` Dmitry A. Kazakov 0 siblings, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-18 7:14 UTC (permalink / raw) On 14-02-17 21:55 , Dmitry A. Kazakov wrote: > On Mon, 17 Feb 2014 19:42:07 +0200, Niklas Holsti wrote: > >> On 14-02-17 19:17 , Dmitry A. Kazakov wrote: >>> On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote: >>> >>>> I think that the present method of concatenating strings or using >>>> several Puts is good; what is needed is to extend or replace the 'Image >>>> attribute with similar value-to-string functions which are more >>>> controllable, flexible, and work also for composite types. >>> >>> Except that all these need to be MD primitive operations. There is no way >>> to solve this without MD. >> >> Why multiple dispatch? > > Print (Display, Shape) > > is a textbook example of MD. > >> Which would be the multiple controlling >> parameters? > > File and Value > >> I think only the input value should be controlling; perhaps >> you think that the output channel/device should also be controlling? > > Certainly so. Consider ASCII_File, UTF8_File, Gtk_Text_Buffer_Record and so > on. That could be done using overloading based on the expected type of the Image function result, instead of multiple dispatch. Of course that would require different types to represent ASCII strings and UTF8 strings, etc. Using different types for different kinds of strings would be a good thing anyway, IMO (but I know that this causes problems with a combinatorial explosion of the number of predefined subprograms involving strings). > You cannot convert to string before sending it out, because ASCII will > use E for power of 10, UTF8 will use superscript characters for it, and > Gtk_Text_Buffer_Record will do the GTK markup language. Hrm. I'm not at all sure that I would want such different formatting for different output channels to happen automatically. For one thing, using superscripts for exponents would prevent or complicate the user's copy-paste operations, for example copying the output of a Float number into a calculator accessory. There should really be a type "Text" that represents text, with all its complications of encoding, formatting, styles, fonts, lines, paragraphs, tabulation, indentation, language, ... True, that is horribly complex, but that's reality now. It is debatable if this should be in the language, or in toolkits (GUI or others). Probably some core part of it should be in the language and the rest in a toolkit or in an optional Annex to the language. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-18 7:14 ` Niklas Holsti @ 2014-02-18 8:40 ` Dmitry A. Kazakov 2014-02-18 9:00 ` Niklas Holsti 0 siblings, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-18 8:40 UTC (permalink / raw) On Tue, 18 Feb 2014 09:14:26 +0200, Niklas Holsti wrote: > There should really be a type "Text" that represents text, with all its > complications of encoding, formatting, styles, fonts, lines, paragraphs, > tabulation, indentation, language, ... True, that is horribly complex, > but that's reality now. It is debatable if this should be in the > language, or in toolkits (GUI or others). Probably some core part of it > should be in the language and the rest in a toolkit or in an optional > Annex to the language. You cannot have that type because texts are formatted differently depending on the medium. Different mediums deploy integrated mechanisms of formatting. E.g. paging is postponed until rendering if the medium is HTML. Alignment with proportional fonts is not about fields and decimal places, etc. In 80's there were only typewriter's text medium which is why Text_IO looks as it does. Today there is no way to handle it as single monolithic chunk. The way to A) modularize it, B) keep it at the library level, is a better type system. No hacks will really help, IMO. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-18 8:40 ` Dmitry A. Kazakov @ 2014-02-18 9:00 ` Niklas Holsti 2014-02-18 9:31 ` Dmitry A. Kazakov 0 siblings, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-18 9:00 UTC (permalink / raw) On 14-02-18 10:40 , Dmitry A. Kazakov wrote: > On Tue, 18 Feb 2014 09:14:26 +0200, Niklas Holsti wrote: > >> There should really be a type "Text" that represents text, with all its >> complications of encoding, formatting, styles, fonts, lines, paragraphs, >> tabulation, indentation, language, ... True, that is horribly complex, >> but that's reality now. It is debatable if this should be in the >> language, or in toolkits (GUI or others). Probably some core part of it >> should be in the language and the rest in a toolkit or in an optional >> Annex to the language. > > You cannot have that type Misunderstanding, I think... > because texts are formatted differently depending > on the medium. Different mediums deploy integrated mechanisms of > formatting. E.g. paging is postponed until rendering if the medium is HTML. > Alignment with proportional fonts is not about fields and decimal places, > etc. Exactly. I meant that the type "Text" would represent text abstractly, according to its logical structure, not in rendered form. The final "Put" would then render according to the output medium. Or, if the GUI and application are split, the rendering might happen in the GUI process, and the "Put" would just send across some serialization of the "Text" structure. > In 80's there were only typewriter's text medium which is why Text_IO looks > as it does. At least, programs in the 80's were expected to produce typewriter text. Typesetting was its own field. But today most programs are expected to produce web or GUI pages with formatting, proportional fonts, etc. > Today there is no way to handle it as single monolithic chunk. > The way to A) modularize it, B) keep it at the library level, is a better > type system. No hacks will really help, IMO. I think I agree. But I'm still not convinced that multiple dispatch is necessary, and we may disagree on how to modularize it. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-18 9:00 ` Niklas Holsti @ 2014-02-18 9:31 ` Dmitry A. Kazakov 2014-02-19 8:36 ` Niklas Holsti 0 siblings, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-18 9:31 UTC (permalink / raw) On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote: > On 14-02-18 10:40 , Dmitry A. Kazakov wrote: >> because texts are formatted differently depending >> on the medium. Different mediums deploy integrated mechanisms of >> formatting. E.g. paging is postponed until rendering if the medium is HTML. >> Alignment with proportional fonts is not about fields and decimal places, >> etc. > > Exactly. I meant that the type "Text" would represent text abstractly, > according to its logical structure, not in rendered form. You mean text buffer like in GUI? To me text buffer, stream, file, string are all instances of the class of types over which Put dispatches. OK, we can call the abstract root type of the class "Text." > The final > "Put" would then render according to the output medium. Yes, that Put would be an implementation of the primitive operation defined for the class Text. > Or, if the GUI > and application are split, the rendering might happen in the GUI > process, and the "Put" would just send across some serialization of the > "Text" structure. Yes, however I dislike stateful things, it is difficult to do it otherwise. >> Today there is no way to handle it as single monolithic chunk. >> The way to A) modularize it, B) keep it at the library level, is a better >> type system. No hacks will really help, IMO. > > I think I agree. But I'm still not convinced that multiple dispatch is > necessary, and we may disagree on how to modularize it. I think it is only logical for a strongly typed language to map this kind of stuff onto types. In a language of other type of decomposition, e.g. functional, I would consider other means. But for Ada I really fail to see alternatives. This search for other "ways" (aspects, generics etc) is really damaging the language. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-18 9:31 ` Dmitry A. Kazakov @ 2014-02-19 8:36 ` Niklas Holsti 2014-02-19 9:40 ` Dmitry A. Kazakov 0 siblings, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-19 8:36 UTC (permalink / raw) On 14-02-18 11:31 , Dmitry A. Kazakov wrote: > On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote: > >> On 14-02-18 10:40 , Dmitry A. Kazakov wrote: > >>> because texts are formatted differently depending >>> on the medium. Different mediums deploy integrated mechanisms of >>> formatting. E.g. paging is postponed until rendering if the medium is HTML. >>> Alignment with proportional fonts is not about fields and decimal places, >>> etc. >> >> Exactly. I meant that the type "Text" would represent text abstractly, >> according to its logical structure, not in rendered form. > > You mean text buffer like in GUI? Possibly so, but I'm not familiar with GUI text buffers. It sounds like a similar thing. > To me text buffer, stream, file, string are all instances of the class of > types over which Put dispatches. OK, we can call the abstract root type of > the class "Text." Perhaps Put would just be overloaded for these types. It depends if you consider the types a class, or not. I'm not sure what is best. >> The final >> "Put" would then render according to the output medium. > > Yes, that Put would be an implementation of the primitive operation defined > for the class Text. I would make Text a type, not a class. This would avoid the need for multiple dispatch on a controlling Text parameter. I'm thinking of two levels of "Put": Put (To : in out Text, Item : in String); Add items to a Text, building a logically structured Text, but without rendering it yet. This wil probably need some concept of "points in a Text where more stuff can be inserted" so that the Put can preserve or extend the logical Text structure. Put (To : in out File; Item : in Text); Render the Text into some external File. The Text buffer intermediary means that each level of Put can (if desired) be dispatching on one of the parameters, without needing multiple dispatch. > I think it is only logical for a strongly typed language to map this kind > of stuff onto types. I agree. > This search for other "ways" (aspects, generics etc) is really damaging the > language. I don't agree. I see aspects as strengthening or broadening the type concept, and generics as a meta-type level. But I must admit that I have lately been using generics less often and have instead used classes and dispaching more often. However, I think that generics are useful and are not entirely subsumed by classes. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 8:36 ` Niklas Holsti @ 2014-02-19 9:40 ` Dmitry A. Kazakov 2014-02-19 13:20 ` Niklas Holsti 0 siblings, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-19 9:40 UTC (permalink / raw) On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote: > On 14-02-18 11:31 , Dmitry A. Kazakov wrote: >> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote: >> To me text buffer, stream, file, string are all instances of the class of >> types over which Put dispatches. OK, we can call the abstract root type of >> the class "Text." > > Perhaps Put would just be overloaded for these types. It depends if you > consider the types a class, or not. I'm not sure what is best. When you overload you get an explosion of variants which is especially extreme in the case of MD, because you have N x M x L variants. It is exponential to the number of independent hierarchies. For I/O it is at least 3: medium, data, aggregated parameters. Fourth candidate could be transaction state for complex I/O. Another and even more serious issue is that ad-hoc polymorphism prevents code reuse. You cannot inherit, you cannot write class-wide code because you cannot have class-wide objects. Yet a typical usage of Text_IO is class-wide. When designing a text processing or text rendering application you don't want to deal with concrete types of medium. E.g. writing an interpreter you want it working with whatever type of input, not just string or just File_Type. >>> The final >>> "Put" would then render according to the output medium. >> >> Yes, that Put would be an implementation of the primitive operation defined >> for the class Text. > > I would make Text a type, not a class. This would avoid the need for > multiple dispatch on a controlling Text parameter. > > I'm thinking of two levels of "Put": > > Put (To : in out Text, Item : in String); > Add items to a Text, building a logically structured Text, > but without rendering it yet. This wil probably need > some concept of "points in a Text where more stuff can > be inserted" so that the Put can preserve or extend the > logical Text structure. > > Put (To : in out File; Item : in Text); > Render the Text into some external File. > > The Text buffer intermediary means that each level of Put can (if > desired) be dispatching on one of the parameters, without needing > multiple dispatch. This was attempted before, many many times, actually. From PostScript to HTML, an intermediate language that would take care of separating higher level formatting from lower level rendering. It never worked how many times tried. And for sure, it will be even more hated than Text_IO page formatting is, because the overhead will be far bigger. Imagine describing the semantics of, say, conversion of File, Stream, String to Text and backward. >> This search for other "ways" (aspects, generics etc) is really damaging the >> language. > > I don't agree. I see aspects as strengthening or broadening the type > concept, and generics as a meta-type level. Either is a parametrization. Parametrization does not broaden anything, when held at the meta level. You can parametrize type, statement, object, package, source code itself, you could even do the object code. It is completely orthogonal to what is being parametrized and by which entities. Parametrization is bad when the parametric entity is itself not a language entity. E.g. discriminaned type is OK, because it is still a type. Generic type is not OK, because it is not a type but something else. The latter is an erosion of the type system not broadening. > But I must admit that I have > lately been using generics less often and have instead used classes and > dispaching more often. However, I think that generics are useful and are > not entirely subsumed by classes. Both are classes, the means of constructing these classes are different and so are the properties and usage of these classes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 9:40 ` Dmitry A. Kazakov @ 2014-02-19 13:20 ` Niklas Holsti 2014-02-19 14:13 ` Dmitry A. Kazakov 2014-02-19 15:06 ` Robert A Duff 0 siblings, 2 replies; 77+ messages in thread From: Niklas Holsti @ 2014-02-19 13:20 UTC (permalink / raw) On 14-02-19 11:40 , Dmitry A. Kazakov wrote: > On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote: > >> On 14-02-18 11:31 , Dmitry A. Kazakov wrote: >>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote: > >>> To me text buffer, stream, file, string are all instances of the class of >>> types over which Put dispatches. OK, we can call the abstract root type of >>> the class "Text." My notion of type "Text" is an internal representation of text meant for human reading and viewing. I don't see any logical need for making this type a class; there would be only one predefined (and private) type. (There might be some technical reasons for making the type a class, for example with a root type that is low-cost but simple, and some derived classes which provide more functionality but at greater cost. Perhaps the simple root type would be a mandatory language feature, and the derived classes optional features.) By the way, perhaps the word "text" is ambiguous. I think it is time to make a clear distinction between: (1) a text file (sometimes called an "ASCI file"), which is a sequence of basic symbols (e.g. Character or Wide_Character) used to represent *data* for either reading by another program, or for human reading (without formatting), and (2) a text meant only for human reading/viewing and therefore to be rendered as nicely and readably as the chosen viewing device allows. That some parts of the text can be seen as sequences of characters is secondary, and the specific characters and their sequence can change according to the rendering. Ada.Text_IO implements mainly (1), with some basic support for typewriter-style formatting (column spacing, line spacing, page tracking). The "Text" type I am talking about aims to be the internal representation of (2), before rendering on some viewing device. >> I'm thinking of two levels of "Put": >> >> Put (To : in out Text, Item : in String); >> Add items to a Text, building a logically structured Text, >> but without rendering it yet. This wil probably need >> some concept of "points in a Text where more stuff can >> be inserted" so that the Put can preserve or extend the >> logical Text structure. >> >> Put (To : in out File; Item : in Text); >> Render the Text into some external File. >> >> The Text buffer intermediary means that each level of Put can (if >> desired) be dispatching on one of the parameters, without needing >> multiple dispatch. > > This was attempted before, many many times, actually. From PostScript to > HTML, an intermediate language that would take care of separating higher > level formatting from lower level rendering. It never worked how many times > tried. Uh... surely PostScript and HTML "work". I'm pretty sure that a large fraction, perhaps even a majority of programs today generate most of their human-readable output as HTML. Even if the final HTML generation is delegated to some web-application framework. > And for sure, it will be even more hated than Text_IO page formatting is, > because the overhead will be far bigger. Imagine describing the semantics > of, say, conversion of File, Stream, String to Text and backward. Overhead compared to what? If the need is to generate nicely formatted output, rendered in device-specific ways, and typewriter formatting is not enough, what is the alternative? The overheads of Text_IO are important only when processing large text *data* files (meaning (1) of "text"). For generating human-readable text (meaning (2)), especially in an interactive context, the overheads are utterly negligible. I don't see any need for converting a File/Stream *into* Text, unless the File/Stream is a serialized representation of the full internal structure of a Text object, in which case the File/Stream structure is private and normal serialization/deserialization methods apply. I don't intend that the type "Text" should be so fancy and complete that it could be used as such to implement an advanced word processor. Following the same rationale as Ada.Containers, "Text" should provide as much functionality as can be expected to be useful for (and used by) many Ada programs and programmers, but programmers requiring high performance or high/specific functionality would have to implement more advanced "text" representations themselves. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 13:20 ` Niklas Holsti @ 2014-02-19 14:13 ` Dmitry A. Kazakov 2014-02-19 15:37 ` Georg Bauhaus 2014-02-19 21:45 ` Niklas Holsti 2014-02-19 15:06 ` Robert A Duff 1 sibling, 2 replies; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-19 14:13 UTC (permalink / raw) On Wed, 19 Feb 2014 15:20:18 +0200, Niklas Holsti wrote: > On 14-02-19 11:40 , Dmitry A. Kazakov wrote: >> On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote: >> >>> On 14-02-18 11:31 , Dmitry A. Kazakov wrote: >>>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote: >> >>>> To me text buffer, stream, file, string are all instances of the class of >>>> types over which Put dispatches. OK, we can call the abstract root type of >>>> the class "Text." > > My notion of type "Text" is an internal representation of text meant for > human reading and viewing. I don't see any logical need for making this > type a class; there would be only one predefined (and private) type. Class is needed because there must be more than one implementation of the interface and because the interface itself need to be extended in order to have Ada library implementations of reasonable size and complexity. > By the way, perhaps the word "text" is ambiguous. I think it is time to > make a clear distinction between: > > (1) a text file (sometimes called an "ASCI file"), which is a sequence > of basic symbols (e.g. Character or Wide_Character) used to represent > *data* for either reading by another program, or for human reading > (without formatting), and Sequence of symbols is a string. Text is at least a sequence of strings (lines). > (2) a text meant only for human reading/viewing and therefore to be > rendered as nicely and readably as the chosen viewing device allows. > That some parts of the text can be seen as sequences of characters is > secondary, and the specific characters and their sequence can change > according to the rendering. Rendered text is a text so long the reader can reconstruct (1) from (2). So in effect (1) and (2) are equivalent in the sense that both are (1). > Ada.Text_IO implements mainly (1), with some basic support for > typewriter-style formatting (column spacing, line spacing, page tracking). > > The "Text" type I am talking about aims to be the internal > representation of (2), before rendering on some viewing device. Why should anybody care about (2)? Why Text_IO should have anything to do with (1)? One of the issues Text_IO had was inference into text issues (e.g. pages etc). There is nothing wrong with pages except that 80% of formatting and editing does not care about pages. The result is abstraction inversion, and you want to make it only worse. >>> I'm thinking of two levels of "Put": >>> >>> Put (To : in out Text, Item : in String); >>> Add items to a Text, building a logically structured Text, >>> but without rendering it yet. This wil probably need >>> some concept of "points in a Text where more stuff can >>> be inserted" so that the Put can preserve or extend the >>> logical Text structure. >>> >>> Put (To : in out File; Item : in Text); >>> Render the Text into some external File. >>> >>> The Text buffer intermediary means that each level of Put can (if >>> desired) be dispatching on one of the parameters, without needing >>> multiple dispatch. >> >> This was attempted before, many many times, actually. From PostScript to >> HTML, an intermediate language that would take care of separating higher >> level formatting from lower level rendering. It never worked how many times >> tried. > > Uh... surely PostScript and HTML "work". I'm pretty sure that a large > fraction, perhaps even a majority of programs today generate most of > their human-readable output as HTML. Which is why quality of text is so miserable and why the modern OS makes a i486 out of whatever many cores, gigahertz and terabytes monster you run it on. And of course generating HTML or parsing it is no way simpler than traditional formatting in any sense of that. >> And for sure, it will be even more hated than Text_IO page formatting is, >> because the overhead will be far bigger. Imagine describing the semantics >> of, say, conversion of File, Stream, String to Text and backward. > > Overhead compared to what? Compared to direct dispatch to the implementation tailored for the give medium. Why do I need HTML in order to write a stream or memory string? > If the need is to generate nicely formatted > output, rendered in device-specific ways, and typewriter formatting is > not enough, what is the alternative? I don't understand the question. It is not about alternatives, the formatting must be done. It is about decomposition of the task into software components. I don't want any middlemen especially such that in order of magnitude more complex than direct formatting. > The overheads of Text_IO are important only when processing large text > *data* files (meaning (1) of "text"). For generating human-readable text > (meaning (2)), especially in an interactive context, the overheads are > utterly negligible. It is not completely true. Huge amounts of readable texts are processed without any human intervention. For those Text_IO performance is a big problem: Ada project compilation, syntax highlighting, WYSIWYG text processing etc. > I don't see any need for converting a File/Stream *into* Text, unless > the File/Stream is a serialized representation of the full internal > structure of a Text object, in which case the File/Stream structure is > private and normal serialization/deserialization methods apply. But your proposal was: procedure Get (From : in out Text; Value : out Integer); procedure Get (From : in out File_Type; Item : out Text); You must create a text object in order to apply type-specific Get operation on it. When you emulate MD through cascaded dispatch, and this is what you are doing, you need temp objects to carry intermediate states. That will be very expensive for I/O, and extremely complicated because I/O is a stateful thing. You will have a hell of coordinating the states of the file and its text proxy. > I don't intend that the type "Text" should be so fancy and complete that > it could be used as such to implement an advanced word processor. > Following the same rationale as Ada.Containers, "Text" should provide as > much functionality as can be expected to be useful for (and used by) > many Ada programs and programmers, but programmers requiring high > performance or high/specific functionality would have to implement more > advanced "text" representations themselves. And so you need it extensible, ergo, a class. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 14:13 ` Dmitry A. Kazakov @ 2014-02-19 15:37 ` Georg Bauhaus 2014-02-19 16:32 ` Laurent 2014-02-20 2:39 ` Dennis Lee Bieber 2014-02-19 21:45 ` Niklas Holsti 1 sibling, 2 replies; 77+ messages in thread From: Georg Bauhaus @ 2014-02-19 15:37 UTC (permalink / raw) On 19.02.14 15:13, Dmitry A. Kazakov wrote: > Compared to direct dispatch to the implementation tailored for the give > medium. Why do I need HTML in order to write a stream or memory string? The normal use case for HTML is when there are at least two computer systems involved: (1) one sending documents (->), and receiving requests (<-), ███████████████████████████ ███████████████████████████ (2) one receiving documents (<-), and sending requests (->), such that each of them is controlled exclusively by different parties. There is no dispatching, because a common dispatcher is an impossible part of the setup. (IOW, the possibility is only a mathematical one, whenever it refuses to include earthly constraints of the setup.) The media types of CSS will allow an HTML processor to render the same HTML on a number of different devices. Still, no MD. However, once the equivalence class of XSL is taken into account, you get MD, at least conceptually. But it happens outside the "producer" program (1). ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 15:37 ` Georg Bauhaus @ 2014-02-19 16:32 ` Laurent 2014-02-19 17:46 ` Simon Clubley 2014-02-20 2:39 ` Dennis Lee Bieber 1 sibling, 1 reply; 77+ messages in thread From: Laurent @ 2014-02-19 16:32 UTC (permalink / raw) Quite interesting to see that my noob question started such a long discussion. Wouldn't it be better to move it to an own thread or the ada hacker list if such a thing exits? Laurent ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 16:32 ` Laurent @ 2014-02-19 17:46 ` Simon Clubley 0 siblings, 0 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-19 17:46 UTC (permalink / raw) On 2014-02-19, Laurent <daemon2@internet.lu> wrote: > Quite interesting to see that my noob question started such a long discussion. > Wouldn't it be better to move it to an own thread or the ada hacker list if such a thing exits? > I changed the subject line when I asked my question; this is the usual way to handle a digression in a thread. The subject line on your message (which I am replying to) is: Subject: Re: Text_IO, was: Re: Something I don't understand I see you are using Google Groups as your newsreader however so you may not have seen the subject line change. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 15:37 ` Georg Bauhaus 2014-02-19 16:32 ` Laurent @ 2014-02-20 2:39 ` Dennis Lee Bieber 2014-02-20 11:44 ` G.B. 1 sibling, 1 reply; 77+ messages in thread From: Dennis Lee Bieber @ 2014-02-20 2:39 UTC (permalink / raw) On Wed, 19 Feb 2014 16:37:42 +0100, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> declaimed the following: > >The normal use case for HTML is when there are at least >two computer systems involved: > >(1) one sending documents (->), and receiving requests (<-), > ??????????????????????????? ??????????????????????????? >(2) one receiving documents (<-), and sending requests (->), > >such that each of them is controlled exclusively by >different parties. There is no dispatching, because >a common dispatcher is an impossible part of the setup. >(IOW, the possibility is only a mathematical one, whenever >it refuses to include earthly constraints of the setup.) > Uhm... That defines HTTP. >The media types of CSS will allow an HTML processor to render >the same HTML on a number of different devices. Still, no MD. > And I still prefer the original concept of HTML -- being a mark-up language defining /what/ was provided, but the rendering was totally up to the browser. My first graphical browser actually allowed the user to set font specifications for /each/ HTML element (H1 could be rendered in Gothic Blackletter, H2 in an Uncial, H3 in san serif italic, H4 in serif, ...). CSS is an evil trying to turn HTML into a page-layout language... If one really needs that much control over the document -- ship it as a PDF <G> -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 2:39 ` Dennis Lee Bieber @ 2014-02-20 11:44 ` G.B. 0 siblings, 0 replies; 77+ messages in thread From: G.B. @ 2014-02-20 11:44 UTC (permalink / raw) On 20.02.14 03:39, Dennis Lee Bieber wrote: > On Wed, 19 Feb 2014 16:37:42 +0100, Georg Bauhaus > <rm.dash-bauhaus@futureapps.de> declaimed the following: > >> >> The normal use case for HTML is when there are at least >> two computer systems involved: >> >> (1) one sending documents (->), and receiving requests (<-), >> ??????????????????????????? ??????????????????????????? >> (2) one receiving documents (<-), and sending requests (->), >> (...) > Uhm... That defines HTTP. Yes, hypertext, by design, is for being transported. An Ada program will produce a document, and, as part of this normal use case, will send it. Done. Whereas dispatching that involves rendering is not part of the same Ada program. > CSS is an evil trying to turn HTML into a page-layout language... If > one really needs that much control over the document -- ship it as a PDF Real world HTML adapts to the needs of those financing its use. The two most important adaptations are defined by the powers that be: 1. graphics designers, who just cannot work without a fixed 2D canvas. (They turn everything into fliers.) 2. Big Data monetizers (Ads & Co.; The Media), who need Javascript attachments; Javascript functions are triggered by events bound to DOM elements. PDF does not deliver, by comparison. Neither of them is anywhere near the requirements of template based Text I/O, I think. But there might be some financing for the latter. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 14:13 ` Dmitry A. Kazakov 2014-02-19 15:37 ` Georg Bauhaus @ 2014-02-19 21:45 ` Niklas Holsti 2014-02-20 9:52 ` Dmitry A. Kazakov 1 sibling, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-19 21:45 UTC (permalink / raw) On 14-02-19 16:13 , Dmitry A. Kazakov wrote: > On Wed, 19 Feb 2014 15:20:18 +0200, Niklas Holsti wrote: > >> On 14-02-19 11:40 , Dmitry A. Kazakov wrote: >>> On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote: >>> >>>> On 14-02-18 11:31 , Dmitry A. Kazakov wrote: >>>>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote: >>> >>>>> To me text buffer, stream, file, string are all instances of the class of >>>>> types over which Put dispatches. OK, we can call the abstract root type of >>>>> the class "Text." >> >> My notion of type "Text" is an internal representation of text meant for >> human reading and viewing. I don't see any logical need for making this >> type a class; there would be only one predefined (and private) type. > > Class is needed because there must be more than one implementation of the > interface Why? It is not expected that there should be more than one implementation, in the same Ada program, of Ada.Containers.Vectors, for example. The "Text" type I am talking about is kind of a container for structured text ("text" as in meaning (2) below). > and because the interface itself need to be extended in order to > have Ada library implementations of reasonable size and complexity. That does not convince me. Mere volume (e.g. number of operations) is not, to me, a reason for splitting a coherent interface into different packages. >> By the way, perhaps the word "text" is ambiguous. I think it is time to >> make a clear distinction between: >> >> (1) a text file (sometimes called an "ASCI file"), which is a sequence >> of basic symbols (e.g. Character or Wide_Character) used to represent >> *data* for either reading by another program, or for human reading >> (without formatting), and > > Sequence of symbols is a string. > > Text is at least a sequence of strings (lines). True for meaning (1), false for meaning (2) (see below). Text (in meaning (2)) is a sequence of paragraphs (with more structure at both higher and lower levels). Lines only appear after the text (2) is rendered. >> (2) a text meant only for human reading/viewing and therefore to be >> rendered as nicely and readably as the chosen viewing device allows. >> That some parts of the text can be seen as sequences of characters is >> secondary, and the specific characters and their sequence can change >> according to the rendering. > > Rendered text is a text so long the reader can reconstruct (1) from (2). So > in effect (1) and (2) are equivalent in the sense that both are (1). No, text (2) is *not* the result of rendering text (1). Text (2) is logically structured text (probably some kind of tree) that has been deliberately constructed to have structure. There are, of course, forms of text (1), such as HTML or other mark-up languages, which can represent text (2) and which can be interpreted into text (2) which can then be rendered. It is also possible to extract character strings from rendered text (2), discarding the structure -- for example, PDF-to-text conversion. The existence of such interpretations or lossy conversions does not mean that text (1) and text (2) are equivalent. To make it very concrete: under Windows you use Notepad to create text (1), but MS-Word to create text (2). >> Ada.Text_IO implements mainly (1), with some basic support for >> typewriter-style formatting (column spacing, line spacing, page tracking). >> >> The "Text" type I am talking about aims to be the internal >> representation of (2), before rendering on some viewing device. > > Why should anybody care about (2)? Because users want to see nicely formatted output, and I am suggesting that text (2) is a way to implement that in Ada, by separating the logical construction of the text (2) from its rendering. As you say, this is very like the idea of HTML, but HTML has other aims, too (hypertext, web forms, ...) I thought we (that is, you and I, perhaps not the other participants in the thread) were discussing improving the ability to emit nicely formatted, readable text from Ada programs. If not, I'll stop here. > Why Text_IO should have anything to do with (1)? Text (1) can also be processed with Sequential_IO, but usually text (1) is divided into syntactical, meaningful tokens, such as keywords or decimal numbers, and Text_IO provides (rudimentary) facilities for generating such tokens on output, and lexically scanning and evaluating such tokens on input. The situation is the same in other programming languages, which all provide such token-oriented input-output for text (1) files. For example printf/scanf in C. > One of the issues Text_IO had was inference into text issues > (e.g. pages etc). There is nothing wrong with pages except that 80% of > formatting and editing does not care about pages. That is true today, because output to printed paper sheets plays such a small role today. Decades ago, when such output was very common at least in information systems, pagination was quite important. Think Report Generator, page headers/footers, page subtotals, page numbering... Of course it can all be programmed without pagination support in Text_IO, but that is the old argument about do-it-yourself vs. standard libraries or standard language facilities. OMG, this argument is old... Algol 60 left the definition of I/O facilities to the implementation... Algol 68 put standard I/O for text (1) into the language. > The result is abstraction inversion, and you want to make it > only worse. I don't see that at all. >>>> I'm thinking of two levels of "Put": >>>> >>>> Put (To : in out Text, Item : in String); >>>> Add items to a Text, building a logically structured Text, >>>> but without rendering it yet. This wil probably need >>>> some concept of "points in a Text where more stuff can >>>> be inserted" so that the Put can preserve or extend the >>>> logical Text structure. >>>> >>>> Put (To : in out File; Item : in Text); >>>> Render the Text into some external File. >>>> >>>> The Text buffer intermediary means that each level of Put can (if >>>> desired) be dispatching on one of the parameters, without needing >>>> multiple dispatch. >>> >>> This was attempted before, many many times, actually. From PostScript to >>> HTML, an intermediate language that would take care of separating higher >>> level formatting from lower level rendering. It never worked how many times >>> tried. >> >> Uh... surely PostScript and HTML "work". I'm pretty sure that a large >> fraction, perhaps even a majority of programs today generate most of >> their human-readable output as HTML. > > Which is why quality of text is so miserable and why the modern OS makes a > i486 out of whatever many cores, gigahertz and terabytes monster you run it > on. You are changing the issue from "works" to "needs a lot of resources and is misused". So you lose the argument :-) > And of course generating HTML or parsing it is no way simpler than > traditional formatting in any sense of that. What do you mean by "traditional formatting"? I'm not suggesting that the Ada programer would write code to generate HTML. The Ada programmer's code would create a "Text" (i.e. a text (2)), which can be output as HTML, if it is emitted to a device/file/channel which wants HTML. To other devices the same "Text" could be emitted in other forms. A GUI toolkit could use its own text-rendering functions to render the "Text" in a window. >>> And for sure, it will be even more hated than Text_IO page formatting is, >>> because the overhead will be far bigger. Imagine describing the semantics >>> of, say, conversion of File, Stream, String to Text and backward. >> >> Overhead compared to what? > > Compared to direct dispatch to the implementation tailored for the give > medium. Why do I need HTML in order to write a stream or memory string? Stream or memory string are text (1), not text (2). I'm not suggesting that Text_IO should be removed. Of course Ada programs must be able to read and write files of text (1). It may even be desirable to extend the token-level formatting abilities of Text_IO or the Image functions, either by more parameters or by templates or pictures. But my main point is that if our goal is text formatted to modern standards of appearance (with proportional fonts et cetera) then the rendering cannot be made token by token, or Put (item) by Put (item); the renderer must work on a whole text (2). Just as a browser must have a whole HTML <table> in order to display any cell of the table in its final form. >> If the need is to generate nicely formatted >> output, rendered in device-specific ways, and typewriter formatting is >> not enough, what is the alternative? > > I don't understand the question. It is not about alternatives, the > formatting must be done. It is about decomposition of the task into > software components. I don't want any middlemen especially such that in > order of magnitude more complex than direct formatting. Can you give an example of what you mean by "direct formatting"? >> The overheads of Text_IO are important only when processing large text >> *data* files (meaning (1) of "text"). For generating human-readable text >> (meaning (2)), especially in an interactive context, the overheads are >> utterly negligible. > > It is not completely true. Huge amounts of readable texts are processed > without any human intervention. For those Text_IO performance is a big > problem: Ada project compilation, Ada source-code is clearly text (1), text as data, even if it is also human-readable and human-writable. I agree that Text_IO overhead can be significant in text (1) processing, as I said. I believe that GNAT, for example, reads its source files by mapping the whole file into memory, and does not use Text_IO, and not even the OS bulk read() function. (But such tricks are of course system-specific, non-standard.) > syntax highlighting, WYSIWYG text processing etc. If you are talking about interactive applications, at most a screenful of text is shown at a time, therefore Text_IO overheads would be insignificant. But I think that this kind of application would not use Text_IO anyway, because the formatting capabilities of Text_IO would not be sufficient. My proposed "Text", that is text (2), should work better. >> I don't see any need for converting a File/Stream *into* Text, unless >> the File/Stream is a serialized representation of the full internal >> structure of a Text object, in which case the File/Stream structure is >> private and normal serialization/deserialization methods apply. > > But your proposal was: > > procedure Get (From : in out Text; Value : out Integer); > procedure Get (From : in out File_Type; Item : out Text); No, I proposed Put operations, not Get operations. "Text" (that is, text (2)) is meant only for output, not for input. For input, use text (1). Not all output is symmetric with input. Think about an audio device: it is simple to generate audio containing any specified mix and score of pure tones or instrument voices; it would be much more difficult to recover the same score and instrument/voice parameters by digitizing and analysing the generated audio signal. Even more so for the analogous input/output of video. >> I don't intend that the type "Text" should be so fancy and complete that >> it could be used as such to implement an advanced word processor. >> Following the same rationale as Ada.Containers, "Text" should provide as >> much functionality as can be expected to be useful for (and used by) >> many Ada programs and programmers, but programmers requiring high >> performance or high/specific functionality would have to implement more >> advanced "text" representations themselves. > > And so you need it extensible, ergo, a class. Not so, if we accept the same rationale as for Ada.Containers: they are meant for use in applications without extreme or special demands on the performance of the containers. The Ada container types are tagged types, but you cannot create a better-performing or significantly more functional container by deriving from a container type; you can only extend the interface with new operations or override some operations to work differently. Ok, so that leads to ad-hoc polymorphism, which has some draw-backs, as you have explained. But IMO not a show-stopper. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 21:45 ` Niklas Holsti @ 2014-02-20 9:52 ` Dmitry A. Kazakov 2014-02-20 18:19 ` Niklas Holsti 0 siblings, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-20 9:52 UTC (permalink / raw) On Wed, 19 Feb 2014 23:45:47 +0200, Niklas Holsti wrote: > On 14-02-19 16:13 , Dmitry A. Kazakov wrote: >> On Wed, 19 Feb 2014 15:20:18 +0200, Niklas Holsti wrote: >> >>> On 14-02-19 11:40 , Dmitry A. Kazakov wrote: >>>> On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote: >>>> >>>>> On 14-02-18 11:31 , Dmitry A. Kazakov wrote: >>>>>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote: >>>> >>>>>> To me text buffer, stream, file, string are all instances of the class of >>>>>> types over which Put dispatches. OK, we can call the abstract root type of >>>>>> the class "Text." >>> >>> My notion of type "Text" is an internal representation of text meant for >>> human reading and viewing. I don't see any logical need for making this >>> type a class; there would be only one predefined (and private) type. >> >> Class is needed because there must be more than one implementation of the >> interface > > Why? It is not expected that there should be more than one > implementation, in the same Ada program, of Ada.Containers.Vectors, for > example. Ada.Containers.Vectors is generic and suffers same issues as Text_IO. How are you going to handle encoding using single implementation? > The "Text" type I am talking about is kind of a container for structured > text ("text" as in meaning (2) below). What are you going to do when 1. the structure does not match? 2. the content itself varies? >> and because the interface itself need to be extended in order to >> have Ada library implementations of reasonable size and complexity. > > That does not convince me. Mere volume (e.g. number of operations) is > not, to me, a reason for splitting a coherent interface into different > packages. It is not the number but ability to add new unknown to language designers operations. >>> (2) a text meant only for human reading/viewing and therefore to be >>> rendered as nicely and readably as the chosen viewing device allows. >>> That some parts of the text can be seen as sequences of characters is >>> secondary, and the specific characters and their sequence can change >>> according to the rendering. >> >> Rendered text is a text so long the reader can reconstruct (1) from (2). So >> in effect (1) and (2) are equivalent in the sense that both are (1). > > No, text (2) is *not* the result of rendering text (1). Text (2) is > logically structured text (probably some kind of tree) that has been > deliberately constructed to have structure. Whatever. It can have hyperlinks, embedded video and casual games in it. How are you going to pack this into the RM? How do you find a consensus what belong to text and what does not? It is just bad design. > To make it very concrete: under Windows you use Notepad to create text > (1), but MS-Word to create text (2). And I dispatch to Notepad, Word, GPS, and other implementations of text processing and text formats, while it is all text to me. >>> Ada.Text_IO implements mainly (1), with some basic support for >>> typewriter-style formatting (column spacing, line spacing, page tracking). >>> >>> The "Text" type I am talking about aims to be the internal >>> representation of (2), before rendering on some viewing device. >> >> Why should anybody care about (2)? > > Because users want to see nicely formatted output, That alone does not justify the architecture of the text formatting library you propose. It could if you demonstrated that other architectures are unable to produce nicely formatted output. But they are well capable of. But my question was about the internal representations of a certain narrow subclass of texts you propose to be the universal description of all texts Ada should support. >> Why Text_IO should have anything to do with (1)? > > Text (1) can also be processed with Sequential_IO, but usually text (1) > is divided into syntactical, meaningful tokens, such as keywords or > decimal numbers, and Text_IO provides (rudimentary) facilities for > generating such tokens on output, and lexically scanning and evaluating > such tokens on input. That is not a property of text. It is of a container of objects of assorted types. > The situation is the same in other programming languages, which all > provide such token-oriented input-output for text (1) files. For example > printf/scanf in C. Sequential text processing is not what text is. Nobody argues against sequential processing, though there are cases where it is not sequential (e.g. syntax highlighting). But that has little to do with viewing a text as a sequence of lines or pages or paragraphs etc. Furthermore, there is no single preferred view of a text medium. Some application might wish to view it as lines, like compiler do, others might prefer other views. This is why a class is needed to decouple views from formatting actions and the medium. >>>> This was attempted before, many many times, actually. From PostScript to >>>> HTML, an intermediate language that would take care of separating higher >>>> level formatting from lower level rendering. It never worked how many times >>>> tried. >>> >>> Uh... surely PostScript and HTML "work". I'm pretty sure that a large >>> fraction, perhaps even a majority of programs today generate most of >>> their human-readable output as HTML. >> >> Which is why quality of text is so miserable and why the modern OS makes a >> i486 out of whatever many cores, gigahertz and terabytes monster you run it >> on. > > You are changing the issue from "works" to "needs a lot of resources and > is misused". So you lose the argument :-) But we agreed on the point about resources. So what justifies the orgy? Ease of use? HTML is very poor on that. Safety? HTML is a joke regarding it. Maintainability? etc. >> And of course generating HTML or parsing it is no way simpler than >> traditional formatting in any sense of that. > > What do you mean by "traditional formatting"? Without an intermediate layer. How Put (File, "&"); is better than Put (File, '''); ? > I'm not suggesting that the Ada programer would write code to generate > HTML. The Ada programmer's code would create a "Text" (i.e. a text (2)), > which can be output as HTML, if it is emitted to a device/file/channel > which wants HTML. To put it simple, you don't want HTML. But that was the point I made, HTML does not work as a middleman. Yet you want to introduce one of your own hoping it would work better than HTML. It will not. > I'm not suggesting that Text_IO should be removed. Of course Ada > programs must be able to read and write files of text (1). It may even > be desirable to extend the token-level formatting abilities of Text_IO > or the Image functions, either by more parameters or by templates or > pictures. So Text_IO remains a mess, and we add more mess to it. > But my main point is that if our goal is text formatted to modern > standards of appearance (with proportional fonts et cetera) then the > rendering cannot be made token by token, or Put (item) by Put (item); > the renderer must work on a whole text (2). It is not "modern", it is simply bad. Bad standards existed in the past and will appear in the future. It is not Ada's concern, IMO. >>> If the need is to generate nicely formatted >>> output, rendered in device-specific ways, and typewriter formatting is >>> not enough, what is the alternative? >> >> I don't understand the question. It is not about alternatives, the >> formatting must be done. It is about decomposition of the task into >> software components. I don't want any middlemen especially such that in >> order of magnitude more complex than direct formatting. > > Can you give an example of what you mean by "direct formatting"? Without intermediate objects representing items sufficiently larger than the things being processed. I want keep formatting "imperative", if you will. >> syntax highlighting, WYSIWYG text processing etc. > > If you are talking about interactive applications, at most a screenful > of text is shown at a time, therefore Text_IO overheads would be > insignificant. The design you propose, as you are replacing local operations with ones dealing with the text as a whole. > But I think that this kind of application would not use > Text_IO anyway, because the formatting capabilities of Text_IO would not > be sufficient. See? That is because of monolithic design putting imaginary requirements ahead. This is a wrong way. >>> I don't see any need for converting a File/Stream *into* Text, unless >>> the File/Stream is a serialized representation of the full internal >>> structure of a Text object, in which case the File/Stream structure is >>> private and normal serialization/deserialization methods apply. >> >> But your proposal was: >> >> procedure Get (From : in out Text; Value : out Integer); >> procedure Get (From : in out File_Type; Item : out Text); > > No, I proposed Put operations, not Get operations. "Text" (that is, text > (2)) is meant only for output, not for input. For input, use text (1). Only Text_O? No Text_I at all? >>> I don't intend that the type "Text" should be so fancy and complete that >>> it could be used as such to implement an advanced word processor. >>> Following the same rationale as Ada.Containers, "Text" should provide as >>> much functionality as can be expected to be useful for (and used by) >>> many Ada programs and programmers, but programmers requiring high >>> performance or high/specific functionality would have to implement more >>> advanced "text" representations themselves. >> >> And so you need it extensible, ergo, a class. > > Not so, if we accept the same rationale as for Ada.Containers: they are > meant for use in applications without extreme or special demands on the > performance of the containers. Ada container library was wrong design from the start. But that is another story for another day. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 9:52 ` Dmitry A. Kazakov @ 2014-02-20 18:19 ` Niklas Holsti 0 siblings, 0 replies; 77+ messages in thread From: Niklas Holsti @ 2014-02-20 18:19 UTC (permalink / raw) On 14-02-20 11:52 , Dmitry A. Kazakov wrote: > On Wed, 19 Feb 2014 23:45:47 +0200, Niklas Holsti wrote: >>>> I don't see any need for converting a File/Stream *into* Text, unless >>>> the File/Stream is a serialized representation of the full internal >>>> structure of a Text object, in which case the File/Stream structure is >>>> private and normal serialization/deserialization methods apply. Dmitry wrote: >>> But your proposal was: >>> >>> procedure Get (From : in out Text; Value : out Integer); >>> procedure Get (From : in out File_Type; Item : out Text); Niklas wrote: >> No, I proposed Put operations, not Get operations. "Text" (that is, text >> (2)) is meant only for output, not for input. For input, use text (1). > > Only Text_O? No Text_I at all? Exactly. That is, for text in the meaning (2), structured text intended for human viewing. Text data files (sequences of characters) of course need both input and output, as provided today by Text_IO. All your other points just take us further from a common understanding (as usual when I discuss something with you, unfortunately). >>> And so you need it extensible, ergo, a class. >> >> Not so, if we accept the same rationale as for Ada.Containers: they are >> meant for use in applications without extreme or special demands on the >> performance of the containers. > > Ada container library was wrong design from the start. But that is another > story for another day. Yeah, I know you want to start over on Ada. Feel free, I will certainly read your novo-Ada language proposal with interest (seriously, not joking at all). But it needs to have a concrete rationale and motivation, not philosophical abstractions. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 13:20 ` Niklas Holsti 2014-02-19 14:13 ` Dmitry A. Kazakov @ 2014-02-19 15:06 ` Robert A Duff 2014-02-19 17:03 ` Niklas Holsti 1 sibling, 1 reply; 77+ messages in thread From: Robert A Duff @ 2014-02-19 15:06 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > My notion of type "Text" is an internal representation of text meant for > human reading and viewing. I don't see any logical need for making this > type a class; there would be only one predefined (and private) type. How is your notion of Text different from (say) HTML? Or an internal tree-ish representation of HTML? Anyway, I'd say your notion of Text has nothing to do with Text_IO, which is about plain unformatted text. Originally 7-bit ASCII. - Bob ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 15:06 ` Robert A Duff @ 2014-02-19 17:03 ` Niklas Holsti 2014-02-19 22:30 ` Robert A Duff 0 siblings, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-19 17:03 UTC (permalink / raw) On 14-02-19 17:06 , Robert A Duff wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> My notion of type "Text" is an internal representation of text meant for >> human reading and viewing. I don't see any logical need for making this >> type a class; there would be only one predefined (and private) type. > > How is your notion of Text different from (say) HTML? Because "Text" is an internal form with a hidden implementation. > Or an internal tree-ish representation of HTML? More or less. Think "abstract syntax tree" instead of "concrete language sentence". Or "Document Object Model". > Anyway, I'd say your notion of Text has nothing to do with Text_IO, > which is about plain unformatted text. Originally 7-bit ASCII. Yes, Text_IO is about plain unformatted text, except for "typewriter formatting" with column, line, and page controls. The discussion was about how to improve the text (output) facilities of Ada. The abstract "Text" structure is one suggestion. But it should perhaps be called something else, to avoid confusing Ada.Text_IO with Ada.Text.IO :-) Anyway, I'm not suggesting "Text" input, only "Text" output. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 17:03 ` Niklas Holsti @ 2014-02-19 22:30 ` Robert A Duff 0 siblings, 0 replies; 77+ messages in thread From: Robert A Duff @ 2014-02-19 22:30 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > On 14-02-19 17:06 , Robert A Duff wrote: >> Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >> >>> My notion of type "Text" is an internal representation of text meant for >>> human reading and viewing. I don't see any logical need for making this >>> type a class; there would be only one predefined (and private) type. >> >> How is your notion of Text different from (say) HTML? > > Because "Text" is an internal form with a hidden implementation. > >> Or an internal tree-ish representation of HTML? > > More or less. Think "abstract syntax tree" instead of "concrete language > sentence". Or "Document Object Model". So what you're asking for is an Ada binding to HTML (or to Postscript, or something). >> Anyway, I'd say your notion of Text has nothing to do with Text_IO, >> which is about plain unformatted text. Originally 7-bit ASCII. > > Yes, Text_IO is about plain unformatted text, except for "typewriter > formatting" with column, line, and page controls. Right, what I meant is that if your notion of Text were added to Ada, it should not replace Text_IO. There's still a need for simple I/O of simple sequences of characters. What Text_IO SHOULD be about is plain text. I'd get rid of the page-related stuff, and I'd get rid of the line and column counters -- we don't need that level of "formatting". Of course, I'm just criticizing the design. I'm not suggesting that it should be changed now. It should have been changed in 1979. Compatibility rules! > The discussion was about how to improve the text (output) facilities of > Ada. The abstract "Text" structure is one suggestion. But it should > perhaps be called something else, to avoid confusing Ada.Text_IO with > Ada.Text.IO :-) Anyway, I'm not suggesting "Text" input, only "Text" output. Understood. - Bob ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 16:59 ` Niklas Holsti 2014-02-17 17:17 ` Dmitry A. Kazakov @ 2014-02-17 18:13 ` Simon Clubley 2014-02-17 20:09 ` Dmitry A. Kazakov ` (2 more replies) 2014-02-19 21:46 ` Robert A Duff 2 siblings, 3 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-17 18:13 UTC (permalink / raw) On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: > On 14-02-17 14:52 , Simon Clubley wrote: >> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > [snip] >>> A simplified and type-safe version of C's printf style >>> (template-based) formatting would be more readable than >>> concatenating a bunch of strings together to print messages, >>> and MUCH better than using a series of Put calls to print >>> a single message. >>> >> >> _Totally_ agree with this. > > I disagree, but then I don't understand how Robert would make C's > template idea type-safe -- might Robert expand on his ideas? > Oh, I can see a way in which it can be made fully type safe. Assume that support for internal to external conversions is implemented within the type itself as Robert suggests. Furthermore, assume, as I suggested, that you need to pass a format parameter to the type in order for the value to be formatted as required. The Ada version of printf would iterate over the combined format string and pass the fragment of it intended for the formatting of the current variable to the variable type's Internal_To_External support routine. If the passed format fragment was compatible with the data type, the Internal_To_External routine would process the format and return the formatted string back to the Ada version of printf so it can be added into the output buffer. If, OTOH, the format fragment was incompatible with the data type, the Internal_To_External support routine within the type would raise a exception. And voila, C printf templates in a fully Ada type safe manner. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 18:13 ` Simon Clubley @ 2014-02-17 20:09 ` Dmitry A. Kazakov 2014-02-18 7:50 ` Georg Bauhaus 2014-02-17 20:22 ` Niklas Holsti 2014-02-19 21:52 ` Robert A Duff 2 siblings, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-17 20:09 UTC (permalink / raw) On Mon, 17 Feb 2014 18:13:40 +0000 (UTC), Simon Clubley wrote: > On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >> On 14-02-17 14:52 , Simon Clubley wrote: >>> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: >> [snip] >>>> A simplified and type-safe version of C's printf style >>>> (template-based) formatting would be more readable than >>>> concatenating a bunch of strings together to print messages, >>>> and MUCH better than using a series of Put calls to print >>>> a single message. >>>> >>> >>> _Totally_ agree with this. >> >> I disagree, but then I don't understand how Robert would make C's >> template idea type-safe -- might Robert expand on his ideas? > > Oh, I can see a way in which it can be made fully type safe. > > Assume that support for internal to external conversions is implemented > within the type itself as Robert suggests. > > Furthermore, assume, as I suggested, that you need to pass a format > parameter to the type in order for the value to be formatted as required. > > The Ada version of printf would iterate over the combined format string > and pass the fragment of it intended for the formatting of the current > variable to the variable type's Internal_To_External support routine. > > If the passed format fragment was compatible with the data type, the > Internal_To_External routine would process the format and return the > formatted string back to the Ada version of printf so it can be added > into the output buffer. > > If, OTOH, the format fragment was incompatible with the data type, the > Internal_To_External support routine within the type would raise a > exception. Actually it is possible to have it statically type safe with some little compiler support. Not that I like that style of text formatting, I find it extremely boring. Ada's style of independent Put and Get is so much better. Note that even C++ switched to this style, I mean its out<< and in>> operators. Anyway, the method is same as GNAT's Spitbol patterns are treated. Instead of having the format a string, you do it a full-blown type. With terms (built-in literals) defined to format certain types. The full format is composed out of terms using operations like "&". You can make it an aspect if you don't want living objects of the format type, or of a universal type for similar reasons. This has two advantages. Firstly, you require the expression be static and you can check its terms against the types of the values. Secondly the format need not to be parsed at run time. > And voila, C printf templates in a fully Ada type safe manner. Type-safe it is when statically checked. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 20:09 ` Dmitry A. Kazakov @ 2014-02-18 7:50 ` Georg Bauhaus 2014-02-18 8:28 ` Dmitry A. Kazakov 0 siblings, 1 reply; 77+ messages in thread From: Georg Bauhaus @ 2014-02-18 7:50 UTC (permalink / raw) On 17/02/14 21:09, Dmitry A. Kazakov wrote: > Actually it is possible to have it statically type safe with some little > compiler support. What does "little compiler support" mean? > Ada's style of independent Put and Get is so much better. > Note that even C++ switched to this style, I mean its out<< and in>> > operators. C++, however, has automatic template resolution, Ada hasn't. Nor does Ada have anything more fancy than ordinary types, no type parameters of types directly, etc. The Spitbol operators all return Pattern, and they do so for operands of type Pattern, character stuff, or function pointers only. No MD. So, I guess we cannot even have C++-like operator<< etc, without a "little compiler support"? ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-18 7:50 ` Georg Bauhaus @ 2014-02-18 8:28 ` Dmitry A. Kazakov 0 siblings, 0 replies; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-18 8:28 UTC (permalink / raw) On Tue, 18 Feb 2014 08:50:27 +0100, Georg Bauhaus wrote: > On 17/02/14 21:09, Dmitry A. Kazakov wrote: >> Actually it is possible to have it statically type safe with some little >> compiler support. > > What does "little compiler support" mean? Binding (and checking) terms of the format expression against the types of values: Put ( "Index=" & I (Field=>8, Align=>Right) & "X=" & F (10.2), (Index, X) ); Here I, integer format, must match Index, F, real format must match X. >> Ada's style of independent Put and Get is so much better. >> Note that even C++ switched to this style, I mean its out<< and in>> >> operators. > > C++, however, has automatic template resolution, Ada hasn't. > Nor does Ada have anything more fancy than ordinary types, > no type parameters of types directly, etc. You would need ad-hoc tuples for handling lists of assorted values to print, as I used in the example above. Or else you can use aspects which are so messy anyway that whatever harm to Ada's syntax it would do, it is already done: Put (File) with Format => ..., Value1 => ..., ... ValueN => ...; >The Spitbol operators > all return Pattern, and they do so for operands of type Pattern, > character stuff, or function pointers only. No MD. Yes. I prefer a MD solution and no formats at all. > So, I guess we cannot even have C++-like operator<< etc, > without a "little compiler support"? But << operators is an MD solution! I was talking about a formats. Formats is a poor-man's dispatch. Instead of using the type information from the value, the format specifies the type explicitly, e.g. %d, reads among other "integer". That introduces nothing but yet another source of errors. Also when pursued honestly as FORTRAN and PL did it requires a whole mess of means for formatting arrays (remember that horror?) and for a modern OO language records, record extensions etc. Good luck with that. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 18:13 ` Simon Clubley 2014-02-17 20:09 ` Dmitry A. Kazakov @ 2014-02-17 20:22 ` Niklas Holsti 2014-02-18 0:50 ` Simon Clubley 2014-02-19 22:01 ` Robert A Duff 2014-02-19 21:52 ` Robert A Duff 2 siblings, 2 replies; 77+ messages in thread From: Niklas Holsti @ 2014-02-17 20:22 UTC (permalink / raw) On 14-02-17 20:13 , Simon Clubley wrote: > On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >> On 14-02-17 14:52 , Simon Clubley wrote: >>> On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: >> [snip] >>>> A simplified and type-safe version of C's printf style >>>> (template-based) formatting would be more readable than >>>> concatenating a bunch of strings together to print messages, >>>> and MUCH better than using a series of Put calls to print >>>> a single message. >>>> >>> >>> _Totally_ agree with this. >> >> I disagree, but then I don't understand how Robert would make C's >> template idea type-safe -- might Robert expand on his ideas? >> > > Oh, I can see a way in which it can be made fully type safe. > > Assume that support for internal to external conversions is implemented > within the type itself as Robert suggests. Ok. So the type comes with some predefined (perhaps overridable) "Image" function that takes a value of the type and some kind of format specification. > Furthermore, assume, as I suggested, that you need to pass a format > parameter to the type in order for the value to be formatted as required. Ok. > The Ada version of printf would iterate over the combined format string > and pass the fragment of it intended for the formatting of the current > variable to the variable type's Internal_To_External support routine. Ok, but yuck... Why collect all the format "fragments" for all ther variables into one string, which then has to be picked apart again? According to some convoluted and at the same time limited syntax-embedded-in-the-string, such as the C "%" stropping. This invites errors in matching the fragments in the format string with the variables in the variable sequence, just as in current template-based systems e.g. C. You add a variable, but forget to add the format fragment, et cetera. With the current method using string concatenation, the format parameters are automatically associated with the right variable, being parameters in the same Image call. > If the passed format fragment was compatible with the data type, the > Internal_To_External routine would process the format and return the > formatted string back to the Ada version of printf so it can be added > into the output buffer. In other words, effectively the same as the current string concatenation method, but with added formatting parameters to the Image functions. Except that the current method fits in the normal Ada expression syntax and semantics, but your proposal would be something special, requiring a variable-length list of variables to be output, like C varargs. > If, OTOH, the format fragment was incompatible with the data type, the > Internal_To_External support routine within the type would raise a > exception. So this is only *dynamically* type safe, not statically so. Moreover, as C formats already demonstrate, sooner or later one will run out of useful and unique letters and format forms, so a format fragment meant for variable X, of type T, may by mistake be applied to variable Y, of type S -- and will happen to be valid for that type, too, but will not produced the desired result. > And voila, C printf templates in a fully Ada type safe manner. No, dynamic type safety is not fully "Ada type safe". Ada is (mainly) statically type safe; dynamism only enters in subtype safety. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 20:22 ` Niklas Holsti @ 2014-02-18 0:50 ` Simon Clubley 2014-02-18 6:56 ` Niklas Holsti 2014-02-19 22:01 ` Robert A Duff 1 sibling, 1 reply; 77+ messages in thread From: Simon Clubley @ 2014-02-18 0:50 UTC (permalink / raw) On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: > This invites errors in matching the fragments in the format string with > the variables in the variable sequence, just as in current > template-based systems e.g. C. You add a variable, but forget to add the > format fragment, et cetera. With the current method using string > concatenation, the format parameters are automatically associated with > the right variable, being parameters in the same Image call. > That could be caught at compilation time because there would be a mismatch between the format string and the number of variables. > > So this is only *dynamically* type safe, not statically so. Moreover, as > C formats already demonstrate, sooner or later one will run out of > useful and unique letters and format forms, so a format fragment meant > for variable X, of type T, may by mistake be applied to variable Y, of > type S -- and will happen to be valid for that type, too, but will not > produced the desired result. > >> And voila, C printf templates in a fully Ada type safe manner. > > No, dynamic type safety is not fully "Ada type safe". Ada is (mainly) > statically type safe; dynamism only enters in subtype safety. > I see your point, but it's still better than what the C language itself provides and it is guaranteed to catch type mismatches even if it's deferred to runtime. I wonder if it's possible to do something along the lines of gcc which looks at the printf format string during compilation and complains, during compilation, if there's a mismatch detected in data types. I am interested to see what Robert's detailed proposals look like or what any other ideas for printf style template I/O might look like. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-18 0:50 ` Simon Clubley @ 2014-02-18 6:56 ` Niklas Holsti 2014-02-18 8:04 ` Georg Bauhaus 0 siblings, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-18 6:56 UTC (permalink / raw) On 14-02-18 02:50 , Simon Clubley wrote: > On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >> This invites errors in matching the fragments in the format string with >> the variables in the variable sequence, just as in current >> template-based systems e.g. C. You add a variable, but forget to add the >> format fragment, et cetera. With the current method using string >> concatenation, the format parameters are automatically associated with >> the right variable, being parameters in the same Image call. >> > > That could be caught at compilation time because there would be a > mismatch between the format string and the number of variables. Only if the format string is a static constant, which would be rather limiting. > I wonder if it's possible to do something along the lines of gcc > which looks at the printf format string during compilation and > complains, during compilation, if there's a mismatch detected in > data types. Again, that works only when the format string is a constant, which is limiting. Some of that limitation can be worked around in C by using the '*' character in place of a numerical field width or precision, but that would be more yucky again -- some variables in the list would now configure the format string, instead of being output, and one would have to count and match up the format fragments and the variables in the list to find out which is which. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-18 6:56 ` Niklas Holsti @ 2014-02-18 8:04 ` Georg Bauhaus 0 siblings, 0 replies; 77+ messages in thread From: Georg Bauhaus @ 2014-02-18 8:04 UTC (permalink / raw) On 18/02/14 07:56, Niklas Holsti wrote: > Only if the format string is a static constant, which would be rather > limiting. Starting from some frequent use cases, such as - logging and similar technical status reports, - invoices, bank statements and other economic reports static constant formats would cover a lot. I'd think that generics, as Mark H noted, might allow for elaborating minor variations at run-time, at least in some cases. A big plus of templates is that they are instances of Bentley's programming pearls, of proven value. They shift the focus from how the language achieves printing to what is being printed, the latter being what matters. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 20:22 ` Niklas Holsti 2014-02-18 0:50 ` Simon Clubley @ 2014-02-19 22:01 ` Robert A Duff 2014-02-20 8:25 ` Dmitry A. Kazakov 2014-02-20 20:45 ` Niklas Holsti 1 sibling, 2 replies; 77+ messages in thread From: Robert A Duff @ 2014-02-19 22:01 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > No, dynamic type safety is not fully "Ada type safe". Ada is (mainly) > statically type safe; dynamism only enters in subtype safety. Well, if you take the view that "types" are "those things that can be checked statically", then all programming languages are statically type safe, rendering the notion meaningless. Even something like 'bash', which has only one (static) type. In this view, 'bash' does zero static type checking, yet all the type checking it does is static. In other words, the term "subtype" in Ada is a cheat, deliberately used to enable bogus claims about static type safety in Ada, as if the run-time checks associated with subtypes somehow don't count. - Bob ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 22:01 ` Robert A Duff @ 2014-02-20 8:25 ` Dmitry A. Kazakov 2014-02-20 15:54 ` Robert A Duff 2014-02-20 20:45 ` Niklas Holsti 1 sibling, 1 reply; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-20 8:25 UTC (permalink / raw) On Wed, 19 Feb 2014 17:01:45 -0500, Robert A Duff wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> No, dynamic type safety is not fully "Ada type safe". Ada is (mainly) >> statically type safe; dynamism only enters in subtype safety. > > Well, if you take the view that "types" are "those things that can be > checked statically", then all programming languages are statically type > safe, rendering the notion meaningless. Even something like 'bash', > which has only one (static) type. In this view, 'bash' does zero static > type checking, yet all the type checking it does is static. Yes, there is no such thing as a truly untyped language because a type can always be added afterwards. [However I wonder you supporting that kind argument, for second time, actually, after you said (rightfully) that there is written Ada and Reference Manual's Ada.] The question is how much of the language semantics is mapped on the types, explicit or implied no matter. That amount makes Ada strongly typed and bash "untyped." > In other words, the term "subtype" in Ada is a cheat, deliberately used > to enable bogus claims about static type safety in Ada, as if the > run-time checks associated with subtypes somehow don't count. Yes, they do not count. Constraint_Error is not a failed check, it is a contracted behavior. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 8:25 ` Dmitry A. Kazakov @ 2014-02-20 15:54 ` Robert A Duff 2014-02-20 17:54 ` Dmitry A. Kazakov 0 siblings, 1 reply; 77+ messages in thread From: Robert A Duff @ 2014-02-20 15:54 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > Yes, they do not count. Constraint_Error is not a failed check, it is a > contracted behavior. It's usually a bug. And when I see "warning: C_E will be raised..." I am happy for that static check. - Bob ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 15:54 ` Robert A Duff @ 2014-02-20 17:54 ` Dmitry A. Kazakov 0 siblings, 0 replies; 77+ messages in thread From: Dmitry A. Kazakov @ 2014-02-20 17:54 UTC (permalink / raw) On Thu, 20 Feb 2014 10:54:37 -0500, Robert A Duff wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> Yes, they do not count. Constraint_Error is not a failed check, it is a >> contracted behavior. > > It's usually a bug. And when I see "warning: C_E will be raised..." > I am happy for that static check. I am not. A proper check would be: "error: procedure Foo is contracted not to raise C_E, but its declaration region contains a declaration that raises C_E..." -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 22:01 ` Robert A Duff 2014-02-20 8:25 ` Dmitry A. Kazakov @ 2014-02-20 20:45 ` Niklas Holsti 1 sibling, 0 replies; 77+ messages in thread From: Niklas Holsti @ 2014-02-20 20:45 UTC (permalink / raw) On 14-02-20 00:01 , Robert A Duff wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> No, dynamic type safety is not fully "Ada type safe". Ada is (mainly) >> statically type safe; dynamism only enters in subtype safety. > > Well, if you take the view that "types" are "those things that can be > checked statically", then all programming languages are statically type > safe, rendering the notion meaningless. Type safety to me means that code reading a datum interprets the datum's representation correctly, using the same type/representation as the code that wrote the datum. The value read is the value written, not some unpredictable reinterpretation of the bits in memory. This notion has nothing to do with what is statically checked or not checked, and even less with what *can* be checked statically. Type safety could be implemented by dynamically tagging each datum with its type and checking tags at run time. But "Ada type safety" to me means that type safety is checked statically. Perhaps I am being too pedantic and strict about this, but I think I'm not alone in this view. > In other words, the term "subtype" in Ada is a cheat, deliberately used > to enable bogus claims about static type safety in Ada, as if the > run-time checks associated with subtypes somehow don't count. Subtype checking deals with permitted values, not with correct use of the machine representation. I don't see any cheating, it is well understood that such constraints or assertions on values need run-time checks, although more and more of them can also be proved with SPARK or other such tools. Consequently, when I program in Ada, and subprogram Foo signals a Constraint_Error because its parameter X (type Integer) has the value 105, while the subtype of X permits only 1..10, I can be sure that the caller of Foo really provided the parameter value 105 (type Integer). I don't need to worry that the caller provided a Float parameter which Foo tried to interpret as Integer. Simon's proposal for printf-like formatting in Ada is not, IMO, "Ada type safe", because it needs a run-time check to verify that the type of a parameter is correct, and this is because the correct type depends on the *value* of the format string. But I admit that one can take the other view, that the type of the parameter is always correct, and any run-time problems are "subtype" errors in the value of the format string. Clearly, however, Simon's proposal (and any proposal that depends on a potentially dynamic format or template value) reduces the level of static type checking, which IMO is bad. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 18:13 ` Simon Clubley 2014-02-17 20:09 ` Dmitry A. Kazakov 2014-02-17 20:22 ` Niklas Holsti @ 2014-02-19 21:52 ` Robert A Duff 2014-02-20 0:50 ` Simon Clubley 2 siblings, 1 reply; 77+ messages in thread From: Robert A Duff @ 2014-02-19 21:52 UTC (permalink / raw) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: > And voila, C printf templates in a fully Ada type safe manner. Note that C printf templates are type safe (statically!) if you use gcc, and if you always use statically-known templates (which in my experience is true approximately 100% of the time). - Bob ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 21:52 ` Robert A Duff @ 2014-02-20 0:50 ` Simon Clubley 0 siblings, 0 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-20 0:50 UTC (permalink / raw) On 2014-02-19, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: > >> And voila, C printf templates in a fully Ada type safe manner. > > Note that C printf templates are type safe (statically!) if you use > gcc, and if you always use statically-known templates (which in my > experience is true approximately 100% of the time). > Note to self: Next time, don't use the phrase "And voila" as a casual afterthought without actually thinking things through a bit more. :-) Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 16:59 ` Niklas Holsti 2014-02-17 17:17 ` Dmitry A. Kazakov 2014-02-17 18:13 ` Simon Clubley @ 2014-02-19 21:46 ` Robert A Duff 2014-02-20 0:09 ` Jeffrey Carter 2014-02-20 20:02 ` Niklas Holsti 2 siblings, 2 replies; 77+ messages in thread From: Robert A Duff @ 2014-02-19 21:46 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > I disagree, but then I don't understand how Robert would make C's > template idea type-safe -- might Robert expand on his ideas? Most people call me "Bob". Yeah, I know my "From:" line say "Robert". ;-) My answer depends on if (or how much) I'm allowed to change Ada's type system. I've done this in pure standard Ada. Something like: type Template is new String; procedure Put(T: Template; X1, X2, X3, X4, X5, X6, X7, X8: String := ""); Put("There were \1 warnings and \2 errors.\n", Image(Warning_Count), Image(Error_Count)); prints the template as is to standard output, except it replaces \1 with X1, and \2 with X2, and the "\n" is new-line. You can have multi-line templates. "\\" represents "\". Note my use of X1...X8 to simulate C's variable-length parameter lists. This is a kludge. Note that Template is a different type from String. This prevents a bug that can happen in C, where you say printf(blah), and blah is some data read off the internet. That can be a security hole! The user is responsible for writing suitable Image functions for their data types, and they can take whatever formatting parameters you like. This seems much more readable than C's way of encoding the field widths and whatnot in the template. For localization/internationalization, you can have a table mapping "There were \1 warnings and \2 errors.\n" to the corresponding template in (say) French. Different languages have different word orders, so you might have: "... \2 ... \1 ... \n" to reverse the order of insertion. This is all 100% type safe. Most of the checking is static. It checks at run time that the number of \1, \2, \3, ... escapes matches the number of non-empty Xn parameters passed. Now, if you let me change Ada, I'd allow user-defined literals. Any type derived from the Has_Literals interface allows literal syntax, and it overrides the Literal_Value function to convert the sequence of characters to that type. Template would no longer need to be derived from String; it could be a private extension of Has_Literals, and the Literal_Value function could "precompile" the template into some convenient/efficient internal form. The Literal_Value call is evaluated at compile time, so the above-mentioned run-time check can now be static. Change the types of the Xn parameters to Has_Image'Class, so you can pass Warning_Count, and it automatically dispatches to Image(Warning_Count). If you want to use extra formatting options you'd call your own Image function explicitly. Integer types are derived from Has_Image, and the Image function is not an attribute, and (most importantly of all! ;-)) it doesn't insert an annoying extra blank. I'd also allow variable-length argument lists and/or arrays of strings. > I think that the present method of concatenating strings or using > several Puts is good; I think Put (at least to standard output/error) should be task safe. That is, it should be atomic with respect to other tasks doing Put. Puts from different tasks would be interspersed, but you wouldn't get character-by-character interspersal, and you certainly wouldn't get the Ada rule ("erroneous and therefore unpredictable behavior"). That rules out the "series of Puts" method. You need to build up your whole message (possibly multi-line) and then Put it in one fell swoop. The concatenating strings method just looks ugly to me -- I can't easily see what the message is going to look like. With a template, I see the whole message, with marks for where variable data is inserted. >...what is needed is to extend or replace the 'Image > attribute with similar value-to-string functions which are more > controllable, flexible, and work also for composite types. Perhaps > something analogous to the stream attributes, but with the ability to > control the output format at each invocation, which is not possible with > the stream attributes. It is odd that in Ada, 'Image doesn't support the same formatting control as Text_IO. - Bob ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 21:46 ` Robert A Duff @ 2014-02-20 0:09 ` Jeffrey Carter 2014-02-20 1:09 ` Simon Clubley 2014-02-20 20:02 ` Niklas Holsti 1 sibling, 1 reply; 77+ messages in thread From: Jeffrey Carter @ 2014-02-20 0:09 UTC (permalink / raw) On 02/19/2014 02:46 PM, Robert A Duff wrote: > > Put("There were \1 warnings and \2 errors.\n", > Image(Warning_Count), Image(Error_Count)); And then you end up with There were 1 warnings and 1 errors. I suppose you could have Put ("There were \1 \2 and \3 \4.\n", Image (Warning_Count), (if Warning_Count = 1 then "warning" else "warnings"), Image (Error_Count), (if Error_Count = 1 then "error" else "errors") ); but then the Template is essentially unreadable. Put ("There were \1 warning\2 and \3 error\4.\n", Image (Warning_Count), (if Warning_Count = 1 then "" else "s"), Image (Error_Count), (if Error_Count = 1 then "" else "s") ); but then you can't use "" to indicate the end of the strings to include in the output. Any way you approach it is ugly. There should be some way to deal with this that is simpler and easier than what we have. -- Jeff Carter "C's solution to this [variable-sized array parameters] has real problems, and people who are complaining about safety definitely have a point." Dennis Ritchie 25 ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 0:09 ` Jeffrey Carter @ 2014-02-20 1:09 ` Simon Clubley 2014-02-20 7:06 ` Niklas Holsti ` (2 more replies) 0 siblings, 3 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-20 1:09 UTC (permalink / raw) On 2014-02-19, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote: > On 02/19/2014 02:46 PM, Robert A Duff wrote: >> >> Put("There were \1 warnings and \2 errors.\n", >> Image(Warning_Count), Image(Error_Count)); > > And then you end up with > > There were 1 warnings and 1 errors. > > I suppose you could have > > Put ("There were \1 \2 and \3 \4.\n", > Image (Warning_Count), > (if Warning_Count = 1 then "warning" else "warnings"), > Image (Error_Count), > (if Error_Count = 1 then "error" else "errors") ); > > but then the Template is essentially unreadable. > Are you familiar with the VMS $FAO directive (which is the way VMS does template formatting) ? Background material on $FAO is at: http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html The table of formatting directives are at the bottom of that page. Of interest is the directive "!%S" which inserts either "S" or "s" if the most recent numeric value was not one, the directive "!n%C" which inserts a specific string if the previous numeric field value matches the "n" condition and the "!%E" directive which inserts a string if the previous numeric field value did _not_ match a previous "!n%C" test. Something like that would handle this problem rather cleanly. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 1:09 ` Simon Clubley @ 2014-02-20 7:06 ` Niklas Holsti 2014-02-20 13:05 ` Simon Clubley 2014-02-20 11:51 ` G.B. 2014-02-21 11:50 ` Brian Drummond 2 siblings, 1 reply; 77+ messages in thread From: Niklas Holsti @ 2014-02-20 7:06 UTC (permalink / raw) On 14-02-20 03:09 , Simon Clubley wrote: > On 2014-02-19, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote: >> On 02/19/2014 02:46 PM, Robert A Duff wrote: >>> >>> Put("There were \1 warnings and \2 errors.\n", >>> Image(Warning_Count), Image(Error_Count)); >> >> And then you end up with >> >> There were 1 warnings and 1 errors. >> >> I suppose you could have >> >> Put ("There were \1 \2 and \3 \4.\n", >> Image (Warning_Count), >> (if Warning_Count = 1 then "warning" else "warnings"), >> Image (Error_Count), >> (if Error_Count = 1 then "error" else "errors") ); >> >> but then the Template is essentially unreadable. >> > > Are you familiar with the VMS $FAO directive (which is the way VMS does > template formatting) ? > > Background material on $FAO is at: > > http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html > > The table of formatting directives are at the bottom of that page. > > Of interest is the directive "!%S" which inserts either "S" or "s" if > the most recent numeric value was not one, the directive "!n%C" which > inserts a specific string if the previous numeric field value matches > the "n" condition and the "!%E" directive which inserts a string if the > previous numeric field value did _not_ match a previous "!n%C" test. > > Something like that would handle this problem rather cleanly. Cleanly? I would call those directives "line-noise formatting". Trying to embed logical decisions into the template string is yucky. Concatenating conditional string expressions in Ada is a lot cleaner IMO. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 7:06 ` Niklas Holsti @ 2014-02-20 13:05 ` Simon Clubley 0 siblings, 0 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-20 13:05 UTC (permalink / raw) On 2014-02-20, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: > On 14-02-20 03:09 , Simon Clubley wrote: >> >> Are you familiar with the VMS $FAO directive (which is the way VMS does >> template formatting) ? >> >> Background material on $FAO is at: >> >> http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html >> >> The table of formatting directives are at the bottom of that page. >> >> Of interest is the directive "!%S" which inserts either "S" or "s" if >> the most recent numeric value was not one, the directive "!n%C" which >> inserts a specific string if the previous numeric field value matches >> the "n" condition and the "!%E" directive which inserts a string if the >> previous numeric field value did _not_ match a previous "!n%C" test. >> >> Something like that would handle this problem rather cleanly. > > Cleanly? I would call those directives "line-noise formatting". Trying > to embed logical decisions into the template string is yucky. > Actually, when I said "cleanly", I meant the general approach of using conditional formatting directives, not the specific $FAO syntax. > Concatenating conditional string expressions in Ada is a lot cleaner IMO. > That works in some cases, but it doesn't work when you are trying to produce formatted reports with lots of columns with specific widths and formatting required. It also depends on what you are wanting to do with the template capability. Are you wanting to output free-form text with various parameters inserted or are you trying to format a detailed report ? I could see myself using it to do both. What about everyone else here ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 1:09 ` Simon Clubley 2014-02-20 7:06 ` Niklas Holsti @ 2014-02-20 11:51 ` G.B. 2014-02-20 12:53 ` Simon Clubley 2014-02-21 11:50 ` Brian Drummond 2 siblings, 1 reply; 77+ messages in thread From: G.B. @ 2014-02-20 11:51 UTC (permalink / raw) On 20.02.14 02:09, Simon Clubley wrote: > Are you familiar with the VMS $FAO directive (which is the way VMS does > template formatting) ? > > Background material on $FAO is at: > > http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html > [... !%S] > Something like that would handle this problem rather cleanly. Would this address the needs of international language processing? Even English has plural words without 's'; other grammars might need different ways of representing plurals altogether; I understand that doubling a word or syllable or symbol is a scheme for expressing plurals in East Asia, for example. Handling natural language issues is a bit too tricky to be part of a regular programming formalism, I think. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 11:51 ` G.B. @ 2014-02-20 12:53 ` Simon Clubley 0 siblings, 0 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-20 12:53 UTC (permalink / raw) On 2014-02-20, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote: > On 20.02.14 02:09, Simon Clubley wrote: > >> Are you familiar with the VMS $FAO directive (which is the way VMS does >> template formatting) ? >> >> Background material on $FAO is at: >> >> http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html >> [... !%S] >> Something like that would handle this problem rather cleanly. > > Would this address the needs of international language processing? > Even English has plural words without 's'; other grammars might > need different ways of representing plurals altogether; I understand > that doubling a word or syllable or symbol is a scheme for expressing > plurals in East Asia, for example. > That's why VMS Engineering added the option to $FAO which allows a application specified word to be inserted based on the value of the previous number. I'm not saying we should duplicate this exactly. I just mentioned it as a real world example of a template formatting system which has conditional formatting built into it. > Handling natural language issues is a bit too tricky > to be part of a regular programming formalism, I think. > It's certainly not easy. I wonder how something like gettext would handle this problem ? (I've never had to support foreign languages in my code so I don't know the answer to that question.) Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-20 1:09 ` Simon Clubley 2014-02-20 7:06 ` Niklas Holsti 2014-02-20 11:51 ` G.B. @ 2014-02-21 11:50 ` Brian Drummond 2014-02-23 21:37 ` AdaMagica 2 siblings, 1 reply; 77+ messages in thread From: Brian Drummond @ 2014-02-21 11:50 UTC (permalink / raw) On Thu, 20 Feb 2014 01:09:27 +0000, Simon Clubley wrote: > On 2014-02-19, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> > Background material on $FAO is at: > > http://h71000.www7.hp.com/doc/82final/4527/4527pro_047.html > > The table of formatting directives are at the bottom of that page. > > Of interest is the directive "!%S" which inserts either "S" or "s" if > the most recent numeric value was not one, the directive "!n%C" which > inserts a specific string if the previous numeric field value matches > the "n" condition and the "!%E" directive which inserts a string if the > previous numeric field value did _not_ match a previous "!n%C" test. > > Something like that would handle this problem rather cleanly. the best laid plans, of mouses and mans gang aft agley... - Brian ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-21 11:50 ` Brian Drummond @ 2014-02-23 21:37 ` AdaMagica 2014-02-23 23:23 ` Bill Findlay ` (2 more replies) 0 siblings, 3 replies; 77+ messages in thread From: AdaMagica @ 2014-02-23 21:37 UTC (permalink / raw) > the best laid plans, > of mouses and mans > gang aft agley... I don't know Scottish dialect, but I know Robert Burns's lines as ... of mice and men ... which is proper English. Is yours the original? ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-23 21:37 ` AdaMagica @ 2014-02-23 23:23 ` Bill Findlay 2014-02-24 4:29 ` AdaMagica 2014-02-24 12:22 ` Brian Drummond 2 siblings, 0 replies; 77+ messages in thread From: Bill Findlay @ 2014-02-23 23:23 UTC (permalink / raw) On 23/02/2014 21:37, in article 3862580c-e5be-4b8a-8358-07ea61372957@googlegroups.com, "AdaMagica" <christ-usch.grein@t-online.de> wrote: >> the best laid plans, >> of mouses and mans >> gang aft agley... > > I don't know Scottish dialect, but I know Robert Burns's lines as > > ... of mice and men ... > > which is proper English. Is yours the original? Wheech! (That's Scots for whoosh! 8-) -- Bill Findlay with blueyonder.co.uk; use surname & forename; ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-23 21:37 ` AdaMagica 2014-02-23 23:23 ` Bill Findlay @ 2014-02-24 4:29 ` AdaMagica 2014-02-24 12:22 ` Brian Drummond 2 siblings, 0 replies; 77+ messages in thread From: AdaMagica @ 2014-02-24 4:29 UTC (permalink / raw) On Sunday, February 23, 2014 10:37:20 PM UTC+1, AdaMagica wrote: > > the best laid plans, > > of mouses and mans > > gang aft agley... To A Mouse, On Turning Her Up In Her Nest With The Plough http://www.robertburns.org/works/75.shtml ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-23 21:37 ` AdaMagica 2014-02-23 23:23 ` Bill Findlay 2014-02-24 4:29 ` AdaMagica @ 2014-02-24 12:22 ` Brian Drummond 2014-02-24 19:03 ` AdaMagica 2 siblings, 1 reply; 77+ messages in thread From: Brian Drummond @ 2014-02-24 12:22 UTC (permalink / raw) On Sun, 23 Feb 2014 13:37:20 -0800, AdaMagica wrote: >> the best laid plans, >> of mouses and mans gang aft agley... > > I don't know Scottish dialect, but I know Robert Burns's lines as > > ... of mice and men ... > > which is proper English. Is yours the original? eh, no, the context (snipped) was discussing the generation of plural forms as part of text I/O, and so... apologies for any confusion so caused. - Brian ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-24 12:22 ` Brian Drummond @ 2014-02-24 19:03 ` AdaMagica 0 siblings, 0 replies; 77+ messages in thread From: AdaMagica @ 2014-02-24 19:03 UTC (permalink / raw) Ah - I see. Yes, plurals are awkward in all languages. An Ada issue about Physical Units Checking also tried to solve this problem, on an international base. http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00324.txt?rev=1.3 Christoph ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 21:46 ` Robert A Duff 2014-02-20 0:09 ` Jeffrey Carter @ 2014-02-20 20:02 ` Niklas Holsti 1 sibling, 0 replies; 77+ messages in thread From: Niklas Holsti @ 2014-02-20 20:02 UTC (permalink / raw) On 14-02-19 23:46 , Robert A Duff wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> I disagree, but then I don't understand how Robert would make C's >> template idea type-safe -- might Robert expand on his ideas? > > Most people call me "Bob". Yeah, I know my "From:" line say "Robert". ;-) Apologies. I did remember your preference, but only after clicking "Send" :-( > My answer depends on if (or how much) I'm allowed to change Ada's type > system. I've done this in pure standard Ada. Something like: > > type Template is new String; > procedure Put(T: Template; X1, X2, X3, X4, X5, X6, X7, X8: String := ""); > > Put("There were \1 warnings and \2 errors.\n", > Image(Warning_Count), Image(Error_Count)); > > prints the template as is to standard output, except it replaces \1 with > X1, and \2 with X2, and the "\n" is new-line. You can have multi-line > templates. "\\" represents "\". > > Note my use of X1...X8 to simulate C's variable-length parameter > lists. This is a kludge. That is where I think this breaks down for current Ada. To really add this to Ada, you need variable-length parameter lists, or the ability to aggregate strings of various lengths into a vector of strings. > Note that Template is a different type from String. This prevents > a bug that can happen in C, where you say printf(blah), and blah > is some data read off the internet. That can be a security hole! But Template objects can still be variable, so they can still be constructed at run-time from external data (say, some application configuration file). Or do you intend to define Template as a type that forbids variable objects and allows only static constants? But even with variable Templates, this is clearly less risky than the case in C, where AIUI the risk comes from malicious type breaking where the format conversion character misuses the corresponding parameter. That cannot happen in your proposal because all parameters are Strings and there are no format conversion characters in the Template. > The user is responsible for writing suitable Image functions > for their data types, and they can take whatever formatting > parameters you like. This seems much more readable than C's > way of encoding the field widths and whatnot in the template. Yes indeed, I agree fully with that. > For localization/internationalization, you can have a table > mapping "There were \1 warnings and \2 errors.\n" to the > corresponding template in (say) French. Different languages > have different word orders, so you might have: > > "... \2 ... \1 ... \n" > > to reverse the order of insertion. So here the templates would be run-time variable, according to the locale, and not compile-time constants? I have little experience of multi-language output, but I have not been impressed by the tools and methods I've seen. I think it is another problem and won't be solved by such simple template-based tricks. > This is all 100% type safe. Most of the checking is static. > It checks at run time that the number of \1, \2, \3, ... escapes > matches the number of non-empty Xn parameters passed. Why should only non-empty Xn be counted? I think it must be permitted for some Xn to be empty, without this meaning "end of the Xn list", but just making the corresponding escape produce an empty output string. But ok, this is a consequence of the kludge with a fixed number of Xn parameters in the profile. > Now, if you let me change Ada, Apart from the type-safe variable-length parameter lists, you mean? ;-) > I'd allow user-defined literals. > Any type derived from the Has_Literals interface allows > literal syntax, and it overrides the Literal_Value function > to convert the sequence of characters to that type. Not a bad idea. Would only string literals qualify, not character or numeric ones? To avoid ambiguities, this should be forbidden for any type that already allows string literals, right? But this is beginning to look a bit like C++ parametrized constructors, called implicitly... slippery slope? > Template would no longer need to be derived from String; it > could be a private extension of Has_Literals, and the Literal_Value > function could "precompile" the template into some convenient/efficient > internal form. > > The Literal_Value call is evaluated at compile time, so the > above-mentioned run-time check can now be static. If the Template is defined by a literal, yes. But I assume Templates could still be variable objects, too, forcing a run-time check. > Change the types of the Xn parameters to Has_Image'Class, > so you can pass Warning_Count, and it automatically dispatches > to Image(Warning_Count). If you want to use extra formatting > options you'd call your own Image function explicitly. But then you get a parameter list which mixes Has_Image'Class and Strings from Image functions. Or do you mean that String is in Has_Image'Class, with an Image function that is the identity function? That would work... sneaky! > Integer types are derived from Has_Image, and the Image function > is not an attribute, and (most importantly of all! ;-)) > it doesn't insert an annoying extra blank. I second that change to the Image function. That is, omit the extra blank. > I'd also allow variable-length argument lists and/or arrays of strings. Do you mean polymorphic variable-length parameter lists? Or only lists that are declared as monomorphic using some 'Class, such as Has_Image'Class? >> I think that the present method of concatenating strings or using >> several Puts is good; > > I think Put (at least to standard output/error) should be task safe. > That is, it should be atomic with respect to other tasks doing Put. > Puts from different tasks would be interspersed, but you wouldn't > get character-by-character interspersal, and you certainly wouldn't > get the Ada rule ("erroneous and therefore unpredictable behavior"). Hmm yes. I don't know the history behind the non-task-safe choice. Perhaps there was a fear of unnecessary distributed overhead for non-tasking programs on operating systems where the OS I/O system is not task safe. > That rules out the "series of Puts" method. You need to build up > your whole message (possibly multi-line) and then Put it in one > fell swoop. Yes, certainly, if you have multiple tasks which output to the same device. > The concatenating strings method just looks ugly to me -- I can't easily > see what the message is going to look like. With a template, I see > the whole message, with marks for where variable data is inserted. I can understand this feeling, but the template method has its own ugliness -- the need for escapes and the need to count and match up escapes with parameters to understand what text will replace each escape. > It is odd that in Ada, 'Image doesn't support the same formatting > control as Text_IO. Yes indeed. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-17 12:52 ` Simon Clubley 2014-02-17 15:32 ` G.B. 2014-02-17 16:59 ` Niklas Holsti @ 2014-02-19 21:15 ` Robert A Duff 2014-02-19 22:01 ` Simon Clubley 2 siblings, 1 reply; 77+ messages in thread From: Robert A Duff @ 2014-02-19 21:15 UTC (permalink / raw) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: > On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: >> Input should be separate from output. Put(Stream, X), where X is an >> integer makes sense, because we know X is an integer. Get(X) >> makes no sense, because we have no idea what the user is going >> to type. For text input, you need "read the next token, and tell >> me what it is", not "read an integer token, and blow up if the >> user typed something else". > > While the current input routines need replacing, I don't agree with the > Ada RTL trying to work out what the input format is and pass a token > type back to the program. The problem is that unless you are careful, > you can end up with a Excel type solution in which it works most of > the time but fails when it thinks it knows better than you do what > you entered. Right, it's not at all clear that this should be part of the language. But my "read the next token, and tell me what it is" method is how it should normally be done, and if the language doesn't support it, then the programmer will do that, which is fine. But the "read an integer token, and blow up if the user typed something else" method is rarely useful. I'd stick with "read a character", "read a line", and "read the whole file". > For example, consider the input "123,456". > > Is the user entering a array of two numbers ? > > Is the user entering one number but with a thousands seperator ? > > Is the user in mainland Europe and hence is really entering "123.456" ? > > Should this input be treated as a string (because it has a comma in it) > or should the Ada RTL impose it's idea of a number and convert the > input into some standard format even though that may not look anything > like what the user meant ? All good questions, that are perhaps best left up to the programmer. > What happens when the final destination is a range limited data type ? All integer types in Ada are range-limited. I'd prefer to allow unbounded integers. > You either have to still do the checking manually or take a exception > if the input value is outside of the range of the data type. > >> A simplified and type-safe version of C's printf style >> (template-based) formatting would be more readable than >> concatenating a bunch of strings together to print messages, >> and MUCH better than using a series of Put calls to print >> a single message. >> > > _Totally_ agree with this. It would also be nice if one could write > something like this (pseudo Fortran style to get the idea across): > "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth > (in this example) of data cleanly. That's not really what I meant by "simplified". ;-) >> There should be a convenient way to read an entire file into >> a String. Similar for writing. > > Yes, but you may need two methods. One for binary (unchanged) input and > one for text input with end of line conversions. Maybe. Should the binary one return a String, or an array of bytes, or something else? - Bob ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Text_IO, was: Re: Something I don't understand 2014-02-19 21:15 ` Robert A Duff @ 2014-02-19 22:01 ` Simon Clubley 0 siblings, 0 replies; 77+ messages in thread From: Simon Clubley @ 2014-02-19 22:01 UTC (permalink / raw) On 2014-02-19, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: >> >> _Totally_ agree with this. It would also be nice if one could write >> something like this (pseudo Fortran style to get the idea across): >> "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth >> (in this example) of data cleanly. > > That's not really what I meant by "simplified". ;-) > :-) >> >> Yes, but you may need two methods. One for binary (unchanged) input and >> one for text input with end of line conversions. > > Maybe. Should the binary one return a String, or an array of bytes, > or something else? > Conceptually, I would have to say an array of bytes data type distinct from a String. This is based on my perception of a String as been associated with text data (after all, it _is_ called a String :-)) and that conceptually you cannot really assign such meaning to something you have gone to the trouble to read as binary data. What really matters is that you can guarantee the binary data will not be altered during the I/O process, that you know the exact length of the data, and that you can cleanly access the bytes in the binary data. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-16 1:39 ` Robert A Duff 2014-02-16 9:08 ` Text_IO, was: " Simon Clubley @ 2014-02-16 14:50 ` Mike H 2014-02-17 16:09 ` Laurent 2 siblings, 0 replies; 77+ messages in thread From: Mike H @ 2014-02-16 14:50 UTC (permalink / raw) In message <wcc1tz3al9l.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes >Laurent <daemon2@internet.lu> writes: > >Some stylistic comments on the code below: > In my experience, most Ada shops have in-house coding standards. The last place I worked (contracting) placed great emphasis on the connection between meaningful names and commenting style. Peer review was part of the signing off process so writing self documenting code became a matter of habit. -- Mike Swim? Naturally at Severn Vale <http://www.severnvalesc.org/> ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-16 1:39 ` Robert A Duff 2014-02-16 9:08 ` Text_IO, was: " Simon Clubley 2014-02-16 14:50 ` Mike H @ 2014-02-17 16:09 ` Laurent 2014-02-17 17:42 ` Mike H 2014-02-17 22:31 ` Jeffrey Carter 2 siblings, 2 replies; 77+ messages in thread From: Laurent @ 2014-02-17 16:09 UTC (permalink / raw) Am Sonntag, 16. Februar 2014 02:39:34 UTC+1 schrieb Robert A Duff: > Some stylistic comments on the code below: > Exceptions are for dealing with cases where one piece of code detects > a (possible) error, and another piece of code decides whether it > case here, so should be written without any exceptions. As I wrote in my first post the whole thing is an exercise from a book. I'm learning programming mostly by myself and it is just an hobby. The actual chapter is about ADTs and most of them which are part of the exercise I'm doing were written by the author of this book. So I think it was/is best to stick to the way the author named his variables or build his programs. > No need for a loop name. Not needed yes, but they won't hurt anyone. In this package is not only this loop but a few others. So I put named loops instead of comments. > You should use typical style, so other Ada programmers can read your > code more easily: lower case keywords, Max_Name instead of MaxName. > (Or Max_Name_Length?) Dito first answer > S should declared "constant". You should enable warnings in GNAT > that detect this mistake. MaxName : CONSTANT Positive := 30; -- defined in other package SUBTYPE NameType IS String (1 .. MaxName); -- defined in other package It is, unfortunately with the original version of the code GNAT didn't complain about Name >MaxName. > Why should there be a limit on the length of the name? Maybe you have > a good reason, but usually such arbitrary limits are a bad idea. Book Author's choice Thanks for the advice but in this case I think I will stick to the formatting given in the book.Still have the possibility to adapt it later. Laurent ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-17 16:09 ` Laurent @ 2014-02-17 17:42 ` Mike H 2014-02-18 1:05 ` Dennis Lee Bieber 2014-02-17 22:31 ` Jeffrey Carter 1 sibling, 1 reply; 77+ messages in thread From: Mike H @ 2014-02-17 17:42 UTC (permalink / raw) In message <48278bd6-740c-40aa-b098-e20fe84fe911@googlegroups.com>, Laurent <daemon2@internet.lu> writes >> No need for a loop name. > >Not needed yes, but they won't hurt anyone. In this package is not only >this loop but a few others. >So I put named loops instead of comments. > It is all a matter of style. Personally, on seeing a named loop I would take it as a warning that something nasty may be intended. Such as jumping out of an inner loop and thus risking leaving some unfinished business behind. -- Who is General Failure and why is he reading my hard disc? Mike ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-17 17:42 ` Mike H @ 2014-02-18 1:05 ` Dennis Lee Bieber 0 siblings, 0 replies; 77+ messages in thread From: Dennis Lee Bieber @ 2014-02-18 1:05 UTC (permalink / raw) On Mon, 17 Feb 2014 17:42:39 +0000, Mike H <postmaster@ada-augusta.demon.co.uk> declaimed the following: >In message <48278bd6-740c-40aa-b098-e20fe84fe911@googlegroups.com>, >Laurent <daemon2@internet.lu> writes >>> No need for a loop name. >> >>Not needed yes, but they won't hurt anyone. In this package is not only >>this loop but a few others. >>So I put named loops instead of comments. >> >It is all a matter of style. > >Personally, on seeing a named loop I would take it as a warning that >something nasty may be intended. Such as jumping out of an inner loop >and thus risking leaving some unfinished business behind. Along with the minor overhead of the compiler having to keep the label and address in some internal table until it falls out of scope... <G> -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-17 16:09 ` Laurent 2014-02-17 17:42 ` Mike H @ 2014-02-17 22:31 ` Jeffrey Carter 2014-02-19 12:51 ` Laurent 1 sibling, 1 reply; 77+ messages in thread From: Jeffrey Carter @ 2014-02-17 22:31 UTC (permalink / raw) On 02/17/2014 09:09 AM, Laurent wrote: > > As I wrote in my first post the whole thing is an exercise from a book. I'm > learning programming mostly by myself and it is just an hobby. > > So I think it was/is best to stick to the way the author named his variables > or build his programs. > > Book Author's choice > > Thanks for the advice but in this case I think I will stick to the formatting > given in the book.Still have the possibility to adapt it later. What book/author? -- Jeff Carter "I'm off to Alaska. If you need me, I'll be at Frozen Tundra 6-9290." Play It Again, Sam 130 ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Something I don't understand 2014-02-17 22:31 ` Jeffrey Carter @ 2014-02-19 12:51 ` Laurent 0 siblings, 0 replies; 77+ messages in thread From: Laurent @ 2014-02-19 12:51 UTC (permalink / raw) > > What book/author? > > Jeff Carter Ada 95:Problem Solving and Program Design by Michael B. Feldman, Elliot B. Koffman 3rd Edition (1999) Not very recent lecture but I like the way how problems are described and solved. Also the reason why I chose Ada and not Java. Visited an evening course for Java (+/- 30hrs). Found that the documentation used was unstructured/ confuse, missing clear examples and exercises. Thanks Laurent ^ permalink raw reply [flat|nested] 77+ messages in thread
end of thread, other threads:[~2014-02-24 19:03 UTC | newest] Thread overview: 77+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-13 23:57 Something I don't understand Laurent 2014-02-14 0:18 ` adambeneschan 2014-02-14 7:05 ` Charles H. Sampson 2014-02-15 15:27 ` Laurent 2014-02-15 19:10 ` Laurent 2014-02-15 20:05 ` Niklas Holsti 2014-02-15 21:16 ` Laurent 2014-02-15 21:40 ` Jeffrey Carter 2014-02-16 1:39 ` Robert A Duff 2014-02-16 9:08 ` Text_IO, was: " Simon Clubley 2014-02-16 9:43 ` Dmitry A. Kazakov 2014-02-16 16:57 ` Dennis Lee Bieber 2014-02-16 16:17 ` Robert A Duff 2014-02-17 12:52 ` Simon Clubley 2014-02-17 15:32 ` G.B. 2014-02-17 15:35 ` G.B. 2014-02-17 17:34 ` Mike H 2014-02-17 16:59 ` Niklas Holsti 2014-02-17 17:17 ` Dmitry A. Kazakov 2014-02-17 17:42 ` Niklas Holsti 2014-02-17 19:55 ` Dmitry A. Kazakov 2014-02-18 7:14 ` Niklas Holsti 2014-02-18 8:40 ` Dmitry A. Kazakov 2014-02-18 9:00 ` Niklas Holsti 2014-02-18 9:31 ` Dmitry A. Kazakov 2014-02-19 8:36 ` Niklas Holsti 2014-02-19 9:40 ` Dmitry A. Kazakov 2014-02-19 13:20 ` Niklas Holsti 2014-02-19 14:13 ` Dmitry A. Kazakov 2014-02-19 15:37 ` Georg Bauhaus 2014-02-19 16:32 ` Laurent 2014-02-19 17:46 ` Simon Clubley 2014-02-20 2:39 ` Dennis Lee Bieber 2014-02-20 11:44 ` G.B. 2014-02-19 21:45 ` Niklas Holsti 2014-02-20 9:52 ` Dmitry A. Kazakov 2014-02-20 18:19 ` Niklas Holsti 2014-02-19 15:06 ` Robert A Duff 2014-02-19 17:03 ` Niklas Holsti 2014-02-19 22:30 ` Robert A Duff 2014-02-17 18:13 ` Simon Clubley 2014-02-17 20:09 ` Dmitry A. Kazakov 2014-02-18 7:50 ` Georg Bauhaus 2014-02-18 8:28 ` Dmitry A. Kazakov 2014-02-17 20:22 ` Niklas Holsti 2014-02-18 0:50 ` Simon Clubley 2014-02-18 6:56 ` Niklas Holsti 2014-02-18 8:04 ` Georg Bauhaus 2014-02-19 22:01 ` Robert A Duff 2014-02-20 8:25 ` Dmitry A. Kazakov 2014-02-20 15:54 ` Robert A Duff 2014-02-20 17:54 ` Dmitry A. Kazakov 2014-02-20 20:45 ` Niklas Holsti 2014-02-19 21:52 ` Robert A Duff 2014-02-20 0:50 ` Simon Clubley 2014-02-19 21:46 ` Robert A Duff 2014-02-20 0:09 ` Jeffrey Carter 2014-02-20 1:09 ` Simon Clubley 2014-02-20 7:06 ` Niklas Holsti 2014-02-20 13:05 ` Simon Clubley 2014-02-20 11:51 ` G.B. 2014-02-20 12:53 ` Simon Clubley 2014-02-21 11:50 ` Brian Drummond 2014-02-23 21:37 ` AdaMagica 2014-02-23 23:23 ` Bill Findlay 2014-02-24 4:29 ` AdaMagica 2014-02-24 12:22 ` Brian Drummond 2014-02-24 19:03 ` AdaMagica 2014-02-20 20:02 ` Niklas Holsti 2014-02-19 21:15 ` Robert A Duff 2014-02-19 22:01 ` Simon Clubley 2014-02-16 14:50 ` Mike H 2014-02-17 16:09 ` Laurent 2014-02-17 17:42 ` Mike H 2014-02-18 1:05 ` Dennis Lee Bieber 2014-02-17 22:31 ` Jeffrey Carter 2014-02-19 12:51 ` Laurent
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox