[Cfp-interest] revised syntax.txt document

[David Hough CFP]

Per the suggestions in today's meeting, I've revised 

http://www.validlab.com/cfp/syntax.txt

Here are the diffs:


------- syntax.txt -------
3a4,5
> What syntax should be used to express IEEE 754-2008 alternate
> exception handling in C?    
5c7,12
< How fast you can drive a car depends on how fast you can stop
---
> The C Floating Point group working of TS 18661 has developed two
> principal approaches and seeks advice from the C committee as
> to which of these two, or some other,
> would be more productive to develop in detail.   What follows is
> the background, necessary semantics, and discussion of try/catch
> and #pragma approaches.
7a15
> 
9a18,21
> 
> How fast you can drive a car depends on how fast you can stop
> 
> 
48,54d59
< 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.
< 
65c70
< catch (floating-point exception1) {
---
> catch (floating-point-exceptions1) {
68c73
< catch (floating-point exception2) {
---
> catch (floating-point-exceptions2) {
75,76c80,83
< the normal case code is interrupted as quickly as possible (and thus its
< output variables may be in an indeterminate state) and the corresponding
---
> the normal case code is interrupted as quickly as possible 
> (and thus variables written and other state modified as side effects
> may be indeterminate) 
> and the corresponding
90a98,104
> Sometimes the possibility of interrupting computation and 
> creating an indeterminate state is worth avoiding; 
> one can imagine having an additional kind of catch keyword
> such as "catchafter" or "patchup"
> to be used in those cases to insure that
> the try clause completed before exception testing.
> 
108a123,126
> 
> Like other floating-point environment, the exception environment is
> inherited from the parent thread and then thread-local (C Standard 7.6).
> 
119c137
< and matlab. 
---
> visual basic, and matlab. 
124,126c142,147
< ruby has a somewhat
< more different version; any begin/end compound statement may have one or
< more rescue clauses corresponding to catch; there is no explicit try keyword.
---
> NetRexx has a somewhat
> more different version; any do/end compound statement may have one or
> more catch clauses; there is no explicit try keyword.
> Ruby has a similar structure but the catch keyword is "rescue".
> Avoiding an explicit try clause reduces the number of gratuitous nesting
> levels.
213d233
< 
231a252
> Other syntaxes that have been used in the past include:
232a254,265
> PL/I:
>  ON exception BEGIN; ... END;
> 
> Basic:
>  ON ERROR GOTO label
>  ON event GOSUB label
> 
> Rexx:
>  SIGNAL ON exception;
> 
> but these don't seem to offer any advantage.
> 
238a272,297
> 
> 
> Note: Can adequate floating-point exception handling be handled without any
> syntactic support in C?    Most of what is desired can be expressed
> with the existing floating-point flag functions 
> or by enabling SIGFPE handlers for hardware floating-point traps.    
> However the flags functions are very verbose and tend to obscure the
> underlying logic of the applications, and even a SIGFPE handler that does
> nothing but abort or longjump has a lot of implementation-dependent
> handling of the trap details; one that does anything more complicated
> might end up decoding op codes, once again obscuring the application logic.
> Worse, the C standard 7.14.1.1 specifies that the signal function behavior
> is undefined in the presence of multiple threads.
> Worst, the application programmer must decide whether coding with
> flags or traps is best, 
> even though that system-dependent decision might better be left to the 
> compiler and runtime.
> 
> So even though existing standard C has support for detecting exception flags
> and handling SIGFPE, 
> that's sort of 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 and debug.    
> C provides malloc and free instead.    
> Fortran-90 eventually caught up to C in this respect.