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

Guards for wrapper types #202

Open
jackfirth opened this issue Sep 10, 2019 · 1 comment
Open

Guards for wrapper types #202

jackfirth opened this issue Sep 10, 2019 · 1 comment
Labels
enhancement New feature or request

Comments

@jackfirth
Copy link
Owner

jackfirth commented Sep 10, 2019

Part of #42. Wrapper types should allow guards. The signature of a wrapper guard should match the contract (-> wrapper-type? any/c any/c), accepting an argument with information about the wrapper type (in order to use the type name in error messages, for instance) and an argument for the value being wrapped. It should return a single value representing the replacement value to wrap (possibly normalized to some canonical form, or wrapped with a chaperone, etc.).

Then, the make-wrapper-implementation function and the define-wrapper-type macro should both accept an optional #:guard parameter matching this contract. As a convenience, a (wrapper-guard/c contract) contract combinator should construct a function suitable for use with the #:guard option that simply checks the field with the contract.

Wrapper type guards can possibly be implemented more efficiently than tuple type guards (see #203), since they can assume exactly one field and there's no need to call apply anywhere in the code that translates tuple guards to struct guards.

@jackfirth jackfirth added the enhancement New feature or request label Sep 10, 2019
@jackfirth jackfirth added this to the Datatypes Alpha Release milestone Sep 10, 2019
@jackfirth jackfirth mentioned this issue Sep 10, 2019
3 tasks
@jackfirth
Copy link
Owner Author

Update: guard functions should probably match the contract (-> wrapper-type? (-> any/c any/c)), just to get any allocation related to error messages out of the way at type creation time.

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

No branches or pull requests

1 participant