Skip to content

[Strings] string.concat #4777

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

Merged
merged 5 commits into from
Jul 8, 2022
Merged

[Strings] string.concat #4777

merged 5 commits into from
Jul 8, 2022

Conversation

kripken
Copy link
Member

@kripken kripken commented Jul 7, 2022

No description provided.

@kripken kripken requested review from tlively and aheejin July 7, 2022 23:27
Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but would it be simpler to make this a BinaryOp rather than an entire new expression class? That's what we did for the SIMD binary operations, for example.

@kripken
Copy link
Member Author

kripken commented Jul 8, 2022

Good question. I followed the example of RefEq, but all of RefEq, StringConcat, StringEq could all be under Binary...

Some reasons to have separate classes:

  • Faster, since we constantly do a switch over all expression classes, and if we have an opcode inside them like Binary does then we'd have two switches basically.
  • Shorter checking code: curr->is<RefEq>() versus checking if it's a binary + checking the op.
  • Atm Binary is basically a simple MVP operation on numeric inputs. It can't trap, has no control flow, etc. When you read something is a Binary in the code that's simpler cognitively.

Some reasons to group into fewer classes with opcodes inside them:

  • Less work when writing a PR like this. Especially with something like SIMD that has a billion operations.
  • When the grouping matters it's simpler cognitively: RefAs is a family of similar operations, and often they are handled in the same way.

Overall my intuition is that grouping is nice when they are very similar, but maybe not otherwise.

If that makes sense, then perhaps we could have a StringBinary or RefBinary. But even StringConcat and StringEq feel "different" to me... only one can trap, for example. I could see an argument for combining RefEq and StringEq in theory...?

@tlively
Copy link
Member

tlively commented Jul 8, 2022

Ah the trapping seems like a good heuristic for when it should be its own class. LGTM!

@kripken kripken merged commit b88bedb into main Jul 8, 2022
@kripken kripken deleted the string.concat branch July 8, 2022 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants