Audrey Tang wrote:
Indeed, and I'd like to apologize publicly for the snipping.
Accepted and forgiven.
However, the re2c or regel-based scanner refactoring isn't different
from a "flex upgrade patch", as it (by definition) can't affect IMCC's
public API at all. An additional advantage is that they will let us rid
of the flaky API situation with flex. In any case it wouldn't take 6
months.
In vsoni's original words:
a. Remove flex and implement re2c
b. Remove static and global variables
The full quote in context is:
----
Since flex is not generating reeentrant code, this option will get rid of
flex altogether and replace it with re2c. This would require significant
reworking on the code. So the plan of action would be as follows:
a. Remove flex and implement re2c
b. Remove static and global variables
Apart from this we also need to refactor the code to get rid of arrays to a
hash table implementation for macros.
All in all this would be over hauling lot of code.
----
And you answered:
The cost/benefit balance on this solution is not good. A lot of people
are depending on IMCC now, and a refactor of that magnitude will throw
several important projects on Parrot into a dead stall.
Yup. Always take the estimate of the developer and multiply it by at
least 3. If the developer thinks it will require "significant
reworking", it's likely to be a massive overhaul.
It will involve overhauls, but again, the public interface -- at bison
level and above -- cannot break. So the "dead stall" ruling --
effectively dismissing re2c and other scanner alternatives instantly --
strikes me as extremely surprising.
It's not the definition of the interface I'm concerned about, it's the
behavior behind the interface. Can you guarantee that you can substitute
re2c for flex without changing any behavior of IMCC? If you say "Yes",
I'll still be suspicious the answer will turn out to be "No".
I'm also not convinced that re2c is a significant improvement over flex.
I'd rather spend that developer time on things that are significant
improvements.
I am convinced that we need to avoid yanking working systems out from
under developers whenever possible.
Allison
