questions about camxes PEG grammar
13 views
Skip to first unread message
scope845h...@icebubble.org
Jan 24, 2021, 4:35:34 PM1/24/21
to loj...@googlegroups.com
doi la camxes .a la masatos.xagiuaras .a la gleki .a la ilmen .e zo'e
I'm looking at the PEG grammar for Lojban in the repository at
https://github.com/lojban/ilmentufa and have some questions...
le preti xi pa pi'e pa zo'u:
{za'a} The build system is written in Javascript, and doesn't use a
traditional build system, i.e. "make". {.uanai} Why?
{.e'u} I think the system would be much clearer if it used standard
tools like make, sed, awk, and/or diff/patch. Because PEG files are
line-oriented, awk would probably be preferable to sed. Most systems
that have git (the format of the repository) will already have these
tools. Providing the alternative grammars as diffs would probably be
ideal, because diffs are easily read and understood by human beings,
and can be applied manually, without even needing any extra software
at all. (Any text editor would suffice.)
If I actually did use the JS script to build the alternative grammars,
the next thing I'd do would be to run a diff on them, anyway, to see
what changes are made in each of the grammars. So, using diff & patch
would seem to be most sensible.
le preti xi pa pi'e re zo'u:
{za'a} The README.md is rather confusing and written in broken
English. {ru'a} Without intending any offense, it appears as if
English is not the author's native language.
{.e'u} I would be happy to discuss the README, off-list, to figure out
what the author means, and help re-work the README to make it clearer
and more understandable.
le preti xi pa pi'e ci zo'u:
{za'a} The .peg files contain a brief description of the syntax of
parsing expressions:
...
# 3) Concatenation is expressed by juxtaposition with no operator symbol.
# 4) / represents *ORDERED* alternation (choice). If the first
# option succeeds, the others will never be checked.
# 5) ? indicates that the element to the left is optional.
# 6) * represents optional repetition of the construct to the left.
# 7) + represents one_or_more repetition of the construct to the left.
...
{.uanai} However, it does not specify the order of operations or
relative precedence of each of the operators. For example, does
"a <- b c / d" mean "a <- (b c) / d" or "a <- b (c / d)"? And
does "x <- y / z+" mean "x <- (y / z)+" or "x <- y / (z+)"?
{ja'o} One can intuit the intended order of operations by reading the
file, with a knowledge of Lojban grammar, but {.e'u} more specificity
would be helpful.
le preti xi re pi'e pa zo'u:
{za'a} I noticed that you handle elidible terminators differently in
the PEG than in the EBNF. For example, in the EBNF, one of the
alternatives for sumti-6_97 is:
LI # mex /LOhO#/
But in the PEG, it's:
li_clause <- LI_clause free* mex LOhO_elidible free*
{ja'o} In the EBNF, the free* are only allowed if the terminator is
present. But, in the PEG, it appears that free* can follow an elided
terminator.
{.uanai} What's the rationale for doing this? How do you determine to
which construct the free modifiers apply when the terminator is
omitted?
le preti xi re pi'e re zo'u:
{za'a} There is at least one place in the PEG where the PEG grammar
differs from the EBNF (and the YACC). For example:
#stag = simple_tense_modal ((jek / joik) simple_tense_modal)*
stag <- simple_tense_modal ((jek / joik) simple_tense_modal)* / tense_modal (joik_jek tense_modal)*
{ja'o} The PEG rule which would comply with the EBNF grammar is
commented-out, and replaced with a rule which allows full "tag"s
(i.e., full {fi'o} clauses) anywhere that only simple tags ("stag"s)
used to be allowed. This changes (by expanding it) the set of
utterances that would represent grammatical Lojban text.
{.uanai} What's the rationale for doing this?
{.e'u} If the intent is to implement an extension to Lojban's grammar,
shouldn't this be split-out into a separate "experimental" PEG, like
the others?
le preti xi re pi'e ci zo'u:
{za'a} The PEG grammar, in several places, uses constructs like:
pehe_sa <- PEhE_clause (!PEhE_clause (sa_word / SA_clause !PEhE_clause))* SA_clause
cehe_sa <- CEhE_clause (!CEhE_clause (sa_word / SA_clause !CEhE_clause))* SA_clause
This is an idiom which appears repeatedly in the PEG, but there is no
explanation for what this is doing or why.
{.e'u} Some higher-level explanation of how erasure words are handled
would be helpful.
le preti xi re pi'e vo zo'u:
{za'a} The PEG contains many non-terminals of the form
"<someword>_clause", "<someword>_pre", "<someword>_post",
"<someword>_sa", "pre_clause", and "post_clause", but there is no
explanation of what this is doing or why.
{.e'u} Some higher-level explanation of the conventions used for
naming the non-terminals, and how they interact, would be helpful.
.i ki'esai fa'o
I'm looking at the PEG grammar for Lojban in the repository at
https://github.com/lojban/ilmentufa and have some questions...
le preti xi pa pi'e pa zo'u:
{za'a} The build system is written in Javascript, and doesn't use a
traditional build system, i.e. "make". {.uanai} Why?
{.e'u} I think the system would be much clearer if it used standard
tools like make, sed, awk, and/or diff/patch. Because PEG files are
line-oriented, awk would probably be preferable to sed. Most systems
that have git (the format of the repository) will already have these
tools. Providing the alternative grammars as diffs would probably be
ideal, because diffs are easily read and understood by human beings,
and can be applied manually, without even needing any extra software
at all. (Any text editor would suffice.)
If I actually did use the JS script to build the alternative grammars,
the next thing I'd do would be to run a diff on them, anyway, to see
what changes are made in each of the grammars. So, using diff & patch
would seem to be most sensible.
le preti xi pa pi'e re zo'u:
{za'a} The README.md is rather confusing and written in broken
English. {ru'a} Without intending any offense, it appears as if
English is not the author's native language.
{.e'u} I would be happy to discuss the README, off-list, to figure out
what the author means, and help re-work the README to make it clearer
and more understandable.
le preti xi pa pi'e ci zo'u:
{za'a} The .peg files contain a brief description of the syntax of
parsing expressions:
...
# 3) Concatenation is expressed by juxtaposition with no operator symbol.
# 4) / represents *ORDERED* alternation (choice). If the first
# option succeeds, the others will never be checked.
# 5) ? indicates that the element to the left is optional.
# 6) * represents optional repetition of the construct to the left.
# 7) + represents one_or_more repetition of the construct to the left.
...
{.uanai} However, it does not specify the order of operations or
relative precedence of each of the operators. For example, does
"a <- b c / d" mean "a <- (b c) / d" or "a <- b (c / d)"? And
does "x <- y / z+" mean "x <- (y / z)+" or "x <- y / (z+)"?
{ja'o} One can intuit the intended order of operations by reading the
file, with a knowledge of Lojban grammar, but {.e'u} more specificity
would be helpful.
le preti xi re pi'e pa zo'u:
{za'a} I noticed that you handle elidible terminators differently in
the PEG than in the EBNF. For example, in the EBNF, one of the
alternatives for sumti-6_97 is:
LI # mex /LOhO#/
But in the PEG, it's:
li_clause <- LI_clause free* mex LOhO_elidible free*
{ja'o} In the EBNF, the free* are only allowed if the terminator is
present. But, in the PEG, it appears that free* can follow an elided
terminator.
{.uanai} What's the rationale for doing this? How do you determine to
which construct the free modifiers apply when the terminator is
omitted?
le preti xi re pi'e re zo'u:
{za'a} There is at least one place in the PEG where the PEG grammar
differs from the EBNF (and the YACC). For example:
#stag = simple_tense_modal ((jek / joik) simple_tense_modal)*
stag <- simple_tense_modal ((jek / joik) simple_tense_modal)* / tense_modal (joik_jek tense_modal)*
{ja'o} The PEG rule which would comply with the EBNF grammar is
commented-out, and replaced with a rule which allows full "tag"s
(i.e., full {fi'o} clauses) anywhere that only simple tags ("stag"s)
used to be allowed. This changes (by expanding it) the set of
utterances that would represent grammatical Lojban text.
{.uanai} What's the rationale for doing this?
{.e'u} If the intent is to implement an extension to Lojban's grammar,
shouldn't this be split-out into a separate "experimental" PEG, like
the others?
le preti xi re pi'e ci zo'u:
{za'a} The PEG grammar, in several places, uses constructs like:
pehe_sa <- PEhE_clause (!PEhE_clause (sa_word / SA_clause !PEhE_clause))* SA_clause
cehe_sa <- CEhE_clause (!CEhE_clause (sa_word / SA_clause !CEhE_clause))* SA_clause
This is an idiom which appears repeatedly in the PEG, but there is no
explanation for what this is doing or why.
{.e'u} Some higher-level explanation of how erasure words are handled
would be helpful.
le preti xi re pi'e vo zo'u:
{za'a} The PEG contains many non-terminals of the form
"<someword>_clause", "<someword>_pre", "<someword>_post",
"<someword>_sa", "pre_clause", and "post_clause", but there is no
explanation of what this is doing or why.
{.e'u} Some higher-level explanation of the conventions used for
naming the non-terminals, and how they interact, would be helpful.
.i ki'esai fa'o
gleki.is...@gmail.com
Jan 26, 2021, 12:45:44 AM1/26/21
to lojban
Em segunda-feira, 25 de janeiro de 2021 às 00:35:34 UTC+3, scope845h...@icebubble.org escreveu:
doi la camxes .a la masatos.xagiuaras .a la gleki .a la ilmen .e zo'e
I'm looking at the PEG grammar for Lojban in the repository at
https://github.com/lojban/ilmentufa and have some questions...
le preti xi pa pi'e pa zo'u:
{za'a} The build system is written in Javascript, and doesn't use a
traditional build system, i.e. "make". {.uanai} Why
There are implementations in Java (the original camxes), in python and iirc in haskell
Must be buried in this mriste or the wiki. It's all BPFK discussions.
mezohe
Jan 26, 2021, 1:59:05 PM1/26/21
to loj...@googlegroups.com
2021-01-24 21:36 scope845h...@icebubble.org:
followed by the {sa} itself. For example:
{nelci fa do ce'e ti pe'e je mi ce'e ta sa pe'e je mi'o ce'e ta}
^------pehe_sa------^
Though CONSTRUCT_sa itself doesn't limit what comes after it, it is only
referred to at the beginning of the corresponding CONSTRUCT rule, which
ensures that what follows is something that can start the same kind of
construct that starts the deleted text.
The negative lookaheads are there so that only one "jump" "back" (of
course, the parser actually speculates about SAs basically everywhere)
to the closest start of a CONSTRUCT happens.
SA implemented in this way is flaky (for example, {sa sa}, instead of
deleting a longer text, works like a single {sa}), and it's buggy in all
camxes versions that I've used. In ilmentufa camxes, for example,
sa-deletions can't include zei-lujvo or bu-letterals. SA handling in
PEGs other than standard camxes is even more broken or has been fully
removed.
>
> le preti xi re pi'e vo zo'u:
>
> {za'a} The PEG contains many non-terminals of the form
> "<someword>_clause", "<someword>_pre", "<someword>_post",
> "<someword>_sa", "pre_clause", and "post_clause", but there is no
> explanation of what this is doing or why.
>
> {.e'u} Some higher-level explanation of the conventions used for
> naming the non-terminals, and how they interact, would be helpful.
>
"Clause" in camxes means a word together with any free modifiers before
(pre_clause) or after it (post_clause). pre_clause handles only BAhE.
post_clause handles SI and indicators, and prevents parsing of parts of
zei-lujvo and bu-letterals as their usual selmaho.
I think the grammar uses individual SELMAhO_pre and SELMAhO_post rules,
instead of using pre_clause and post_clause directly in SELMAhO_clause,
only as a relic of an earlier, now removed, way of handling SA. Another
relic of this is the name of any_word_SA_handling, which no longer has
anything to do with SA.
>
> le preti xi re pi'e ci zo'u:
>
> {za'a} The PEG grammar, in several places, uses constructs like:
>
> pehe_sa <- PEhE_clause (!PEhE_clause (sa_word / SA_clause !PEhE_clause))* SA_clause
>
> cehe_sa <- CEhE_clause (!CEhE_clause (sa_word / SA_clause !CEhE_clause))* SA_clause
>
> This is an idiom which appears repeatedly in the PEG, but there is no
> explanation for what this is doing or why.
>
> {.e'u} Some higher-level explanation of how erasure words are handled
> would be helpful.
>
The CONSTRUCT_sa rules are meant to match the text that a {sa} deletes
> le preti xi re pi'e ci zo'u:
>
> {za'a} The PEG grammar, in several places, uses constructs like:
>
> pehe_sa <- PEhE_clause (!PEhE_clause (sa_word / SA_clause !PEhE_clause))* SA_clause
>
> cehe_sa <- CEhE_clause (!CEhE_clause (sa_word / SA_clause !CEhE_clause))* SA_clause
>
> This is an idiom which appears repeatedly in the PEG, but there is no
> explanation for what this is doing or why.
>
> {.e'u} Some higher-level explanation of how erasure words are handled
> would be helpful.
>
followed by the {sa} itself. For example:
{nelci fa do ce'e ti pe'e je mi ce'e ta sa pe'e je mi'o ce'e ta}
^------pehe_sa------^
Though CONSTRUCT_sa itself doesn't limit what comes after it, it is only
referred to at the beginning of the corresponding CONSTRUCT rule, which
ensures that what follows is something that can start the same kind of
construct that starts the deleted text.
The negative lookaheads are there so that only one "jump" "back" (of
course, the parser actually speculates about SAs basically everywhere)
to the closest start of a CONSTRUCT happens.
SA implemented in this way is flaky (for example, {sa sa}, instead of
deleting a longer text, works like a single {sa}), and it's buggy in all
camxes versions that I've used. In ilmentufa camxes, for example,
sa-deletions can't include zei-lujvo or bu-letterals. SA handling in
PEGs other than standard camxes is even more broken or has been fully
removed.
>
> le preti xi re pi'e vo zo'u:
>
> {za'a} The PEG contains many non-terminals of the form
> "<someword>_clause", "<someword>_pre", "<someword>_post",
> "<someword>_sa", "pre_clause", and "post_clause", but there is no
> explanation of what this is doing or why.
>
> {.e'u} Some higher-level explanation of the conventions used for
> naming the non-terminals, and how they interact, would be helpful.
>
(pre_clause) or after it (post_clause). pre_clause handles only BAhE.
post_clause handles SI and indicators, and prevents parsing of parts of
zei-lujvo and bu-letterals as their usual selmaho.
I think the grammar uses individual SELMAhO_pre and SELMAhO_post rules,
instead of using pre_clause and post_clause directly in SELMAhO_clause,
only as a relic of an earlier, now removed, way of handling SA. Another
relic of this is the name of any_word_SA_handling, which no longer has
anything to do with SA.
Reply all
Reply to author
Forward
0 new messages