We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
This was suggested to me by @DeLaGuardo.
It seems like there's an elegant extension of s/defn's syntax to support different return schemas per arity:
s/defn
(s/defn foo (:- Return1 []) (:- Return2 [a]))
Transducer functions are a good motivation:
(s/defn map (:- Transducer [f] ...etc) (:- [A] [f & xs] ...etc))
There would need to be a restriction that disallows combining this syntax the original return syntax.
The question is, how to support this in FnSchema? FnSchema is hardcoded with a single return schema.
Idea: we could introduce a new container for a list of FnSchemas:
(->MultipleFnSchemas [(->FnSchema Return1 Inputs1), (->FnSchema Return2 Inputs2)])
Not sure how to extend the syntax of s/=>* to support this. Perhaps repeat the same idea at the syntax level?
s/=>*
(s/multiple-fn-schemas (s/=> Return1 Inputs1) (s/=> Return2 Inputs2))
The text was updated successfully, but these errors were encountered:
No branches or pull requests
This was suggested to me by @DeLaGuardo.
It seems like there's an elegant extension of
s/defn
's syntax to support different return schemas per arity:Transducer functions are a good motivation:
There would need to be a restriction that disallows combining this syntax the original return syntax.
The question is, how to support this in FnSchema? FnSchema is hardcoded with a single return schema.
Idea: we could introduce a new container for a list of FnSchemas:
Not sure how to extend the syntax of
s/=>*
to support this. Perhaps repeat the same idea at the syntax level?The text was updated successfully, but these errors were encountered: