Replied inline...

On 10 June 2017 at 07:40, Eckhard Bick <[email protected]> wrote:

> 1. We introduce a magic tag LINE, maintained by the compiler, constituted
> by the *whole* reading line (plus the word form at the start) as *one* tag,
> i.e. *without breaking on space*.
>

That part is easy and basically already done. The reading already stores an
ordered list of tags - this is not the problem.


2. If LIST or on-the-fly definitions use a tag parenthesis with space, e.g.
> (Tag1 Tag2), in a rule with the flag TAGORDER, this will be converted
> internally to /^(.* )?Tag1 Tag2( .*)?$/r.
>
>     REMOVE TAGORDER (Tag3) IF (*1 (Tag1 Tag2)) ;
>

That's where it breaks. To change how some sets are compiled (or even
worse, recompiled for non-inline sets) based on a rule flag is a major
change and kludge. There is currently zero interaction between these two
parts, and there shouldn't be. Sets don't know they are being parsed in the
context of a rule, and it would be messy to add markers to not deduplicate
these new kinds of sets.



> In addition to, or instead of, TAGORDER at the rule level, we could also
> introduce the concept of a "nonbreaking space character", e.g. ·
> (mini-bullet) or double underscore, to allow flexible use of tag order down
> at the level of individual contexts: (Tag1·Tag2) or (Tag1__Tag2).
>

In the final solution, I will need to introduce regex-like * . .+ .* (or
whatever) as placeholders for zero, one, one-or-more, zero-or-more any-tags
to let writers express everything.



> Tino, is my intuition correct that it would not be so hard to turn this
> algorithmical idea into code? And what would it cost, speed-wise? Given
> that it would be relevant only for some rules, I guess, it can't be too bad.


Code-wise, not worth delaying the actual implementation for. It'd reach far
into many corners, without actually getting us any closer to the correct
solution.

Speed-wise, it would be bad.

-- Tino Didriksen

-- 
You received this message because you are subscribed to the Google Groups 
"Constraint Grammar" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/constraint-grammar.
For more options, visit https://groups.google.com/d/optout.

Reply via email to