Re: How to default? (was Unary dot)
On Sat, Apr 13, 2002 at 08:53:41AM -0700, Glenn Linderman wrote: > > Off hand, it seems like defaulting to "is dynamic_topic" would make > more of those common useful $_-dependent subroutines work without > change, but I guess if the perl 5 to 6 translator can detect use of $_ > before definition of $_ within a sub accurately, that it could provide > the appropriate annotation during conversion. > ... I agree dynamic scoping of $_ in subroutines by default would make for an easier transition between 5 and 6. And at first I preferred it. But I'm gradually leaning in the opposite direction. The lexical scoping of $_ encourages encapsulation (good coding practice), and minimizes unexpected side effects. > I'm not a real heavy user of $_ for everything, as some people seem to > be. It's useful at times, but can also be confusing at times. I think the two most confusing aspects of $_ in 5 are the fact that it isn't created consistently (only when there isn't a named alias) and how easy it is to accidentally clobber it. Both of which should be eliminated in 6. :) > Regarding is topic_preserving: I assume that it would not have to be > the first parameter; it would generally be more useful as the last, I > expect, as in split, or the first optional parameter. Of course, > there are cases where first and last are the same, or the other > parameters can also be usefully defaulted when the first one is, etc. Yeah, any of the properties or //= should work on any parameter in the list. > There'd be an interaction between is topic_preserving, default parameter > values, and explicit parameter values which should be clarified. Now I > understand why someone suggested using //= $_ instead of is > topic_preserving, somewhere along the line. Well, "topic_preserving" wasn't intended as a defaulting mechanism, just as a way of keeping the value of $_ across subroutines, even though it's lexically scoped. That's why I prefer the subroutine property, it makes it clearer that we're fundamentally altering the behaviour of subroutines, instead of making it look like we're just monkeying around with the parameters. For defaulting to the current topic, I'd probaly choose a property name "topic_default" instead. Possibly it would be helpful to be explicit about the options we're discussing: sub foo ($bar //= $_, ... The parameter can be passed a value, but it will default to the outer $_ if not passed a value. It will not set the value of $bar as topic within the subroutine, so the inner $_ will be undefined (unless there was a global $_ defined, which would produce really anti-dwim behaviour). One thing to consider here is that we're already abusing the "$_ is lexical" concept to make the $_ of the calling scope accessible as a value for the parameter. If you wanted to also make $bar the topic within the sub, you'd have to use the property C: sub foo ($bar //= $_ is given, ... So, the C property would condense the two behaviours into one. I would guess that if you've defaulted to $_ you would expect it to also be $_ within the sub anyway. sub foo ($bar is topic_default, ... It also makes it clearer that this isn't your ordinary //= default happening, but a special lexical scope bending one. The other proposed property, C, wouldn't accept a value passed in, it would only and always be the $_ of the calling scope, and make it the topic within the subroutine scope. sub foo ($bar is topic_preserving, ... Okay, looking at the details laid out like this, I would probably ditch the "topic_preserving" property in favor of "topic_default". But "topic_default" isn't going to give us perl 5 behaviour. Neither would "topic_preserving", because both alter the parameter structure of the sub. So, my favorite final solution: Use the subroutine property "dynamic_topic" for perl 5 behaviour, "topic_default" to create C type subs. > If the user supplied both //= 3 and is topic_preserving, that would > either be a bug or a feature. I guess as a feature, it would use $_, > but if $_ were undef, then it would use 3 ??? I'd say a bug. I don't know, can you: sub foo ($bar //= $some_value //= 3, ... (Presuming that $some_value is a true global or otherwise accessible in the scope where the sub was defined.) If you can do that, then it should probably work the same for $_ defaulting. Allison
Re: vector processing in Perl6?
Rich Morin writes: : Some while back, I asked the Perk5-porters whether there were any : parts of Perl that could benefit from vector processors (e.g., the : G4 Velocity Engine). The consensus of the respondents ranged from : "probably not" to "I don't want to think about it". Well, Perl 5 doesn't really support compact arrays of known size, and those are the only kind that are easy to think about when it comes to vectorization. : I think that better answers could have been found, given the right : motivation, but nobody was taking VPs seriously back then (the G4 : was seen as a small, niche machine). With booming sales of iMacs : and the advent of Mac OS X, however, the G4 is starting to look a : bit more real. : : Looking at some of Perl6 language features (e.g., hyperoperators : and Damian's Quantum magic), it seems like it might be time to ask : the question again. So: : :* What parts of Perl6 might benefit from a vector processor? Well, compact arrays of known size, either compact ints or floaters. :* Are there any language constructs (pragmas?) that might be : useful to add to enhance use of VPs? Not pragams, perhaps, but definitely things of a declarative nature. This sort of proposed declaration ought to vectorize easily: my num @a is dim(1024,1024) = init_a(); my num @b is dim(1024,1024) = init_b(); my num @c is dim(1024,1024); @c = @a ^* @b; Vectorizing compact arrays of indefinite size is probably the next easiest thing. Vectorizing noncompact arrays of scalars would be tricky, and really only doable if it could be guaranteed that all of the scalars in the array are of exactly the same form. Perl 5 certainly has no way of enforcing that, though it's possible Perl 6 could with sufficiently precise declaration. :* Is there an abstract model that could let Perl6 take advantage : of assorted VP architectures? Well, you really want to talk to the PDL folks there, I suspect. We're not necessarily trying to put all of the PDL abstractions into Perl 6, but we're most definitely trying to make it easy for the PDLers to warp Perl into the language of their dreams. Larry
Re: Unary dot
[EMAIL PROTECTED] writes: : Dave Mitchell wrote: : : > The top 20 'my $var' declarations in .pm files in the bleedperl : > distribution: : : How *dare* you introduce hard data into this discussion! : Next you'll be wanting to deal in actual facts rather than personal : opinion and sheer guesses!! : : ;-) : : Thanks, Dave. Very illuminating. Of course, one of the big reasons we went with $self was the pun: my $self = shift; which we won't have now. Unless we always hide the invocant and force you to say my $self = invocant; or some such mummery. But that seems a bit retro. Larry
Re: How to default? (was Unary dot)
> There'd be an interaction between is topic_preserving, default parameter > values, and explicit parameter values which should be clarified. Now I > understand why someone suggested using //= $_ instead of is > topic_preserving, somewhere along the line. Clearly if the user > supplies the parameter, is topic_preserving would limit itself to making > that parameter available as $_ within the sub. If the user supplied > both //= 3 and is topic_preserving, that would either be a bug or a > feature. I guess as a feature, it would use $_, but if $_ were undef, > then it would use 3 ??? Personally, I like //= $_. It's clear, such that a reader would immediately know what it's doing. topic_preserving, despite being more verbose, is not so clear. Plus, if someone didn't know about that feature, that's probably the first thing they would do (provided they knew about defaults) to accomplish that task. Luke
Re: Fisher-Yates shuffle
On Sat, Apr 13, 2002 at 12:51:06AM -0700, Ashley Winters wrote:
> Perl today: A semicolon is required after every statement, except before a
> closing curly or end of file.
> Perl 6: A semicolon is also required after every block, except when the
> closing curly is on a line of its own, or it precedes another closing curly
> or end of file.
This is incorrect according to the examples in the apocalypse:
if 1 { ...; break; }
die "panic: shouldn't see this";
The apocalypse implies that the new rule applies to "expression
blocks"--as opposed, I think, to statement blocks. As far as I
understand these terms, if always takes statement blocks, so this
rule does not apply.
Who can clear up the confusion?
Andrew
Re: How to default? (was Unary dot)
Allison Randal wrote:
> What if $_ were dynamically scoped, but only for subroutines? Dynamic
> scoping is not necessarily the same thing as a global $_. It would
> merely pretend (only for $_) that the subroutine had been defined in the
> scope where it was evaluated. But that could get you into trouble with
> recursion. So then you would want some way to explicitly either turn on,
> or turn off, dynamic scoping for a specific subroutine. The C
> (or C) property would be an obvious way to turn it off (since
> it would create a $_ scoped to the subroutine). But, what if you wanted
> it off by default? It could be turned on either as a characteristic of
> the sub as a whole, or as a characteristic of an individual parameter:
>
> sub foo is dynamic_topic {
> ...
> }
>
> sub foo ($bar is topic_preserving, $baz) {
> ...
> }
>
> The property C would be both binding the value of
> the $_ in the calling scope to $bar and making $bar the current topic in
> the scope of the sub.
>
> The subroutine property would be basically the same, but wouldn't give
> you a named variable, and also wouldn't require you to include an extra
> parameter (which could be nice).
OK, I can see how all these things could work. Off hand, it seems like
defaulting to "is dynamic_topic" would make more of those common useful
$_-dependent subroutines work without change, but I guess if the perl 5
to 6 translator can detect use of $_ before definition of $_ within a
sub accurately, that it could provide the appropriate annotation during
conversion. And personally, I haven't written subs that assume dynamic
$_ usage (I think), so I'm not too concerned about which way the default
goes. I'm not a real heavy user of $_ for everything, as some people
seem to be. It's useful at times, but can also be confusing at times.
Regarding is topic_preserving: I assume that it would not have to be the
first parameter; it would generally be more useful as the last, I
expect, as in split, or the first optional parameter. Of course, there
are cases where first and last are the same, or the other parameters can
also be usefully defaulted when the first one is, etc.
There'd be an interaction between is topic_preserving, default parameter
values, and explicit parameter values which should be clarified. Now I
understand why someone suggested using //= $_ instead of is
topic_preserving, somewhere along the line. Clearly if the user
supplies the parameter, is topic_preserving would limit itself to making
that parameter available as $_ within the sub. If the user supplied
both //= 3 and is topic_preserving, that would either be a bug or a
feature. I guess as a feature, it would use $_, but if $_ were undef,
then it would use 3 ???
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 05:34:13PM -0700, Glenn Linderman wrote:
> Allison Randal wrote:
> > > In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
> > > > $_ becomes lexical
>
> > Sound logic. And it almost did go that way. But subs that access the
> > current $_ directly are far too common, and far to useful.
>
> One thing I'm missing is how those common useful subs that access the
> current $_ directly will be affected by $_ becoming lexical...
>
> Or perhaps $_ stays global, but gets automatically "restored" at the end
> of blocks in which it is changed, so that it appears lexical in value,
> even though it is global in the name space ???
No, it is truly lexical. Absolutely, positively.
And you're right that this should present a problem. The lexical scope
of a subroutine is the lexical scope where it was defined, not the
lexical scope where it was evaluated. So, typical subs can only access
global external variables, while closures and lexical subs access
external variables from the scope in which they were defined.
I suspect I've imperfectly represented the original idea, but I'll
proceed as devil's advocate, for the sake of discussion...
What if $_ were dynamically scoped, but only for subroutines? Dynamic
scoping is not necessarily the same thing as a global $_. It would
merely pretend (only for $_) that the subroutine had been defined in the
scope where it was evaluated. But that could get you into trouble with
recursion. So then you would want some way to explicitly either turn on,
or turn off, dynamic scoping for a specific subroutine. The C
(or C) property would be an obvious way to turn it off (since
it would create a $_ scoped to the subroutine). But, what if you wanted
it off by default? It could be turned on either as a characteristic of
the sub as a whole, or as a characteristic of an individual parameter:
sub foo is dynamic_topic {
...
}
sub foo ($bar is topic_preserving, $baz) {
...
}
The property C would be both binding the value of
the $_ in the calling scope to $bar and making $bar the current topic in
the scope of the sub.
The subroutine property would be basically the same, but wouldn't give
you a named variable, and also wouldn't require you to include an extra
parameter (which could be nice).
Allison
Re: Fisher-Yates shuffle
- Original Message -
From: <[EMAIL PROTECTED]>
> On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
> > [EMAIL PROTECTED] writes:
> > >
> > > Why isn't
> > >
> > > if %foo {"key"} {print "Hello 1"}
> > >
> > > equivalent with the perl5 syntax:
> > >
> > > if (%foo) {"key"} {print "Hello 1"}
> > >
> > > Which keyword is it expecting?
> >
> > Keyword /els(e|if)/, or end of line, or semicolon. Sorry badly phrased
> > on my part. The closing brace of {"key"} only ends the statement if it
> > is followed by /\s*$/, or a semicolon.
>
>
> You've got to be kidding. That makes the whitespace rules even more
> insane; your program can behave quite differently wether there's a space,
> a newline, or nothing between two tokens. Wonderful! People who tend
> to use -e all the time (like me) will love it. (Not!) Pasting code into
> IRC will be so much more fun.
I don't think it's all that insane, Perl has history with implied
semicolons.
Perl today: A semicolon is required after every statement, except before a
closing curly or end of file.
Perl 6: A semicolon is also required after every block, except when the
closing curly is on a line of its own, or it precedes another closing curly
or end of file.
As far as whitespace, you can get around that
if%foo{"key"}->{print"Hello"} # -> and \s{ are kinda equivalent
if%foo->{"key"};{print"Hello"}
Using -> like that would be evil. We should put it in the test suite now...
Ashley Winters
