[liblouis-liblouisxml] Re: Regex question
- From: "John Gardner" <john.gardner@xxxxxxxxxxxx>
- To: <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Sun, 27 Oct 2013 10:00:33 -0700
Susan, maybe I just don't understand what you are saying. Are you proposing
to develop a new DSL with all these structures that needs just a list of
parameters to translate any language? How does that differ from what we
have now? How do we convince many people to write/maintain that DSL? Why
will a new DSL not also break when new structures are introduced, with their
inevitable bugs? How do you overcome Ken's observation that you need to
present people with something they can understand if you want them to
participate?
Why not instead just implement such structures as subroutines, compiled or
not, that are available to people making/maintaining scripts for languages?
Or is this what you are saying, and I have just misunderstood?
I am glad you have joined this list Susan. You have lots of ideas, and we
all learn from you even when we don't end up being persuaded.
John G
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Susan Jolly
Sent: Sunday, October 27, 2013 8:45 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Regex question
We still aren't communicating. The immediate problem isn't how to implement
an action within the engine. The problem is how the person responsible for
maintaining the translation table for a particular braille system can define
a special action and the conditions under which it applies.
Since liblouis handles a large number of different braille systems, it's
been possible to discover that there are many special cases that can be
handled by the same simple action if the action is parameterized. The
various actions are built into the engine but there needs to be a way for
the table maintainer to specify the parameters. If I'm understanding
correctly, John Boyer is suggesting a way for the maintainer to specify a
particular action plus its parameters. In my opinion the details of the
specification should be independent of the method by which the conditions
and action are actually implemented in the engine. For example, it isn't
necessary that the specification use a regex even if use of a regex were to
turn out to be the best way to implement the rule within the engine.
I've worked primarily with EBAE but I've encountered some complex special
rules that don't seem amenable to the above approach. In these case I've
fully implemented the rule, both the conditions and the action, in the
engine. An example is the EBAE rule for stammered words that prohibits the
use of any contractions directly involved in the stammer. Thus in the
stammer g-g-ghost the first (gh) contraction is not used but the second (st)
one is. This is a case where the conditions for using the rule require
rather complex built-in heuristics for determining whether or not a word is
a stammer.
I've given all these fully implemented special rules identifiers that can be
referenced in a translation table so as to activate the desired rules.
Susan
For a description of the software, to download it and links to project pages
go to http://www.abilitiessoft.com
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
