Update pre-null-safety spec with new null safety sections #2023

eernstg · 2021-12-10T12:40:12Z

This PR was created by deleting the sections from Subtypes to (but not including) Reference plus the appendix Algorithmic Subtyping, and inserting the section Subtypes from the null safety update branch plus all the following sections until (but not including) Reference, plus the new version of the appendix Algorithmic Subtyping.

The point is that this PR introduces a large chunk of the new material related to null safety which is introduced into the language specification, and it does not include all the small changes to sections that are mostly the same as before (those changes will be submitted as other PRs later on). In other words, the text before Subtyping is unchanged (apart from the fixes mentioned below), and references from the new material to any location before Subtyping may thus very well refer to obsolete language.

A couple of other updates were necessary in order to make the result LaTeX'able:

dart.sty was updated to be the version used with the null safety PR (the new version includes a number of declarations that are used by the material about null safety).
dartLangSpec.tex was updated to use \Delta rather than \Gamma to denote a type variable environment (that's the common notation; we previously used \Gamma, but that's typically a "term" variable environment, so \Delta would be less confusing for readers who also read research papers involving type systems).
\RawFunctionTypeNamed was updated to allow for the required modifier; a couple of changes were necessary in sections before Subtyping in order to make dartLangSpec.tex LaTeX'able again, but this only involved adding the new LaTeX macro argument {r}, further updates will take place later on (this update just updates stuff from Subtyping and out).
The symbol used to indicate that a word or phrase is being defined was changed from \diamond to \triangle, because \triangle is now also used over = in order to indicate that a certain term of the form A = B defines A.
Compile-time errors are now also indicated in the margin (using an \ominus symbol, similar to the symbolic traffic sign meaning "No entrance"), this symbol is used in the new material, that is, nowhere before section Subtyping; for instance, it occurs in section Type Null.

Unfortunately, the diff algorithm in git (and, probably, almost any diff algorithm) does not quite understand that the operation performed here is "delete two big chunks of text and insert replacements that are mostly new material", but it does seem to get on track after a while.

eernstg · 2022-01-06T17:02:28Z

An update fixing a few issues with interface types is on the way, will upload in half an hour, approx. ;-)

eernstg · 2022-01-06T17:17:17Z

Done.

github-actions · 2022-01-10T13:29:21Z

Visit the preview URL for this PR (updated for commit 6cd9296):

https://dart-specification--pr2023-specify-null-safety-56htdccy.web.app

_{(expires Mon, 11 Jul 2022 14:42:40 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 6941ecd630c4f067ff3d02708a45ae0f0a42b88a}

chloestefantsova · 2022-04-27T12:38:30Z

chloestefantsova · 2022-04-29T15:00:14Z

I checked the part "Rules of Inference", in the green "after" column the lines range from 20728 to 20889. It looks good to me.

EDIT: In my review I assumed that the requirement for the bounds of two function types is to be in the mutual-subtypes relationship. After a conversation with Erik I realized that the spec needs to be updated to mean that.

specification/dartLangSpec.tex

chloestefantsova · 2022-05-04T14:18:58Z

I reviewed the part "Subsequent commentary" to the subtype algorithm, in the green "after" column the lines range from 20889 to 21291. I have two drive-by questions to the surrounding text. Otherwise, the part LGTM.

specification/dartLangSpec.tex

chloestefantsova · 2022-05-16T12:18:47Z

I checked the part "Type Nullability", in the green "after" column the lines range from 21291 to 21414. I have left some comments, but otherwise LGTM.

specification/dartLangSpec.tex

chloestefantsova · 2022-05-16T13:18:41Z

I checked the part "Top merge", in the green "after" column the lines range from 21414 to 21494. LGTM with one comment.

chloestefantsova · 2022-05-16T14:14:10Z

I checked the part "IsTopType", in the green "after" column the lines range from 21494 to 21539. It LGTM.

chloestefantsova · 2022-05-17T10:18:32Z

I checked the part "Moretop, morebottom", in the green "after" column the lines range from 21539 to 21582. LGTM.

specification/dartLangSpec.tex

chloestefantsova · 2022-05-17T10:50:03Z

I checked the part "Type normalization", in the green "after" column the lines range from 21582 to 21737. LGTM with one question.

chloestefantsova · 2022-05-17T11:32:19Z

I checked the part "Canonical syntax of types", in the green "after" column the lines range from 21737 to 21931. LGTM.

chloestefantsova · 2022-05-17T11:52:58Z

specification/dartLangSpec.tex

+\end{dartCode}
+
+\commentary{%
+No \emph{least} upper bound exists for \code{A} and \code{B},


As I understand it, with the exception of a top type?

This particular sentence refers to the real, mathematical least upper bound in a set (Dart types) with an ordering relation (subtyping). The usage of 'least upper bound' in older versions of the spec is misleading, because it was never a least upper bound.

So we're looking for a type which is a supertype of both A and B, and it must be the least element among all the types which are supertypes of both A and B. It can't be I because we don't have I <: J; similarly it can't be J. But it also can't be a top type, because we don't have Top <: I (or J, or a bunch of other types).

So I think the claim is correct.

But it also can't be a top type, because we don't have Top <: I (or J, or a bunch of other types).

I don't think I understand this argument. Shouldn't we have I <: Top and J <: Top (in the reverse order) in order to claim Top as the upper bound for both I and J?

Additionally, I think declarations class I {} and class J {} imply class I extends Object {} respectively class J extends Object {}, which makes Object an upper bound for A and B.

True, Object is an upper bound for each of those classes, but that makes no difference: The least upper bound (mathematically speaking) of a set S of elements in an ordered set {v1, .. vk} is an element v from S that satisfies (1) vj <: v, for all j, and (v1 <: other && .. && vk <: other) => v <: other. It's the latter part that fails, so Top and Object aren't 'least', they are just upper bounds.

specification/dartLangSpec.tex

chloestefantsova · 2022-05-18T13:58:10Z

I checked the parts "Class building types", "Interface types", "Intersection types", "Never", "Null", "Type", "Function", "dynamic", in the green "after" column the lines range from 23015 to 24140. LGTM with some comments.

specification/dartLangSpec.tex

chloestefantsova · 2022-05-18T17:56:10Z

specification/dartLangSpec.tex

+\LMHash{}%
+A check of the form \code{$v$\,\,!=\,\,\NULL},
+\code{\NULL\,\,!=\,\,$v$},
+or \code{$v$\,\,\IS\,\,$T$}


Is it true for every type T? What about the case of T = S??

I changed the text to follow the null safety spec precisely about the rule such that we don't need to worry about unintended novelties.

However, v is T where the static type of v is T? is oddly specific, and it certainly doesn't cover the precise behavior of the CFE nor the analyzer.

So we would presumably need to find a way to describe the current behavior of the tools in more detail, such that they can continue to handle cases like X extends int? and still be in sync with the spec. I'll create an issue for that.

I made some changes to the text according to the response in #2258.

chloestefantsova · 2022-05-18T17:58:40Z

I checked the part "Type inference", in the green "after" column the lines range from 24140 to 24613. LGTM with some minor questions.

chloestefantsova · 2022-05-18T18:57:45Z

specification/dartLangSpec.tex

+  \item $B_{0i}[Z_0/X_0, \ldots, Z_k/X_k]$ and $B_{1i}[Z_0/Y_0, \ldots, Z_k/Y_k]$
+    have the same canonical syntax, for $i \in 0 .. k$.


Should we ask for a weaker requirement: the bounds should be mutual subtypes or should be equal if all top types treated as being equal to each other and the bottom types treated as being equal to each other?

Yes! The requirement should be 'mutual subtypes', and it's been updated now. I overlooked the change were === in the null safety feature spec was changed to mean 'mutual subtypes', and that's the reason why I kept the old text because === was still there. That shows the power of change propagation! ;-)

specification/dartLangSpec.tex

chloestefantsova · 2022-05-18T19:01:36Z

I checked the part "Appendix. Algorithmic subtyping", in the green "after" column the lines range fro 24613 to 24847. LGTM with some question. That concludes my initial pass over the PR.

eernstg

Review response.

specification/dartLangSpec.tex

eernstg · 2022-05-25T14:26:11Z

specification/dartLangSpec.tex

+\LMHash{}%
+A check of the form \code{$v$\,\,!=\,\,\NULL},
+\code{\NULL\,\,!=\,\,$v$},
+or \code{$v$\,\,\IS\,\,$T$}


I changed the text to follow the null safety spec precisely about the rule such that we don't need to worry about unintended novelties.

However, v is T where the static type of v is T? is oddly specific, and it certainly doesn't cover the precise behavior of the CFE nor the analyzer.

So we would presumably need to find a way to describe the current behavior of the tools in more detail, such that they can continue to handle cases like X extends int? and still be in sync with the spec. I'll create an issue for that.

eernstg · 2022-05-25T17:05:38Z

specification/dartLangSpec.tex

+\LMHash{}%
+A check of the form \code{$v$\,\,!=\,\,\NULL},
+\code{\NULL\,\,!=\,\,$v$},
+or \code{$v$\,\,\IS\,\,$T$}


eernstg · 2022-06-01T09:24:31Z

specification/dartLangSpec.tex

+\LMHash{}%
+A check of the form \code{$v$\,\,!=\,\,\NULL},
+\code{\NULL\,\,!=\,\,$v$},
+or \code{$v$\,\,\IS\,\,$T$}


I made some changes to the text according to the response in #2258.

eernstg · 2022-06-01T09:26:01Z

specification/dartLangSpec.tex

+  \item $B_{0i}[Z_0/X_0, \ldots, Z_k/X_k]$ and $B_{1i}[Z_0/Y_0, \ldots, Z_k/Y_k]$
+    have the same canonical syntax, for $i \in 0 .. k$.


Yes! The requirement should be 'mutual subtypes', and it's been updated now. I overlooked the change were === in the null safety feature spec was changed to mean 'mutual subtypes', and that's the reason why I kept the old text because === was still there. That shows the power of change propagation! ;-)

specification/dartLangSpec.tex

eernstg · 2022-07-04T14:42:10Z

The PR was rebased on the current master, that is, 3e99947.

… the spec

eernstg assigned leafpetersen Dec 10, 2021

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from 3829332 to f5cb6da Compare January 7, 2022 11:27

eernstg mentioned this pull request Jan 7, 2022

Specify null safety: Sections 'Variables' and 'Local Variable Declarations' #2052

Merged

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from f5cb6da to 24422fc Compare January 11, 2022 12:51

eernstg mentioned this pull request Feb 7, 2022

In "Dart Programming Language Specification 6th edition draft Version 2.15-dev" page 35 #2097

Closed

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from 24422fc to 0fa020d Compare March 4, 2022 11:33

eernstg mentioned this pull request Apr 19, 2022

Adjust wording about extension vs. static method conflicts #2207

Merged

chloestefantsova reviewed May 4, 2022

View reviewed changes

specification/dartLangSpec.tex Show resolved Hide resolved

specification/dartLangSpec.tex Show resolved Hide resolved

eernstg mentioned this pull request May 9, 2022

Crash with invalid named mixin application dart-lang/sdk#48919

Open

chloestefantsova reviewed May 16, 2022

View reviewed changes

specification/dartLangSpec.tex Outdated Show resolved Hide resolved

chloestefantsova reviewed May 16, 2022

View reviewed changes

specification/dartLangSpec.tex Outdated Show resolved Hide resolved

chloestefantsova reviewed May 16, 2022

View reviewed changes

specification/dartLangSpec.tex Show resolved Hide resolved

chloestefantsova reviewed May 16, 2022

View reviewed changes

specification/dartLangSpec.tex Show resolved Hide resolved

chloestefantsova reviewed May 17, 2022

View reviewed changes

specification/dartLangSpec.tex Outdated Show resolved Hide resolved

chloestefantsova reviewed May 17, 2022

View reviewed changes

specification/dartLangSpec.tex Show resolved Hide resolved

chloestefantsova reviewed May 17, 2022

View reviewed changes

specification/dartLangSpec.tex Show resolved Hide resolved

chloestefantsova reviewed May 17, 2022

View reviewed changes

specification/dartLangSpec.tex Outdated Show resolved Hide resolved

chloestefantsova reviewed May 18, 2022

View reviewed changes

specification/dartLangSpec.tex Outdated Show resolved Hide resolved

chloestefantsova reviewed May 18, 2022

View reviewed changes

specification/dartLangSpec.tex Outdated Show resolved Hide resolved

chloestefantsova reviewed May 18, 2022

View reviewed changes

specification/dartLangSpec.tex Show resolved Hide resolved

eernstg mentioned this pull request Jun 1, 2022

Promotion based on a non-null test: Implementation more flexible than specification #2258

Open

eernstg commented Jun 1, 2022

View reviewed changes

eernstg mentioned this pull request Jun 3, 2022

Specify the context type for the index in an increment/decrement operation #2271

Open

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from b9279cb to 6cd9296 Compare July 4, 2022 14:39

eernstg mentioned this pull request Jul 11, 2022

Non-nullable type used in examples #2342

Closed

eernstg mentioned this pull request Nov 2, 2022

Specify null safety #2605

Open

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from 6cd9296 to 66420dd Compare November 30, 2023 17:04

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from 185037e to ddd09ec Compare December 18, 2023 13:49

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from ddd09ec to 6c9de7a Compare September 2, 2024 16:40

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from ea307ec to 430eaf5 Compare September 23, 2024 09:54

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from 430eaf5 to fb18232 Compare October 11, 2024 13:38

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from fb18232 to 8f0fb8e Compare November 25, 2024 09:51

eernstg added 8 commits November 28, 2024 10:32

Update pre-null-safety spec with null safety sections near the end of…

373be23

… the spec

Interface type and subtype rule fixes

2f0329b

Adjusted class building types

a155e97

WIP

b0bd96c

Review response

d62394b

Whitespace

a08a5ca

Fix RawFunctionTypeNamed command

09189ee

Update command \flatten to \Flatten

8322dc2

eernstg force-pushed the specify_null_safety_new_sections_dec21 branch from 8f0fb8e to 8322dc2 Compare November 28, 2024 09:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update pre-null-safety spec with new null safety sections #2023

Update pre-null-safety spec with new null safety sections #2023

eernstg commented Dec 10, 2021 •

edited

Loading

eernstg commented Jan 6, 2022

eernstg commented Jan 6, 2022

github-actions bot commented Jan 10, 2022 •

edited

Loading

chloestefantsova commented Apr 27, 2022 •

edited

Loading

chloestefantsova commented Apr 29, 2022 •

edited

Loading

chloestefantsova commented May 4, 2022

chloestefantsova commented May 16, 2022

chloestefantsova commented May 16, 2022

chloestefantsova commented May 16, 2022

chloestefantsova commented May 17, 2022 •

edited

Loading

chloestefantsova commented May 17, 2022

chloestefantsova commented May 17, 2022

chloestefantsova May 17, 2022

eernstg May 25, 2022

chloestefantsova Jun 1, 2022

eernstg Jun 1, 2022

chloestefantsova commented May 18, 2022

chloestefantsova May 18, 2022

eernstg May 25, 2022

eernstg May 25, 2022

eernstg Jun 1, 2022

chloestefantsova commented May 18, 2022

chloestefantsova May 18, 2022

eernstg Jun 1, 2022

chloestefantsova commented May 18, 2022

eernstg left a comment

eernstg May 25, 2022

eernstg May 25, 2022

eernstg Jun 1, 2022

eernstg Jun 1, 2022

eernstg commented Jul 4, 2022

		\item $B_{0i}[Z_0/X_0, \ldots, Z_k/X_k]$ and $B_{1i}[Z_0/Y_0, \ldots, Z_k/Y_k]$
		have the same canonical syntax, for $i \in 0 .. k$.

Update pre-null-safety spec with new null safety sections #2023

Are you sure you want to change the base?

Update pre-null-safety spec with new null safety sections #2023

Conversation

eernstg commented Dec 10, 2021 • edited Loading

eernstg commented Jan 6, 2022

eernstg commented Jan 6, 2022

github-actions bot commented Jan 10, 2022 • edited Loading

chloestefantsova commented Apr 27, 2022 • edited Loading

chloestefantsova commented Apr 29, 2022 • edited Loading

chloestefantsova commented May 4, 2022

chloestefantsova commented May 16, 2022

chloestefantsova commented May 16, 2022

chloestefantsova commented May 16, 2022

chloestefantsova commented May 17, 2022 • edited Loading

chloestefantsova commented May 17, 2022

chloestefantsova commented May 17, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chloestefantsova commented May 18, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chloestefantsova commented May 18, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chloestefantsova commented May 18, 2022

eernstg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eernstg commented Jul 4, 2022

eernstg commented Dec 10, 2021 •

edited

Loading

github-actions bot commented Jan 10, 2022 •

edited

Loading

chloestefantsova commented Apr 27, 2022 •

edited

Loading

chloestefantsova commented Apr 29, 2022 •

edited

Loading

chloestefantsova commented May 17, 2022 •

edited

Loading