Re: Auto My?
JOSEPH RYAN writes: > As bad of an idea that I think this is, I wonder if Perl6's reflection > capabilities will be powerful enough to where a module/pragma could be > written that would be able to do this? For instance, one idea was: > lexically change the current grammar to a subclass of the grammar. In > this subclass, there is a hook on the "variable" deparsing rule that > will implictly declare a variable into its outer scope if it has not > yet been declared in the current scope. Totally whacky, sure; but > doable? I don't doubt it. I'd write it right now, but we don't know enough about the compiler interface yet. > That brings up another idea that I had just now: will it be possible > to load 2 different grammars at once if they don't conflict with each > other? For instance, say we have loaded a grammer, > Grammar::WhackyVars, that subclasses from the main Perl6 grammar but > modifies the "variable" rule somehow. However, then say I want to use > a grammar that also subclasses from the main Perl6 grammar that lets > you use "happyfunactiontime" instead of the word "class". Since the > modified rules don't conflict with each other, can I just "use > Grammar::HappyFunActionTime" and everything will work? Or will > Grammar::HappyFunActionTime overload the changes done by the > Grammar::WhackyVars? This begs the use of a particular abstraction Perl 6 has introduced with grammars. Maybe grammar munges aren't subclasses at all, but grammatical roles. The only problem I see with such roles is code generation. If we're going to make it parse in such a modular way, we ought to generate code in the same modular way. That will take some clever design (but I think it can be done). This is important insight right about now, since we're rethinking what the parse tree that rules spit out looks like. Luke
Re: Auto My?
- Original Message - From: Luke Palmer <[EMAIL PROTECTED]> Date: Saturday, December 18, 2004 4:16 pm Subject: Re: Auto My? > Rod Adams writes: > There are pros and cons, and it basically ends up being a design > choice. > > Well, at least when strictures are on. When they are off, the > coder is > > obviously playing fast and loose, and should get the easy > 'everything > > global' behavior. > > When strictures are on, the compiler ought to die if you're tyring to > use a variable without declaration. This is another reason why Perl > doesn't like autodeclaration. As bad of an idea that I think this is, I wonder if Perl6's reflection capabilities will be powerful enough to where a module/pragma could be written that would be able to do this? For instance, one idea was: lexically change the current grammar to a subclass of the grammar. In this subclass, there is a hook on the "variable" deparsing rule that will implictly declare a variable into its outer scope if it has not yet been declared in the current scope. Totally whacky, sure; but doable? That brings up another idea that I had just now: will it be possible to load 2 different grammars at once if they don't conflict with each other? For instance, say we have loaded a grammer, Grammar::WhackyVars, that subclasses from the main Perl6 grammar but modifies the "variable" rule somehow. However, then say I want to use a grammar that also subclasses from the main Perl6 grammar that lets you use "happyfunactiontime" instead of the word "class". Since the modified rules don't conflict with each other, can I just "use Grammar::HappyFunActionTime" and everything will work? Or will Grammar::HappyFunActionTime overload the changes done by the Grammar::WhackyVars? - Joe
Re: Auto My?
Rod Adams skribis 2004-12-18 14:55 (-0600):
> Considering that "proper" and common usage, not to mention strictures,
> dictates a heavy insistence on 'my'. I will thus assume that creation of
> lexical variables with 'my' far out numbers the creation of package
> space globals. Should we not then have it where it's the default
> behavior, and creation of package ones take explicit declaration (via
> 'our')
No.
Some other languages, including Ruby, do this. I dislike it. The best
thing about strict is that it catches typos. With automatic declaration,
you loose typo checking, or solve it in an ugly manner by requiring
assignment (which is still declaration, just with different syntax).
Just typing "my " before the first use of a variable isn't hard, and it
makes things much clearer for both the programmer and the machine. For
the programmer, because you immediately see what some variable's scope
is, and for the machine because it no longer has to guess whether
something's a typo in order to warn you ("used only once" is not always
a typo).
Juerd
Re: Auto My?
Rod Adams writes: > Considering that "proper" and common usage, not to mention strictures, > dictates a heavy insistence on 'my'. I will thus assume that creation > of lexical variables with 'my' far out numbers the creation of package > space globals. Should we not then have it where it's the default > behavior, and creation of package ones take explicit declaration (via > 'our')? Larry has addressed this before, coining "I made 'my' short for a reason". Python and Ruby both autodeclare in the lexical scope like this, and some people like that. Sometimes you see bogus assignments in those languages just to declare a variable in an outer scope. Also, the idea is a bit brittle in the face of large subs. If you change the control flow a little bit, you might accidentally change a variable's scope, and then what you thought was one variable just became two distinct lexicals. There are pros and cons, and it basically ends up being a design choice. > Well, at least when strictures are on. When they are off, the coder is > obviously playing fast and loose, and should get the easy 'everything > global' behavior. When strictures are on, the compiler ought to die if you're tyring to use a variable without declaration. This is another reason why Perl doesn't like autodeclaration. Luke
Auto My?
Considering that "proper" and common usage, not to mention strictures, dictates a heavy insistence on 'my'. I will thus assume that creation of lexical variables with 'my' far out numbers the creation of package space globals. Should we not then have it where it's the default behavior, and creation of package ones take explicit declaration (via 'our')? Well, at least when strictures are on. When they are off, the coder is obviously playing fast and loose, and should get the easy 'everything global' behavior. What issues am I overlooking here? -- Rod
