The resulting type system from the migration is here only partly displayed, and will not been commented. It should be enough to say, that I also recurred to the use of templates in the LFG source grammar in order to design the type system. The reader will see that features may have distinct types of values. This is also something which can complicate the migration, since in order to describe an efficient ALEP grammar, one has to make choices upon the various types of values allowed, in dependence of the phenomenon he/she wants to account for. This diversity of kind of types is not present in the LFG source grammar, which thus gives no hint for a decision concerning the type of values to be (optimally) chosen. The inheritance relations are encoded with the > sign. The inheritance relation is also something which is to be designed in a second step, once the LFG source grammar has been migrated:
type( sign:{ syn => type({ syntax:{} }),
sem => type({ semantic:{} }),
spec => type({ specifier:{} }),
refined => atom({ y,n }),
string => list,
rest => list
},
''
).
syntax >
{n_syntax,
d_syntax,
a_syntax > {st_a_syntax,
a_nom_syntax},
st_syntax,
p_syntax > {p_obj_syntax,
p_adj_syntax},
t_syntax
}.
type( syntax:{ agr => boolean([{nom,acc,dat,gen},{fem,mas,neut},
{sg,pl},{p1,p2,p3},{weak,strong}]),
gaps => type({ gap_lists:{} })
},
''
).
type( d_syntax:{ cat => atom({ det, d1, dp, e}),
fcomp => list(type({ sign:{} })),
ehf => atom({ yes, no})
},
''
).
type( n_syntax:{ cat => atom({ noun, n_app, n1, n2, np })
},
''
).
type( p_syntax:{ cat => atom({ p, pp }),
pdet => atom({ yes, no })
},
''
).
type( p_obj_syntax:{ obj => list(type({ sign:{} })),
pcase => atom
},
''
).
....