[00:16:01] *** Quits: wmacmil (~wmacmil@c83-252-138-144.bredband.comhem.se) (Ping timeout: 272 seconds) [03:57:53] *** Joins: drbean (~drbean@TC210-63-209-18.static.apol.com.tw) [10:32:15] *** Quits: drbean (~drbean@TC210-63-209-18.static.apol.com.tw) (Ping timeout: 272 seconds) [12:43:02] *** Joins: wmacmil (~wmacmil@c83-252-138-144.bredband.comhem.se) [12:43:59] is there any place in the rgl [12:44:17] where ast transformation is necessary for translation [12:46:25] like are there certain linguistic features in certain languages so incompatible that it's either (i) impossible to use a shared Abstract or (ii) the complexity of all the bookkeeping in the linear files warrant a simpler solution with to unique, but similair ASTs [12:46:39] i can clarify any of that ^^ [13:35:27] would this thing I've talked about here be related? https://inariksit.github.io/gf/2018/08/28/gf-gotchas.html#linearise-theoretical-forms-and-let-the-application-grammarian-to-deal-with-them [13:35:37] the thing about basque verb forms [13:35:40] "Actually, I wonder if the def feature would work here–just define all trees of form [13:35:40] PredVP (UsePron p) (ComplSlash (SlashV2a v) (UsePron p)) [13:35:40] as the corresponding tree using ReflVP: [13:35:40] PredVP (UsePron p) (ReflVP (SlashV2a v)) [13:35:41] In practice, it won’t work in the RGL, because relevant funs are defined as fun, and they’d need to be defined as data." [13:36:33] *** Joins: drbean (~drbean@TC210-63-209-75.static.apol.com.tw) [13:37:20] the current canon in linguistic features being incompatible is, "it's okay if some trees in the RGL are nonsense, as long as you provide _some_ way to get trees that aren't nonsense" [13:37:36] and that "some way" can involve an Extra or Extend module [13:38:20] so, maybe GF RGL 15 years ago had more ambitious goals, and would've liked to def a `PredVP (UsePron p) (ComplSlash (SlashV2a v) (UsePron p))` into `PredVP (UsePron p) (ReflVP (SlashV2a v))` [13:39:02] but the modern RGL practice is to accept the nonsense tree, because RGL isn't supposed to provide translation equivalents, just a collection of syntactic structures [13:39:19] and it's up to application grammarians to mix and match those structures in their application grammars [14:16:23] *** Quits: wmacmil (~wmacmil@c83-252-138-144.bredband.comhem.se) (Remote host closed the connection) [14:18:30] *** Joins: wmacmil (~wmacmil@c83-252-138-144.bredband.comhem.se) [14:45:31] *** Quits: drbean (~drbean@TC210-63-209-75.static.apol.com.tw) (Ping timeout: 265 seconds) [14:55:22] yeah that's very interesting, and gives me a much better perspective on the Rgl [14:55:48] but i'm also wondering, is there just one central Abstract that encompasses the whole RGL [14:56:40] the RGL has a common core, which is all of Grammar. in addition, there are language-specific extra modules, and Extend as an attempt to unify some of the extensions [14:57:08] there some modified Abstract grammars are written in parallel, with haskell translations modifications of given subsets of the RGL Abstract [14:57:14] or are all the extensions standalone [14:57:27] here's an example how to use an extra module but still mostly the standard RGL: https://inariksit.github.io/gf/2020/11/17/agreement-2.html#controlling-style-in-an-application-grammar [14:57:34] :) [14:57:44] and here's an example of the modified abstract https://github.com/LauretteM/gf-rgl-zul/tree/master/src/zulu [14:58:55] if you need a citation on the zulu RG, here's a paper where they use it https://groups.google.com/g/gf-dev/c/A6lNwZ813b0/m/2h293GzwCgAJ [14:59:56] so yes, both exist, and both can be used in applications!