Introduce ?TYPE macro
#296
Conversation
|
Thanks for the PR, but I have some questions / concerns about it. I understand the rationale for allowing the possibility to run PropEr without the parse_transform, but the current description of the PR is very vague (and slightly contradictory). Most notably, it does not come with any description of what is allowed (or not allowed) to be the argument of the Second, can I use
Third, I am a bit uncertain whether allowing to write Finally, but perhaps these are only minor issues, I have a slight trouble with the phrasing that the PR message uses.
|
It allows explicitly using PropEr's "native types" feature.
This is more powerful than the current automatic parse transform-based inference:
* it can be used outside of `?FORALL` to produce PropEr types & combine
them with other PropEr or native types.
* it allows using the "native types" feature with the proper parse transform disabled
* it allows expressing more types directly, without creating additional type aliases,
for example: `?TYPE(atom() | float())`.
The semantics are identical to automatic inference, if the expression was wrapped
in a simple `id` type (when the syntax allows expressing such a type). For example:
```erlang
-record(foo, {}).
-type id(X) :: X.
% semantically equivalent definitions:
?FORALL(X, id(#foo{}), Prop).
?FORALL(X, ?TYPE(#foo{}), Prop).
```
michalmuskala
force-pushed
the
type-macro
branch
from
bb23466 to
50fb72d
Compare
michalmuskala
changed the title
?TYPE macro
|
Hi @kostis, thank you for your feedback. I updated the description to make it clearer, and I've also updated the documentation to mention the Indeed, this is adding a new feature. The fact that it enables using PropEr's "native types" feature without the parse transform is a side-effect (quite desirable to me, though, and the initial trigger for developing this feature). I believe the updated commit message and documentation should address your concerns & questions. I believe the only element that is not addressed is: "is this a good idea": I believe it is, making PropEr more powerful and succinct in what it can express. Moreover, the -type id(X) :: X.
?FORALL(X, id([atom() | float()]), ...).I believe this change makes PropEr more consistent allowing the same syntax to be used everywhere and not be subject to the limitations of the Erlang parser/compiler. |
Fix an error in building the documentation and improve the wording.
Codecov Report
@@ Coverage Diff @@
## master #296 +/- ##
==========================================
+ Coverage 85.34% 85.42% +0.08%
==========================================
Files 14 14
Lines 4591 4591
==========================================
+ Hits 3918 3922 +4
+ Misses 673 669 -4
Continue to review full report at Codecov.
|
|
Is there anything missing here from my side? |
It allows explicitly using PropEr's "native types" feature.
This is more powerful than the current automatic parse transform-based inference:
?FORALLto produce PropEr types & combinethem with other PropEr or native types.
for example:
?TYPE(atom() | float()).The semantics are identical to automatic inference, if the expression was wrapped
in a simple
idtype (when the syntax allows expressing such a type). For example:Original PR message:
In practice, this is even more powerful than the parse transform. In particular,
it's possible to define ad-hoc types with
?TYPE(X | Y), where before defininga one-off type alias was necessary.