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.)
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 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 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.
.. and allow any letter in [g-zG-Z] as modifier (previously 'l','L','n')
Also allow modifier for floats
This give more freedom to ppx rewritters (what about a ppx for zarith)
Checks are performed when translating from Parsetree to Typedtree.
Invalid_literal is raised if the modifier is not recognized ([lLn]?)
Integer_overflow is raised as before.
Lexer: use g-zG-Z for integer literal modifier
Lexer: Allow modifier on float
Clean wrt previous commits
Lexer: use named substring
Cleanup
typo
doc
fix after rebase
rebase on trunk
Update typecore.ml
Fix printast.ml
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 allows library user to override the untyping behavior of specific
typedtree nodes.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15888 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This makes them available in compiler-libs, enabling various uses
outside the compiler.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15886 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Leandro Ostera
Thomas Refis
Drup
Gabriel Scherer
Leo White
Runhang Li
Daniel Bünzli
Hugo Heuzard
Gabriel Radanne
Alain Frisch
Valentin Gatien-Baron
Runhang Li
Mark Shinwell
Fabrice Le Fessant
Pierre Chambart
Damien Doligez
Jeremie Dimino
Nicolas Ojeda Bar
Jacques Garrigue
Jérémie Dimino