Meta-language for mxTextTools

[Tony J. Ibbs (Tibs)]

Christian Tismer <tismer at appliedbiometrics.com> wrote:
> I got the impression: Why another language?

Yes, that always makes me uncomfortable too. Although, really, the original
tuple form is *already* another language (just a very low level one).

> Can't we express the tagging tuples by Python programs?
> Marc's tuples are nothing more than predefined actions,
> conditions, and jumps to labels.
>
> Given a restricted subset of Python, and a couple of known
> functions which are to be used, the tags could be expressed
> as a small number of Python functions, and
> it would be a real application for the ByteCodeHacks
> to turn these Python functions back into tagging tables.
> We would go without any parsing since Python does it for us.


Strangely enough, I have had exactly this thought myself.

I guess the reply is in two parts:

1. I wanted to keep this to something simple that I could have a hope of
implementing myself. In the very, very restricted spare time I have (we have
two small children!) I *might* just be able to use this little language as a
way into learning mxTextTools and produce something I can write quicker than
the tuples themselves. Simple text transforms to produce a "mini-language"
is something I've done before and can give back seemingly amazing progress
for little effort.

2. I can't help feeling that "jump-to-label" (aka
skip-forwards/backwards-N-statements) is intrinsically necessary in such an
engine, and I can't see any way of doing that sensible whilst keeping to
Python syntax.

3. I rather wanted not to hack Python itself, and to keep independent of
whether one is using CPython, JPython (which OK, can't use the current
mxTextTools anyway) or some other language accessing the DLL. Perhaps a bit
spurious, this one.

(BTW, there is no comfy chair)

Oh, I just thought of:
4. Also, for me, I think that the way to go from the original tuple-form to
(perhaps) a final form as Python programs would be via something I can think
in more easily than the original tuples - so perhaps in the end this "little
language" will be no more than a half-way house.

Having said all of the above, I am definitely not averse to someone else
coming up with something better, or explaining to me why what I am doing is
the hard way to do it and, look, here is a lazier way...

> Whoops - I could make the tagging engine into a pluggable
> interpreter for stackless Python, this is just another engine.


Please feel free - you do that and I will happily use it...

> yes-I-have-to-duck-and-cover-ly y'rs - chris :-)


Oh, I don't know, it seemed sensible to me (hint: not a recommendation!)

--
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home