[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lojban] Questions on isolating utterances before completely parsing



>> * Is it true that the fact that LIhU, TOI, and TUhE are elidable makes
>> isolating an utterance impossible without completely parsing the text
>> the utterance is in? (Just making sure.)
>
> I'm not entirely sure what enables those to be elided, but I believe that
> such cases are rare, like only-at-the-end-of-text rare. Also, there are
> various people, me, .xorxes., possibly others I don't know, who feel that
> they should /never/ be elidable anyway.

Those are elidable for exactly the reason that every other terminator
in the language is elidable, and in exactly the same way. The only
usual thing is that those can include {.i} inside them, while most
others cannot. (LEhU and ZOI are the other considerations; not also ZO
and the rest of the Magic Words).

.i mi lu mi prami do cusku

Is completely grammatical text, and parses exactly as though a {li'u}
had been included between {do} and {cusku}. You may not like the
style, but I assert that that is only because you have not
internalized the grammar.

Nonetheless, it's probably legitimate to assume that those cases are
rare. Particularly, it seems completely fair (hypothetically) to make
a parser that exhibits sub-optimal performance in those unusual cases
(reparsing all of the above bridi, instead of just the {mi prami do}
part, for instance).

The continuations approach feels more right in general, though.

>
> Based on that, and the fact that it's expected the user is going to be
> typing more, it's reasonable to assume for the sake of as-you-type parsing,
> they aren't elided if they aren't in the text, as it's assumed that the end
> of current input is not the end of text.
>
> In something like {lu ko'a broda to brodi ko'e li'u}, the {li'u} marks the
> end of the quoted text, so you'd have to allow for that....
>
>>
>> * Should the person make the third parser anyway while making LIhU,
>> TOI, and TUhE *required and non-elidable*?
>
> I say yes, but since that's not official, I should say no. Then again, if
> the third parser /assumes/ non-elidability, I doubt it will cause problems.
>
> Alternatively, you can cause the third parser to assume current-end-of-input
> is always equal to terminate-everything-unterminated, and that should work
> out fine.
>
>>
>> * Is there another practical solution for the editor?
>
> .alyn.'s idea sounds pretty good to me.
>
>>
>> Remember, the problem is that the hypothetical text editor is getting
>> slow because otherwise it needs to parse the entire text for every
>> edit.
>
> Something tells me this "hypothetical" parser isn't very hypothetical. :D
>
> --
> mu'o mi'e .aionys.
>
> .i.a'o.e'e ko cmima le bende pe lo pilno be denpa bu .i doi.luk. mi patfu do
> zo'o
> (Come to the Dot Side! Luke, I am your father. :D )
>
> --
> You received this message because you are subscribed to the Google Groups
> "lojban" group.
> To post to this group, send email to lojban@googlegroups.com.
> To unsubscribe from this group, send email to
> lojban+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/lojban?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.