Hmm... that kind of recursive should still work with an enumerated approach. In part 1, you would have already implemented a ~. based mechanism, and for part 2, you would throw on a ^:_ mechanism (or perhaps a looping equivalent, since you're maintaining a match list for each rule) where you're discarding any intermediate results which have exceeded the maximum length.
But, sure, these are basically parsing rules, and parsing is what bison was designed to do. Thanks, -- Raul On Tue, Dec 29, 2020 at 11:12 AM David Lambert <[email protected]> wrote: > > Part 2 changes the rules to be recursive. Encountering shift/reduce > or reduce/reduce conflicts the generalized bison parser tries both. > Anyway, I applied the rules to match each string rather than trying to > itemize productions. Maybe that works since there's a maximal string > length. When my j solution to part 2 failed it dawned on me that the > rules were in BNF. > > |Date: Mon, 28 Dec 2020 21:59:58 -0500 > |From: Raul Miller <[email protected]> > |To: Chat forum <[email protected]> > |Subject: Re: [Jchat] https://adventofcode.com/2020/day/19 > |Message-ID: > | <CAD2jOU_q7WWAsVWdK5e83xddnkkO=zvwt5forjrpvgtupf+...@mail.gmail.com > > > |Content-Type: text/plain; charset="UTF-8" > | > |Seems to me that that problem consists of itemizing the possibilities > |for each rule. Or does part 2 get into an example which exceeds a > |threshold in the vicinity of a billion possibilities? (I must admit > |that I haven't indulged, this year.) > | > |Thanks, > |-- > |Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
