On Sunday, 22 December 2013 12:18:16 UTC+11, Jeffrey Kegler wrote: > > @Ron: Astute of you to single out the $recce->read(\$input) case. I > agonized many hours over how to handle that argument. Marpa doesn't change > it, but needs to refer to it later. But what if the user changes it? I > could warn them not to in the docs, of course, but I don't have every line > of the ever-expanding Marpa docs memorized, and I doubt many others have. > On the other side, there was efficiency -- the $input string can reasonably > be many megabytes long. >
I'm surprised you agonised over it. To me it was obvious to save copying as potentially-huge string. I didn't think you'd make a copy. Still, that's safe. The alternative of course would be a SHA1 hash or something. And there'd be no need to keep checking. Just if the code dies you could do one check and include the result (eq, ne) in the error msg. (This off the top of my head). In cases like this, where there's a potential problem, I ask myself, how > will the symptom appear? In the case of the user changing (either > deliberately or by accident) $input, the symptoms are likely to be > mysterious and extremely difficult to trace to their source. Bugs like > that must be avoided at all costs. > Absolutely. > So I decided that, space efficiency or not, I needed Marpa to make its > own, private, copy of $input internally. This turns out to allow other > efficiencies, and in retrospect I am glad I made the decision. > Hmmm. Interesting. I guess this is a reference to, errr, (frequent) dereferencing. > So, not only does Marpa leave $input untouched, it copies it away safe > from the user's subsequent changes. > Sure. -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
