Past usage breaks

[Ilmen]

Well, a few days ago, Xalbo pointed out that experimental
bridi-head-less CU does alter the way previously valid sentences are
parsed, and thus break past usage.

[18:49:03] <@xalbo> gerna: lu broda .i cu se cusku mi
[18:49:03] <gerna> (0[{lu <(1broda VAU)1 i> LI'U} cu {<se cusku> <mi
VAU>}])0
[18:49:12] <@xalbo> cipra: lu broda .i cu se cusku mi
[18:49:14] <cipra> ([lu {<CU (�broda VAU�)> <i (�cu [se cusku] [mi
VAU]�)>} LIhU] VAU)
[18:49:25] <@xalbo> I knew I could come up with one if I tried hard
enough :)


I checked through the experimental features of Camxes-Exp and found two
more of them that may break past usage. I show below one example of
parsing alteration for each of them (STD stands for standard grammar,
and EXP for the experimental one):

# CU: { lu coi cu mo }
STD: (0[{lu <(1coi DO'U)1 (1)1> LI'U} cu {mo VAU}])0
EXP: ([lu {<coi DOhU> <cu (�mo VAU�)>} LIhU] VAU)

# VAU+JA: { broda me lu brodo vau je brodi }
STD: (0[{broda <(1me [lu {brodo vau} LI'U] ME'U)1 je brodi>} VAU])0
EXP: (CU [broda {me <lu (�CU [brodo vau] [je {brodi VAU} VAU]�) LIhU>
MEhU}] VAU)

# VAhO: { lu mi .e do vu'o noi broda .e ko'a }
STD: (0[{<lu (1[{mi e do} vu'o {noi <broda VAU> KU'O}] VAU)1 LI'U> e
ko'a} VAU])0
EXP: ([lu {<(�mi [e do]�) (�vu'o [noi {CU <broda VAU>} KUhO] [e ko'a]�)>
VAU} LIhU] VAU)


I guess that tag simplification can cause similar divergences, but it'd
be for silly reasons. .u'i

So, with regard to this, do you think termless CU is still a worthy
feature for Camxes-Exp, or should I remove it?
As for vu'o, I think the change is worthy, as the conditions for the
parse change to happen seem uncommon enough.

Any thought?

mi'e la .ilmen. mu'o

[Gleki Arxokuna]

This is all terrible, due to the {lu} too powerful. Like {lu} is sorta mini-parser that looks for the grammar to break and puts {li'u} at that place.

ofc i wish the behaviour of {lu} could be straightened but i dont see how.

On Wed, Jan 15, 2014 at 3:43 AM, Ilmen <ilmen....@gmail.com> wrote:

Well, a few days ago, Xalbo pointed out that experimental bridi-head-less CU does alter the way previously valid sentences are parsed, and thus break past usage.

[18:49:03] <@xalbo> gerna: lu broda .i cu se cusku mi
[18:49:03] <gerna> (0[{lu <(1broda VAU)1 i> LI'U} cu {<se cusku> <mi VAU>}])0
[18:49:12] <@xalbo> cipra: lu broda .i cu se cusku mi

[18:49:14] <cipra> ([lu {<CU (ąbroda VAUą)> <i (ącu [se cusku] [mi VAU]ą)>} LIhU] VAU)

[18:49:25] <@xalbo> I knew I could come up with one if I tried hard enough :)


I checked through the experimental features of Camxes-Exp and found two more of them that may break past usage. I show below one example of parsing alteration for each of them (STD stands for standard grammar, and EXP for the experimental one):

# CU: { lu coi cu mo }
STD: (0[{lu <(1coi DO'U)1 (1)1> LI'U} cu {mo VAU}])0

EXP: ([lu {<coi DOhU> <cu (ąmo VAUą)>} LIhU] VAU)

# VAU+JA: { broda me lu brodo vau je brodi }
STD: (0[{broda <(1me [lu {brodo vau} LI'U] ME'U)1 je brodi>} VAU])0

EXP: (CU [broda {me <lu (ąCU [brodo vau] [je {brodi VAU} VAU]ą) LIhU> MEhU}] VAU)

# VAhO: { lu mi .e do vu'o noi broda .e ko'a }
STD: (0[{<lu (1[{mi e do} vu'o {noi <broda VAU> KU'O}] VAU)1 LI'U> e ko'a} VAU])0

EXP: ([lu {<(ąmi [e do]ą) (ąvu'o [noi {CU <broda VAU>} KUhO] [e ko'a]ą)> VAU} LIhU] VAU)

I guess that tag simplification can cause similar divergences, but it'd be for silly reasons. .u'i

So, with regard to this, do you think termless CU is still a worthy feature for Camxes-Exp, or should I remove it?
As for vu'o, I think the change is worthy, as the conditions for the parse change to happen seem uncommon enough.

Any thought?

mi'e la .ilmen. mu'o

--
You received this message because you are subscribed to the Google Groups "lojban zasni" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lojban-zasni+unsubscribe@googlegroups.com.
To post to this group, send email to lojban...@googlegroups.com.
Visit this group at http://groups.google.com/group/lojban-zasni.
For more options, visit https://groups.google.com/groups/opt_out.