<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">A few late suggestions for the draft …<div><br></div><div><div style="font-size: 13px;">We need a statement near the beginning that this is for TS 18661 Part 5 "Supplementary attributes”.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">Paragraph 2: “for performance reasons” seems redundant.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">C already has a way of representing multiple exceptions (e.g., FE_INVALID | FE_OVERFLOW). In the code model under SEMANTICS, we could use exceptions1 and exceptions2, and omit “One could extend the syntax to allow a list of exceptions …”.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">Next to last paragraph: replace the last two occurrences of “or” with “and”.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">Last paragraph: refer to us as the C FP group working of TS 18661.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">-Jim</div><div style="font-size: 13px;"><br></div><div><div>On Jun 11, 2014, at 5:00 PM, David Hough CFP <<a href="mailto:pcfp@oakapple.net">pcfp@oakapple.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>I incorporated some other bits to make it more self-contained<br>and self-explanatory, I hope.<br><br><a href="http://www.validlab.com/cfp/">http://www.validlab.com/cfp/</a><br><br>is updated.<br><br>Here are the diffs:<br><br>7,8d6<br>< BACKGROUND:<br>< <br>47,52c45,46<br>< Although existing standard C has support for detecting exception flags<br>< and handling SIGFPE, that's like saying that Fortran-77 supports a heap.<br>< It is true that any competent Fortran-77 programmer could program blank <br>< common to be used like a heap. It is also true that the result is<br>< difficult to write correctly and even harder to read. C provides malloc<br>< and free instead. Fortran-90 eventually caught up to C in this respect.<br>---<br><blockquote type="cite">The general programming paradigm as it might be naturally<br>expressed in many languages is<br></blockquote>54,60d47<br>< SEMANTICS:<br>< <br>< So from the higher point of view of an applications programmer, rather than<br>< the lower point of view of a system implementer,<br>< the common programming exception-handling paradigm is naturally<br>< expressed in many languages in this fashion:<br>< <br>90,116d76<br>< IEEE 754 specifies default exception handling, but if the default were<br>< always satisfactory then it wouldn't be exceptional. By definition,<br>< an exception can't be handled the same way in every situation in which it<br>< might arise. So alternate exception handling must be specified from<br>< time to time, more often in code that is intended to be as fast as possible<br>< in the normal case, but as robust as possible when exceptions arise which<br>< are not normal, but are not so rare that they can be ignored.<br>< So some desirable attributes of exception handling include<br>< <br>< 1) the normal case should be as fast as possible<br>< 2) the exceptional case should be detected as quickly as possible<br>< 3) the application programmer can understand the exception and its handling<br>< in terms that do not depend on the specific hardware and operating system, <br>< so the syntax and semantics are portable<br>< 4) the compiler/operating system/hardware figure out the most efficient<br>< way to implement the intended semantics on a particular platform,<br>< rather than leaving that burden on the application programmer<br>< <br>< SYNTAX:<br>< <br>< There are many different ways to express the syntax. They all have<br>< in common a need to specify<br>< <br>< 1) the normal case code that the exception handling applies to<br>< 2) the exceptions to be handled specially<br>< 3) the exception case code to be executed when those exceptions arise<br>< <br>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></blockquote></div><br></div></body></html>