Closed int-index closed 2 years ago
I definitely like genTables
over runTabular
, but do we want to go from the function param to the glr
boolean? I thought happy-tabular
was supposed to be somewhat agnostic to the parsing strategy --- must maybe that's a impossible/nonsensical ideal so the glr
bool is fine?
Sure, I can revert that bit.
Thanks. I took a look at https://github.com/simonmar/happy/pull/200 to confirm and indeed the GLR stuff was pretty well separated in the end, so that goal does look attainable.
Well, #200 uses a Bool
flag too, I used it as a reference.
@int-index Ah I see. Yes, you were very right to demand we make the diffs readable. These things slipped past me.
Also, btw, I am rebasing #200 on master and then this to queue up the next steps, so you can just worry about this for the moment.
Nice! So do we want to merge #200 on top of this?
Definitely some parts of #200, since it introduces the .cabal
files and so on.
Okay, will you and @Ericson2314 do this? I would then after #200 is merged follow up with the next MR concerning the frontend and backend.
Also, I‘d like to make some more grammar-related types derive Show
, and I’d appreciate it if Grammar
would contain hd
and tl
fields so we wouldn’t always have to pass them separately. Can we integrate this in #200 or should this be a follow-up MR?
@knothed see what I wrote in https://github.com/simonmar/happy/pull/200#issuecomment-932634187. I am adding a little checklist to that PR.
This data type encapsulates the result of processing the
Grammar
.In addition to
ActionTable
andGotoTable
, it also includes intermediate results such asLr0Items
, which are needed for debug printing and info table generation.The
find_redundancies
function has been moved fromMain.lhs
toTabular.lhs
almost verbatim (usegit show --color-moved=blocks
to confirm).