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

Streamline append VM implementation and remove enums #1643

Closed
wants to merge 3 commits into from

Conversation

wycats
Copy link
Contributor

@wycats wycats commented Oct 30, 2024

This PR begins the process of incrementally implementing many of the improvements in the error recovery branch.

I'm going to start with the easy stuff and work my way up to more complicated parts of the implementation, and in that spirit, this PR has two changes:

  1. Streamline the AppendVM by using private fields and an optional debug field pattern. This simplifies the implementation and also makes it possible to consolidate InternalAppendVM into the normal VM. The benefit of the "opcode-only" subset of the VM was waning anyway, and most of the remaining distinction had to do with private implementation details that are no longer present in the VM interface because they're now implemented using private fields.
  2. Replace const enum and enum with normal constants and literal types. There was a good reason for us to use const enum when we originally made the decision. But the dynamics have changed. Between (a) the fact that we can't reliably that const enum will be compiled away anymore, and (b) the fact that TS now has literal types, using normal constants and literal types is a better choice.

Historically, many of these enums used `const enum`s, which at least had
the benefit of being compiled away at build time.

We've now moved to mostly normal `enum`s, which are both less efficient
than normal constants, and a relic of an earlier TypeScript era before
literal types.

This PR moves all enums to normal constants, and creates types for the
constant values when the code needs them.
@@ -7,7 +7,8 @@ export {
s,
unicode,
} from './lib/builder/builder';
export { Builder, type BuilderStatement } from './lib/builder/builder-interface';
export { type BuilderStatement } from './lib/builder/builder-interface';
export * from './lib/builder/constants';
Copy link
Contributor

Choose a reason for hiding this comment

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

can we export explicitly, instead of export *?
From a "knowing what is here" perspective, * feels like an unneeded indirection, and risks leaking things we don't actually want to expose as public API.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was all public API but sucked into the Builder enum. And the codebase already does a lot of export *.

Copy link
Contributor

Choose a reason for hiding this comment

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

is this file generated?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Negative.

Copy link
Contributor

Choose a reason for hiding this comment

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

it's not too bad

Copy link
Contributor

@NullVoxPopuli NullVoxPopuli left a comment

Choose a reason for hiding this comment

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

I'm surprised how much getting rid of enums helps with general readability

@NullVoxPopuli
Copy link
Contributor

Ope -- this is a regression
image

Copy link
Contributor

@NullVoxPopuli NullVoxPopuli left a comment

Choose a reason for hiding this comment

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

We have a significant perf regression for some reason.

@wycats wycats closed this Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants