Front page | perl.perl5.porters |
Postings from May 2012
Father Chrysostomos via RT wrote: >If require is always a keyword I am troubled by the implications of this sort of condition. What does it mean to be a keyword? What is the alternative to it being a keyword? I'm aiming for a system where the things that have historically been builtin keywords are processed as mere names of subroutines, and there's no strong distinction between keyword-like entities and compile-time-resolved subroutines. If you end up needing to make such a distinction then something's gone wrong. >So, which behaviour should \&CORE::require have? It should probably be >the same as CORE::require. And require???s fixed prototype should be >treated as a special case. If you have a sub ref \&CORE::require, it must behave as a pure subroutine at runtime. If you call through the ref, you are calling a sub, and there is no opportunity for its prototype or other compile-time magic to affect the call. By contrast, if you refer to it without sigil, in a compile-time-resolvable manner, then its prototype and other magic should take full effect at compile time, regardless of exactly what name you used to refer to it. In the case of require, the special interpretation of barewords is part of that compile-time magic. >I was trying to come up with a model that would encompass all special >cases, such that there wouldn't be any special cases any more (they all >being CV-specific parsing rules), but I have failed in this particular case. Where exactly does the problem arise? I see no categorical problem with doing this for require. -zeframThread Previous | Thread Next