First draft of Carbon pattern matching design doc. #87

josh11b · 2020-06-19T21:09:28Z

Describe how matching of structured values may work

geoffromer · 2020-06-23T23:51:02Z

docs/design/pattern-matching.md

+
+There is a lot going on here. First, let's break down the core structure of a
+`match` statement. It accepts a value that will be inspected, here the result of
+the call to `Bar()`. It then will find the _first_ `case` that matches this


The fact that match uses the first match, whereas overload resolution uses the best match, will somewhat erode the consistency/simplicity benefits of treating them as two aspects of the same system. I wonder if it would work to use order only as a tiebreaker when neither choice is a better match than the other? That way overload resolution would never select a different case than match pattern matching would, although it can fail in cases where match would succeed.

geoffromer · 2020-06-23T23:52:15Z

docs/design/pattern-matching.md

+that depends on a generic input value (`N` in the example above) and so is not
+known when typechecking.
+
+### Pattern matching as function overload resolution


Suggested change

### Pattern matching as function overload resolution

### Function overload resolution as pattern matching

geoffromer · 2020-06-23T23:52:46Z

docs/design/pattern-matching.md

+
+### Pattern matching as function overload resolution
+
+The argument list to a function in Carbon is a pattern. Functions may be


Suggested change

The argument list to a function in Carbon is a pattern. Functions may be

The parameter list to a function in Carbon is a pattern. Functions may be

geoffromer · 2020-06-24T00:01:35Z

docs/design/pattern-matching.md

+operated on. This position is espoused in the
+["Carbon closed function overloading" proposal (TODO)](#broken-links-footnote)<!-- T:Carbon closed function overloading proposal -->.
+
+**Question:** Is there a rule for selecting an overload if there are multiple


I'm finding it difficult to keep track of the logical structure of this document: sometimes "Question:" seems to denote an open question, and sometimes it's a question that the doc is going to propose an answer to. Similarly, sometimes "Proposal" seems to introduce a new topic, and other times it seems to answer a previous "Question:". I'd recommend making more use of section headings to distinguish separate topics.

I'd also recommend not explicitly labelling things as "Questions" unless you want to flag them as open questions that you don't have a proposed answer for. You may also want to omit the "Proposal" labels, to avoid issues like on line 358, where the "Proposal" label doesn't actually mark the start of the proposal (as evidenced by the fact that the next word is "furthermore").

geoffromer · 2020-06-25T22:16:19Z

docs/design/pattern-matching.md

+- Function overloading allows multiple patterns, but at compile time any
+  function call must be resolved to match a single pattern.
+
+## Features


In the discussion of keyword, optional, and deduced arguments, and variadics, it would be really helpful to explain how (if at all) these features relate to pattern matching.

geoffromer · 2020-06-25T22:20:31Z

docs/design/pattern-matching.md

+declare as keyword arguments in order to match. See
+["Carbon struct types" (TODO)](#broken-links-footnote)<!-- T:Carbon struct types -->.
+
+**Proposal:** Furthermore, I believe we should use keywords in overload


This phrasing makes it sound like you're talking about keywords like requires (which controls how a function participates in overload resolution). I'd sort of prefer we use a different term that doesn't have that ambiguity ("named arguments", maybe?), but if that ship has sailed we'll need to be religious about saying "keyword arguments" rather than "keywords".

geoffromer · 2020-06-25T22:23:49Z

docs/design/pattern-matching.md

+would be hard to rewrite to avoid using conditions.
+
+We still intend to support conditions in function overload resolution for
+consistency, but the use cases are less clear. Note that in order to satisfy the


Wouldn't pretty much any use case for std::enable_if or C++20 requires be a use case for conditional patterns?

geoffromer · 2020-06-25T22:34:41Z

docs/design/pattern-matching.md

+**Proposal:** Conditions will not be used to affect deductions -- since
+conditions are arbitrary expressions they will be evaluated as a black box
+returning "true" or "false", not as information that can disambiguate tricky
+deduction cases.


Note that C++ tries to peek inside the black box, using structural relationships between requires clauses to determine when an overload is a better match than another. For example, an overload with requires(A && B) will generally be considered a better match than an overload with requires(A). This aspect of requires is pretty complicated (Richard probably has all the details), so I wouldn't say that's a good example for Carbon to follow, but the doc should probably note the contrast between Carbon's approach and C++'s.

geoffromer · 2020-06-25T22:37:27Z

docs/design/pattern-matching.md

+returning "true" or "false", not as information that can disambiguate tricky
+deduction cases.
+
+## Specification


I think it would really help to have a more extended informal description of the design, before the formal specification. Specifications are good at precision and disambiguation, but they're bad at explanation.

Moved content from tuples doc.

geoffromer · 2020-07-27T23:53:20Z

docs/design/pattern-matching.md

+parameters, any may have defaults, and the caller may skip specifying any
+optional argument and still specify later arguments.
+
+### Deduced parameters


As discussed by chat, I think we should explore the possibility of eliminating the out-of-line square bracket syntax for deduced parameters, because deduction is really just a special case of pattern-matching anyway. For example, the examples in this section seem like they could be rewritten to avoid it:

fn DeducesType(_: a) -> Int {

and

fn DeducesSize(FixedLenArray(Int, Int: size): a) -> Int {

kulakowski · 2020-07-29T19:21:53Z

docs/design/pattern-matching.md

+value specification (see above).
+
+**Question:** Do we want to require that all deductions are resolved at compile
+time? This would only be relevant to the `match` statement:


I think to put it another way: when you say 'unique' above, do you mean that for all a1 and a2 that match, a1 == a2? Or something else?

kulakowski · 2020-07-29T19:22:00Z

docs/design/pattern-matching.md

+  if (T != Bool) {
+    return Vec(T);
+  } else {
+    return BitVec;
+  }


This particular example uses type equality. In the case where Bool is one side of the equality, it doesn't matter very much. But in general, reasoning about type equality is going to involve an awful lot of questions to answer. There's no single notion of equality. Is Array<N + M> == Array<M + N>? How high does your type hierarchy go? If it's more than all types are of the same type Type, then it gets more fun. Can you compare types of different super types for equality, for instance?

Structural pattern matching dodges lots of this; Array<M + N> doesn't match Array<M + N>. But non-structural pattern matching can reintroduce the fun. Conditions and deduced matches are nonstructural, I think.case (Array(X), Array(Y)) if X == Y: ....

jsiek · 2020-09-16T12:59:44Z

docs/design/pattern-matching.md

+
+Only the value specification is required.
+
+**Deduced specification:** [ `[`&lt;type> `:` [ `$` | `$$` ] &lt;id>`,` ... `]`


In other Carbon documents its stated that types are given by arbitrary expressions.
So I take it that the "type" non-terminal above should instead be "expression".
But that causes a problem... there's an ambiguity in the syntax between patterns
and tuple expressions... my experimental parser complains of reduce-reduce conflicts
(those are the really bad ones). One thought regarding how to fix this conflict is
to flip the id and the type expression, so it goes id : expression.

jsiek · 2020-09-16T13:42:20Z

docs/design/pattern-matching.md

+
+In all three cases, a &lt;value pattern> can either be:
+
+- &lt;value>


Is the non-terminal defined somewhere? How does it differ from ? Is it a subset of that only includes things like literals and tuples of literals?

github-actions · 2021-08-14T01:48:03Z

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please comment or remove the inactive label.
This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.

github-actions · 2021-08-29T01:48:50Z

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active or becomes active again, please reopen it.
This PR was closed and archived because there has been no new activity in the 14 days since the inactive label was added.

First draft of Carbon pattern matching design doc.

05205ad

googlebot added the cla: yes PR meets CLA requirements according to bot. label Jun 19, 2020

josh11b added 5 commits June 19, 2020 14:12

Fill in PR number.

eddbd68

Fix a few conversion mistakes.

0724653

Manually run pre-commit.

ab6f76c

More markdown conversion fixes.

77e6f09

More backticks

2eb977c

josh11b added proposal A proposal WIP labels Jun 22, 2020

josh11b mentioned this pull request Jun 23, 2020

Carbon <-> C/C++ interoperability #80

Closed

More details about template/generic constants.

0730b08

geoffromer reviewed Jun 25, 2020

View reviewed changes

chandlerc changed the base branch from master to trunk July 2, 2020 03:20

josh11b added 9 commits July 6, 2020 15:05

Fix escaping.

ac21393

Update to reflect new tuples doc.

0ff93de

Add pointer to generics doc.

45577a2

match statements and cases takes comma-separated lists in parens.

8eb9c9f

Move type deduction text from structs doc.

923bd40

Fix argument vs. parameter distinction.

26dfae1

Fix presubmits.

31d9822

Expand variadics section.

37215ce

Moved content from tuples doc.

A bit more on variadics

ce4a6ff

geoffromer reviewed Jul 27, 2020

View reviewed changes

kulakowski reviewed Jul 29, 2020

View reviewed changes

Add details to "Deducing parameters of types"

95f9c7c

jsiek reviewed Sep 16, 2020

View reviewed changes

jonmeow marked this pull request as draft April 20, 2021 16:20

jonmeow removed the WIP label Apr 20, 2021

github-actions bot added the inactive Issues and PRs which have been inactive for at least 90 days. label Aug 14, 2021

github-actions bot closed this Aug 29, 2021

github-actions bot added the proposal deferred Decision made, proposal deferred label Jul 25, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First draft of Carbon pattern matching design doc. #87

First draft of Carbon pattern matching design doc. #87

josh11b commented Jun 19, 2020

geoffromer Jun 23, 2020

geoffromer Jun 23, 2020

geoffromer Jun 23, 2020

geoffromer Jun 24, 2020

geoffromer Jun 25, 2020

geoffromer Jun 25, 2020

geoffromer Jun 25, 2020

geoffromer Jun 25, 2020

geoffromer Jun 25, 2020

geoffromer Jul 27, 2020

kulakowski Jul 29, 2020

kulakowski Jul 29, 2020

jsiek Sep 16, 2020 •

edited

Loading

jsiek Sep 16, 2020

github-actions bot commented Aug 14, 2021

github-actions bot commented Aug 29, 2021

	### Pattern matching as function overload resolution
	### Function overload resolution as pattern matching


		### Pattern matching as function overload resolution

		The argument list to a function in Carbon is a pattern. Functions may be

	The argument list to a function in Carbon is a pattern. Functions may be
	The parameter list to a function in Carbon is a pattern. Functions may be


		Only the value specification is required.

		Deduced specification: [ `[`<type> `:` [ `$` \| `$$` ] <id>`,` ... `]`


		In all three cases, a <value pattern> can either be:

		- <value>

First draft of Carbon pattern matching design doc. #87

First draft of Carbon pattern matching design doc. #87

Conversation

josh11b commented Jun 19, 2020

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

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jsiek Sep 16, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Aug 14, 2021

github-actions bot commented Aug 29, 2021

jsiek Sep 16, 2020 •

edited

Loading