[J3] Exception handling - Golang proposal

[Van Snyder]

On Sat, 2019-07-06 at 20:52 -0400, Steve Lionel via J3 wrote:
> One of the major features we've said we'd like to see in F202X is 
> "exception handling", but this is probably the least well defined (for 
> Fortran) of any of the features proposed....

Perhaps you have forgotten 18-115, which for meeting 215 was classified
as "info" instead of being assigned to a subgroup.  I assume "info"
means "we hope this paper dies quietly without us having to think about
it or discuss it"  It was a response to the desire for development of
exception handling, which we had decided was a desirable "major
feature."  It was not discussed, either in subgroup or plenary.  Did
anybody read it?

Of course, classifying my papers that are responses to "major features"
that are considered desirable, as "info" instead of assigning them to a
subgroup or discussing them in plenary, is nothing new or unique to
meeting 215.  After all, 19-120 and 19-121, explicitly titled "Support
for containers," were also classified as "info" instead of being
assigned to a subgroup, and were not discussed in plenary.  Did anybody
read them?  Did any subgroup surreptitiously discuss them?

In support of containers (as a variety of generic programming), 19-122
was assigned to /JOR at meeting 218, who didn't understand it, and
didn't ask me for explanation.

So I have prepared papers about support for containers and placed them
in the meeting 219 distribution (19-167, 19-168, 19-169, 19-170).  I
shall, of course, be unhappy -- but not surprised -- if these are
classified as "info" and expected to die a quiet death without any
discussion.  I am familiar with this process, after observing that my
proposal for units of measurement went from "Hey, that's a pretty good
idea but we don't have time to do it now" in 2004 (04-302), to "Why
don't you do this as a TR" at Delft in 2005 (where there was
constructive discussion of details), to "Hell no!" in Garching two years
ago.

In case anybody is interested in informational material concerning the
ideas behind those four papers, I have put the following files into the
Tutorials folder:

      * Geschke-Mitchell.pdf (1975)
      * Parnas.pdf (1970)
      * POP-2-Reference-Manual.pdf (1968)
      * Rice-1981.pdf
      * Ross.pdf (1969)
      * Tennent.pdf (1981)
      * X3J3-1985.pdf

Parnas's paper was the first one (that I have found so far) that
explicitly observed that changes to programs too frequently have costs
proportional to the size of the program rather than to the magnitude of
the change.  He discussed his conclusions regarding the reason for that
phenomenon, and proposed a solution as a software engineering principle,
rather than as a language design principle.  Ross had apparently
observed the phenomenon one year earlier, but didn't write exactly that
observation explicitly.  He (and Geschke and Mitchell) proposed
solutions as language design principles.  19-167, 19-168, and 19-170 are
aimed explicitly at this problem, because almost nobody follows Parnas's
advice in every detail -- for very good reasons.

It wouldn't hurt also to read about "setters" in Python.  Several
respondents to Anton's survey asked for "setters."  I called them
"updaters" in 19-168 -- not least because that's what Burstall and
Popplestone called them in POP-2.  Geschke and Mitchell discussed this
idea at length -- years before Python was a gleam in anybody's eye --
but did not give it a special name.  I invented this concept
independently.  When I submitted a paper to TOPLAS, the Editor drew my
attention to (some of) the above-cited works.  My 1985 proposal to X3J3
was an attempt to deal with the problems described in those papers, and
to address the controversy concerning the syntax to select structure
components.  The percent sign was originally a "place holder" intended
to exist only until a suitable syntax developed consensus -- which
didn't happen.  John Rice, Rex Page, and Brian Smith understood what I
was proposing and its value, but the rest of X3J3 -- about 35 members --
said "Fortran programmers want to see what their program is doing and
how it does it."  Ross, Parnas, and Geschke and Mitchell pointed out
fifteen years earlier that this is precisely what one SHOULD NOT WANT!

> Tonight I ran across a proposal being suggested for the Go language
> which bears some similarities to at least one proposal I've seen for
> Fortran. Some in the  Go community don't like it.

In case anybody is interested in reading about exceptions and exception
handling in Ada, I've put the Ada 2012 standard in the Tutorials folder
as ISO_IEC_8652:2012_RM.pdf.  I also recommend textbooks by John Barnes
and Norman Cohen.

The lead developer of Verdix Ada, Randy Brukardt, says that declaring
exceptions and exception handlers in a Verdix Ada program imposes very
low runtime overhead until an exception is raised.  He said he cannot
speak definitively for other Ada processors, but he believes they all
have very low overhead until an exception is raised.  The developers of
GNU Ada say that declaring exceptions and having exception handlers
imposes zero runtime overhead until an exception is raised.

The requirements documents for Ada, which started circulation with one
entitled "Strawman" in April 1975
(https://en.wikisource.org/wiki/Strawman_language_requirements, section
I.C), insisted upon exception handling.  The June 1978 "Steelman"
requirements concerning exceptions
(https://en.wikisource.org/wiki/Steelman_language_requirements#10._Exception_Handling, Section 10) are detailed and explicit.  My group at JPL reviewed and commented upon all five requirements documents, as well as all four proposed designs that responded to the requirements.  We preferred and commented upon the "green" design.  This turned out to be Jean Ichbiah's design.  It became the basis for the original Ada standard, in 1983, which, or course, had exception handling.  Maybe -- just maybe -- during the last thirty six (or forty one) years, Ada processor developers have figured out how to do it well.

So why would exception handling in "Go" be interesting?  Perhaps Hegel
was right.  "The only thing we learn from history is that we do not
learn from history."

> I haven't studied it enough to see if there are any "take-aways" for 
> Fortran, but I found it worthwhile reading as I saw echoes of some of 
> our earlier discussions.
> 
> The actual proposal and discussion: 
> https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md
> 
> Some other discussion: https://github.com/golang/go/issues/32437
> 
> Article about the "kerfluffle": 
> https://thenewstack.io/this-week-in-programming-do-or-not-do-there-is-no-try/
> 
> Steve
>