sttaft
commented
1 year ago Here two comments when this proposal was recently circulated on the ARG list:
Tullio Vardanega via ada-auth.org, Fri, Nov 18, 10:41 AM (2 days ago)
I second Tuck's proposal.
Randy Brukardt via ada-auth.org, Nov 19, 2022, 3:04 AM (1 day ago)
Tucker writes:
After a recent chat with Raphaël, I'd like to propose we resurrect AI12-0190-1 on Anonymous Functions.
Thanks for providing the minutes, it saved me from looking them up (or giving an uninformed response to this suggestion). Note that this AI was NOT put on Hold, but rather voted No Action. We did NOT want to see this particular proposal again. So "resurrecting" it would be the wrong action. I could see creating a Github issue to find out actual interest and then to work out some proposal that actually was responsive to the need.
Lambda functions have become even more widespread in languages since we had this discussion, and Raph reminded me of how many programmers now consider lambda functions a fundamental building block. In the large majority of cases, they are not returning lambda functions, but are rather passing them into things like iterators and reducers.
(1) Many programmers consider garbage collection a fundamental requirement for a programming language, but that does not mean that we need to run out to add it to Ada. Even if we did so, it seems unlikely that any of the existing implementations would support it, as it seems to run counter to the needs of many of the paying customers.
(2) People that chose Ada are not particularly interested in what the "many" are doing; if they were, they wouldn't be using Ada in the first place. And no amount of adding whatever feature the "many" think is missing from Ada has made it more popular to date. I have absolutely no reason to think that would change.
(3) The proposal in AI12-0190-1 didn't provide much of what the "fundamental building block" would be good for. I suspect most of the programmers that want it would find the emasculated version in AI12-0190-1 as insufficient. Even if they very rarely return a lambda function, they'll still be unhappy the first time they try (or run into one of the other limitations). I note that the minutes say that no less of an authority than Tucker Taft says that "full lambdas only work for garbage collected languages" and that he was unable to devise a set of rules for safe lambdas. So it seems that STT doesn't believe that this need can be met for the "many programmers" noted above.
(4) This, like all extension proposals, need to be evaluated against what the goals for Ada are. I think those are for a readable language that allows efficient, close-to-the-metal programming, and also one that provides a well-defined basis for static analysis. Lambdas seem to miss the mark for these things; they are fairly high-level with a lot of overhead (for closures) in general; and they cannot have any contracts (and even if they could somehow have them, it would be unlikely for anyone to write them, as their purpose is ease-of-writing with most of the usual things like subtypes implicit). I don't how these meet any of the primary goals for Ada.
(Aside: We got plenty of push-back for conditional expressions and quantified expressions, continuing much further in this direction is a place many existing Ada users don't want to go.)
Given the above, I would be surprised if a new lambda proposal ended up much different than the last one. And much of the above was in those minutes from our last discussion.
You're welcome to create an issue if you like, but my advice would be to spend your limited time on proposals that fit the goals of Ada better.
Randy.
raph-amiard
There is a 2012 AI proposing lambda expressions for Ada (AI12-0190-1), called "anonymous functions" in the AI:
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0190-1.txt?rev=1.13
After a recent chat with Raphaël, I'd like to propose we resurrect this AI on Anonymous Functions. Lambda expressions have become even more widespread in languages since we had this discussion, and Raph reminded me of how many programmers now consider lambda expressions a fundamental building block. In the large majority of cases, they are not returning lambda expressions, but are rather passing them into things like iterators and reducers. For the record, below are the minutes from the final discussion on this item. As can be seen, there were a lot of open issues.
For reference, here is a Wikipedia article on "anonymous functions": https://en.wikipedia.org/wiki/Anonymous_function
Take care, -Tuck
Detailed Review of Ada 2012 AIs
AI12-0190-1/08 Anonymous functions (Other AI versions) The syntax was changed to anonymous_function (rather than function_expression, which was confusing with expression function), and we changed the rules so that the parameter names are properly declared, which should fix the conformance issues. Randy notes that Tucker had illustrated how confusing the original naming was by having originally written expression_function when he meant function_expression, and then repeating this error in every draft he sent (presumably because it didn't get found by search-and-replace).
No other typos or technical issues are raised.
Randy asks if we want this. He argues that this feature is premature, hard to implement, and harms readability. It's impossible to put contracts on this feature, or on the anonymous access-to-subprogram that it is tied to. That harms static analysis.
Tucker asks for a vote, saying we've discussed all of this before.
Randy suddenly remembers that this has an implicit type of closure as well, since it can generated inside of a declare expression. We pretty much agreed we didn't want anything other than simple objects in a declare expression, and this definitely is not a simple object. It might cause functional people to start putting everything they can into a declare expression to get this closure-like behavior, which would be bad for readability, turning Ada expressions into LISP with a dozen closing parenthesis at the end of an expression.
We try the vote.
Approves AI with changes: 6-5-1.
Randy votes against, reasons given above. Gary votes against: sees it hurting readability, and not sufficient benefit for the cost.
Jeff and John vote against. Jeff agrees with Randy; he had another comment but can't find it. John doesn't like anonymous things in general.
Erhard also votes against. He does not like the mapping onto access. He is concerned about accessibility issues, especially for objects being returned. He notes it's not really a lambda, which is what he really wants. Tucker notes that full lambdas really only work for garbage-collected languages. He tried to devise a set of rules for objects that would be safe for a lambda, but he was unable to do so. He says Erhard is welcome to try.
Ed abstains.
This vote fails; with 12 voters, there can be no more than 2 against. (Not that anyone would want to argue that any proposal that nearly half of the group opposes should go in anyway.)
We then get bogged down on the next step. We can put the AI on Hold, or make it a No Action. The question really boils down to whether we would want to work on this exact version again. More people seem to suggest No Action rather than Hold. Tucker notes that there isn't much practical difference, as we can always restart work on it using this version as a starting point, so long as it is not deleted from the disk. And we keep all of our AIs forever.
No Action: 10-0-2 Abstain: Justin, Tucker.