CVS difference for acs/ac-00137.txt

Differences between 1.1 and version 1.2
Log of other versions for file acs/ac-00137.txt

--- acs/ac-00137.txt	2006/11/14 00:47:04	1.1
+++ acs/ac-00137.txt	2006/11/14 01:16:45	1.2
@@ -381,3 +381,180 @@
 
 ****************************************************************
 
+From: Christoph Grein
+Date: Wednesday, November  8, 2006  2:15 AM
+
+> The "positional-before-named rule" was a bad idea from the start.
+
+I disagree. How should an expression like F(A, P => Q, B, X => Y) be
+interpreted? We would have to add still new rules with questionable use.
+
+> But how can we relax it now, without compatibility concerns?
+
+I also see the problem with generics and once suffered from it. But: Is
+this inconvenience really worth a language change?
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Wednesday, November  8, 2006  3:21 PM
+
+> I disagree. How should an expression like F(A, P => Q, B, X => Y) be
+> interpreted? We would have to add still new rules with questionable use.
+
+Not new rules -- different rules.  If I ran the circus, overload resolution
+would ignore the parameter names.  The above would be resolved as for
+F(A, Q, B, Y).  Then, after overload resolution, a legality rule would
+require that the name of the second parameter be P, and the fourth X.
+
+Defaulted parameters should be equivalent to expanding out all the overloaded
+versions without defaults.  Thus:
+
+    procedure P (X : T1 := 1; Y : T2; Z : T3 := 3);
+
+would be equivalent to:
+
+    procedure P (X : T1; Y : T2; Z : T3);
+    procedure P (X : T1; Y : T2);
+    procedure P (Y : T2; Z : T3);
+    procedure P (Y : T2);
+
+This would make it useful to have defaulted parameters before non-defaulted
+ones.  For example, consider Text_IO.Put_Line.  Conceptually, we want it to
+take two arguments, a file and a string, with the file defaulting to "standard
+output".  You can't do that in Ada, which means you have to have two
+Put_Line's, which is a kludge.
+
+As I said, this would be incompatible, and therefore out of the question for
+Ada.
+
+> > But how can we relax it now, without compatibility concerns?
+>
+> I also see the problem with generics and once suffered from it. But: Is
+> this inconvenience really worth a language change?
+
+No.
+
+****************************************************************
+
+From: Jeffrey Carter
+Date: Wednesday, November  8, 2006  5:59 PM
+
+> This would make it useful to have defaulted parameters before non-defaulted
+> ones.  For example, consider Text_IO.Put_Line.  Conceptually, we want it to
+> take two arguments, a file and a string, with the file defaulting to "standard
+> output".  You can't do that in Ada, which means you have to have two
+> Put_Line's, which is a kludge.
+
+Actually, it defaults to Current_Output, which defaults to Standard_Output.
+
+The only problem here is the insistence that the file parameter has to
+come 1st. There's no reason it couldn't have been
+
+procedure Put_Line
+    (Item : in String; File : in File_Handle := Current_Output);
+
+You could still write calls identical to what is done now:
+
+Put_Line (Item => "Hello");
+Put_Line (File => Fred, Item => "World");
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Wednesday, November  8, 2006  7:19 PM
+
+> > This would make it useful to have defaulted parameters before non-defaulted
+> > ones.  For example, consider Text_IO.Put_Line.  Conceptually, we want it to
+> > take two arguments, a file and a string, with the file defaulting to "standard
+> > output".  You can't do that in Ada, which means you have to have two
+> > Put_Line's, which is a kludge.
+>
+> Actually, it defaults to Current_Output, which defaults to Standard_Output.
+
+Ah, yes, I had forgotten about the Current_Output silliness.  ;-)
+
+> The only problem here is the insistence that the file parameter has to come
+> 1st. There's no reason it couldn't have been
+>
+> procedure Put_Line
+>     (Item : in String; File : in File_Handle := Current_Output);
+
+I find it very natural that the File come first.  Maybe it's just what I'm used
+to.
+
+> You could still write calls identical to what is done now:
+>
+> Put_Line (Item => "Hello");
+> Put_Line (File => Fred, Item => "World");
+
+I want to write:
+
+    Put_Line(Out_File, "Hello");
+
+Named notation is for readability.  A vague name like "Item" doesn't add
+readability; it should be left out at the call site.  And named notation is NOT
+for people who are too lazy to look up the declared order.  If I ran the
+circus, the order of actuals would be required to be the same as that of the
+formals.
+
+I would certainly find it confusing to declare Put_Line with the File second,
+and then call it with the File first.
+
+****************************************************************
+
+From: Jeffrey Carter
+Date: Wednesday, November  8, 2006  10:43 PM
+
+> I find it very natural that the File come first.  Maybe it's just what
+> I'm used to.
+
+The C library (fgets, fputc, fputs) has the file last. Coming from
+Pascal, though, I was used to it 1st, too.
+
+> Named notation is for readability.  A vague name like "Item" doesn't add
+> readability; it should be left out at the call site.  And named notation is NOT
+> for people who are too lazy to look up the declared order.  If I ran the
+> circus, the order of actuals would be required to be the same as that of the
+> formals.
+
+And when I'm king, procedure calls will have to use named notation, so
+there will some additional pressure to use meaningful parameter names.
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Thursday, November  9, 2006  2:04 AM
+
+> And named notation is NOT for people who are too lazy
+> to look up the declared order.  If I ran the circus, the
+> order of actuals would be required to be the same as that of
+> the formals.
+
+This is turning into a discussion of the Duff language, not of Ada, so
+maybe it should be posted on Duff-Comment ;-)
+
+Named notation is for maintenance.  Occasionally, I find myself changing
+the order of parameters during maintenance, not because of some rule of
+the language, but because I discover that the parameters are not in their
+"natural" order.  Since I used named notation pretty systematically, the
+existing call sites don't have to be modified.  OK, they may not be ideal,
+but I am not going to edit them all.  (I work on a fairly large project.)
+New calls can be written using the preferable order, and over time
+existing calls may be changed, too.
+
+When this situation arises, I am happy that I use Ada and not the Duff
+language...
+
+****************************************************************
+
+From: Jeff Cousins
+Date: Monday, November 13, 2006  9:43 AM
+
+> The C library (fgets, fputc, fputs) has the file last. Coming from
+Pascal, though, I
+> was used to it 1st, too.
+The C library's fprintf has the file first, so C isn't consistent.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent