El 2020-03-29 11:21, Mikel L. Forcada escribió:
Folks:
The elders in Apertium will not be surprised if I voiced my opposition
to changing the format in the Apertium formats used between different
modules of the pipeline. In any case, this is affects the core
functionality of Apertium in many ways and its need should be
justified in an uncontestable way so that the PMC makes a decision to
have a new version of Apertium which should inevitably have paths to
backward compatibility so that legacy languages and language pairs
work identically and without any loss of performance. I believe we are
far from "uncontestability", but that is just my personal opinion.
Agree.
Currently, modes are linear pipelines. Any functionality requiring
information that is currently ingested by one module and not passed
ahead could be sent to later modules by teeing
(https://en.wikipedia.org/wiki/Tee_(command)), named pipes, etc. We
would have a directed acyclic graph, much as in tools like make,
snakemake, dgsh (https://github.com/dspinellis/dgsh/wiki) etc.
A DAG would be an interesting way of setting up the pipeline ... a bit
like
the "compute graphs" that are used in NNs nowadays ... but I'm
not sure how it could be done in a unixy way.
Any justification should first prove that the functionality is robust
and needed by working around the current format and modules, and be
presented in a level of formality which is comparable to that used
currently in our documentation.
Completely agree.
Having said that, no one cannot oppose people forking and testing. If
the new thing works, Apertium could bless the fork and merge it
(depending on how the fork handles provisions for legacy Apertium
workflows). But, as I said, this seems premature to me. But I am
usually very conservative.
I think in addition we need to have clear examples of the information
that should be included and a translational motivation for it. How
is the information going to help us, with concrete translation
examples.
Fran
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
