Difference between revisions of "User talk:Popcorndude/Recursive Transfer"

From Apertium
Jump to navigation Jump to search
Line 15: Line 15:
   
 
* Serbo-Croatian clitics
 
* Serbo-Croatian clitics
  +
  +
Serbo-Croatian closely observes Wackernagel's Law that clitics (unstressed functional words) are placed in the second position in all clauses. The first element may be a single word or a noun phrase: Taj je čovjek rekao, "That man (has) said", or Taj čovjek je rekao'.
  +
  +
<pre>
  +
Taj je čovjek rekao.
  +
That is man said.
  +
</pre>
   
 
* Object incorporation
 
* Object incorporation

Revision as of 01:21, 9 March 2019

General comments and things to look at

  • GLR
  • PCFGs


Reading list

Linguistic/transfer phenomena

  • Serbo-Croatian clitics

Serbo-Croatian closely observes Wackernagel's Law that clitics (unstressed functional words) are placed in the second position in all clauses. The first element may be a single word or a noun phrase: Taj je čovjek rekao, "That man (has) said", or Taj čovjek je rekao'.

   Taj  je čovjek rekao.
   That is man    said.
  • Object incorporation
  • Constituent reordering
  • NP-internal reordering
  • Optional NP-internal reordering
  • Ambiguous rules

X de Y -> X Y             memoría de traducción -> translation memory 
       -> Y's X           hermana de mi vecina -> my neighbour's sister
       -> X of Y          constitución de 1812  -> constitution of 1812

Implementation Ideas

Using Bison or something like it might be faster than writing a custom parser and it might also be one less source of error to have that component already exist. On the other hand, it would be really nice to allow rules to handle situations like

           S
          / \
         /   VP
        /    /\
       /    V  NP
      (N)      /\
       |      /  \
       |     /    \
       |   Adj  ^  N
       |________|

Here the subject is being stuck in the middle of another NP, which I'm really not sure how to deal with in Yacc (except maybe by manually reinserting the subject into the input stream when the object is parsed, but that seems like a bad idea). With writing a custom one, we could make it so that the Reduce operation can produce more than one node as output, so a rule for the above could be something like

NP.nom NP.acc -> adj.acc n.nom n.acc {2} {3 1};

or something more general like

NP.$case * -> adj.$case * n.$case {3 1(gender=3.gender)} {2};
# match an adjective and noun with the same case marking, separate by another word
# copy the gender marking from the noun to the adjective and output in N-Adj order
# then deal with the other word

Questions:

  • Should the parser generate a C file and compile like Bison does or should it just generate a rule table and load that from a file?
  • To what extent is it possible and desirable to put parts of this data in the monolingual repositories?
    • If this were possible to the fullest extent it would substantially decrease the total number of rules that need to be written since the Catalan rules could then be reused in every pair that includes Catalan.
    • This would probably require every language to be parsing to more or less the same abstract syntax tree.
    • In any event, there are probably lexical things that affect syntax and would have to be pair-specific

Popcorndude (talk) 18:03, 8 March 2019 (CET)

Recursive transfer talks about glue rules and I think the simplest way to implement that would probably be to not require that the input stream reduce to a single node. That is, an input like "det n det n" could reduce to "NP NP" and then just be output like that without it being a problem that it doesn't get to a root node.
There's also a mention of converting left-recursive grammars to right-recursive ones, and if that's just talking about rules like "X -> y X" then maybe it would make sense to have a notation for arbitrarily many of a term which is then compiled to a left-recursive rule.
Popcorndude (talk) 01:49, 9 March 2019 (CET)