Oh, definitely - and I was not advocating for the removal of the dyad rule.
Good thing to point out, though. Thanks, -- Raul On Fri, Oct 13, 2017 at 1:57 PM, Henry Rich <[email protected]> wrote: > I agree with all you said, but I point out that even though trident could > execute N V N, rule 2 is still necessary, otherwise a sentence like > > - 2 - 3 > > would execute as > > (- 2) - 3 > > Henry Rich > > > On 10/13/2017 1:46 PM, Raul Miller wrote: >> >> I am not quite sure what you are asking here, so I hope that I can be >> forgiven for reviewing some of what I hope are the relevant basics. >> >> Anyways.. here's the full RR(4) parsing table that we are discussing: >> >> ---------- >> >> EDGE VERB NOUN ANY 0 Monad >> EDGE+AVN VERB VERB NOUN 1 Monad >> EDGE+AVN NOUN VERB NOUN 2 Dyad >> EDGE+AVN VERB+NOUN ADV ANY 3 Adverb >> EDGE+AVN VERB+NOUN CONJ VERB+NOUN 4 Conj >> EDGE+AVN VERB VERB VERB 5 Trident >> EDGE CAVN CAVN CAVN 6 Trident >> EDGE CAVN CAVN ANY 7 Bident >> NAME+NOUN ASGN CAVN ANY 8 Is >> LPAR CAVN RPAR ANY 9 Paren >> >> Legend: AVN denotes ADV+VERB+NOUN >> CAVN denotes CONJ+ADV+VERB+NOUN >> EDGE denotes MARK+ASGN+LPAR >> >> ---------- >> >> As you can see, the Trident rules (#5 and #6) come after the Dyad rule >> that you quoted (#2). >> >> Now... to get to the issue where I was saying my thinking was incorrect: >> >> While it's true that the handler for the Dyad rule is the one that >> takes care of the N V N combination, there is nothing prohibiting the >> handler for the Trident rule from being capable of doing the same >> thing (or even being the same handler). Whether that would be a good >> idea or not gets into issues which are probably best saved for a >> different discussion. >> >> (There might or might not be a bit of redundant work with using the >> same handler for both Dyad and Trident. But somewhat redundant >> implementation winds up being characteristic of most parser >> implementations, even if that is not immediately obvious when >> reviewing the code. The nature of abstraction - how we think about >> syntax, for example - can easily lead us into conflicting ideas about >> what should have happened where.) >> >> ---------- >> >> Anyways, bident and trident are parsing rules - they are a patterns >> which (in the case of the J parser) are checked against the current >> four element top of the parsing stack. And, if they match, they >> identify which tokens are to be handed off to their corresponding >> handler. (Two parsing elements are handed off for Bident, and three >> elements are handed off for Trident.) >> >> The details of the handler are up to the implementation. (It makes a >> lot of sense for Bident to have its own "bident handler" and for >> Trident to have its own "trident handler", but technically the parser >> could be designed such that they both use the same handler, which then >> has to figure out for whether it has been given two or three things to >> be handled.) >> >> ---------- >> >> Finally, note that whatever happens, the result of the handler will be >> a single parsing element (a noun, verb, adverb or conjunction) which >> replaces sequence of elements which were passed to the handler. >> >> Does any of this address the questions you were asking? Or, have I >> totally misunderstood what you were asking about? (If I misunderstood, >> perhaps you could try asking again in a different way?) >> >> Oh, and by the way... the RR(4) notation is somewhat documented at >> https://en.wikipedia.org/wiki/LR_parser (In other words: right to left >> parsing, rightmost derivation with 4 token lookahead. ... though, >> thinking about that, the definition of lookahead might mean that it's >> technically RR(3) ... that said, the notation itself is perhaps a bit >> sloppy for describing J's parser.) >> >> Thanks, >> > > > --- > This email has been checked for viruses by AVG. > http://www.avg.com > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
