CVS difference for ai12s/ai12-0212-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0212-1.txt

--- ai12s/ai12-0212-1.txt	2017/06/13 02:55:19	1.4
+++ ai12s/ai12-0212-1.txt	2017/08/08 03:32:37	1.5
@@ -554,3 +554,257 @@
 arbitrary order.)
 
 ****************************************************************
+
+From: Florian Schanda
+Sent: Tuesday, June 13, 2017  1:43 AM
+
+> I don't much like the name "unary_display": I'm reading a "display", 
+> my compiler uses "displays" to implement up-level access to local 
+> variables, and I really don't see any point in introducing yet another use
+> of the term.
+> We're talking about container aggregates, why not call them that??
+
+I think calling display container aggregate would be fine. But we should stick
+with the term "comprehension" for the, well, comprehensions.
+
+> Re: "in order". Components in an Ada aggregate generally are evaluated 
+> in an arbitrary order. I think we need to have a really good reason to 
+> go away from that. So either you need to explain why the unusual rules 
+> or adjust this to be in an arbitrary order. (Note that the new "for" 
+> construct executes in an arbitrary order.)
+
+We soon have precedence for this: the delta aggregates are also evaluated LTR. 
+Plus, if you think about it; an aggregate for a list where the elements are
+added in arbitrary order would be a bit counter-intuitive.
+
+Or maybe I am missing a finer point here, and you mean we evaluate in
+arbitrary order, but still add LTR?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 13, 2017  1:06 PM
+
+> > I don't much like the name "unary_display": I'm reading a "display", 
+> > my compiler uses "displays" to implement up-level access to local 
+> > variables, and I really don't see any point in introducing
+> yet another use of the term.
+> > We're talking about container aggregates, why not call them that??
+> 
+> I think calling display container aggregate would be fine. 
+> But we should stick with the term "comprehension" for the, well, 
+> comprehensions.
+
+WTF is a "comprehension"? I'd rather not stuff more obscure terminology into
+Ada that is mostly going to get in the way of getting the job done.
+
+> > Re: "in order". Components in an Ada aggregate generally are 
+> > evaluated in an arbitrary order. I think we need to have a really 
+> > good reason to go away from that. So either you need to explain why 
+> > the unusual rules or adjust this to be in an arbitrary order. (Note that
+> > the new "for" construct executes in an arbitrary order.)
+> 
+> We soon have precedence for this: the delta aggregates are also 
+> evaluated LTR. 
+> Plus, if you think about it; an aggregate for a list where the 
+> elements are added in arbitrary order would be a bit 
+> counter-intuitive.
+> 
+> Or maybe I am missing a finer point here, and you mean we evaluate in 
+> arbitrary order, but still add LTR?
+
+Well, I was actually thinking about maps, in which the order of insertion
+should be irrelevant.
+
+But you're right in that a list or vector aggregate is closest to an array
+aggregate, and for that the order matters (if it is positional). But even
+there, the order of evaluation is unspecified.
+
+For maps/sets, the order of insertiong should be irrelevant. Same with a
+named vector (do you have that? You ought to).
+
+I didn't see what you proposed for a map, but IMHO I think it ought to look
+something like:
+
+   ("Tuck" => US, "Jeff" => UK, "Tuillo" => Italy, ...)
+
+One easily can imagine a vector that works similarly, using the indexes:
+
+   (1 => "Tuck", 2 => "Jeff", 3 => "Randy", 4 => "Florian", ...)
+
+After all, Ada programmers learn that positional anything is bad at an early
+stage; we don't want to force the use of positional aggregates unless there
+is no other choice. (Yes, for a list, it seems that there is no sane way to
+name the nodes, so positional is the only possibility.)
+
+****************************************************************
+
+From: Florian Schanda
+Sent: Wednesday, June 14, 2017  2:29 AM
+
+> WTF is a "comprehension"? I'd rather not stuff more obscure 
+> terminology into Ada that is mostly going to get in the way of getting the
+> job done.
+
+It's a reasonable common construct in functional programming, but also
+features in some imperatives languages. Here is an overview from wikipedia:
+
+https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28list_comprehension%29
+
+But I think the language that made the term popular was Python:
+
+https://docs.python.org/2/reference/expressions.html#list-displays
+
+They also distinguish between displays and comprehension; in Python a list can
+be written as [1, 2, 3] which most people think of as a literal, but it is
+actually a display.
+
+Again, I hesitate to mention Python as my main inspiration for this because,
+well, Python has many flaws, but I think this is one of the more elegant parts
+of the language and I think our proposed approach to make this syntax work for
+user-defined types and not just built-in types really sets it apart from other
+languages.
+
+> For maps/sets, the order of insertiong should be irrelevant. Same with 
+> a named vector (do you have that? You ought to).
+
+Yes; all that matters is which "inclusion" function you specify (I've done it
+for all the standard containers), for sets it is include (so (1, 2, 2, 3)
+will do the obvious), for maps it is insert (since 1 => 2, 1 => 3 makes little
+sense) and for lists it is append.
+
+> I didn't see what you proposed for a map, but IMHO I think it ought to 
+> look something like:
+> 
+>    ("Tuck" => US, "Jeff" => UK, "Tuillo" => Italy, ...)
+
+Yes, that is what I have. I've called these binary because the inclusion
+function has two parameters (in addition to the container) instead of just one.
+
+> One easily can imagine a vector that works similarly, using the indexes:
+> 
+>    (1 => "Tuck", 2 => "Jeff", 3 => "Randy", 4 => "Florian", ...)
+
+We could do that, but it seems painful, so I'd rather not come up with grammar
+that allows it. It would also mean the compiler would have to sort the list
+first and that also seems like unnecessary complexity ;)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 14, 2017  3:42 AM
+
+> WTF is a "comprehension"? I'd rather not stuff more obscure terminology into
+> Ada that is mostly going to get in the way of getting the job done.
+
+A “set comprehension” is a well defined term in set theory.  E.g.:
+
+   https://en.wikipedia.org/wiki/Set-builder_notation
+
+Other sorts of "comprehensions" are generalizations of this notion.  But I
+agree we don’t need to introduce this term into Ada.  We have already added
+something that is essentially an "array comprehension" and we called it an
+"iterated_component_association."  I don’t love that term either, but we
+should probably stick with it.  I also find “display” a particularly
+ambiguous term, and see no reason to use it here.
+
+For what it is worth, I will send as a separate e-mail the ParaSail
+description of user-defined container aggregates (as a PDF).  Not sure what
+Randy’s e-mail system is going to do with that.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 14, 2017  3:45 AM
+
+Here it is.  Actually, this is for “Sparkel,” the SPARK-like variant of
+araSail.
+
+[Sorry, there is no way to attach that here. - Editor.]
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, June 14, 2017  4:00 AM
+
+> WTF is a "comprehension"?
+
+Glad you said that before I did!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 14, 2017  2:26 PM
+
+>They also distinguish between displays and comprehension; in Python a list can
+>be written as [1, 2, 3] which most people think of as a literal, but it is
+>actually a display.
+
+I don't see the point in differentiation: in Ada, an aggregate is often though
+of as a literal, but it can contain many dynamically determined parts, so there
+really is no analogue in other languages.
+
+And it is really is a small step from:
+
+    (For I in Func1 .. Func2 => Func3(I))
+
+which is just an Ada 202x array aggregate, and your proposed:
+
+    (For E of Cont1 => Func(E))
+
+No reason that I can see to differentiate them; your "displays" and
+"comphrehensions" would have the exact same implementation outside of the
+looping mechanism (and us implementers are used to that vis-a-vis aggregates).
+
+>> One easily can imagine a vector that works similarly, using the indexes:
+>>
+>>    (1 => "Tuck", 2 => "Jeff", 3 => "Randy", 4 => "Florian", ...)
+>
+>We could do that, but it seems painful, so I'd rather not come up with grammar
+>that allows it. It would also mean the compiler would have to sort the list
+>first and that also seems like unnecessary complexity ;)
+
+???
+
+The grammar is that of an array aggregate, supplemented with your "for E of
+whatever" syntax. No reason to do anything else. The semantics are different,
+of course, but as little as necessary.
+
+There's no requirement to "sort" the aggregate; the implementation would use
+Insert to implement them, in any order it wants. It shouldn't matter (I guess
+it would have to be a new Insert analog that expands the capacity as needed)
+what order is used, as we're inserting by index. The implementation *could*
+sort the aggregate so the capacity is allocated all at once, but it doesn't
+have to do that optimization. Indeed, your original proposal would *require*
+worst-case insertion behavior (where the capacity is increased multiple times,
+the minimum amount each time, until it is big enough - yuck).
+
+Anyway, to be discussed.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 22, 2017  11:19 AM
+
+> >They also distinguish between displays and comprehension; in Python a 
+> >list can be written as [1, 2, 3] which most people think of as a 
+> >literal, but it is actually a display.
+> 
+> I don't see the point in differentiation: in Ada, an aggregate is often 
+> though of as a literal, but it can contain many dynamically determined
+> parts, so there really is no analogue in other languages.
+> 
+> And it is really is a small step from:
+>     (For I in Func1 .. Func2 => Func3(I)) which is just an Ada 202x 
+> array aggregate, and your proposed:
+>     (For E of Cont1 => Func(E))
+> No reason that I can see to differentiate them; your "displays" and
+> "comphrehensions" would have the exact same implementation outside of the
+> looping mechanism (and us implementers are used to that vis-a-vis aggregates). ...
+
+I agree, we should use named and positional array aggregate syntax (and
+vocabulary) for these new container aggregates, unless there is a compelling
+reason to invent something new.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent