Changeset 83e9bd3


Ignore:
Timestamp:
Jun 2, 2017, 4:58:10 PM (7 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
421a287
Parents:
d3ed39f
Message:

formatting updates

Location:
doc/refrat
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • doc/refrat/Makefile

    rd3ed39f r83e9bd3  
    4444
    4545${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex \
    46                 ../LaTeXmacros/common.tex ../LaTeXmacros/indexstyle ../bibliography/cfa.bib
     46                ../LaTeXmacros/common.tex ../LaTeXmacros/lstlang.sty ../LaTeXmacros/indexstyle ../bibliography/cfa.bib
    4747        # Conditionally create an empty *.ind (index) file for inclusion until makeindex is run.
    4848        if [ ! -r ${basename $@}.ind ] ; then touch ${basename $@}.ind ; fi
    … …  
    7070        fig2dev -L ps $< > $@
    7171
     72%.pstex : %.fig
     73        fig2dev -L pstex $< > $@
     74        fig2dev -L pstex_t -p $@ $< > $@_t
     75
    7276# Local Variables: #
    7377# compile-command: "make" #

  • doc/refrat/refrat.bib

    rd3ed39f r83e9bd3  
    22
    33@manual{ANS:C,
    4     keywords = {ANSI C},
    5     contributer = {gjditchfield@msg},
    6     title = {American National Standard for Information Systems --
     4    keywords    = {ANSI C},
     5    contributer = {gjditchfield@msg},
     6    title       = {American National Standard for Information Systems --
    77          Programming Language -- {C}},
    8     organization = {American National Standards Institute},
    9     address = {1430 Broadway, New York, New York  10018},
    10     month = dec, year = 1989,
    11     note = {X3.159-1989}
     8    organization= {American National Standards Institute},
     9    address     = {1430 Broadway, New York, New York  10018},
     10    month       = dec, year     = 1989,
     11    note        = {X3.159-1989}
    1212}
    1313
    1414@manual{ANS:C11,
    15     keywords = {ANS:C11},
    16     contributer = {gjditchfield@acm.org},
    17     title = {American National Standard Information Systems --
     15    keywords    = {ANS:C11},
     16    contributer = {gjditchfield@acm.org},
     17    title       = {American National Standard Information Systems --
    1818          Programming languages -- {C}},
    19     organization = {American National Standards Institute},
    20     address = {25 West 43rd Street, New York, New York 10036},
    21     month = may, year = 2012,
    22     note = {INCITS/ISO/IEC 9899-2011[2012]}
     19    organization= {American National Standards Institute},
     20    address     = {25 West 43rd Street, New York, New York 10036},
     21    month       = may, year     = 2012,
     22    note        = {INCITS/ISO/IEC 9899-2011[2012]}
    2323}
    2424
    2525@book{c++,
    26     keywords = {C++, ANSI},
    27     author = {Margaret A. Ellis and Bjarne Stroustrup},
    28     title = {The Annotated {C}{\tt ++} Reference Manual},
    29     publisher = {Addison Wesley},
    30     year = 1990,
    31     edition = {first}
     26    keywords    = {C++, ANSI},
     27    author      = {Margaret A. Ellis and Bjarne Stroustrup},
     28    title       = {The Annotated {C}{\tt ++} Reference Manual},
     29    publisher   = {Addison Wesley},
     30    year        = 1990,
     31    edition     = {first}
    3232}
    3333
    3434@Unpublished{Ditchfield96:Overview,
    35   author =      "Glen Ditchfield",
    36   title =        "An Overview of Cforall",
    37   note =        "in preparation",
    38   year =        1996
     35    author      = "Glen Ditchfield",
     36    title       = "An Overview of Cforall",
     37    note        = "in preparation",
     38    year        = 1996
    3939}
    4040
    4141@article{Bak:overload,
    42     keywords = {compilation},
    43     contributer = {gjditchfield@msg},
    44     author = {T. P. Baker},
    45     title = {A One-Pass Algorithm for Overload Resolution in {Ada}},
    46     journal = toplas,
    47     year = 1982,
    48     month = oct, volume = 4, number = 4, pages = {601--614},
    49     abstract = {
     42    keywords    = {compilation},
     43    contributer = {gjditchfield@msg},
     44    author      = {T. P. Baker},
     45    title       = {A One-Pass Algorithm for Overload Resolution in {Ada}},
     46    journal     = toplas,
     47    year        = 1982,
     48    month       = oct, volume   = 4, number     = 4, pages      = {601--614},
     49    abstract    = {
    5050        A simple method is presented for detecting ambiguities and finding
    5151        the correct interpretations of expressions in the programming
    … …  
    5656        approach is demonstrated by a brief formal argument.
    5757    },
    58     comment = {
     58    comment     = {
    5959        See also \cite{D:overload}.
    6060        }
    … …  
    7777
    7878@book{clu,
    79     keywords = {CLU},
    80     contributer = {gjditchfield@msg},
    81     author = {Barbara Liskov and Russell Atkinson and Toby Bloom and Eliot
     79    keywords    = {CLU},
     80    contributer = {gjditchfield@msg},
     81    author      = {Barbara Liskov and Russell Atkinson and Toby Bloom and Eliot
    8282    Moss and J. Craig Schaffert and Robert Scheifler and Alan Snyder},
    83     title = {CLU Reference Manual},
    84     publisher = {Springer-Verlag},
    85     year = 1981,
    86     volume = 114,
    87     series = {Lecture Notes in Computer Science}
     83    title       = {CLU Reference Manual},
     84    publisher   = {Springer-Verlag},
     85    year        = 1981,
     86    volume      = 114,
     87    series      = {Lecture Notes in Computer Science}
    8888}
    8989
    9090@manual{SIMULA87,
    91     keywords = {Simula standard},
    92     contributer = {gjditchfield@msg},
    93     title = {Databehandling -- Programspr{\aa}k -- {SIMULA}},
    94     organization = {Standardiseringskommissionen i Sverige},
    95     note = {Svensk Standard SS 63 61 14},
    96     year = 1987,
    97     abstract = {
     91    keywords    = {Simula standard},
     92    contributer = {gjditchfield@msg},
     93    title       = {Databehandling -- Programspr{\aa}k -- {SIMULA}},
     94    organization        = {Standardiseringskommissionen i Sverige},
     95    note        = {Svensk Standard SS 63 61 14},
     96    year        = 1987,
     97    abstract    = {
    9898        Standard for the programming language SIMULA.  Written in English.
    9999    }
    … …  
    112112
    113113@inproceedings{Thompson90new,
    114   title = {A New C Compiler},
    115   author = {Ken Thompson},
    116   booktitle = {Proceedings of the Summer 1990 UKUUG Conference},
    117   year = 1990,
    118   pages = {41--51}
     114    title       = {A New {C} Compiler},
     115    author      = {Ken Thompson},
     116    booktitle   = {Proceedings of the Summer 1990 UKUUG Conference},
     117    year        = 1990,
     118    pages       = {41--51}
    119119}

  • doc/refrat/refrat.tex

    rd3ed39f r83e9bd3  
    1111%% Created On       : Wed Apr  6 14:52:25 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Wed Apr  5 23:23:28 2017
    14 %% Update Count     : 79
     13%% Last Modified On : Fri Jun  2 10:43:14 2017
     14%% Update Count     : 83
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    2929\usepackage{epic,eepic}
    3030\usepackage{upquote}                                                                    % switch curled `'" to straight
     31\usepackage{calc}
    3132\usepackage{xspace}
    3233\usepackage{varioref}                                                                   % extended references
    … …  
    6263% Names used in the document.
    6364\newcommand{\Version}{\input{../../version}}
    64 
    6565\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
    6666\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
    … …  
    9797\renewcommand{\chaptermark}[1]{\markboth{\thechapter\quad #1}{\thechapter\quad #1}}
    9898\renewcommand{\sectionmark}[1]{\markboth{\thesection\quad #1}{\thesection\quad #1}}
     99\renewcommand{\subsectionmark}[1]{\markboth{\thesubsection\quad #1}{\thesubsection\quad #1}}
    99100\pagenumbering{roman}
    100101\linenumbers                                            % comment out to turn off line numbering
    … …  
    121122
    122123This document is a reference manual and rationale for \CFA, a polymorphic extension of the C programming language.
    123 It makes frequent reference to the {\c11} standard \cite{C11}, and occasionally compares \CFA to {\CC} \cite{C++}.
    124 
    125 The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering differs).
    126 Unfortunately, this means the manual contains more ``forward references'' than usual, making it harder to follow if the reader does not have a copy of the {\c11} standard.
     124It covers low-level syntactic and semantic details of the language to address complex language issues for programmers, and provide language implementers with a precise language description.
     125It makes frequent reference to the \Celeven standard~\cite{C11}, and occasionally compares \CFA to \CC~\cite{C++}.
     126Changes to the syntax and additional features are expected to be included in later revisions.
     127
     128The manual deliberately imitates the ordering of the \Celeven standard (although the section numbering differs).
     129Unfortunately, this means the manual contains more ``forward references'' than usual, making it harder to follow if the reader does not have a copy of the \Celeven standard.
    127130For a simple introduction to \CFA, see the companion document ``An Overview of \CFA''
    128131\cite{Ditchfield96:Overview}.
    … …  
    139142\chapter{Terms, definitions, and symbols}
    140143
    141 Terms from the {\c11} standard used in this document have the same meaning as in the {\c11} standard.
     144Terms from the \Celeven standard used in this document have the same meaning as in the \Celeven standard.
    142145
    143146% No ``Conformance'' or ``Environment'' chapters yet.
    … …  
    149152
    150153\section{Notation}
    151 The syntax notation used in this document is the same as in the {\c11} standard, with one exception: ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', indicates that these rules extend a previous definition, which occurs in this document or in the {\c11} standard.
     154The syntax notation used in this document is the same as in the \Celeven standard, with one exception: ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', indicates that these rules extend a previous definition, which occurs in this document or in the \Celeven standard.
    152155
    153156
    … …  
    162165\begin{rationale}
    163166Hence, a \CFA program can declare an ©int v© and a ©float v© in the same scope;
    164 a {\CC} program can not.
     167a \CC program can not.
    165168\end{rationale}
    166169
    … …  
    285288
    286289\begin{rationale}
    287 Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the usual arithmetic conversions, and \CFA does not include them as safe conversions.
     290Note that \Celeven does not include conversion from \Index{real type}s to \Index{complex type}s in the usual arithmetic conversions, and \CFA does not include them as safe conversions.
    288291\end{rationale}
    289292
    … …  
    370373\begin{rationale}
    371374As in C, there is an implicit conversion from ©void *© to any pointer type.
    372 This is clearly dangerous, and {\CC} does not have this implicit conversion.
     375This is clearly dangerous, and \CC does not have this implicit conversion.
    373376\CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a superset of C as possible, but discourages it by making it unsafe.
    374377\end{rationale}
    … …  
    608611
    609612There are two notable differences between \CFA's overload resolution rules and the rules for
    610 {\CC} defined in \cite{C++}.
     613\CC defined in \cite{C++}.
    611614First, the result type of a function plays a role.
    612 In {\CC}, a function call must be completely resolved based on the arguments to the call in most circumstances.
     615In \CC, a function call must be completely resolved based on the arguments to the call in most circumstances.
    613616In \CFA, a function call may have several interpretations, each with a different result type, and the interpretations of the containing context choose among them.
    614617Second, safe conversions are used to choose among interpretations of all sorts of functions;
    615 in {\CC}, the ``usual arithmetic conversions'' are a separate set of rules that apply only to the built-in operators.
     618in \CC, the ``usual arithmetic conversions'' are a separate set of rules that apply only to the built-in operators.
    616619\end{rationale}
    617620
    … …  
    637640
    638641\begin{rationale}
    639 Expression syntax is quoted from the {\c11} standard.
     642Expression syntax is quoted from the \Celeven standard.
    640643The syntax itself defines the precedence and associativity of operators.
    641644The sections are arranged in decreasing order of precedence, with all operators in a section having the same precedence.
    … …  
    665668The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible} declarations of the identifier.
    666669
    667 A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type and value defined by {\c11}.
     670A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type and value defined by \Celeven.
    668671The predefined integer identifiers ``©1©'' and ``©0©'' have the integer values 1 and 0, respectively.
    669672The other two predefined ``©0©'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
    … …  
    11131116forall( otype T ) T restrict * ?++( T restrict *restrict volatile * );
    11141117\end{lstlisting} with ©T© inferred to be ©float *©.
    1115 This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and ©T© is not syntactically a pointer type. \CFA loosens the constraint.
     1118This looks odd, because \Celeven contains a constraint that requires restrict-qualified types to be pointer-to-object types, and ©T© is not syntactically a pointer type. \CFA loosens the constraint.
    11161119\end{enumerate}
    11171120\end{rationale}
    … …  
    14771480
    14781481\begin{rationale}
    1479 {\c11} does not include conversions from the \Index{real type}s to \Index{complex type}s in the \Index{usual arithmetic conversion}s.  Instead it specifies conversion of the result of binary operations on arguments from mixed type domains. \CFA's predefined operators match that pattern.
     1482\Celeven does not include conversions from the \Index{real type}s to \Index{complex type}s in the \Index{usual arithmetic conversion}s.  Instead it specifies conversion of the result of binary operations on arguments from mixed type domains. \CFA's predefined operators match that pattern.
    14801483\end{rationale}
    14811484
    … …  
    15061509
    15071510\begin{rationale}
    1508 {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of ©int©.
     1511\Celeven defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of ©int©.
    15091512If ©s© is a ©short int©, ``©s *s©'' does not have type ©short int©;
    15101513it is treated as ``©( (int)s ) * ( (int)s )©'', and has type ©int©. \CFA matches that pattern;
    … …  
    15191522\end{lstlisting}
    15201523Since \CFA does not define a multiplication operator for ©short int©, ©square( s )© is treated as ©square( (int)s )©, and the result has type ©int©.
    1521 This is mildly surprising, but it follows the {\c11} operator pattern.
     1524This is mildly surprising, but it follows the \Celeven operator pattern.
    15221525
    15231526A more troubling example is
    … …  
    16171620©ptrdiff_t© is an implementation-defined identifier defined in ©<stddef.h>© that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
    16181621It seems reasonable to use it for pointer addition as well. (This is technically a difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral} argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition.
    1619 The {\c11} standard uses ©size_t© in several cases where a library function takes an argument that is used as a subscript, but ©size_t© is unsuitable here because it is an unsigned type.
     1622The \Celeven standard uses ©size_t© in several cases where a library function takes an argument that is used as a subscript, but ©size_t© is unsuitable here because it is an unsigned type.
    16201623\end{rationale}
    16211624
    … …  
    19301933\end{lstlisting}
    19311934The logical expression calls the ©Rational© inequality operator, passing it ©*rp© and the ©Rational 0©, and getting a 1 or 0 as a result.
    1932 In contrast, {\CC} would apply a programmer-defined ©Rational©-to-©int© conversion to ©*rp© in the equivalent situation.
     1935In contrast, \CC would apply a programmer-defined ©Rational©-to-©int© conversion to ©*rp© in the equivalent situation.
    19331936The conversion to ©int© would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
    19341937\end{rationale}
    … …  
    26262629\begin{itemize}
    26272630\item a typedef name may be redefined to denote the same type as it currently does, provided that type is not a variably modified type;
    2628 \item tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard.
     2631\item tags may be redeclared as specified in section 6.7.2.3 of the \Celeven standard.
    26292632\end{itemize}
    26302633\begin{rationale}
    2631 This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow overloading.
     2634This constraint adds the phrase ``with compatible types'' to the \Celeven constraint, to allow overloading.
    26322635\end{rationale}
    26332636
    26342637An identifier declared by a type declaration shall not be redeclared as a parameter in a function definition whose declarator includes an identifier list.
    26352638\begin{rationale}
    2636 This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters.
     2639This restriction echos \Celeven's ban on the redeclaration of typedef names as parameters.
    26372640This avoids an ambiguity between old-style function declarations and new-style function prototypes:
    26382641\begin{lstlisting}
    … …  
    26612664
    26622665\semantics
    2663 \CFA extends the {\c11} definition of \define{anonymous structure} to include structure specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union specifiers with tags.
     2666\CFA extends the \Celeven definition of \define{anonymous structure} to include structure specifiers with tags, and extends the \Celeven definition of \define{anonymous union} to include union specifiers with tags.
    26642667\begin{rationale}
    26652668This extension imitates an extension in the Plan 9 C compiler \cite{Thompson90new}.
    … …  
    28542857
    28552858\begin{rationale}
    2856 ©lvalue© provides some of the functionality of {\CC}'s ``©T&©'' ( reference to object of type ©T©) type.
    2857 Reference types have four uses in {\CC}.
     2859©lvalue© provides some of the functionality of \CC's ``©T&©'' ( reference to object of type ©T©) type.
     2860Reference types have four uses in \CC.
    28582861\begin{itemize}
    28592862\item
    … …  
    28622865\item
    28632866A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal ©with© statement.
    2864 The following {\CC} code gives an example.
     2867The following \CC code gives an example.
    28652868\begin{lstlisting}
    28662869{
    … …  
    28742877A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument.
    28752878This is most useful for user-defined assignment operators.
    2876 In {\CC}, plain assignment is done by a function called ``©operator=©'', and the two expressions
     2879In \CC, plain assignment is done by a function called ``©operator=©'', and the two expressions
    28772880\begin{lstlisting}
    28782881a = b;
    … …  
    28872890\item
    28882891References to \Index{const-qualified} types can be used instead of value parameters.  Given the
    2889 {\CC} function call ``©fiddle( a_thing )©'', where the type of ©a_thing© is
     2892\CC function call ``©fiddle( a_thing )©'', where the type of ©a_thing© is
    28902893©Thing©, the type of ©fiddle© could be either of
    28912894\begin{lstlisting}
    … …  
    32163219The Simula class \cite{SIMULA87} is essentially a record type.
    32173220Since the only operations on a record are member selection and assignment, which can not be overloaded, there is never any ambiguity as to whether the abstraction or the implementation view is being used.
    3218 In {\CC}
     3221In \CC
    32193222\cite{C++}, operations on class instances include assignment and ``©&©'', which can be overloaded.
    32203223A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used.
    … …  
    35483551\subsection{Predefined macro names}
    35493552
    3550 The implementation shall define the macro names ©__LINE__©, ©__FILE__©, ©__DATE__©, and ©__TIME__©, as in the {\c11} standard.
     3553The implementation shall define the macro names ©__LINE__©, ©__FILE__©, ©__DATE__©, and ©__TIME__©, as in the \Celeven standard.
    35513554It shall not define the macro name ©__STDC__©.
    35523555
    … …  
    36343637\subsection{Pointer and array types}
    36353638
    3636 Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a constant pointer to the first element of the array, and the subscript expression ``©a[i]©'' is equivalent to the dereferencing expression ``©(*( a+( i )))©''.
     3639Array types can barely be said to exist in \Celeven, since in most cases an array name is treated as a constant pointer to the first element of the array, and the subscript expression ``©a[i]©'' is equivalent to the dereferencing expression ``©(*( a+( i )))©''.
    36373640Technically, pointer arithmetic and pointer comparisons other than ``©==©'' and ``©!=©'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
    36383641Consequently, there is no need for a separate ``array type'' specification.
    … …  
    37123715Different operators often have related meanings;
    37133716for instance, in C, ``©+©'', ``©+=©'', and the two versions of ``©++©'' perform variations of addition.
    3714 Languages like {\CC} and Ada allow programmers to define operators for new types, but do not require that these relationships be preserved, or even that all of the operators be implemented.
     3717Languages like \CC and Ada allow programmers to define operators for new types, but do not require that these relationships be preserved, or even that all of the operators be implemented.
    37153718Completeness and consistency is left to the good taste and discretion of the programmer.
    37163719It is possible to encourage these attributes by providing generic operator functions, or member functions of abstract classes, that are defined in terms of other, related operators.
    … …  
    38233826\end{theindex}
    38243827
     3828
    38253829\end{document}
    38263830
Note: See TracChangeset for help on using the changeset viewer.