-
-
Notifications
You must be signed in to change notification settings - Fork 647
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
[and/c | or/c]: ignore any/c
| none/c
.
#4437
base: master
Are you sure you want to change the base?
Conversation
Should |
Treating |
I'm not following the comment about remq. And if |
I mean maybe some places already use |
That's definitely true. We could do something similar to the way that |
For But if Welcome to Racket v8.6 [cs].
> (or/c 1 2 (make-none/c 'any/c))
(or/c 1 2)
> (opt/c (or/c 1 2 (make-none/c 'any/c)))
#<opt-chaperone-contract: (or/c 1 2 any/c)> |
@@ -666,34 +665,21 @@ | |||
(define env (contract-random-generate-get-current-environment)) | |||
(λ () (random-any/c env fuel))) | |||
|
|||
(define-struct any/c () | |||
(define-struct any/c (name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before:
Welcome to Racket v8.6 [cs].
> (object-name (or/c any/c any/c any/c))
'named-any/c
After:
Welcome to Racket v8.6 [cs].
> (object-name (or/c any/c any/c any/c))
'any/c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure what's going on here (I can't tell from what I'm reading on github), but I see a diff where a name
field was added to any/c
and I don't think we want that. We should stick with using named-any/c
if we want a name.
I wonder if
And also |
I don't think that's necessary. My thinking is that This is the setup for the way |
It makes sense to me. And what about |
I think |
@@ -620,7 +620,7 @@ | |||
(make-struct-type-property 'prop:any/c)) | |||
|
|||
;; this property's value isn't looked at; it is just a signal | |||
;; that the contract accepts any value | |||
;; that the contract accepts none value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "no" instead of "none"?
[() any/c] | ||
[raw-arg* | ||
(define raw-args (remove-duplicates (filter-not prop:any/c? raw-arg*) eq?)) | ||
(case (length raw-args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not do this. Instead do (null? (cdr contracts))
as a new second case.
@@ -666,34 +672,18 @@ | |||
(define env (contract-random-generate-get-current-environment)) | |||
(λ () (random-any/c env fuel))) | |||
|
|||
(define-struct any/c () | |||
(struct any/c () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is removing define-
here necessary for the rest of the things that are happening in this PR? If not, let's leave it as is. (I would like to keep the history very clean here as I have used it in the past and it's been helpful.)
@@ -706,19 +696,20 @@ | |||
(none/c-name ctc) | |||
val)) | |||
|
|||
(define-struct none/c (name) | |||
(struct none/c (name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto for this change.
#:property prop:flat-contract | ||
(build-flat-contract-property | ||
#:trusted trust-me | ||
#:late-neg-projection none-curried-late-neg-proj | ||
#:stronger (λ (this that) #t) | ||
#:equivalent (λ (this that) (none/c? that)) | ||
#:stronger (λ (this that) (prop:none/c? that)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this change is incorrect. If there aren't test cases that this change breaks, let's add some.
(cond | ||
[(ormap prop:any/c? args) (named-any/c (contract-name the-or/c))] | ||
[else the-or/c])])) | ||
(let ([none? (make-none/c '(or/c))]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think adding this let is a good idea. We are already using none?
as somethign elsewhere here and it is a different thing than this. Also, the let change the indentation, making the diff more painful to work through; in this case we can do this without an indentation change by using define
.
[(andmap chaperone-contract? args) | ||
(make-chaperone-first-or/c args)] | ||
[else (make-impersonator-first-or/c args)])])) | ||
(let ([none? (make-none/c '(first-or/c))]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto here with the let
.
(case-lambda | ||
[() or/c:none/c] | ||
[raw-arg* | ||
(define raw-args (remq* (list none/c or/c:none/c (first-or/c)) raw-arg*)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use a none/c?
predicate here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because (or/c ...)
and (opt/c (or/c ...))
should have the same name.
#4437 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not following the answer. Definitely it should be the case that opt/c
is less important than the regular use, so we should improve opt/c
. Can you say more about what's going on here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The contract-name
of (opt/c (or/c ...))
is checked in the test file name.rkt.
So if we use none/c?
, this test will fail:
> (contract-name (or/c (make-none/c 'none) #t #f))
'boolean?
> (contract-name (opt/c (or/c (make-none/c 'none) #t #f)))
'(or/c none #t #f)
> (test-name 'boolean? (or/c (make-none/c 'none) #t #f))
FAILED (#<procedure:contract-name> #<opt-chaperone-contract: (or/c none #t #f)>)
got (or/c none #t #f)
expected boolean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the definition of the name of (opt/c (or/c ...)) .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two options are to adjust the test case to avoid checking opt/c
or to improve opt/c
to recognize this case and drop the call to make-none/c
. I'm happy either way. I think the code that was there, dynamically doing the removal, isn't the best choice, so probably better not to make that more complicated. (If it has to get more complicated, it should be moved into a helper function and a call to the helper function should be generated.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't figured out how to improve opt/c
, so I just avoid checking it.
What's the current status of this PR? |
Before:
After:
And the path error in
contract/private/types.rkt
seems to have no effect on TR, does the current version of TR still need this file to set up information?By the way, I didn't find
define/subexpression-pos-prop/name
in the document.