dart-sdk/docs/language/dart.sty

349 lines
13 KiB
Plaintext
Raw Normal View History

\def\builtinId#1{\textsf{\textbf{#1}}}
\def\keyword#1{\textsf{\textbf{#1}}}
\def\metavar#1{\ensuremath{\mathit{#1}}}
\def\ABSTRACT{\builtinId{abstract}}
\def\AS{\builtinId{as}}
\def\COVARIANT{\builtinId{covariant}}
\def\DEFERRED{\builtinId{deferred}}
\def\DYNAMIC{\builtinId{dynamic}}
\def\EXPORT{\builtinId{export}}
\def\EXTERNAL{\builtinId{external}}
\def\FACTORY{\builtinId{factory}}
\def\FUNCTION{\builtinId{Function}}
\def\GET{\builtinId{get}}
\def\IMPLEMENTS{\builtinId{implements}}
\def\IMPORT{\builtinId{import}}
\def\INTERFACE{\builtinId{interface}}
\def\LIBRARY{\builtinId{library}}
\def\MIXIN{\builtinId{mixin}}
\def\OPERATOR{\builtinId{operator}}
\def\PART{\builtinId{part}}
\def\SET{\builtinId{set}}
\def\STATIC{\builtinId{static}}
\def\TYPEDEF{\builtinId{typedef}}
\def\ASSERT{\keyword{assert}}
\def\ASYNC{\keyword{async}}
\def\AWAIT{\keyword{await}}
\def\BREAK{\keyword{break}}
\def\CASE{\keyword{case}}
\def\CATCH{\keyword{catch}}
\def\CLASS{\keyword{class}}
\def\CONST{\keyword{const}}
\def\CONTINUE{\keyword{continue}}
\def\DEFAULT{\keyword{default}}
\def\DO{\keyword{do}}
\def\ELSE{\keyword{else}}
\def\ENUM{\keyword{enum}}
\def\EXTENDS{\keyword{extends}}
\def\FALSE{\keyword{false}}
\def\FINAL{\keyword{final}}
\def\FINALLY{\keyword{finally}}
\def\FOR{\keyword{for}}
\def\HIDE{\keyword{hide}}
\def\IF{\keyword{if}}
\def\IN{\keyword{in}}
\def\IS{\keyword{is}}
\def\NEW{\keyword{new}}
\def\NULL{\keyword{null}}
\def\OF{\keyword{of}}
\def\ON{\keyword{on}}
\def\RETHROW{\keyword{rethrow}}
\def\RETURN{\keyword{return}}
\def\SHOW{\keyword{show}}
\def\SUPER{\keyword{super}}
\def\SWITCH{\keyword{switch}}
\def\SYNC{\keyword{sync}}
\def\THIS{\keyword{this}}
\def\THROW{\keyword{throw}}
\def\TRUE{\keyword{true}}
\def\TRY{\keyword{try}}
\def\VAR{\keyword{var}}
\def\VOID{\keyword{void}}
\def\WHILE{\keyword{while}}
\def\WITH{\keyword{with}}
\def\YIELD{\keyword{yield}}
% Used for inline code snippets.
\def\code#1{\texttt{#1}}
Language specification reorganization. ---------------- NEW description (old description shown at end): This CL is now a reorganization, problem fixing, clarifying update to dartLangSpec.tex which was created as part of the work on the rules for call method extraction. That is, all the call method extraction specific elements have been _deleted_ from this CL (they will reappear as a separate CL later). This CL is now only performing "general clean-up work" which is needed in order to perform many kinds of updates (including call method extraction, but also anything else where the dynamic semantics depends on the static analysis & desugaring). ------------------------------------------------ OLD description Introduced rules for call method extraction. The previous update to dartLangSpec.tex dealt with invocations, but omitted the transformation whereby `e` becomes `e.call` when `e` has a type which is a class with a `call` method and the context expects a value of type `Function` or of a function type. This CL adds some rules dealing with that and introduces a concept for the transformation itself. One part is missing for the initial patch set: There are no rules specifying that call method extraction should be applied to actual arguments. The problem is that static checking of actual arguments to various invocations (function expression invocation, ordinary method invocation, super invocation, etc.etc.) seems to be "delegated" partially to section `Binding Actuals to Formals`, but that section never defines the syntax for the function which is being invoked and it is in general rather dynamic in nature. So I'm not quite sure that the references to static checking at the end of that section are located optimally. Some adjustments may therefor be needed before we can specify this particular feature for actual arguments. Change-Id: Ia2ab6f16cd50e10a3c467722035f0dc4adb50587 Reviewed-on: https://dart-review.googlesource.com/51323 Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
2018-09-17 11:39:24 +00:00
% `call` has no special lexical status, so we just use \code{}.
\def\CALL{\code{call}}
% Define commands for `<<`, `>>`, `>>>` that avoid introducing guillemets.
\def\ltlt{<\mbox <}
\def\gtgt{>\mbox >}
\def\gtgtgt{>\mbox >\mbox >}
Fixed many whitespace issues in dartLangSpec.tex In dartLangSpec.tex there used to be many white space anomalies, e.g., double spaces between words with no apparent justification or multiple empty lines or lines starting with indentation that wasn't justified by any consistent rule that I could spot. This CL fixes that. It also adjusts the grammar rules to be formatted in a systematic way which will be helpful for an update to use something else than bnf.sty (that we can't distribute due to license problems). In particular, when a right hand side is too long for one line it used to flow into the next line just like text (so non-terminals would have `-` inserted at locations where a natural language algorithm thought the "word" could be split in two, and the indentation on the next line was nonsensical). So now it uses `\gnewline{}` ("grammar newline") to switch to a new line and indent somewhat. It also uses `\gcomma{}` to produce a quoted comma (which otherwise looks funny, because the `,' becomes more like `, ' because the comma has a sort of built-in space after it). The command `\cd{...}` is gone and `\code{...}` is used everywhere. Every sentence is now terminated by a newline. This doesn't mean that every line is <80 chars, but it is at least much more readable (in an editor whose window is really big), and it's consistent with the more radical changes that we have made whenever we have made bigger changes to a paragraph. Finally, all comments on interface injection and all comments on spread and rest arguments have been deleted. These comments contained considerations about said features, but they did not contribute to the discussions that we have had about the same or similar topics (in particular because the comments relied on assumptions that do not hold any more). So it's a big diff, but a huge portion of it is white space fixes, and the rest is very systematic. So it should be bearable, and we would surely need to do the same things over time, otherwise. Change-Id: Ia5922c22cb496792d394e76ce8c7bca7df1b4cc8 Reviewed-on: https://dart-review.googlesource.com/25000 Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
2017-12-01 09:44:18 +00:00
% Used as line break in the right hand side of a grammar
% alternative, that is, when starting a "continuation line".
\newcommand{\gnewline}{\leavevmode\\}
Fixed many whitespace issues in dartLangSpec.tex In dartLangSpec.tex there used to be many white space anomalies, e.g., double spaces between words with no apparent justification or multiple empty lines or lines starting with indentation that wasn't justified by any consistent rule that I could spot. This CL fixes that. It also adjusts the grammar rules to be formatted in a systematic way which will be helpful for an update to use something else than bnf.sty (that we can't distribute due to license problems). In particular, when a right hand side is too long for one line it used to flow into the next line just like text (so non-terminals would have `-` inserted at locations where a natural language algorithm thought the "word" could be split in two, and the indentation on the next line was nonsensical). So now it uses `\gnewline{}` ("grammar newline") to switch to a new line and indent somewhat. It also uses `\gcomma{}` to produce a quoted comma (which otherwise looks funny, because the `,' becomes more like `, ' because the comma has a sort of built-in space after it). The command `\cd{...}` is gone and `\code{...}` is used everywhere. Every sentence is now terminated by a newline. This doesn't mean that every line is <80 chars, but it is at least much more readable (in an editor whose window is really big), and it's consistent with the more radical changes that we have made whenever we have made bigger changes to a paragraph. Finally, all comments on interface injection and all comments on spread and rest arguments have been deleted. These comments contained considerations about said features, but they did not contribute to the discussions that we have had about the same or similar topics (in particular because the comments relied on assumptions that do not hold any more). So it's a big diff, but a huge portion of it is white space fixes, and the rest is very systematic. So it should be bearable, and we would surely need to do the same things over time, otherwise. Change-Id: Ia5922c22cb496792d394e76ce8c7bca7df1b4cc8 Reviewed-on: https://dart-review.googlesource.com/25000 Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
2017-12-01 09:44:18 +00:00
% Metavariables for argument lists.
\newcommand{\argumentList}[1]{\metavar{{#1}s}}
\newcommand{\parameterList}[1]{\metavar{{#1}s}}
% Colors used for for different kinds of text.
\definecolor{normativeColor}{rgb}{0,0,0}
\definecolor{commentaryColor}{rgb}{0.5,0.5,0.5}
\definecolor{rationaleColor}{rgb}{0.5,0.5,0.5}
% Environments for different kinds of text.
\newenvironment{Q}[1]{{\bf{}Upcoming: {#1}}}{}
\newenvironment{rationale}[1]{{\color{rationaleColor}\it{#1}}}{}
\newenvironment{commentary}[1]{{\color{commentaryColor}\sf{#1}}}{}
% Auxiliary functions.
Language specification reorganization. ---------------- NEW description (old description shown at end): This CL is now a reorganization, problem fixing, clarifying update to dartLangSpec.tex which was created as part of the work on the rules for call method extraction. That is, all the call method extraction specific elements have been _deleted_ from this CL (they will reappear as a separate CL later). This CL is now only performing "general clean-up work" which is needed in order to perform many kinds of updates (including call method extraction, but also anything else where the dynamic semantics depends on the static analysis & desugaring). ------------------------------------------------ OLD description Introduced rules for call method extraction. The previous update to dartLangSpec.tex dealt with invocations, but omitted the transformation whereby `e` becomes `e.call` when `e` has a type which is a class with a `call` method and the context expects a value of type `Function` or of a function type. This CL adds some rules dealing with that and introduces a concept for the transformation itself. One part is missing for the initial patch set: There are no rules specifying that call method extraction should be applied to actual arguments. The problem is that static checking of actual arguments to various invocations (function expression invocation, ordinary method invocation, super invocation, etc.etc.) seems to be "delegated" partially to section `Binding Actuals to Formals`, but that section never defines the syntax for the function which is being invoked and it is in general rather dynamic in nature. So I'm not quite sure that the references to static checking at the end of that section are located optimally. Some adjustments may therefor be needed before we can specify this particular feature for actual arguments. Change-Id: Ia2ab6f16cd50e10a3c467722035f0dc4adb50587 Reviewed-on: https://dart-review.googlesource.com/51323 Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
2018-09-17 11:39:24 +00:00
\newcommand{\flatten}[1]{\ensuremath{\mbox{\it flatten}({#1})}}
\newcommand{\futureOrBase}[1]{\ensuremath{\mbox{\it futureOrBase}({#1})}}
\newcommand{\overrides}[1]{\ensuremath{\mbox{\it overrides}({#1})}}
\newcommand{\inherited}[1]{\ensuremath{\mbox{\it inherited}({#1})}}
Language specification reorganization. ---------------- NEW description (old description shown at end): This CL is now a reorganization, problem fixing, clarifying update to dartLangSpec.tex which was created as part of the work on the rules for call method extraction. That is, all the call method extraction specific elements have been _deleted_ from this CL (they will reappear as a separate CL later). This CL is now only performing "general clean-up work" which is needed in order to perform many kinds of updates (including call method extraction, but also anything else where the dynamic semantics depends on the static analysis & desugaring). ------------------------------------------------ OLD description Introduced rules for call method extraction. The previous update to dartLangSpec.tex dealt with invocations, but omitted the transformation whereby `e` becomes `e.call` when `e` has a type which is a class with a `call` method and the context expects a value of type `Function` or of a function type. This CL adds some rules dealing with that and introduces a concept for the transformation itself. One part is missing for the initial patch set: There are no rules specifying that call method extraction should be applied to actual arguments. The problem is that static checking of actual arguments to various invocations (function expression invocation, ordinary method invocation, super invocation, etc.etc.) seems to be "delegated" partially to section `Binding Actuals to Formals`, but that section never defines the syntax for the function which is being invoked and it is in general rather dynamic in nature. So I'm not quite sure that the references to static checking at the end of that section are located optimally. Some adjustments may therefor be needed before we can specify this particular feature for actual arguments. Change-Id: Ia2ab6f16cd50e10a3c467722035f0dc4adb50587 Reviewed-on: https://dart-review.googlesource.com/51323 Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
2018-09-17 11:39:24 +00:00
% Used as a mini-section marker, indicating visibly that a range of
% text (usually just a couple of paragraphs) are concerned with one
% specific topic in a list of similar topics (like many forms of
% expressions of a similar nature).
\newcommand{\Case}[1]{\textbf{Case }$\langle\hspace{0.1em}${#1}$\hspace{0.1em}\rangle$\textbf{.}}
\newcommand{\EndCase}{\mbox{}\hfill$\scriptscriptstyle\Box$\xspace}
Language specification reorganization. ---------------- NEW description (old description shown at end): This CL is now a reorganization, problem fixing, clarifying update to dartLangSpec.tex which was created as part of the work on the rules for call method extraction. That is, all the call method extraction specific elements have been _deleted_ from this CL (they will reappear as a separate CL later). This CL is now only performing "general clean-up work" which is needed in order to perform many kinds of updates (including call method extraction, but also anything else where the dynamic semantics depends on the static analysis & desugaring). ------------------------------------------------ OLD description Introduced rules for call method extraction. The previous update to dartLangSpec.tex dealt with invocations, but omitted the transformation whereby `e` becomes `e.call` when `e` has a type which is a class with a `call` method and the context expects a value of type `Function` or of a function type. This CL adds some rules dealing with that and introduces a concept for the transformation itself. One part is missing for the initial patch set: There are no rules specifying that call method extraction should be applied to actual arguments. The problem is that static checking of actual arguments to various invocations (function expression invocation, ordinary method invocation, super invocation, etc.etc.) seems to be "delegated" partially to section `Binding Actuals to Formals`, but that section never defines the syntax for the function which is being invoked and it is in general rather dynamic in nature. So I'm not quite sure that the references to static checking at the end of that section are located optimally. Some adjustments may therefor be needed before we can specify this particular feature for actual arguments. Change-Id: Ia2ab6f16cd50e10a3c467722035f0dc4adb50587 Reviewed-on: https://dart-review.googlesource.com/51323 Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
2018-09-17 11:39:24 +00:00
\newenvironment{dartCode}[1][!ht] {%
\def\@programcr{\@addfield\strut}%
\let\\=\@programcr%
\relax\@vobeyspaces\obeylines%
\ttfamily\color{commentaryColor}%
\vspace{1em}%
}{\normalcolor\vspace{1em}}
\newenvironment{normativeDartCode}[1][!ht] {%
\def\@programcr{\@addfield\strut}%
\let\\=\@programcr%
\relax\@vobeyspaces\obeylines%
\ttfamily\color{normativeColor}%
\vspace{1em}%
}{\normalcolor\vspace{1em}}
% Used for comments in a code context.
\def\comment#1{\textsf{#1}}
% A commonly used metavariable for an identifier, operator.
\newcommand{\id}{\metavar{id}}
\newcommand{\op}{\metavar{op}}
% Used for defining occurrence of phrase, with customized index entry.
\newcommand{\IndexCustom}[2]{%
\leavevmode\marginpar{\ensuremath{\diamond}}\emph{#1}\index{#2}}
% Used when one concept should have >1 entry in the index. Does not add
% the diamond in the margin and shows no text where the command occurs.
% Intended to be used immediately after another \Index... command.
\newcommand{\IndexExtraEntry}[1]{\index{#1}}
% Used for a defining occurrence of a phrase, adding it to the index.
\newcommand{\Index}[1]{\IndexCustom{#1}{#1}}
% Same appearance, but not adding an entry to the index.
\newcommand{\NoIndex}[1]{%
\leavevmode\marginpar{\ensuremath{\diamond}}\emph{#1}}
% Used to specify comma separated lists of similar symbols.
\newcommand{\List}[3]{\ensuremath{{#1}_{#2},\,\ldots,\ {#1}_{#3}}}
% Used to specify comma separated lists of pairs of similar symbols,
% as needed, e.g., for declarations of formal parameters.
% Parameters: Name of first part of pair, name of second part,
% index at start, index at end.
\newcommand{\PairList}[4]{\ensuremath{%
{#1}_{#3}\ {#2}_{#3},\,\ldots,\ {#1}_{#4}\ {#2}_{#4}}}
% Used to specify comma separated lists of triples of similar symbols,
% as needed, e.g., for declarations of formal parameters with defaults.
% Parameters: Name of first part of triple, name of second part,
% name of third part, index at start, index at end.
\newcommand{\TripleList}[5]{\ensuremath{%
{#1}_{#4}\ {#2}_{#4}\ {#3}_{#4},\,\ldots,\ {#1}_{#5}\ {#2}_{#5}\ {#3}_{#5}}}
% Used to abbreviate \EXTENDS{} in function types.
\newcommand{\FunctionTypeExtends}{\ensuremath{\triangleleft}}
% Used to specify comma separated lists of pairs of symbols
% separated by \EXTENDS{}, as needed for type parameter declarations.
% Parameters: Type parameter name, bound name, number of type parameters.
\newcommand{\TypeParameters}[3]{\ensuremath{%
{#1}_1\,\EXTENDS\,{#2}_1,\,\ldots,\ %
{#1}_{#3}\,\EXTENDS\,{#2}_{#3}}}
% Used to specify comma separated lists of symbols followed by
% \EXTENDS{}, as needed for type parameter declarations where we do
% not intend to refer explicitly to the bounds.
% Parameters: Type parameter name, number of type parameters.
\newcommand{\TypeParametersNoBounds}[2]{\ensuremath{%
{#1}_1\,\EXTENDS\,\ldots,\ \ldots,\ {#1}_{#2}\,\EXTENDS\,\ldots}}
% For consistency, we may as well use this whenever possible.
\newcommand{\TypeParametersStd}{\TypeParameters{X}{B}{s}}
% Used to specify comma separated lists of pairs of symbols
% separated by \EXTENDS{}, as needed for type parameter declarations.
% Parameters: Type parameter name, bound name, number of type parameters.
\newcommand{\FTTypeParameters}[3]{\ensuremath{%
{#1}_1\FunctionTypeExtends{#2}_1,\,\ldots,\ %
{#1}_{#3}\FunctionTypeExtends{#2}_{#3}}}
% Used to specify simple non-generic function types: Same syntax as in source.
% Arguments: Return type, formal parameter declarations.
\newcommand{\FunctionTypeSimple}[2]{\code{\ensuremath{#1}\ \FUNCTION({#2})}}
% Used to specify simple generic function types: Same syntax as in source.
% Arguments: Return type, formal parameter declarations.
\newcommand{\FunctionTypeSimpleGeneric}[3]{\code{%
\ensuremath{#1}\ \FUNCTION<{#2}>({#3})}}
% Used to specify function types: Same syntax as in source.
% Arguments: Return type, spacer, type parameter name, bound name,
% number of type parameters, formal parameter declarations.
\newcommand{\FunctionType}[6]{\leavevmode\par\noindent\code{%
\ensuremath{#1}{#2}\FUNCTION<\FTTypeParameters{#3}{#4}{#5}>({#6})}}
% Same as \FunctionType except suitable for inline usage, hence omitting
% the spacer argument.
\newcommand{\RawFunctionType}[5]{\code{%
\ensuremath{#1}\ \FUNCTION<\FTTypeParameters{#2}{#3}{#4}>({#5})}}
% Used to specify function type parameter lists with positional optionals.
% Arguments: Parameter type, number of required parameters,
% number of optional parameters.
\newcommand{\FunctionTypePositionalArguments}[3]{%
\List{#1}{1}{#2},\ [\List{#1}{{#2}+1}{{#2}+{#3}}]}
\newcommand{\FunctionTypePositionalArgumentsStd}{%
\FunctionTypePositionalArguments{T}{n}{k}}
% Used to specify function types with positional optionals:
% Arguments: Return type, spacer, type parameter name, bound name,
% number of type parameters, parameter type, number of required parameters,
% number of optional parameters.
\newcommand{\FunctionTypePositional}[8]{%
\FunctionType{#1}{#2}{#3}{#4}{#5}{%
\FunctionTypePositionalArguments{#6}{#7}{#8}}}
% Same as \FunctionTypePositional except suitable for inline usage,
% hence omitting the spacer argument.
\newcommand{\RawFunctionTypePositional}[7]{%
\RawFunctionType{#1}{#2}{#3}{#4}{%
\FunctionTypePositionalArguments{#5}{#6}{#7}}}
% Used to specify function type parameter lists with named optionals.
% Arguments: Parameter type, number of required parameters,
% name of optional parameters, number of optional parameters.
\newcommand{\FunctionTypeNamedArguments}[4]{%
\List{#1}{1}{#2},\ \{\PairList{#1}{#3}{{#2}+1}{{#2}+{#4}}\}}
\newcommand{\FunctionTypeNamedArgumentsStd}{%
\FunctionTypeNamedArguments{T}{n}{x}{k}}
% Used to specify function types with named parameters:
% Arguments: Return type, spacer, type parameter name, bound name,
% number of type parameters, parameter type, number of required parameters,
% name of optional parameters, number of optional parameters.
\newcommand{\FunctionTypeNamed}[9]{%
\FunctionType{#1}{#2}{#3}{#4}{#5}{%
\FunctionTypeNamedArguments{#6}{#7}{#8}{#9}}}
% Same as \FunctionType except suitable for inline usage, hence omitting
% the spacer argument.
\newcommand{\RawFunctionTypeNamed}[8]{%
\RawFunctionType{#1}{#2}{#3}{#4}{%
\FunctionTypeNamedArguments{#5}{#6}{#7}{#8}}}
% Used to specify function types with no optional parameters:
% Arguments: Return type, spacer, type parameter name, bound name,
% number of type parameters, parameter type,
% number of parameters (all required).
\newcommand{\FunctionTypeAllRequired}[7]{%
\FunctionType{#1}{#2}{#3}{#4}{#5}{\List{#6}{1}{#7}}}
\newcommand{\FunctionTypePositionalStd}[1]{%
\FunctionTypePositional{#1}{ }{X}{B}{s}{T}{n}{k}}
\newcommand{\RawFunctionTypePositionalStd}[1]{%
\RawFunctionTypePositional{#1}{X}{B}{s}{T}{n}{k}}
\newcommand{\FunctionTypeNamedStd}[1]{%
\FunctionTypeNamed{#1}{ }{X}{B}{s}{T}{n}{x}{k}}
\newcommand{\RawFunctionTypeNamedStd}[1]{%
\RawFunctionTypeNamed{#1}{X}{B}{s}{T}{n}{x}{k}}
\newcommand{\FunctionTypeAllRequiredStd}[1]{%
\FunctionTypeAllRequired{#1}{ }{X}{B}{s}{T}{n}}
\newcommand{\FunctionTypePositionalStdCr}[1]{%
\FunctionTypePositional{#1}{\\}{X}{B}{s}{T}{n}{k}}
\newcommand{\FunctionTypeNamedStdCr}[1]{%
\FunctionTypeNamed{#1}{\\}{X}{B}{s}{T}{n}{x}{k}}
\newcommand{\FunctionTypeAllRequiredStdCr}[1]{%
\FunctionTypeAllRequired{#1}{\\}{X}{B}{s}{T}{n}}
\newcommand{\MoreSignatureSpecificSymbol}{\ensuremath{\preceq}}
\newcommand{\NotMoreSignatureSpecificSymbol}{\ensuremath{\not\preceq}}
\newcommand{\LessSignatureSpecificSymbol}{\ensuremath{\succeq}}
\newcommand{\MoreSignatureSpecific}[2]{%
\ensuremath{{#1}\MoreSignatureSpecificSymbol{#2}}}
\newcommand{\NotMoreSignatureSpecific}[2]{%
\ensuremath{{#1}\NotMoreSignatureSpecificSymbol{#2}}}
% Judgment expressing that a subtype relation exists.
\newcommand{\Subtype}[3]{\ensuremath{{#1}\vdash{#2}\,<:\,{#3}}}
\newcommand{\SubtypeStd}[2]{\Subtype{\Gamma}{#1}{#2}}
% Subtype judgment where the environment is omitted (NE: "no environment").
\newcommand{\SubtypeNE}[2]{\ensuremath{{#1}\,<:\,{#2}}}
% Judgment expressing that a supertype relation exists.
\newcommand{\Supertype}[3]{\ensuremath{{#1}\vdash{#2}\,:>\,{#3}}}
\newcommand{\SupertypeStd}[2]{\Supertype{\Gamma}{#1}{#2}}
% Judgment expressing that an assignability relation exists.
\newcommand{\AssignableRelationSymbol}{\ensuremath{\Longleftrightarrow}}
\newcommand{\Assignable}[3]{%
\ensuremath{{#1}\vdash{#2}\,\AssignableRelationSymbol\,{#3}}}
\newcommand{\AssignableStd}[2]{\Assignable{\Gamma}{#1}{#2}}
% Semantic function delivering the superinterfaces of a class.
\newcommand{\Superinterfaces}[1]{\ensuremath{\metavar{Superinterfaces}({#1})}}
\newcommand{\Superinterface}[2]{{#1}\in\Superinterfaces{#2}}
% ----------------------------------------------------------------------
% Support for hash valued Location Markers
Working insertion of hash values; added a few labels in spec Hash values are now computed for each "paragraph" starting with \LMHash (which includes subsequent grammar, dartCode, itemize blocks, but stops at \section-like commands). Now addlatexhash.dart expects three arguments (first the source latex file, then the destination simplified and hash-value-annotated latex source file, and finally a file name used to create the list of hash values emitted). Adjusted testing accordingly. Added a test for robustness of the hash value generation: It is checked that lots of different "unimportant" changes make no difference for the generated hash values (e.g., we can add/remove comments, change white space, add \commentary{..} etc. without changing the hash values). In order to ensure that all "structure" commands in the spec have a label, I added an \LMLabel{..} a handful of places, following the style which is used throughout the spec. In dart.sty, the \renewcommand that made \LMHash{} produce a fixed hash value has been removed such that the actual hash values are now inserted into the generated spec PDF/DVI file. Tests have been adjusted to handle this difference between the spec with and without hash values when comparing the two. R=gbracha@google.com, lrn@google.com, ricow@google.com Committed: https://code.google.com/p/dart/source/detail?r=41658 Reverted: https://code.google.com/p/dart/source/detail?r=41662 Review URL: https://codereview.chromium.org//652993005 git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41687 260f80e4-7a28-3924-810f-c04153c831b5
2014-11-12 08:41:55 +00:00
% very small font, to enable 40 char hash values in the margin
\makeatletter
\ifcase \@ptsize \relax% 10pt
\newcommand{\miniscule}{\@setfontsize\miniscule{2}{3}}% \tiny: 5/6
\or% 11pt
\newcommand{\miniscule}{\@setfontsize\miniscule{3}{4}}% \tiny: 6/7
\or% 12pt
\newcommand{\miniscule}{\@setfontsize\miniscule{3}{4}}% \tiny: 6/7
\fi
\makeatother
% white: location markers should not create visual noise
\definecolor{LMdim}{gray}{1.0}
% insert location marker showing hash value of following paragraph
\newcommand{\LMHash}[1]{\leavevmode\marginpar{\quad%
\raisebox{0.5ex}{\miniscule{\color{LMdim}#1}}\vspace{-2\baselineskip}}%
\color{normativeColor}}
% support convenient renewcommand
\let\OriginalLMHash\LMHash
% define a label, and show the associated logical location marker
\newcommand{\LMLabel}[1]{%
\vspace{-\baselineskip}\leavevmode\OriginalLMHash{\raisebox{10ex}{#1}}%
\label{#1}}
% ----------------------------------------------------------------------