On Sunday, 22 December 2013 11:08:01 UTC+11, Jeffrey Kegler wrote: > > So it's a regression? That puts a different light on the matter. > > With regressions, sometimes I'll decide that the application was depending > on undocumented behavior, which was at its own risk, and that the > regression is not a problem. But in dubious cases, the benefit of the > doubt should go to the application. Another argument for supporting this > undocumented behavior is that there's no downside -- I'm sure nobody wrote > an application that relies on its named argument hashes getting changed by > the Marpa methods. :-) >
I agree with this. I feel sure Marpa's docs don't return values via refs in param lists, do they? If so, it'd be documented, right? But here we're discussing what happens when things are not documented. So we may not reply on values getting changed, but I'd guess some people would nevertheless /assume/ refs don't change without warning (and not just for Marpa). But it does happen. For years, Encode.encode() butchered the value you fed into it :-(. I'm putting this release candidate on hold, while I research this one and > think it out. The SLIF constructor's argument handling could use some > refactoring anyway. > The case of $recce->read( \$input ); is interesting. I assume Marpa does not consume the input, because it uses internal variables to track everything. And anyway an action must be free to rely on the fact that the input string has not changed. -- 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.
