---------------- 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>
The current specification seems to allow (or even mandate) that a
redirecting constructor (factory or generative) must be considered as a
syntactic shorthand for an invocation of the redirection target, with
no checks applied statically or dynamically according to the
declarations in the redirected constructor. So the following would be
OK:
class A {
A(num n) { print(n); }
A.foo(int i): this(i);
}
main() => new A.foo(3.0);
This CL changes dartLangSpec.tex to mandate all the checks (static
and dynamic) for the declaration of the redirecting constructor as
well as each one of the redirection targets.
Note that the analyzer already rejects the above program, which
lessens the disruption and the implementation burden, but compilers
would presumably need to have the dynamic checks implemented.
Underlying issues: https://github.com/dart-lang/sdk/issues/31590,
https://github.com/dart-lang/sdk/issues/32049,
https://github.com/dart-lang/sdk/issues/32511.
Change-Id: Icc15da6b817e4e678cdfc8829a1e06458756eb4b
Reviewed-on: https://dart-review.googlesource.com/28140
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
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>
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
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
Review URL: https://codereview.chromium.org//652993005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41658 260f80e4-7a28-3924-810f-c04153c831b5
Introduced support for adding SHA1 hash valued location markers
at several levels in the language specification, added long explanatory
comment at the end, added a script 'addlatexhash.dart' to normalize
spacing, remove comments, etc., in the spec, such that the hash values
are more robust than they would be with a direct usage of the spec.
The script passes the "dvi2tty test", that is, when the location markers
are empty, the resulting *.dvi files created from dartLangSpec.tex and
from the version processed by the script give rise to the same text via
dvi2tty, i.e., the script does not destroy the spec.
R=gbracha@google.com, ricow@google.com
Review URL: https://codereview.chromium.org//646003002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41191 260f80e4-7a28-3924-810f-c04153c831b5
Erik Ernst