-
Notifications
You must be signed in to change notification settings - Fork 84
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
Bold change: Continue supporting LR's --array --ghc --coerce
mode, abandon the rest
#268
Comments
In general, I second this. That should be The decision on major changes is with the primary maintainers @int-index @Ericson2314 . |
For context, I proposed bringing #272 (which introduces other breaking changes around It would probably be good to fix this issue as the first action before we rebase #272 on top of it and would likely lead to simplifications of #272 in turn. For example, we could finally give accurate type signatures in the template file rather than generating them from Either way, this work would probably be bound for |
What do the other maintainers think? @int-index @Ericson2314 any strong opinions? I think it would make the template files much simpler if we could just assume that it's OK to unbox integers, user coercions, etc. It would also make the life of @Kariiem much simpler, who is the GSoC student working on |
I feel rather strongly that we should retain the option of generating safe code without |
* Support ArrayTarget as the default and only supported target, see #268. * Update HappyTemplate.hs Undoing an accidental removal --------- Co-authored-by: Karim Taha <[email protected]> Co-authored-by: Sebastian Graf <[email protected]>
I agree with that |
I want to ask for feedback regarding @andreasabel's excellent suggestion
This sounds like a good idea in principle, but shouldn't we rather (or also) warn when the flags are omitted rather than when they are present? That is, we could warn
I think (1) is what Andreas suggested, which makes sense. (2) on the other hand depends on whether we regard the payload here as a breaking change. I think we do, do we? Then perhaps |
Well, if the final target is to remove these options, I wouldn't warn about missing Of course, turning on |
Please don't, if it's not a must. It will make e.g. |
Cabal always passes For stable tools like |
I was toying with adding a flag So we should emit a warning if |
#290 provides the fix. Example warning:
|
The happy LR backend has 24 different modes, making it quite insane to maintain and extend. These 24 modes depend on
[Token]
available--array
) or a recursive ascent parser with explicit stack (i.e., generate Haskell code, the default).--array
based parsers tend to be introspectable (this is huge) and smaller but a bit slower. (The latter seldomly matters for an LR parser, because the language it parses will need name resolution and type checking as well.)--ghc
) for using unboxed integers and bytestrings (in--array
mode)unsafeCoerce
for another performance boost (--coerce
)Realistic applications only ever tend to use
--array --ghc --coerce
. I suggest we abandon the non-array, non-ghc modes to get down to a more manageable 4 modes, not least because it also means we can get rid of the mandatory{-# LANGUAGE CPP #-}
that is currently emitted: #263 Ironically, that means that even the code generated without passing--ghc
is GHC dependent. Plus, I don't have any plans to make error resumption work in recursive ascent mode, because the stack unwinding necessary would need a lot of work that is entirely orthogonal to the table-based mechanism.The text was updated successfully, but these errors were encountered: