Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Cannot fine-tune the behaviour of the type system integration component #13

Open
norton opened this Issue May 9, 2011 · 3 comments

Comments

Projects
None yet
2 participants
Contributor

norton commented May 9, 2011

I noticed these 2 compiler warnings. Not sure if this is intentional or not.

src/proper_types.erl:213: Warning: missing specification for function from_binary/1
src/proper_types.erl:310: Warning: missing specification for function unwrap/1

$ erl --version
Erlang R14B01 (erts-5.8.2) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.2 (abort with ^G)
1>

Owner

manopapad commented May 9, 2011

I have commented out the specs for those functions as part of a temporary fix that allows PropEr to spec-test itself. Those functions aren't suitable for use in a generator for the proper_types:type() ADT, so I needed to instruct AutoADT to skip them. The problem is that, right now, AutoADT isn't very configurable, so they best quick-and-dirty way to achieve that was to remove those functions' specs altogether.

We do intend to remedy this at some point, and also provide more ways to fine-tune the behaviour of the type system integration components. Some recommendations we have received on this matter include:

  • a way to mark functions as untestable by the spec tester
  • a way to instruct the spec tester to use user-written generators for certain types
  • a way to instruct AutoADT to skip certain functions from an ADT's automatically-produced generator
  • a way to instruct AutoADT to include user-written symbolic calls in an ADT's automatically-produced generator
Contributor

norton commented May 9, 2011

Ok, thanks. I understand.

The recommendations sound very helpful. I implemented similar features for the ubf and eqc_statem "glue" framework. I decided not to modify the UBF contract with such information but leave it the burden to the test code. The goal and scope of a test can change even though the code (or specs) do not change.

I'd be interested to review your plans before you start the implementation.

@norton norton closed this May 9, 2011

@manopapad manopapad reopened this May 9, 2011

Owner

manopapad commented May 9, 2011

That's great, I will notify you once I have a more concrete plan. I will also take a look at your framework for ideas. Of course, if you have any other ideas on this, I'd love to hear them.

PS: Let's keep this issue open as a reminder. I also edited the title to reflect the greater issue.

@ghost ghost assigned manopapad Feb 26, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment