Re: End-of-scope actions: do/eval duality.
On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote: In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is set to the result of an eval or do. How does this impact exception handling tests on $@ to determine if an exception was thrown, if $@ can be set by a do ? OR is that an error in the pocket guide? No, it's a misunderstanding between you and Tony. The "do" your reference is talking about, is of the form do FILE where file is a string containing a filename, while Tony is talking about the do BLOCK form. do FILE behaves just like eval() (except it reads its data from a source file), while do BLOCK doesn't. Neither. -- Bart.
Re: RFC on Coexistance and simulaneous use of multiple module version s?
On Wed, Feb 14, 2001 at 10:58:57PM -0500, Steve Simmons wrote: Note that it may not be possible to satisfy conflicting requests. If module CA and module CB demand two different versions of the same module CC, the compiler should halt and state the module conflicts. Pardon me for sniping at a great RFC, but I already promised the CPAN workers that I'd make that last statement false. There's no reason in principle why two modules shouldn't be allowed to have their own view of reality. Just because you write Foo::bar in your module doesn't mean that Perl can't know which version of Foo:: you mean. Has anyone considered the problems associated with XS code, or whatever its replacement is? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
defined: Short-cutting on || with undef only.
With Perl 6, it will (probably) be possible to have values with boolean value independent of integer or string values, so that it will be possible to have a value that when viewed as string or number will be "" or 0, but will evaluate as true in a condition. I think this should be applied to the `defined' function, so that, instead of returning a true/false value, it returns an overloaded value that has the same string/number value as its argument, but boolean value being true iff it's not undef. This will make possible things like perl5: $x = undef; $y = $x || "N/A" === $y = "N/A" (not available) $x = 25.4; $y = $x || "N/A" === $y = 25.4 $x = 0; $y = $x || "N/A" === $y = "N/A" (wrong, should be 0) $x = 0; $y = defined($x) ? $x : "N/A" == $y = 0 (right) perl6: $x = undef; $y = defined($x) || "N/A" === $y = "N/A" $x = 25.4; $y = defined($x) || "N/A" === $y = 25.4 $x = 0; $y = defined($x) || "N/A" === $y = 0 In Perl 5, it would be written `defined($x) ? $x : "N/A"', but this has the problem that $x is evaluated twice, so it doesn't work if instead of $x we have a function call (or even if $x is tied...). - Branden
Re: RFC on Coexistance and simulaneous use of multiple module version s?
Paul Johnson wrote:
Note that it may not be possible to satisfy conflicting requests.
If
module CA and module CB demand two different versions of the
same
module CC, the compiler should halt and state the module
conflicts.
Pardon me for sniping at a great RFC, but I already promised the CPAN
workers that I'd make that last statement false. There's no reason in
principle why two modules shouldn't be allowed to have their own view
of reality. Just because you write Foo::bar in your module doesn't
mean
that Perl can't know which version of Foo:: you mean.
Has anyone considered the problems associated with XS code, or whatever
its replacement is?
The big problem about having more than one version of a module loaded at the
same time is with namespaces, because the same namespace is actually used by
more than one (version of) module. In Perl code, this will probably be
defined when the module is `use'd, and all access to the namespace provided
by the module will be issued to that version of the module.
In C low level code, we'll probably won't have how to magically use a
specific version of a specific module for all the XS code, so I think we'll
probably have to say on each namespace access, which module version we are
accessing, ie. instead of
SV *sv = perl_get_sv("package::varname", FALSE);
we'll probably will have to include the version of "package" that is loaded:
SV *sv = perl_get_sv("package::varname", FALSE, 2.35);
I see a problem here when `use MyModule' creates namespaces MyModule,
MyModule::InternalModule, MyModule::OtherModule, etc. and mainly when `use
MyModule' creates namespace OtherNamespace (that has nothing to do with the
name `MyModule'). How will Perl know what's the version of the module
associated with OtherNamespace ??? What if several modules put things in a
common namespace ?
- Branden
Re: defined: Short-cutting on || with undef only.
Branden wrote: I think this should be applied to the `defined' function, Oh, no, here we go again. Branden, why do you insist on dredging up every contentious issue which has already been beaten to death? Maybe you need to read the archives first. -- John Porter You can't keep Perl6 Perl5.
perl6-language needs admin help too :)
As many of you may know, I've recently moved to the other side of the world, and my life's a bit hectic. I hadn't counted on p6-l bursting into life just now, and while I'd like to keep right up to date with it I really can't guarantee daily reading. Would anyone like to volunteer to do weekly summaries and/or general list admin? K.
Re: Closures and default lexical-scope for subs
First of all, sorry to bother you again with this issue, but I guess it
didn't have the appropriate discussion. If you're not interested, please
don't read further...
I wrote:
I expect Perl 6 will have some way to define its variables as being
lexical-scoped in the sub they are used as default, either by the language
default, or by a pragma, as `use scope "subs"; ', as it's proposed in RFC
64.
John Porter wrote:
Well, since the former isn't going to happen, the latter isn't going to
be a problem.
and Michael G Schwern wrote:
I believe this issue was discussed to death on the mailing list Way
Back When and IIRC the result was "its too much trouble to eliminate
two characters". There's heaps and heaps of caveats, arbitrary
decisions and conflicts to be resolved about how the auto-lexical
scoping should work. All this so you don't have to type "use strict"
and the occasional "my".
[snip]
Anyhow, I could be completely wrong about how the discussion turned
out. Check the archives.
Well, I checked the archives, and I found that the discussion begun in
http:[EMAIL PROTECTED]/msg01441.html and the
last post about it was in
http:[EMAIL PROTECTED]/msg01567.html, by Bart
Lateur. And that post was IMO beginning to go into a different direction,
but I saw no comments about it. Did I miss something in the archives? I
looked for it in perl6-language-strict as well but found nothing.
Well, first let me say why I think a way (pragma) to do lexical-scope by
default (for one file/block/scope) would be good. Most (modern) languages do
it and most programmers are used to it. And `my' really doesn't DWIM. For
example,
my $a, $b, $c;# only $a is lexically scoped
my ($a) = FHANDLE; # after deducing (by the above)
# that I should include parenthesis
# around every `my', this example
# comes to read the whole file
# when I wanted only the first line.
if ($x) {
my $y = 1;
} else {
my $y = 2;
}
return $y;# wrong, since my makes $y above
# only inside the if/else blocks.
# I have to do:
my $y;
if ($x) {
$y = 1;
} else {
$y = 2;
}
return $y;
# I know you'll say I could use
my $y = $x ? 1 : 2;
return $y;
# But suppose I wanted to write more code
# inside the if/else blocks and supply a
# return value.
These are the problems I see with `my', not to mention the problems that
arise by NOT having `my' (these are quite well described in RFC 64).
My proposal is: As most code written SHOULD have (almost) all its variables
lexically scoped, in presence of a pragma (like `use scope'), all variables
would be implicitly defined as lexically scoped to the named sub (not
anonymous blocks, only subs) they're in. To access variables outside of this
scope, keywords would be used to statically define that a variable actually
refers to a global variable or a variable of another scope.
I propose the introduction of two new keywords (just like `my' and `our')
for specifying a different scope: `global' and `outer'. `global' would be
used to say that a specific variable or a list of them would refer to the
global variables with those names in the current package. `outer' would be
used to say that a specific variable or a list of them would refer to the
same variables in the `parent' level (that would be used for closures).
Variables accessed with their explicit full packagenames would be the global
variables. Variables in the top-level in the file would be file-scoped. subs
that want to access these file-scoped variables do it with `outer'. `my'
would still be allowed, for lexically scoped variables inside some blocks
inside a sub that should have variables of its own.
When I originally wrote my `outer' proposal (it was named other thing then),
John Porter wrote:
Ugh - upvar? No thanks.
Actually, what I'm proposing is quite very different than `upvar'. `upvar'
is a dynamic thing, it accesses a variable in the scope of the caller.
`outer' is a lexical thing, it tells the compiler that that variable name is
accessing the same variable that the definer was accessing.
For example:
# In a very Perlish Tcl...
my $x = 1;
sub foo {
upvar $x;
print $x;
}
sub bar {
my $x = 2;
foo();
}
bar();
# would print 2
my $x = 1;
sub foo {
outer $x;
print $x;
}
sub bar {
my $x = 2;
foo();
}
bar();
# would print 1
As `outer' accesses the variable of the `definer' and when it was `defined',
it accesses the file-scoped `$x', instead of the caller's (bar's) `$x', that
is what would happen with Tcl's `upvar'.
--
Examples of usage:
use scope;
sub foo {
$bar = shift;
if ($bar) {
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote: I propose the introduction of two new keywords (just like `my' and `our') for specifying a different scope: `global' and `outer'. `global' would be used to say that a specific variable or a list of them would refer to the global variables with those names in the current package. What are "global variables"? Do you mean those that have file scope? Variables accessed with their explicit full packagenames would be the global variables. Wait, I thought we were talking about lexicals, not dynamics. Actually, what I'm proposing is quite very different than `upvar'. `upvar' is a dynamic thing, it accesses a variable in the scope of the caller. `outer' is a lexical thing, it tells the compiler that that variable name is accessing the same variable that the definer was accessing. I'm confused. Consider also I'm not wanting you to use it, or like it whatsoever. I only think it would probably be useful for some of us, and that only adding a new `scope' pragma wouldn't hurt anybody, while possibly helping some. Perhaps. Except that you also propose to burden the language with two new keywords. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
Jonathan Scott Duff wrote: On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote: I propose the introduction of two new keywords (just like `my' and `our') for specifying a different scope: `global' and `outer'. `global' would be used to say that a specific variable or a list of them would refer to the global variables with those names in the current package. What are "global variables"? Do you mean those that have file scope? Sorry... dynamics. These are the ones that are in a package namespace. Variables accessed with their explicit full packagenames would be the global variables. Wait, I thought we were talking about lexicals, not dynamics. Again package vars. Actually, what I'm proposing is quite very different than `upvar'. `upvar' is a dynamic thing, it accesses a variable in the scope of the caller. `outer' is a lexical thing, it tells the compiler that that variable name is accessing the same variable that the definer was accessing. I'm confused. Consider also I'm not wanting you to use it, or like it whatsoever. I only think it would probably be useful for some of us, and that only adding a new `scope' pragma wouldn't hurt anybody, while possibly helping some. Perhaps. Except that you also propose to burden the language with two new keywords. Only if `use scope' is used, otherwise, the keywords would have no meaning. - Branden -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
Branden wrote:
Well, I checked the archives, and I found that the discussion begun in
http:[EMAIL PROTECTED]/msg01441.html
That thread was rather tame; even so, I believe the end result,
if one can be deduced, is that the proposal is not a good one.
There was more heated discussion in the thread rooted at
http://www.mail-archive.com/perl6-language@perl.org/msg01089.html
the discussion of RFC 16.
Well, first let me say why I think a way (pragma) to do lexical-scope by
default (for one file/block/scope) would be good. Most (modern) languages do
it
This is false. Even languages in which lexical variables are the
norm still require a variable declaration; it's not a "default".
And `my' really doesn't DWIM.
Only if WYM isn't what 'my' does. :-)
my $a, $b, $c;# only $a is lexically scoped
RTFM.
my ($a) = FHANDLE; # after deducing (by the above) . . .
# when I wanted only the first line.
Silly beginner gotchas. It's not an inconsistency of the
language by any means.
if ($x) {
my $y = 1;
} else {
my $y = 2;
}
return $y;# wrong,
Just as in any language with lexical variables:
if ( x ) {
int y = 1;
} else {
int y = 2;
}
return( y ); /* wrong */
These are the problems I see with `my', not to mention the problems that
arise by NOT having `my' (these are quite well described in RFC 64).
Except they're not really problems, volumes of discussion
not withstanding.
My proposal is: As most code written SHOULD have (almost) all its variables
lexically scoped, in presence of a pragma (like `use scope'), all variables
would be implicitly defined as lexically scoped to the named sub (not
anonymous blocks, only subs) they're in.
This introduces far more serious problems than it purports to solve.
To access variables outside of this
scope, keywords would be used to statically define that a variable actually
refers to a global variable or a variable of another scope.
I see. Instead of
sub {
my $x;
{
$x = 1;
{
$x = 2;
{
$x = 3;
{
$x = 4;
}
}
}
}
}
You'd have to write
sub {
$x = undef; # to establish it at this scope
{
outer $x = 1;
{
outer 2 $x = 2;
{
outer 3 $x = 3;
{
outer 4 $x = 4;
}
}
}
}
}
Yeah, that's much better. :-P
I propose the introduction of two new keywords
As I said before: ain't happenin'.
Ugh - upvar? No thanks.
Actually, what I'm proposing is quite very different than `upvar'. `upvar'
is a dynamic thing, it accesses a variable in the scope of the caller.
`outer' is a lexical thing, it tells the compiler that that variable name is
accessing the same variable that the definer was accessing.
You are so confused. As you say, upvar deals with scope. That's
lexical. It is *not* dynamic, which deals with namespaces.
(The documenation of upvar may talk about "global variables",
but that's just referring to the outermost lexical scope.)
So, yes, indeed, you are proposing a sort of upvar for perl. Blech.
Note that discussion of upvar also occurs under the discussion
of RFC 143.
Note that `outer $x, $y, $z' is the same as `outer($x, $y, $z)' in contrast
to `outer($x), $y, $z'.
Great. You want to break this one very consistent aspect of perl.
I predict that you're going to say that this isn't saving typing,
No, I'm going to say that it introduces far more serious problems
than it purports to solve.
Furthermore, it adds more ways -- unnecessary ways at that -- to
do things, and more confusion for our already befuddled newbies.
writing modules that essentially need to use lexically scoped variables to
guarantee they won't harm scripts that use those modules, I think it's a
win.
use strict 'vars' + my is already more than sufficient to this need.
I also see no action at a distance here, since the only way to change the
...
assuming `our' *outside* the block would affect variables inside the block.
I have to disagree with you.
--
John Porter
You can't keep Perl6 Perl5.
Re: Closures and default lexical-scope for subs
John Porter wrote:
Well, first let me say why I think a way (pragma) to do lexical-scope by
default (for one file/block/scope) would be good. Most (modern)
languages do
it
This is false. Even languages in which lexical variables are the
norm still require a variable declaration; it's not a "default".
Take PHP and Python, for example.
my $a, $b, $c;# only $a is lexically scoped
RTFM.
my ($a) = FHANDLE; # after deducing (by the above) . . .
# when I wanted only the first line.
Silly beginner gotchas. It's not an inconsistency of the
language by any means.
Yeah. Beginners. I was one too. And I remember always falling on these...
But that's OK, since we probably don't want any new Perl programmers...
My proposal is: As most code written SHOULD have (almost) all its
variables
lexically scoped, in presence of a pragma (like `use scope'), all
variables
would be implicitly defined as lexically scoped to the named sub (not
anonymous blocks, only subs) they're in.
This introduces far more serious problems than it purports to solve.
Tell me one. I couldn't find it.
To access variables outside of this
scope, keywords would be used to statically define that a variable
actually
refers to a global variable or a variable of another scope.
I see. Instead of
sub {
my $x;
{
$x = 1;
{
$x = 2;
{
$x = 3;
{
$x = 4;
}
}
}
}
}
You'd have to write
sub {
$x = undef; # to establish it at this scope
{
outer $x = 1;
{
outer 2 $x = 2;
{
outer 3 $x = 3;
{
outer 4 $x = 4;
}
}
}
}
}
Wrong! Read again:
My proposal is: As most code written SHOULD have (almost) all its
variables
lexically scoped, in presence of a pragma (like `use scope'), all
variables
would be implicitly defined as lexically scoped to the named sub (not
anonymous blocks, only subs) they're in.
***(not anonymous blocks, only subs)*** Got it?
The only change would be cutting the `my $x;' line, since all others are in
the same sub. (As you see, `my' introduces a bit more than typing two
characters).
: # under use scope;
: sub {
: {
: $x = 1;
: {
: $x = 2;
: {
: $x = 3;
: {
: $x = 4;
: }
: }
: }
: }
: }
Or, the smart way:
: sub { $x = 4; }
Or even:
: sub { 4 }
Note that `outer $x, $y, $z' is the same as `outer($x, $y, $z)' in
contrast
to `outer($x), $y, $z'.
Great. You want to break this one very consistent aspect of perl.
print $x, $y, $z;
writing modules that essentially need to use lexically scoped variables
to
guarantee they won't harm scripts that use those modules, I think it's a
win.
use strict 'vars' + my is already more than sufficient to this need.
Sufficient? Yes.
The best way? Maybe, maybe not.
The only way? (So long,) Yes.
I think TSBMTOWTDI.
I also see no action at a distance here, since the only way to change
the
...
assuming `our' *outside* the block would affect variables inside the
block.
Hey! You are changing the meaning of what I said!!! I didn't write that!
: I also see no action at a distance here, since the only way to change the
: way a sub sees a variable is inside the sub the variable is being used.
: That's where I think the discussion about RFC 64 was problematic. It was
: assuming `our' *outside* the block would affect variables inside the
block.
: And that's AAAD for sure!
I never said `our' should affect the variables inside the block! I said this
was the *main* problem in the discussion of RFC 64! Having `our' (or
anything) outside the scope change the scope of things is a very bad idea.
It's clear it ends with all the purpose of it.
I have to disagree with you.
Read it again, and see if it has problems or not. Note again, I'm not asking
you to use it, or even like it. I'm only asking if it has the ``far more
serious problems than it purports to solve'' you said it has.
- Branden
Re: Closures and default lexical-scope for subs
At 01:15 PM 2/15/01 -0500, John Porter wrote: my $a, $b, $c;# only $a is lexically scoped RTFM. Quite. But on a tangent, I see no good reason why this shouldn't be given the same interpretation as "my ($a, $b, $c)" on the grounds that functions taking list arguments that omit their parentheses swallow up the following list. And if the retort is, "my isn't a function," then I would like to know what it really is and why it's listed in perlfunc along with other things that aren't functions. If that's not enough controversy I can also ask about things which are labelled as both functions and operators :-) -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
At 04:38 PM 2/15/2001 -0300, Branden wrote: Yeah. Beginners. I was one too. And I remember always falling on these... But that's OK, since we probably don't want any new Perl programmers... I've skipped pretty much all this thread so far, but I do need to point out that perl isn't targeted at beginning programmers, or beginning perl programmers. It's targeted at experienced programmers. If you learn a language you're a beginner once, and for a little while, but you end up experienced for a much longer time. Perl has lots of stuff that'll trip up beginners. That's OK. People are clever, and they can learn. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Closures and default lexical-scope for subs
Branden wrote: Take PHP and Python, for example. O.k., that's two out of the three modern languages. That's "most". Sorry, I stand corrected. Silly beginner gotchas. It's not an inconsistency of the language by any means. Yeah. Beginners. I was one too. And I remember always falling on these... But that's OK, since we probably don't want any new Perl programmers... Well, you proposed adding AWTDI, *and* breaking one of Perl's (few?) consistencies. Naturally, I oppose both measures. This introduces far more serious problems than it purports to solve. Tell me one. I couldn't find it. You named one yourself, but claimed that it would be "worth it" for some (well, one) programming contexts. Wrong! Read again: O.k. YAWTDI. Just what we need. Note that `outer $x, $y, $z' is the same as `outer($x, $y, $z)' in contrast to `outer($x), $y, $z'. Great. You want to break this one very consistent aspect of perl. print $x, $y, $z; "my" is a declaration, and it has higher precedence than comma. I don't see a problem. print() is not comparable. use strict 'vars' + my is already more than sufficient to this need. Sufficient? Yes. The best way? Maybe, maybe not. The only way? (So long,) Yes. I think TSBMTOWTDI. "...but I hesitate to make ten ways to do it." Furthermore it is arguable (as we're demonstrating :-) that the proposed way is any better.Perhaps if perl had no precedent in this area, it would be something to consider. As it is, it really isn't, because use strict 'var's + my is sufficient -- and not only sufficient, but brilliant. I truly believe this other TWTDI is being proposed -- if you'll pardon me -- mainly for the sake of grandstanding. I also see no action at a distance here, since the only way to change ... assuming `our' *outside* the block would affect variables inside the Hey! You are changing the meaning of what I said!!! I didn't write that! I didn't intend to change the meaning. I was just severely snipping what didn't need repeating. : I also see no action at a distance here, since the only way to change the : way a sub sees a variable is inside the sub the variable is being used. : That's where I think the discussion about RFC 64 was problematic. It was : assuming `our' *outside* the block would affect variables inside the : block. : And that's AAAD for sure! I never said `our' should affect the variables inside the block! Well, I don't know what happened here. All I did was cut out some lines. I did not (at least not intentionally) twiddle the meaning of your (or anyone else's) words. I'm only asking if it has the ``far more serious problems than it purports to solve'' you said it has. Please go back and read all the threads I referred to in my previous post. In a nutshell, I agree with the naysayers. -- John Porter You can't keep Perl6 Perl5.
Re: Closures and default lexical-scope for subs
Take PHP and Python, for example. my $a, $b, $c;# only $a is lexically scoped RTFM. my ($a) = FHANDLE; # after deducing (by the above) . . . # when I wanted only the first line. Silly beginner gotchas. It's not an inconsistency of the language by any means. Yeah. Beginners. I was one too. And I remember always falling on these... But that's OK, since we probably don't want any new Perl programmers... I agree. I hate these gotchas. They cost a *lot* of problems when I'm trying to explain things. Tell me one. I couldn't find it. The main problem I see is cross checking. I *like* having to declare things as 'my' - it catches my errors for me: my $variable; $varaible = 1; # mis-spelled - caught by 'use strict'. If you had this 'use scope' pragma, this auto-error checking would be compromised severely. However, that still doesn't get rid of the gotchas - personally I think that: my $a, $b, $c; should be an error, a warning, or DWIM. Especially: my $a, $b; which is particularly insidious because $a and $b are default globals. Yuck. As should: my ($a) = STDIN; I'm also fond of making 'use strict' and '-w' ON by default, and turned off by pragma. But that's just me. Is there a 'annoying beginner mistakes and what the $!#$@ to do about them RFC'? If not, it might be a worthwhile thing to put together. Ed
Re: Closures and default lexical-scope for subs
Dan Sugalski [EMAIL PROTECTED] wrote: At 04:38 PM 2/15/2001 -0300, Branden wrote: Yeah. Beginners. I was one too. And I remember always falling on these... But that's OK, since we probably don't want any new Perl programmers... I've skipped pretty much all this thread so far, but I do need to point out that perl isn't targeted at beginning programmers, or beginning perl programmers. It's targeted at experienced programmers. If you learn a language you're a beginner once, and for a little while, but you end up experienced for a much longer time. eloquent... clever... clear... true... clap clap clap Perl has lots of stuff that'll trip up beginners. That's OK. People are clever, and they can learn. The same things can be said for any language. Even VB (it takes a while to get used to the bugs). However, many of the things that trip up beginners in other languages, including VB, aren't present in Perl. One of Perl's primary beauties IMO is that it is appropriate to all levels of programmer. Most other languages have a few bell shapes in their learning curve, with the largest at the front. Perl seems to be a steady incline with a teensy little tea bell at the front, which comprises mostly of the most important less of all -- common to all languages -- the grand principle of RTFM. Other than that, once you get past the "modem noise" shock, it's all basic programming theory (if, unless, while, do, sub). My hope for Perl 6 is that it doesn't break that with non-optional fluff. p
Re: Closures and default lexical-scope for subs
Peter Scott wrote:
At 01:15 PM 2/15/01 -0500, John Porter wrote:
my $a, $b, $c;# only $a is lexically scoped
Quite. But on a tangent, I see no good reason why this shouldn't be given
the same interpretation as "my ($a, $b, $c)" on the grounds that functions
taking list arguments that omit their parentheses swallow up the following
list. And if the retort is, "my isn't a function," then I would like to
know what it really is and why it's listed in perlfunc along with other
things that aren't functions.
I agree with this statement. Perhaps someone who was around during the
initial 'my' discussions can shed some light on why it binds so tightly.
I have observed you can do something like this:
my $OUTER = '';
if ( $some_value ) {
# 'my' only on the first one
(my $inner, $OUTER) = split;
# more code that uses $inner ...
}
if ( $OUTER ) {
# $inner not here, but that's fine...
}
But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.
Also, as the author of RFC 64, let me say that while I think it's cute
and nifty, I think it's also true from the discussions that it causes
far more problems than it solves. I no longer think it's a good idea, at
least not in its current incantation. There may be other ways to
approach it, but I can't think of any that aren't more complex than (a
possibly modified) "my".
-Nate
Re: Closures and default lexical-scope for subs
Edward Peschko wrote: Tell me one. I couldn't find it. The main problem I see is cross checking. I *like* having to declare things as 'my' - it catches my errors for me: my $variable; $varaible = 1; # mis-spelled - caught by 'use strict'. Still would be able to do it with `use strict'. My proposal isn't going to replace it! As it didn't replace the default global variables! As I said, I don't want you to use it or even like it, I'm only wanting YAWTDI. If you had this 'use scope' pragma, this auto-error checking would be compromised severely. Actually, I think sometimes it can be done with -w (``Variable xyz used only once, probably spelling error''). However, that still doesn't get rid of the gotchas - personally I think that: my $a, $b, $c; should be an error, a warning, or DWIM. Especially: my $a, $b; OK. Fine to me. Under `use strict' it actually would be already an error. I'm also fond of making 'use strict' and '-w' ON by default, and turned off by pragma. But that's just me. I'm fond of having an alternative to it, ie. `use scope'. I don't want it by default, as I don't want it to replace `strict' either. It would only be there for anyone decide if he would or wouldn't use it. As to turn on by default, I actually don't think making one of this things default would be good, because it would make one-liners and small quick and dirty scripts some harder to write. For longer scripts and modules (that already are many lines long), writing one or two more lines isn't expensive at all... - Branden
Re: End-of-scope actions: do/eval duality.
On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
Bart Lateur wrote:
No, it's a misunderstanding between you and Tony. The "do" your
reference is talking about, is of the form
do FILE
where file is a string containing a filename, while Tony is talking
about the
do BLOCK
form. do FILE behaves just like eval() (except it reads its data from a
source file), while do BLOCK doesn't. Neither.
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }' to
have the behaviour of not dying and setting $@ ?
And that would gains us what exactly?
As the Perl man page says, do FILE is like
scalar eval `cat FILE`;
If you take out the eval, you get:
scalar `cat FILE`;
which is pretty pointless.
I find a "let's require some extra hoops and red tape" not very-Perl like.
Perl is there for the programmer; not the other way around.
Abigail
Re: RFC on Coexistance and simulaneous use of multiple module version s?
Paul Johnson wrote: Has anyone considered the problems associated with XS code, or whatever its replacement is? Pardon my ignorance, but what's XS code?
Re: Closures and default lexical-scope for subs
"Peter" == Peter Scott [EMAIL PROTECTED] writes: Peter Quite. But on a tangent, I see no good reason why this shouldn't be Peter given the same interpretation as "my ($a, $b, $c)" on the grounds that Peter functions taking list arguments that omit their parentheses swallow up Peter the following list. *some* functions. localtime doesn't. my is a unary function, prototyped vaguely as (\$) or (\@) or (\%). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Closures and default lexical-scope for subs
Branden wrote: If you had this 'use scope' pragma, this auto-error checking would be compromised severely. Actually, I think sometimes it can be done with -w (``Variable xyz used only once, probably spelling error''). Except that only applies to un-declared variables, which currently (and hopefully forever) can only be global variables. -- John Porter
Re: Closures and default lexical-scope for subs
John Porter wrote: Branden wrote: Well, I checked the archives, and I found that the discussion begun in http:[EMAIL PROTECTED]/msg01441.html That thread was rather tame; even so, I believe the end result, if one can be deduced, is that the proposal is not a good one. There was more heated discussion in the thread rooted at http://www.mail-archive.com/perl6-language@perl.org/msg01089.html the discussion of RFC 16. Well, actually, I read that, and it pretty much discusses making `strict' default or not (which I believe is not), but I saw nothing against another pragma like the one proposed in RFC 64. I actually didn't see one thing that's a flaw in what I'm proposing. If you're seeing one, please tell me! I know it pretty much can have flaws, but I'm not seeing them. OTOH, I'm not saying it's perfect. Of course not! It may have some advantages over `strict' (it's more succint) the same way `strict' has advantages over it (error checking, more disciplined, more possibility to define scopes). Again, I'm not proposing ending with `strict', neither making it a default. It's only YAWTDI. Is there a problem with that? I know that "...but I hesitate to make ten ways to do it." As there's only two, it would be three, so I think we have still seven to find ;-) Once more, I don't ask you to use it or like it. I just think we could allow others to use it and like it (I would). Thanks, - Branden
Re: defined: Short-cutting on || with undef only.
On Thu, Feb 15, 2001 at 10:31:34AM -0300, Branden wrote: With Perl 6, it will (probably) be possible to have values with boolean value independent of integer or string values, so that it will be possible to have a value that when viewed as string or number will be "" or 0, but will evaluate as true in a condition. You mean the beaten-to-death ??, formely known as |||, operator? It has torn p5p to shreds repeatedly. Abigail
Re: End-of-scope actions: do/eval duality.
[EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }'
to
have the behaviour of not dying and setting $@ ?
And that would gains us what exactly?
As the Perl man page says, do FILE is like
scalar eval `cat FILE`;
If you take out the eval, you get:
scalar `cat FILE`;
which is pretty pointless.
I find a "let's require some extra hoops and red tape" not very-Perl like.
Perl is there for the programmer; not the other way around.
Please read ``Larry's talk in Atlanta about Perl 6'', the text is in
http://dev.perl.org/~ask/als/larry-als.txt, you can find it in
http://dev.perl.org. Read the fifth paragraph under `[Simplifications]'.
- Branden
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 11:49:44AM -0800, Randal L. Schwartz wrote: "Peter" == Peter Scott [EMAIL PROTECTED] writes: Peter Quite. But on a tangent, I see no good reason why this shouldn't be Peter given the same interpretation as "my ($a, $b, $c)" on the grounds that Peter functions taking list arguments that omit their parentheses swallow up Peter the following list. *some* functions. localtime doesn't. my is a unary function, prototyped vaguely as (\$) or (\@) or (\%). If my() would be an unary function, how come that my ($foo, $bar); makes $bar a lexical variable? my just isn't a function. Just like return or while aren't, even when followed by parenthesis. They are language constructs. Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
I agree with this statement. Perhaps someone who was around during the
initial 'my' discussions can shed some light on why it binds so tightly.
I have observed you can do something like this:
my $OUTER = '';
if ( $some_value ) {
# 'my' only on the first one
(my $inner, $OUTER) = split;
# more code that uses $inner ...
}
if ( $OUTER ) {
# $inner not here, but that's fine...
}
But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.
As I wrote elsewhere, other reasons not to change the behaviour of my:
GetOptions (foo = \my $foo,
bar = \my $bar);
tie my $shoe = $tring;
Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 10:44:24AM -0800, Peter Scott wrote: Quite. But on a tangent, I see no good reason why this shouldn't be given the same interpretation as "my ($a, $b, $c)" on the grounds that functions taking list arguments that omit their parentheses swallow up the following list. And if the retort is, "my isn't a function," then I would like to know what it really is and why it's listed in perlfunc along with other things that aren't functions. my is language construct. Just like if, while and return that can be followed by parenthesis, but aren't functions. If that's not enough controversy I can also ask about things which are labelled as both functions and operators :-) Functions and operators are the same. It's just that what is labelled an operator usually takes a fixed number of arguments, often consists of non-alphanumerical characters and unlike what's labelled a function, is often not prefix. But that's only syntactic sugar (and vinegar due to precedence tables). Abigail
Re: Closures and default lexical-scope for subs
Still would be able to do it with `use strict'. My proposal isn't going to replace it! As it didn't replace the default global variables! As I said, I don't want you to use it or even like it, I'm only wanting YAWTDI. Right, but your approach isn't going to help in the cases where it is needed most, ie: long programs where it *is* nice to have lexical variables. There are two possibilities here: 1 - long scripts where you need lexicals 2 - short scripts where you don't. In #1, 'use scope' is going to hinder more than help, for the reasons that I mentioned. In #2, 'use scope' is not needed because you simply don't have strict on. Actually, I think sometimes it can be done with -w (``Variable xyz used only once, probably spelling error''). Right, but what of cases when you are consistantly using the wrong variable. Or you use it wrong twice. If its not bulletproof, I'd rather not rely on it. I'm fond of having an alternative to it, ie. `use scope'. I don't want it by default, as I don't want it to replace `strict' either. It would only be there for anyone decide if he would or wouldn't use it. The question is whether or not the pragma is worth the extra complexity in the parser/implementation that it would add as opposed to the benefit of its being there. If it was not that difficult to implement, I wouldn't mind seeing it.. As to turn on by default, I actually don't think making one of this things default would be good, because it would make one-liners and small quick and dirty scripts some harder to write. For longer scripts and modules (that already are many lines long), writing one or two more lines isn't expensive at all... well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. The main rationale behind this is that - face it '-w' is pretty much useless now for any module that includes other modules. Why? because you get those warnings as well as your own. Even the standard distribution of perl isn't free of this behaviour. Make them the default, and people will adhere to them. And '-w' will become useful again. And as newbies, they will also get feedback on things that used to be silent and hence learn faster. Ed
Re: Closures and default lexical-scope for subs
Branden wrote: There was more heated discussion in the thread rooted at http://www.mail-archive.com/perl6-language@perl.org/msg01089.html the discussion of RFC 16. Well, actually, I read that, and it pretty much discusses making `strict' default or not (which I believe is not), but I saw nothing against another pragma like the one proposed in RFC 64. You're focusing too narrowly on your specific proposal. In talking about other proposals, those threads make a lot of points which are relevant to yours. IOW, you're missing the spirit of it. "...but I hesitate to make ten ways to do it." As there's only two, it would be three, so I think we have still seven to find ;-) Again, you're missing the spirit of the aphorism (perhaps intentionally). We should be very careful when considering adding more WTDI, particularly if those WTDI are not necessary, as in this case. Once more, I don't ask you to use it or like it. That's the umpteenth time you've said that, but you seem to be trying to counter something I never said. I'm arguing against your proposal because I think it's a bad idea and is bad for perl. I assure you if it goes in, I will not use it. You don't need to worry about that. -- John Porter Ann wenno haddum billizac...
Re: RFC on Coexistance and simulaneous use of multiple module version s?
Steve Simmons [EMAIL PROTECTED] wrote: Paul Johnson wrote: Has anyone considered the problems associated with XS code, or whatever its replacement is? Pardon my ignorance, but what's XS code? Simply put (and paraphrastically, so don't nitpick, anyone), XS is using a funky type of C used to code Perl back ends. You end up with compiled modules in .DLL (Win32) or .so (Linux/etc) format. XS is used to supply Perl with functionality that it currently doesn't have, such as connecting with a C-based library, or to do something faster in compiled code than you could do in Perl code (which latter use is becoming more and more irrelevant on faster and faster machines). p
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote: well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. We already have a switch that means "quick and dirty", it's called "-e" -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 02:40:52PM -0600, Jonathan Scott Duff wrote: On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote: well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. We already have a switch that means "quick and dirty", it's called "-e" Beautiful. then just co-opt it. Right now when I say: #!/usr/local/bin/perl -e in a file i get Can't emulate -e on #! line at a.p. Either that, or add '-q' as a file version for '-e'. And in any case, make '-e' have the additional connotation that implies 'no strict', and 'no warn'. Seems simple enough to me. Ed
Re: Closures and default lexical-scope for subs
At 12:43 PM 2/15/01 -0800, Edward Peschko wrote: On Thu, Feb 15, 2001 at 02:40:52PM -0600, Jonathan Scott Duff wrote: On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote: well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. We already have a switch that means "quick and dirty", it's called "-e" Beautiful. then just co-opt it. Right now when I say: #!/usr/local/bin/perl -e in a file i get Can't emulate -e on #! line at a.p. Either that, or add '-q' as a file version for '-e'. And in any case, make '-e' have the additional connotation that implies 'no strict', and 'no warn'. no 'warnings' Seems simple enough to me. Yes, that's what I thought; but this has generated more heat than light, at least on the times I've brought it up, e.g., http:[EMAIL PROTECTED]/msg00025.html Better get the asbestos underwear ready. -- Peter Scott Pacific Systems Design Technologies
Re: End-of-scope actions: do/eval duality.
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote: I find a "let's require some extra hoops and red tape" not very-Perl like. Perl is there for the programmer; not the other way around. Please read ``Larry's talk in Atlanta about Perl 6'', the text is in http://dev.perl.org/~ask/als/larry-als.txt, you can find it in http://dev.perl.org. Read the fifth paragraph under `[Simplifications]'. Having read that many times over, I agree with Abigail. You can't just magically invoke Larry and expect that to prove your point. Or prove that you have a point. -- For me, UNIX is a way of being. -Armando P. Stettner
Re: Closures and default lexical-scope for subs
And in any case, make '-e' have the additional connotation that implies 'no strict', and 'no warn'. no 'warnings' thanks. 'no warnings' Seems simple enough to me. Yes, that's what I thought; but this has generated more heat than light, at least on the times I've brought it up, e.g., http:[EMAIL PROTECTED]/msg00025.html Well, I agree with pretty much everything you said, except I like '-q' better than '-z' for aesthetic reasons. So... what was the rationale against it? Ed
Re: Closures and default lexical-scope for subs
At 01:03 PM 2/15/01 -0800, Edward Peschko wrote: http:[EMAIL PROTECTED]/msg00025.html Well, I agree with pretty much everything you said, except I like '-q' better than '-z' for aesthetic reasons. So... what was the rationale against it? Best read the archives... I am the wrong person to ask for a statement of the opposing viewpoint... -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
Peter Scott wrote: And in any case, make '-e' have the additional connotation that implies 'no strict', and 'no warn'. no 'warnings' Seems simple enough to me. Yes, that's what I thought; but this has generated more heat than light, at least on the times I've brought it up, e.g., Please, let's not retrace this argument. It's really become apparent to me that there's two types of folks on this: 1) the quick and dirty users / utility scripters 2) the instructors and massive code maintainers (Depending on your project at the time, you may switch between roles). The former vehemently support "RFC 16: Keep default Perl free of constraints such as warnings and strict", under various mantras from "Make things easy" to "Hey, one liners!" The latter vehemently support the concept of "use strict" and "use warnings" being on by default. The justification is that it helps people write cleaner code, catch errors faster, etc, and all you have to do is say "my" in front of all your variables. (However, let's not forget about strict refs!) I personally think that this is something Larry is going to have to decide. However, I would like to note that leaving these off by default lowers the transition curve to Perl 6 immensely for those people that use Perl as a glue/scripting/sysadmin language. Key: Not everyone becomes a Perl expert. Many people never leave novice/intermediate level. This doesn't mean that we should design the language for these people, but it also doesn't mean we should thumb our noses at them. -Nate
Re: Closures and default lexical-scope for subs
So... what was the rationale against it? Best read the archives... I am the wrong person to ask for a statement of the opposing viewpoint... hey... I'm a lazy guy.. ;-) So - I guess coming from someone who holds the opposing viewpoint, what was it? Ed
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 08:19:27PM +, Nicholas Clark wrote:
On Thu, Feb 15, 2001 at 09:05:55PM +0100, [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.
As I wrote elsewhere, other reasons not to change the behaviour of my:
GetOptions (foo = \my $foo,
bar = \my $bar);
tie my $shoe = $tring;
Hmm. Nathan's example of my is in void context
Abigail's are not.
As there appears to be a way to tell them apart, is it possible (sane?) to
make both work? Or at least issue warnings (not mandatory, but defaulting
to on unless you have some sort of no warnings) for Nathan's case?
[where () round all three would make it do what he meant]
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
best way to shoot down my suggestion is an example where existing behaviour
can't be determined from void/scalar/list context.
Will the above do?
Abigail
Re: RFC on Coexistance and simulaneous use of multiple module version s?
Many thanks to all for the pointers. Paul Johnson wrote: I don't think any proposal of this nature would be conplete without a consideration of these aspects. Agreed.
Re: Closures and default lexical-scope for subs
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
best way to shoot down my suggestion is an example where existing behaviour
can't be determined from void/scalar/list context.
Will the above do?
well, I'd say no. How many people are going to run into this and have it not
do what they expect as opposed to:
my $a, $b, $c;
However, I think that:
my $a, $b, $c;
and
my $a, $b, $c = @_;
should work the same and they wouldn't do so if 'void' context was the only
criteria used.
Ed
RE: RFC on Coexistance and simulaneous use of multiple module version s?
From: Steve Simmons [mailto:[EMAIL PROTECTED]] Paul Johnson wrote: Has anyone considered the problems associated with XS code, or whatever its replacement is? Pardon my ignorance, but what's XS code? Extra code is. Which knack had you obfuscation for could left out have been. --Yoda My personal preference is that we firmly entrench Inline.pm as a barrier between your average Perl programmer and XS. -Or whatever it may become. Then XS could be described as the extra stuff you never (thank God) need to know. Garrett
Re: defined: Short-cutting on || with undef only.
On Thu, Feb 15, 2001 at 08:52:01PM +0100, [EMAIL PROTECTED] wrote: You mean the beaten-to-death ??, formely known as |||, operator? It has torn p5p to shreds repeatedly. Could be worse, could be url open(). duck cover;
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 02:03:21PM -0800, Edward Peschko wrote:
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
best way to shoot down my suggestion is an example where existing behaviour
can't be determined from void/scalar/list context.
Will the above do?
well, I'd say no. How many people are going to run into this and have it not
do what they expect as opposed to:
my $a, $b, $c;
The point isn't how many are going to run into this.
The point is how to determine when to warn or when not to warn.
It was suggested to DWIM when I use my in void context, and not when
my isn't used in void context. With the above example, such a rule
would mean '$bar1' is my()ed, and '$bar2' isn't. That's IMO, very hard
to explain, very hard to bugtrack and totally unexpected. Even if not
everyone uses it.
However, I think that:
my $a, $b, $c;
and
my $a, $b, $c = @_;
should work the same and they wouldn't do so if 'void' context was the only
criteria used.
Both of the above my()s are in void context.
Also, if I have:
@a = (1 .. 10);
$a, $b, $c = @_;
$c becomes 10. Should $c become 3 when my is placed before $a?
Abigail
Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
[resent to perl6-language, sorry for any duplicates] Edward Peschko wrote: I personally think that this is something Larry is going to have to decide. However, I would like to note that leaving these off by default lowers the transition curve to Perl 6 immensely for those people that use Perl as a glue/scripting/sysadmin language. Right, but what I don't understand is that its two extra characters at the end of a command line... whats the big deal about typing '-q' on one line in scripts? Its easy enough to advertise '-q' and put it in big lights... Yes and no, I think. As Alan Burlinson pointed out earlier, this is *not* a purely clean-slate we have here to work with. There are lots and lots and lots of users who know how Perl works. Many of these users don't even know that you can do this: my $x = 5; Let alone that this: my $x, $y, $z; Doesn't DWIM, again according to what most people think. Key: Not everyone becomes a Perl expert. Many people never leave novice/intermediate level. This doesn't mean that we should design the language for these people, but it also doesn't mean we should thumb our noses at them. So - why is it a religious issue then? I respect the fact that you want to write scripts without 'use strict'. I do this all the time. But I really think that its a small price to pay to put '-q' on the #!/usr/bin/perl command line for the vast benefits that it would give us all as far as CPAN goes. Let's separate the CPAN thing out for a moment. "use strict" and "use warnings" are not the universal solutions to CPAN quality issues, at least as far as I'm aware. As for the -q thing, I think it is far *less* of a burden to add "use strict" and "use warnings" when you're writing a big piece of code. When you're writing 5 lines, every extra character counts. When you're writing 500 or 5000 lines, 2 lines of "use" statements are nothing. So - in the place of a '-q', would you support a mechanism for making sure that CPAN is '-w' clean? If so, how would you enforce it? Absolutely, 100%. But this is a separate issue. For example, a big problem with CPAN is also packaging. There's lots of modules that don't use the h2xs/Makefile.PL approach. Also, many modules on CPAN have been in beta for years, and not just 0.99 beta but 0.02 beta, broken and uninstallable. There's also a lot of modules that don't run under -T. But "strict" won't fix these issues. If we're interested in increased CPAN quality, there's a bunch of stuff we can do. We can have a standard test suite that's run against every module uploaded to check if it's installable and compiles basically. We can check for -w, -T, use strict, and tons of other stuff. We can check for the packaging to make sure that "perl -MCPAN -e shell" will install the stuff cleanly. If there's simple problems (misnamed tar files, a $VERSION split onto multiple lines), we can even auto-fix this. Then send all the results to the user who uploaded the module. Heck, I'd even volunteer to head up a project to do this. But I think it's a separate issue from "use strict" and "use warnings", let's not confuse the two. -Nate
Re: Closures and default lexical-scope for subs
It was suggested to DWIM when I use my in void context, and not when
my isn't used in void context. With the above example, such a rule
would mean '$bar1' is my()ed, and '$bar2' isn't. That's IMO, very hard
to explain, very hard to bugtrack and totally unexpected. Even if not
everyone uses it.
well, for the small fraction of people that use it, they probably are
experienced and know to use parens to disambiguate. That's what I do when
I come across something totally unexpected. And anyways:
my $a, $b, $c = @_;
not working is 'very hard to bugtrack and totally unexpected' for a larger
percentage of perl programmers out there.
Anyways, I think this problem goes away if we adopt a suggestion that I
make below.
However, I think that:
my $a, $b, $c;
and
my $a, $b, $c = @_;
Hmm. then I have a misunderstanding of what exactly 'void' context is. 'void'
context to me is when you say
$a, $b, $c;
ie: when something is not the lhs of an '='.
should work the same and they wouldn't do so if 'void' context was the only
criteria used.
Both of the above my()s are in void context.
well, then it works then. cool.
Also, if I have:
@a = (1 .. 10);
$a, $b, $c = @_;
How about 'an implicit parens around a set of statements separated by commas
in any context'? This is consistent
$a, $b, $c = $d, $e, $f; # ($a, $b, $c) = ($d, $e, $f);
And if you say something like:
$a, $b, $c == 10, $d == 11
you need to disambiguate the sub-statements by saying
$a, $b, ($c ==10), ($d == 11)
my $a = STDIN # DWIM
my $a, $b, $c.
As for your examples:
GetOptions (foo = \(my $foo), bar = \(my $bar))
tie (my $shoe) = $string;
both of these look easier to follow to me, at least.
$c becomes 10. Should $c become 3 when my is placed before $a?
No, I think in both cases, they should produce '3'.
ok, now back to:
(my $foo1, $bar1) = (my $foo2, $bar2) = ('foo', 'bar');
Works as expected. $foo1, $bar1, $foo2, $bar2 are all 'my'ed.
Ed
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Thu, Feb 15, 2001 at 03:02:10PM -0800, Nathan Wiger wrote: If we're interested in increased CPAN quality, there's a bunch of stuff we can do. See also, CPANTS (totally vaporware, but its a plan) http:[EMAIL PROTECTED]/msg00148.html Heck, I'd even volunteer to head up a project to do this. Don't say that too loud, I might just take you up on it.
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 03:07:51PM -0800, Edward Peschko wrote: Also, if I have: @a = (1 .. 10); $a, $b, $c = @_; How about 'an implicit parens around a set of statements separated by commas in any context'? This is consistent $a, $b, $c = $d, $e, $f; # ($a, $b, $c) = ($d, $e, $f); Do you mean: (($a, $b), $c) = (($d, $e), $f); perhaps? And if you say something like: $a, $b, $c == 10, $d == 11 you need to disambiguate the sub-statements by saying $a, $b, ($c ==10), ($d == 11) So, the cost of leaving off parens at some places, is to add them elsewhere? What's the point? In the long run, you aren't gaining anything, all you are doing is messing up the precedence table. It's already complicated enough, why have a different precendence table in perl6? Fine, you might not need the parens for my(), you suddenly need them where you don't need them in perl5. my $a = STDIN # DWIM my $a, $b, $c. As for your examples: GetOptions (foo = \(my $foo), bar = \(my $bar)) tie (my $shoe) = $string; Not enough arguments for tie... This trap is documented. both of these look easier to follow to me, at least. You're kidding, right? If I wanted LISP, I know where to find it. $c becomes 10. Should $c become 3 when my is placed before $a? No, I think in both cases, they should produce '3'. Ah, more pointless changes with perl5. I think I've seen enough of perl6 by now. I'll treasure my copy of perl5 till the end of times. Abigail
Re: Closures and default lexical-scope for subs
At 09:01 PM 2/15/01 +0100, [EMAIL PROTECTED] wrote: On Thu, Feb 15, 2001 at 11:08:47AM -0800, Edward Peschko wrote: However, that still doesn't get rid of the gotchas - personally I think that: my $a, $b, $c; should be an error, a warning, or DWIM. Especially: Personally, I don't think so. GetOptions (foo = \my $foo, bar = \my $bar); and tie my $shoe = $tring; are just way too practical to suddenly require more hoops. I don't want to DWIM this. Would it be so bad to have to type GetOptions (foo = \my ($foo), bar = \my $bar); tie my ($shoe) = $tring; if we made 'my' consistent with all other functions that take lists (yes-I-know-it's-not-a-function)? -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 10:29:33PM +0100, [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 08:19:27PM +, Nicholas Clark wrote:
On Thu, Feb 15, 2001 at 09:05:55PM +0100, [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.
As I wrote elsewhere, other reasons not to change the behaviour of my:
GetOptions (foo = \my $foo,
bar = \my $bar);
tie my $shoe = $tring;
Hmm. Nathan's example of my is in void context
Abigail's are not.
As there appears to be a way to tell them apart, is it possible (sane?) to
make both work? Or at least issue warnings (not mandatory, but defaulting
to on unless you have some sort of no warnings) for Nathan's case?
[where () round all three would make it do what he meant]
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
No. But I couldn't think of anything like that, which was why I asked.
best way to shoot down my suggestion is an example where existing behaviour
can't be determined from void/scalar/list context.
Will the above do?
Yes, thanks.
I would *not* like to teach why the they behaved differently.
Nicholas Clark
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Thu, Feb 15, 2001 at 02:54:37PM -0800, Nathan Wiger wrote: Edward Peschko wrote: Right, but what I don't understand is that its two extra characters at the end of a command line... whats the big deal about typing '-q' on one line in scripts? Its easy enough to advertise '-q' and put it in big lights... Yes and no, I think. As Alan Burlinson pointed out earlier, this is *not* a purely clean-slate we have here to work with. There are lots and lots and lots of users who know how Perl works. Many of these users don't even know that you can do this: my $x = 5; Let alone that this: my $x, $y, $z; right, but that's a pretty small issue. For one, my *would* be more well known if perl had a default stricter policy. And preventing pain is a simple matter of people knowing that '-q' exists and advertising that fact. You could even put the message in the output for the error as an upgrade note: Global symbol "$ca" requires explicit package name at aa line 2. Execution of aa aborted due to compilation errors. --- NOTE: to perl5 users - by default, perl is doing more up-front error checking. To get the old behavior, you can say 'perl -q' in front of your scripts, as in: #!/usr/local/bin/perl -q (although ultimately the error checking can help quite a bit in tracking down errors. see 'use strict' and 'use warning' in the manual.) --- I think that notes like these tied to the executable are going to be big helpers in migrating people up in general. And my guess is that there are going to be a lot bigger issues than this to face for upgrading people. my $x, $y, $z; Doesn't DWIM, again according to what most people think. It would DWIM if I had my druthers. write scripts without 'use strict'. I do this all the time. But I really think that its a small price to pay to put '-q' on the #!/usr/bin/perl command line for the vast benefits that it would give us all as far as CPAN goes. Let's separate the CPAN thing out for a moment. "use strict" and "use warnings" are not the universal solutions to CPAN quality issues, at least as far as I'm aware. No of course not the 'end all be all'. But they are a large, large, large part of it. Its proactive thinking versus reactive thinking. It forces module writers to *have* a warnings policy and a strict policy. How many times have I wanted to put 'use strict' in a module and forgotten about it? How many times have I wanted to use '-w' but was not able to because of all the junk that comes out of it? Too many to count... Make it by default and a large portion of the problem is solved. As for the -q thing, I think it is far *less* of a burden to add "use strict" and "use warnings" when you're writing a big piece of code. When you're writing 5 lines, every extra character counts. When you're writing 500 or 5000 lines, 2 lines of "use" statements are nothing. well, take the two possible cases: 1) With -e, you have no extra characters to type. 2) With -q, you have two extra characters to type. If you get really used to -q, then it rolls off the fingertips: '/usr/local/bin/perl -q'. And in the rare case that you forget '-q', you'll get instant feedback from all the errors that you get. Now take the opposite case. That you forget 'use strict'. In this case, you can - and I have - looked at it for hours to find the errors that I missed. And worse yet, these are runtime errors. And then I realize that I meant 'use strict' and typically whack my head a couple of times. So - in the place of a '-q', would you support a mechanism for making sure that CPAN is '-w' clean? If so, how would you enforce it? Absolutely, 100%. But this is a separate issue. For example, a big problem with CPAN is also packaging. There's lots of modules that don't use the h2xs/Makefile.PL approach. Also, many modules on CPAN have been in beta for years, and not just 0.99 beta but 0.02 beta, broken and uninstallable. There's also a lot of modules that don't run under -T. But "strict" won't fix these issues. of course, but they will fix a large part of them. You'd be amazed how many errors will be caught with 'use strict' and 'use warnings'... If we're interested in increased CPAN quality, there's a bunch of stuff we can do. We can have a standard test suite that's run against every module uploaded to check if it's installable and compiles basically. We can check for -w, -T, use strict, and tons of other stuff. We can check But we don't want to check for '-w' and 'use strict'. We want to leave that up to the module owner. All I want is a clear policy towards warnings and strict. Thats a hell of a lot easier to achieve with something proactive. As for '-T', well, some modules don't *want* to be run in '-T' mode. The 'installable' part is intriguing, but then again there are problems with feedback - do you allow a module to be uploaded if it doesn't compile against system b, and c but works flawlessly for a,d,e,
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Thursday 15 February 2001 19:21, Edward Peschko wrote: How many times have I wanted to put 'use strict' in a module and forgotten about it? Then it isn't, technically, a perl problem. How many times have I wanted to use '-w' but was not able to because of all the junk that comes out of it? That also, technically, isn't a perl problem. Make it by default and a large portion of the problem is solved. Define "large portion" and "the problem." If you get really used to -q, then it rolls off the fingertips: '/usr/local/bin/perl -q'. If you really get used to "use strict;", then it rolls off the fingertips, too. of course, but they will fix a large part of them. You'd be amazed how many errors will be caught with 'use strict' and 'use warnings'... You'd be amazed how many errors *aren't* caught with strict and warnings. If we're interested in increased CPAN quality, there's a bunch of stuff we can do. We can have a standard test suite that's run against every module uploaded to check if it's installable and compiles basically. We can check for -w, -T, use strict, and tons of other stuff. We can check But we don't want to check for '-w' and 'use strict'. We want to leave that up to the module owner. All I want is a clear policy towards warnings and strict. Thats a hell of a lot easier to achieve with something proactive. What can be more proactive than "Your code should work."? As for '-T', well, some modules don't *want* to be run in '-T' mode. Why not? Evvery module should handle untainted data, just in case, right? That is potentially far more dangerous than using a global in the wrong package, no? In my experience, its always been the proactive policies which work the best. Reactive policies have lots of shortcomings and are hard to set up. Which is easier to do - prevent a fire or put one out after its started? Well, speaking from experience, put one out. There are an unbelievable number of ways a fire can start, a lot of them unforeseeable. But most fires themselves fall into a half-dozen classes, with fairly standard firefighting techniques. And the more I think about it, you cannot make the project you describe proactive - ie: we will not accept your module *until* conditions x,y,z occur - this would be too onerous to accept for module developers. So you want to force people to adhere to strict rules, but it would be too onerous to force them to adhere to strict rules? (Personally, I don't care about the extra warnings, as long as I can shut them up. That doesn't really change perl's behavior. Forced strictness does.) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Closures and default lexical-scope for subs
On Fri, Feb 16, 2001 at 12:32:01AM +0100, [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 03:07:51PM -0800, Edward Peschko wrote:
Also, if I have:
@a = (1 .. 10);
$a, $b, $c = @_;
How about 'an implicit parens around a set of statements separated by commas
in any context'? This is consistent
$a, $b, $c = $d, $e, $f; # ($a, $b, $c) = ($d, $e, $f);
Do you mean:
(($a, $b), $c) = (($d, $e), $f);
perhaps?
No, actually not. I mean to add the parens by determination of
'list operators', things like '='. I would discourage ',' in its use
as a statement separator, and replace it with ';'. And I'd like
to be able to say:
while ($content = $collector; length($content))
{
}
or even
while { $content = $collector; return(length($content)) }
{
}
although that does look sort of funky.
So, the cost of leaving off parens at some places, is to add them elsewhere?
What's the point? In the long run, you aren't gaining anything, all you
are doing is messing up the precedence table. It's already complicated
enough, why have a different precendence table in perl6? Fine, you might
not need the parens for my(), you suddenly need them where you don't need
them in perl5.
Well, I just analyzed this empirically. I went through a rather large module
(libwww) to analyze how much impact the changes that I'd propose would make,
in a real-life setting, and how many parens you would lose/gain in-toto:
The pattern:
my(...) = @_;
appears 116 times.
The pattern:
($x1,$y1,$z1) = ($x2, $y2, $z2);
or
while (($a1,$b1) = each (%suffixType))
appears approx 25 times.
With just these two types of items you could lose 143 pairs of parenthesis
minimum. Add on extra sundry things, and you lose 50 more paren pairs. If you
went for broke, you could probably lose lots more than this
Now, as for the things this breaks:
There were 3 things that broke outright, all statements that were:
while ($content = $collector, length $$content) {
Additionally, there were some statements that looked like:
$VERSION = sprintf("%d.%02d", q$Revision: 1.16 $ =~ /(\d+)\.(\d+)/);
which I don't think break because the operator in question (=~) only
works against scalars..
So that's 3 statements out of 9000 lines of code. But then again, I only did
a rough analysis, you are welcome to check it over.
tie (my $shoe) = $string;
Not enough arguments for tie...
This trap is documented.
I guess then I don't understand what:
tie my $shoe = $string
is supposed to do... I count either one or two arguments here, depending
on how I parse it.
both of these look easier to follow to me, at least.
You're kidding, right? If I wanted LISP, I know where to find it.
no, I'm not. And anyways, this solution is far less lispish than what
you are suggesting:
my $a, $b, $c = @_
vs
my ($a, $b, $c) = @_;
while $key, $value = each %hash
vs
while ($key, $value = each %hash)
vs
while (($key, $value) = each %hash)
I think I've seen enough of perl6 by now. I'll treasure my copy of perl5
till the end of times.
you are welcome to do that. Its called 'use perl5' at the top of your
script.
Ed
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
I guess this was what was meant by 'put your asbestos gloves on'.
On Thu, Feb 15, 2001 at 07:57:31PM -0500, Bryan C. Warnock wrote:
On Thursday 15 February 2001 19:21, Edward Peschko wrote:
How many times have I wanted to put 'use strict' in a module and
forgotten
about it?
Then it isn't, technically, a perl problem.
Yes, its a perl usability problem. It comes down to how easy perl is to use.
How many times have I wanted to use '-w' but was not able to because
of all the junk that comes out of it?
That also, technically, isn't a perl problem.
Yes, its a perl usability problem. It comes down to how easy perl is to use.
Make it by default and a large portion of the problem is solved.
Define "large portion" and "the problem."
The problem is stability/usability of modules on CPAN. The 'large portion'
of problems is the errors caused by people not using '-w' and 'strict' on their
modules causing run-time errors.
If you get really used to -q, then it rolls off the fingertips:
'/usr/local/bin/perl -q'.
If you really get used to "use strict;", then it rolls off the fingertips,
too.
yeah, but I covered this down below. If you forget '-q' it isn't that big
a deal, its easily found. If you forget 'use strict'
ANYWAYS, READ MY POST AGAIN ABOUT WHAT HAPPENS IF YOU FORGET 'USE STRICT'
BEFORE YOU SAY SOMETHING LIKE THIS.
You'd be amazed how many errors *aren't* caught with strict and warnings.
This is irrelevant. I never said it would fix the world.
What can be more proactive than "Your code should work."?
Its the enforceablity of that concept.
What I'm saying is that if you *really* want a revolution, try to force people
to only be able to release their modules *until* it works on a large number
of platforms. If you used that as a criteria, perl itself would never get out
the door. ( witness the number of bug reports on perl5-porters )
As for '-T', well, some modules don't *want* to be run in '-T' mode.
Why not? Evvery module should handle untainted data, just in
case, right?
well, no, actually. Some modules evaluate code given on the command line, and
are quite useful. And regular expressions can take - as an argument -
unevaluated code through ?{}.
That is potentially far more dangerous than using a global in the wrong
package, no?
That's why -T exists. You can turn it on if you are going to be using it in
suid scripts, and boom, it gives you a list of errors.
But the point is that sometimes things that are taint-unsafe are useful. And
hence you can't use a blanket evaluation mechanism, it has to be done case
by case.
In my experience, its always been the proactive policies which work the
best.
Reactive policies have lots of shortcomings and are hard to set up. Which
is
easier to do - prevent a fire or put one out after its started?
Well, speaking from experience, put one out. There are an unbelievable
number of ways a fire can start, a lot of them unforeseeable. But most
fires themselves fall into a half-dozen classes, with fairly standard
firefighting techniques.
ok, let me put it another way - why start fires just so you can put them out?
And the more I think about it, you cannot make the project you describe
proactive - ie: we will not accept your module *until* conditions x,y,z
occur - this would be too onerous to accept for module developers.
So you want to force people to adhere to strict rules, but it would be too
onerous to force them to adhere to strict rules?
I think that there is a basic misconception here - there is NO FORCING GOING
ON. The only thing I'm 'forcing' people to do is come up with a policy towards
warnings or strictness. Who am I to say a module writer if he/she wants to put
'no strict; no warnings' in his/her module?
The fact is, though, that people will get used to the extra safety blanket that
these two things give, and I bet people will use it 75% of the time if not more.
And we'll all be better off.
And anyways, yeah, there's a big differnce between a use strict policy, and
making a module work on 20 different platforms before it can be published.
The manpower might not be available. the equipment might not be available. The
module owner might not WANT to port his module to multiple platforms. And so
on and so on and so on.
(Personally, I don't care about the extra warnings, as long as I can shut
them up. That doesn't really change perl's behavior. Forced strictness
does.)
Exactly. You can shut them up with 'no warnings' or '-q'. There is no such thing
as 'forced strictness', that's a straw dog that's unfortunately relatively
easy to beat.
Ed
Re: Warnings, strict, and CPAN
Was this trip really necessary? Read this thread from back in September. http:[EMAIL PROTECTED]/msg00167.html There's also a whole mailing list devoted to this. http:[EMAIL PROTECTED]/ I've argued why warnings should be on by default (except in one-liners) and lost. Its all been said, guys. Even with warnings on, they are all too often ignored. Just today I got an email from a friend asking "why doesn't this program work"? The program was throwing a warning, but he'd ignored it. Turns out it was one of the problems. And he's no newbie. Taint by default is just right out, I would hope this would be obvious. Any program which takes, say, a filename from the command line and uses it to open a file for writing would have to do pointless detainting. It would become a useless ritual in /(.*)/. Worse, one would get used to that idiom and put it in places where you're *really* supposed to be detainting. strict by default is right out. That's not the sort of language Perl is. And before you start in on taint more, there are already a few RFCs on improving it, read them. I'm the bloody QA chair and I don't even think its a good idea anymore. The idea of auditing other's code (CPAN for instance) is WAY more complicated than just "you must use taint, warnings and strict". 750 megs of code from 1000+ authors around the world, there's no way in hell you can enforce such simplistic and arbitrary standards. See http:[EMAIL PROTECTED]/msg00148.html for some ideas. Now, there are numerous ways to enforce good style on your local development environment. You can replace perl on your production machine with something that does "perl -Mstrict -Tw" if you really want (be prepare to watch lots of modules break internally under taint). You can run modules and programs with some of the auditing tools available and in the works (Dunce::Files for one, more on the way). You can add to your default Makefile.PL a simple scan for "use strict", etc... You can use a test review enforcement system such as Aegis. Set up code standards and enforce them with a scanning program. Test coverage analysis is being built into Test::Harness, etc... You have to do all this anyway, flipping a few command line switches isn't going to solve fundemental software engineering problems. Yes, it would be nice if warnings were on by default, but it has too many caveats. Its also all to easy to be shut off (and don't think that's not the first switch a newbie will find). Supply your own discipline, don't make the language do it or you will be sorry. (Devo moment... "Freedom of choice is what you got, freedom from choice is what you want") And please avoid the temptation to drag this point ad nauseum. Instead of Yet Again arguing back and forth on this, go write me some code auditing tools.
