Perl code thats readable and maintainable ;-)
In reality - it doesn't look too disimilar from the awk original. I didn't
appreciate that we'd probably need to keep 2 versions (one for unix and one
for windows). In that case - I'd argue that we only need to "maintain" one
and regenerate the other when required. Provided they both work the same, I'd
say it doesn't matter what the perl one looked like, because thats not the
one that'd be maintained :-)
Personally - I'd be tempted to keep this as a background process for the ecpg
maintiner anyway rather than a normal end user. Probably using something like
a 'syncparser' make target and keep the generation separate from the normal
build process.
That way - awk/perl (you could then pick just one) would only be a requirement
if you want to regenerate the grammer via the 'syncparser' target. This does
have the benefit that the ecpg maintainer can then control when the sync'ing
is done and that its less likely to inadvertantly break the ecpg branch of
source tree.
At the end of the day - this is something Michael has just been doing manually
already and we're trying to help automate the process..
(ducks for cover)
> As against that ... does a2p produce code that is readable/maintainable?
> If the code wasn't perl to start with I'd be a little worried about
> ending up with ugly hard-to-read code.
--
Mike Aubury
http://www.aubit.com/
Aubit Computing Ltd is registered in England and Wales, Number: 3112827
Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ