Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve arbitrary function generation #136

Closed
rickynils opened this issue Jan 17, 2015 · 7 comments
Closed

Improve arbitrary function generation #136

rickynils opened this issue Jan 17, 2015 · 7 comments
Assignees

Comments

@rickynils
Copy link
Contributor

This has been discussed for some time. The current way of generating functions are quite stupid, since it will only generate constant functions.
#66 does some changes in this area, but it must be updated to current master. And maybe we should take the Haskell QuickCheck route instead, using some fashion of CoArbitrary.

@rickynils rickynils added this to the 2.0.0 milestone Jan 17, 2015
@rickynils rickynils self-assigned this Jan 17, 2015
@tonymorris
Copy link
Contributor

CoArbitrary, as in Haskell, is not possible given the Gen implementation (returning Option).

@pocketberserker
Copy link
Contributor

I tried to implement CoArbitrary pocketberserker/scalacheck@4293d29 and replace arbitrary function implementation pocketberserker/scalacheck@169d1e4 .

@jedesah
Copy link
Contributor

jedesah commented May 3, 2015

As a side note, it would be really nice if the generated functions could have a nice toString method. When trying to figure out why your property fails, it sort of sucks to see <function2> as the representation of the function that was generated.

I took a stab at a version that uses reflection, and one of the advantages of this approach is that it is possible to generate functions like so:

object Take extends String => String {
  def apply(a: String): String = take(a)
  def toString = "take(_)"
}

But I think reflection is an inferior approach to CoArbitrary. One might use reflection to automate generation of some CoArbitrary or something, but it should not be the main mechanism of generation since that would not allow to take advantage of the type system for customization.

Just something to keep in mind.

Is anyone working on this right now? Is there an estimate?

@non
Copy link
Contributor

non commented Jun 11, 2015

Hello, is there any plan to improve function generation for Scalacheck, either along the lines of @pocketberserker's work, or another way?

@xuwei-k
Copy link
Contributor

xuwei-k commented Jun 11, 2015

pocketberserker's codes still does not work correctly due to mutable random number generator(scala.util.Random)

Maybe there are 2 ways

  • immutable random number generator + State monad like( I have implemented )
  • mutable random number generator + IO monad like (Haskell's QuickCheck ?)

@xuwei-k
Copy link
Contributor

xuwei-k commented Jun 11, 2015

As a side note, it would be really nice if the generated functions could have a nice toString

Is anyone working on this right now? Is there an estimate?

work in progress

@non
Copy link
Contributor

non commented Jun 12, 2015

I created a branch to update Scalacheck to use an immutable RNG, and created a basic Cogen type there. I was able to hack together a Gen[A => B] which produces deterministic, but non-constant, functions:

https://github.com/non/scalacheck/blob/topic/immutable-rng/src/main/scala/org/scalacheck/Gen.scala#L614

The warts around using Option are still there -- I may try something a bit more radical.

@rickynils, is this direction something you'd like to see in a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants