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? 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
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: