You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If going through the motions to reinvent the wheel and already having access to a parser, why not make it uniquely advantageous and practical?
One of the biggest problems with bash and traditional shells is slow execution speed of loading and interpreting constant source files.
While avoiding the moderately more difficult cases of non-constant sourcing and eval as potential interpretive "hole" sequence points, but most other bits are low-hanging fruit source transformable into machine code ahead-of-time.
Love the idea! Thanks for the links as well, I'll read through them.
(We've dipped our toes into memoizing simple sub-operations like tokenizing, but haven't tackled anything more interesting in that direction.)
More broadly, we're definitely open to creative ideas like this. Whether it's for the sake of performance, inspectability/security, or testing/analysis--I'd wholly agree it's worthwhile to find interesting ways to leverage our "reinventing the wheel" 🙂
If going through the motions to reinvent the wheel and already having access to a parser, why not make it uniquely advantageous and practical?
One of the biggest problems with bash and traditional shells is slow execution speed of loading and interpreting constant source files.
While avoiding the moderately more difficult cases of non-constant sourcing and eval as potential interpretive "hole" sequence points, but most other bits are low-hanging fruit source transformable into machine code ahead-of-time.
References, prior art and discussion:
The text was updated successfully, but these errors were encountered: