> I don't see why it should take longer to use a language optimised
> for the job rather than a general purpose language.
Mainly because a lot of work has already been done in the latter,
which would need to be thrown away. This isn't a language issue,
it's just the position we're starting from.
To do a complete rewrite, I'd have to not only reimplement the
Procsy rules themselves, but also find out about the structure of
.hl files, decide how they are going to be represented, etc. This
is all completely possible, but not instantaneous.
>> (iii) the danger of hidden "traps" -- technical or
>> other problems with the re-write that might come to light half-way down
>> the road.
> Surely with our own code, we have complete control over this.
Yes of course. But if, using the current PROCSY, I find features I need
but don't have, I can add them without having to prevail on you to change
the underlying language, or to wait for you to have time to do so. I can
hardly expect that my feature requests will always be your top
priority.
>> (iv) rules written directly in ProXML, or any
>> programming language, might look even more unattractive to a linguist
>> than the current Procsy rules.
> I don't agree at all. ProXML is specifically designed for looking
> at hierarchical data.
Again, this isn't to do with the difference between ProXML and Python.
The existing PROCSY rules are written in PROCSY -- a purpose built
language which happens to be written in Python. It sure ain't perfect
but it has built-in instructions for setting HLsyn parameters at
particular times and values, etc. The rules operate specifically on
hierarchical data.
A PROCSY rule file contains only rules -- input and (especially)
output issues, and interpreting the rules, are dealt with by the Python
code. It is this very sensible separation I was referring to when I
suggested that the rules were reasonably readable. PROCSY rules, like
ProXML, operate on hierarchical data.
Much the same is true of ProXML for changing attributes on an XML
file (as in ProSynth), because it has a special output channel for
a copy of the input XML with attributes changed, and special rules
for changing them so. In effectively the same way, PROCSY has a special
output channel for .hl files, and special rules for operating on
them.
> Mark and I agreed that we would probably need: (i) dynamic allocation of
> data tables
Undoubtedly, with the necessary features added, writing PRO(C)SY in
ProXML would be perfectly possible.
> In summary, we could end up with a set of scripts for synthesis
> which just used XML for linguistic representations and proXML for
> knowledge representation.
I agree that the idea of having all knowledge representation in a
single format is seductive. I'm far less clear that the advantages
outweigh the costs.
> Or we could have a motley collection of
> C programs, Python programs, intermediate text files and rules designed
> to work on linear phonological representations.
I don't know what any of this refers to, other than the Python programs.
There are no C programs, no intermediate text files, and the PROCSY
program does not work on a linear representation but on a structured
dictionary representation which reflects the structure of the XML file in
a faithful and pretty sensible way.
I don't think I have any more to add to this discussion. As I have
said before, anything is possible, and when I go in on Thursday, I am
happy to start implementing whatever decision has been made by then,
as long as it has been made with an understanding of what seem to me
to be the issues.
Mark Wainwright
This archive was generated by hypermail 2b29 : Tue Nov 28 2000 - 16:11:43 GMT