在 2006/7/18 上午 1:21 時，Allison Randal 寫到：
LOL :) Audrey, I love you dear, but you always have an interesting way of interpreting what I say. :)Yes, I'm not willing to start a 6+ month project to gut IMCC. The cost is too great and the benefit isn't great enough.
Indeed, and I'd like to apologize publicly for the snipping.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
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.So, my answer is: No.
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.
If you have a way to make IMCC reentrant that involves upgrading to a more recent version of flex and passing one additional parameter, go for it! Send us a patch and if it passes all the tests, we'll apply it.
As flex 2.5.30+ is not API compatible with the current flex IMCC is using, I wonder how it is different from re2c or regel, in particular that shoehorning an additional YYLEX parameter to make it work with bison will also involve overhauls beyond the original bison interface.
I guess my question is: If I send two patches, of equal size, one uses re2c and is much cleaner and faster; another uses a kluged-up flex with its new, backward-incompatible reentrant API, would you reject one and apply the other? If you are willing to let alternative scanners go in, I'd much rather working on that instead of trying to work around the bison/flex interface.
- A version of PGE written in C is a good idea, because it will spread Perl 6 regexes/grammars far and wide. (It will be difficult, because of all the Parrot features that will have to be reimplemented in a standalone PGE. But, it is possible.)
Well, as discussed in #parrot, an offline-parser (i.e. one that does not permit changes to the gramamr during parsing) with rule syntax can be much more easily generated as a C-emitter backend from either PIR/PGE or Perl5/PCR. I'm looking into it with vsoni right now,.
Audrey
PGP.sig
Description: This is a digitally signed message part
