This prevents users from mistakenly constructing a Tpat_value pattern
using the natural implementation
{ pat with pat_desc = Tpat_value pat }
which breaks the attributes-placement invariant (the attributes are
duplicated with this version, instead of being placed only on the
value pattern, with empty attributes on the computation pattern).
(Suggestion from Jacques Garrigue.)
pat_attributes and pat_extra nodes should be on the inner value
pattern, rather than on the outer computation pattern, so that a user
looking for a specific value-pattern constructor with a specific
attribute does not need to consider the Tpat_value case specifically.
(Thanks to Alain Frisch for this suggestion.)
Value patterns match on a value (the result of computation), while
computation patterns handle the effects (hint hint) of
a computation. The only forms of computation patterns in OCaml today
are value patterns and exception patterns (exception p).
The sub-pattern `p` of the `lazy p` construction should be
a computation pattern, rather than a value pattern. This pull-request
does not make this change.
Most of the changes in this PR are boilerplate -- it really is a lot
of work now to add a new syntactic category to the typed-tree
syntax. This boilerplate is fairly automatic and should be easy to
review.
There is a subtle part to the patch, though: the implementation of the
pattern type-checking. It now has to reconstruct the value/computation
distinction (absent from the parse-tree), and return values from two
different types. Instead of splitting the type-checker in several
functions (which risked code duplications), I choose to use a GADT to
have the same [type_pat] function return two different types depending
on the caller. This is the least invasive way to adapt this part of
the codebase, whose inherent complexity is so large (unfortunately)
that adding a GADT to the mix barely makes a difference.
The previous implementation used global state and was making another
change more difficult than it had to be.
Note: I got rid of `rev_let_bound_idents` in the API because computing
it is no more efficient than `Fun.compose List.rev let_bound_idents`.
(Only the _full versions might have a more-efficient rev_ version,
and those are not exposed, which is the right choice:
a simpler API is worth a list reversal.)
The concrete syntax only allows attributes on tags/constructors/fields
(Rtag, Otag), not on inherited subtypes (Rinherit, Oinherit); we add
this as new enforced invariant in ast_invariants.
Florian Angeletti and myself ran into a problem when trying to use attributes
for ellision of parts of manual example. We wanted to be turn any ast-node
marked with the [@ellipsis] attribute into "..." in the rendering of the
corresponding code block, but for this we need the location of the
attributed node, and it turns out that some constructions supported
attributes without carrying a location:
- Rtag in row_field
- Otag in object_field
- type_exception record
- type_extension record
We added locations in all those positions, guaranteeing the invariant
that all nodes to which attributes can be attached have a precise
position.
This commits extends the pattern syntax to support local open in
patterns. Four new constructions mirroring the expression constructions
are added
* `M.(pattern)`
* `M.[pattern_list]` ⟺ M.([pattern_list])
* `M.{labeled_pattern_list}` ⟺ M.({label_pattern_list})
* `M.[| .. |] ⟺ M.( [| .. |] )
At the typing phase, the construction `M.(pattern)` brings all
identifiers defined within M inside the scope and then proceed with the
typing of `pattern`. All others constructions are desugared to the
`M.(..)` construction during parsing.
Questionable implementation details:
* Currently, the local pattern open use the `type_open` function like
the local expression pattern. However, this implies that values defined
inside `M` are also brought to the scope. A specialized
`type_open_for_pattern` would be more efficient.
This week we merged several changes from Thomas Refis, to allow the
use of exception patterns under or-patterns, to write code such as
match foo x with
| None | exception Not_found -> ...
| Some -> ...
Unfortunately, I failed to properly assess the impact of this change,
and in particular to make sure that Luc Maranget had properly reviewed
this code -- any change to the pattern-matching machinery should be
reviewed by Luc.
The problem that I had not foreseen and that he would have immediately
realized is that, while adapting the pattern-matching *compiler* is
relatively easy (Thomas inserted a transformation at the right place
to separate exception patterns from the others and handle them
separately, using the staticraise construct used by the
pattern-matching compiler to avoid duplicating the
right-hand-side branch), adapting the pattern-matching warnings
machinery is both more subtle and easier to overlook (it may fail
silently and nobody notices, unlike wrong code production). This part
of the compiler is subtle and best understood by Luc, but he does not
have the time to do a proper review of those changes in the timeframe
for the 4.03 feature freeze (mid-December).
I believe the right move in this case, implemented in the present
commit, is to revert the change from trunk (this is not a feature that
we must *imperatively* have in 4.03), do a proper job of understanding
the changes, and integrate the change when we are confident it is
ready. I hope to do this in 2016, together with Luc Maranget and
Thomas Refis -- hopefully this would allow Thomas and I to be more
confident when changing the pattern-matching machinery in the future.
Revert "Merge pull request #343 from trefis/pr7083"
This reverts commit 22681b8d2a, reversing
changes made to a24e4edf0a.
Revert "Merge pull request #341 from trefis/or-exception"
This reverts commit f8f68bd329, reversing
changes made to 1534fe8082.
Revert "Merge pull request #305 from trefis/or-exception"
This reverts commit cfeda89396, reversing
changes made to 77cf36cf82.
Translate [%ocaml.extension_constructor <path>] to the
runtime-representation of the extension constructor denoted by
<path>. This allows one to get the extension constructor without
having to create a dummy value.
From comments in typedtree.mli:
When introduced in 2000, this [type] enabled a more efficient code
generation for optional arguments. However, today the information is
redundant as labels are passed to [transl_apply] too. Could be cleaned
up.
This will enable type-directed optimizations during translation of
module coercions.
WARNING: this breaks Typedtree representation, magic number will have to
be adjusted.
From: Frederic Bour <frederic.bour@lakaban.net>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15582 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02