[Cfp-interest] further revisions to syntax discussion

[Jim Thomas]

A few late suggestions for the draft …

We need a statement near the beginning that this is for TS 18661 Part 5 "Supplementary attributes”.

Paragraph 2: “for performance reasons” seems redundant.

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 …”.

Next to last paragraph: replace the last two occurrences of “or” with “and”.

Last paragraph: refer to us as the C FP group working of TS 18661.

-Jim

On Jun 11, 2014, at 5:00 PM, David Hough CFP <pcfp at oakapple.net> wrote:

> 
> I incorporated some other bits to make it more self-contained
> and self-explanatory, I hope.
> 
> http://www.validlab.com/cfp/
> 
> is updated.
> 
> Here are the diffs:
> 
> 7,8d6
> < BACKGROUND:
> < 
> 47,52c45,46
> < Although existing standard C has support for detecting exception flags
> < and handling SIGFPE, that's like saying that Fortran-77 supports a heap.
> < It is true that any competent Fortran-77 programmer could program blank 
> < common to be used like a heap.    It is also true that the result is
> < difficult to write correctly and even harder to read.    C provides malloc
> < and free instead.    Fortran-90 eventually caught up to C in this respect.
> ---
>> The general programming paradigm as it might be naturally
>> expressed in many languages is
> 54,60d47
> < SEMANTICS:
> < 
> < So from the higher point of view of an applications programmer, rather than
> < the lower point of view of a system implementer,
> < the common programming exception-handling paradigm is naturally
> < expressed in many languages in this fashion:
> < 
> 90,116d76
> < IEEE 754 specifies default exception handling, but if the default were
> < always satisfactory then it wouldn't be exceptional.   By definition,
> < an exception can't be handled the same way in every situation in which it
> < might arise.    So alternate exception handling must be specified from
> < time to time, more often in code that is intended to be as fast as possible
> < in the normal case, but as robust as possible when exceptions arise which
> < are not normal, but are not so rare that they can be ignored.
> < So some desirable attributes of exception handling include
> < 
> < 1) the normal case should be as fast as possible
> < 2) the exceptional case should be detected as quickly as possible
> < 3) the application programmer can understand the exception and its handling
> <    in terms that do not depend on the specific hardware and operating system, 
> <    so the syntax and semantics are portable
> < 4) the compiler/operating system/hardware figure out the most efficient
> <    way to implement the intended semantics on a particular platform,
> <    rather than leaving that burden on the application programmer
> < 
> < SYNTAX:
> < 
> < There are many different ways to express the syntax.    They all have
> < in common a need to specify
> < 
> < 1) the normal case code that the exception handling applies to
> < 2) the exceptions to be handled specially
> < 3) the exception case code to be executed when those exceptions arise
> < 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140612/22e13c75/attachment-0001.html