-
Notifications
You must be signed in to change notification settings - Fork 72
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
Allow trailing comments #30
Comments
@kazu-yamamoto I agree that Say we have a type class class Foo where
instance Foo Int where And a property p :: Foo a => a -> Bool Then the user might want to write.
Any thoughts? |
If this is important, we can write: prop> (p :: Int -> Bool) I think that we should more flexible one to users. I guess that "$" is more flexible than "()" at this moment. |
The user would still need to know about this. How would you document it and make sure that the user actually reads it? Saying something like "Trailing comments do not work!" is relatively clear. An other approach would be to strip trailing comments; but we may run into other corner cases here. I'm really not sure what to do here. |
Just for image: With trailing comments: Without trailing comments: Which do yo prefer? BTW, I guess dropping trailing comments is possible but its implementation would be troublesome. |
Personally I prefer the second. In the first, the comments look too much like being part of the property. I think trailing comments could be useful, but only if they get a different layout (e.g. normal font weight, italic, and gray text color). Something similar to this. prop> xs == ys -- xs always equals ys That would again require parsing. I agree that striping trailing comments could be troublesome. The longer I think about it, the less I like it. So what to do? I'd tend to just document that trailing comments are not supported. What do you think? |
OK. Let's not allow trailing comments at this moment. We can get back this issue if users actually require. |
A given term is enclosed with "(" and ")" when it is passed to quickCheck.
This does not allow trailing comments. For instance,
(where "some" ensures non-empty list and "valid" ensures a tree is well-formed)
Using
$
instead of()
solves this problem. But it breaks a literal with type notation. For instanceBut is this important? I guess typical properties have binary operators which can be parsed even if there are type notations.
The text was updated successfully, but these errors were encountered: