-
Notifications
You must be signed in to change notification settings - Fork 484
[Builtin] Add "dumb" Data
matching
#7209
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
base: master
Are you sure you want to change the base?
Conversation
|
/benchmark lists |
Click here to check the status of your benchmark. |
Comparing benchmark results of 'lists' on '65c6e4d795' (base) and '5aa6ceb229' (PR) Results table
|
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.
This all is well-implemented, but I believe we shouldn't do it.
We had a discussion with Philip DiSarro on Slack. My question to him was
I'm asking because if
chooseData
isn't particularly useful, then neithercaseData
will be and so instead of worrying about the latter I should just implement proper casing onData
using theCase
constructor of the AST
And his answer was
Yes that would be much more impactful from my perspective.
He also said
Either way, this is a very small edge case relative to unwrapping expected constructor.
chooseData
is rarely ever used.
Basically, if chooseData
is rarely ever used and people just unwrap the expected constructor (I
, List
etc), then casing on Data
like implemented here isn't very useful and so we should do the more useful alternative of casing on Constr
specifically to mimic the behavior of SOPs and approximate their efficiency, which is something that is definitely going to be used a lot on the chain.
part of #6602
Here we don't do any elaborate casing on
Constr
constructor ofData
; instead, it will simply case on each constructors ofData
. This might not be useful since this style of casing isn't used frequently in real-world script.Feel free to close this PR, once we have smarter/more useful casing on Constr.