Re: Fisher-Yates shuffle
[EMAIL PROTECTED] writes:
> 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.
So use a semicolon. Or disambiguate with parentheses. Or try and
convince Larry that he's wrong about this. Or use the perl5 syntax
rules that will be understood by default.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Subroutine variables are like underwear
On Fri, 12 Apr 2002, Miko O'Sullivan wrote:
> SUMMARY
>
> A way to declare public names for params irrelevant to the internal variable
> names:
>
> sub load_data (-filename $filename_tainted ; 'version' 'ver'
> $version_input / /= 1) {...}
I like it. It's clean (doesn't introduce any wierd operators or keywords,
or abuses of existing ones) and logical. I think it could be rather
useful for the user of the function. I have a tendency to remember single
letters better than entire names, so a nice (or mean from a readability
standpoint) module writer could say:
sub head ( $data ; -n 'number_of_lines' $lines //= 10) {...}
And I could just remember to call
head($foo, -n => 25)
instead of positional or the long number_of_lines thingy.
Of course I don't know if I'd like people who named things just
'number_of_lines'. That destroys perls wonderful terseness.
> Setting names wouldn't be required. If they aren't set, then Perl uses the
> name of the variable. One question would be if the variable name is still
> used as the name for a param. My inclination is no: declaring them means
> you want the declared name, not the private name. If you want all the
> names, you declare them all.
I like your inclination too.
Luke
Subroutine variables are like underwear
SUMMARY
A way to declare public names for params irrelevant to the internal variable
names:
sub load_data (-filename $filename_tainted ; 'version' 'ver'
$version_input / /= 1) {...}
DETAILS
Subroutine variables are like underwear: you don't generally go showing them
to everybody. So, when I noticed how named params seem to be designed for
Perl 6, I felt, well, bashful about it. Consider this sub declaration:
sub load_data ($filename ; $version / /= 1) {...}
You could call this sub like this:
my %data = load_data(filename=>'weblog', version=>1);
Now, suppose I decide I don't like the variable name "$filename". I might
want to change it to "$filename_tainted". I wouldn't want to have to change
every call to that subroutine, especially if I've put the module on CPAN.
Yes, I could do this:
sub load_data ($filename ; $version / /= 1) {
my $filename_tainted = $filename;
undef $filename;
}
but gosh that's a lot of work just to maintain flexibility in a few
variable names. Even worse, sometimes I can't remember if it's $filename or
$file_name or $filepath or $file_path or... you get the idea. So, suppose
there were a way to declare that any of one or more named params "counts" as
the name for the param. There are several ways to do this, here's my idea:
each named param can be preceded by one or more names that begin with - or
are quoted. Bare strings without - or quotes aren't allowed because those
would be data types. Here's an example:
sub load_data (-filename $filename_tainted ; 'version' 'ver'
$version_input / /= 1) {...}
Setting names wouldn't be required. If they aren't set, then Perl uses the
name of the variable. One question would be if the variable name is still
used as the name for a param. My inclination is no: declaring them means
you want the declared name, not the private name. If you want all the
names, you declare them all.
-Miko
Re: Unary dot
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. Damian
Re: How to default? (was Unary dot)
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 ??? Guess I haven't got all the Apocalypses memorized :) -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
Re: How to default? (was Unary dot)
Okay, first thing to keep in mind, this hasn't been finally-finalized yet. Alot was hashed out in the process of proofing E4, but there will be more to come. On Fri, Apr 12, 2002 at 07:39:17PM -0400, Trey Harris wrote: > In a message dated Fri, 12 Apr 2002, Glenn Linderman writes: > > $_ becomes lexical > > $_ gets aliased to the first topic of a given clause (hence changes > > value more often, but the lexical scoping helps reduce that impact) > > Okay. But it sounds like you're saying that C, and C only, > introduces a topic, and that can't be right. From Ex4: You are correct, C is not the only topicalizer. C is too, and ->, etc... > "This is a fundamental change from Perl 5, where $_ was only aliased to > the current topic in a for loop. In Perl 6, the current topic -- whatever > its name and however you make it the topic -- is always aliased to $_." You could really say topic is just another name for $_. > "In a Perl 6 method, the invocant (i.e. the first argument of the method, > which is a reference to the object on which the method was invoked) is > always the topic" Emphasis on "method". > And obviously a C block introduces a topic (though I guess we > can pretend that C is a special kind of C). Yes. > So I had (wrongly, I guess?) extended this logic to: "all blocks taking > parameters introduce a topic, which is the first parameter". Which made > me think that C blocks, too, introduce a topic, which would be > equivalent to @_[0]. Sound logic. And it almost did go that way. But subs that access the current $_ directly are far too common, and far to useful. (Drat! Now I have to leave for several hours, just when it's getting interesting...) Allison
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 02:44:38AM -0400, Trey Harris wrote:
> I think I've missed something, even after poring over the archives for
> some hours looking for the answer. How does one write defaulting
> subroutines a la builtins like print() and chomp()? Assume the code:
>
> for <> {
> printRec;
> }
> printRec "Done!";
>
> sub printRec {
> chomp;
> print ":$_:\n";
> }
>
> Assuming the input file "1\n2\n3\n", I want to end up with:
>
> :1:
> :2:
> :3:
> :Done!:
>
> I assume I'm missing something in the "sub printRec {" line. But what?
> (I also assume, perhaps incorrectly, that I won't have to resort to
> anything so crass as checking whether my first parameter is defined...)
The first call to printRec, where you simply want to use the same $_
works without changes. Larry decided that ordinary subs don't
topicalize, partly for this very reason.
But you will be able to tell your subs to topicalize, using a property.
It hasn't been decided yet if this property will be "is topic" or
"is given", probably the latter.
sub printRec ($msg is given) {
...
}
So for the second call to printRec, you could do something like:
sub printRec ($msg //= $_ is given) {
...
}
Which would allow you to default to the outer $_ and make the first
argument the topic. It's kind of ugly, though, and wouldn't deal with
subsequent parameters in quite the way you would want. I much prefer
handling the problem with overloading:
sub printRec {
chomp;
print ":$_:\n";
}
sub printRec ($msg is given) {
printRec;
}
Allison
Re: How to default? (was Unary dot)
In a message dated Fri, 12 Apr 2002, Glenn Linderman writes: > $_ becomes lexical > $_ gets aliased to the first topic of a given clause (hence changes > value more often, but the lexical scoping helps reduce that impact) Okay. But it sounds like you're saying that C, and C only, introduces a topic, and that can't be right. From Ex4: "This is a fundamental change from Perl 5, where $_ was only aliased to the current topic in a for loop. In Perl 6, the current topic -- whatever its name and however you make it the topic -- is always aliased to $_." And later: "In a Perl 6 method, the invocant (i.e. the first argument of the method, which is a reference to the object on which the method was invoked) is always the topic" And obviously a C block introduces a topic (though I guess we can pretend that C is a special kind of C). So I had (wrongly, I guess?) extended this logic to: "all blocks taking parameters introduce a topic, which is the first parameter". Which made me think that C blocks, too, introduce a topic, which would be equivalent to @_[0]. So where did I go wrong? Trey
Re: How to default? (was Unary dot)
Trey Harris wrote: > > Oops, caught my own mistake... > Because $_ is always the topic, which is always the first parameter to a > block, which in subroutines is @_[0], right? So in a sub, $_ == @_[0]. > The only question I have is if you modify @_ with a shift, does $_ > continue to point at the old @_[0], or does it now point at the new @_[0], > the original @_[1]? The above seems to me to be very confused. My understanding of Perl 5 is that $_ != @_[0] Shifting @_ has nothing to do with the value of $_ in any context I am aware of. And I've heard nothing about Perl 6 that changes that. Things about Perl 6 that are different than Perl 5 with respect to $_ include: $_ becomes lexical $_ gets aliased to the first topic of a given clause (hence changes value more often, but the lexical scoping helps reduce that impact) > Trey -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
On Wed, Apr 10, 2002 at 05:47:01PM -0500, Allison Randal wrote: > I'm in favor of the standardized variable name. It is a restriction, but > not an onerous one. I've never used anything but $self, and I'm sure it > would be easy to adapt to whatever else was chosen. Are there any > statistics availble on current usage of $self vs. $this vs. whatever? It > might be easiest to go with what the majority find most comfortable. The top 20 'my $var' declarations in .pm files in the bleedperl distribution: (I was in need of some displacement activity) 1076 $self 181 $x 126 $file 110 $class 109 $name 98 $i 92 $line 82 $r 80 $s 75 $dir 74 $a 71 $fh 70 $key 69 $path 68 $p 68 $y 66 $c 66 $n 63 $text 60 $type and in 48th place: 22 $this Dave. -- "Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit." Lady Croom - Arcadia
Re: Unary dot
On Thu, Apr 11, 2002 at 08:49:40AM -0700, Larry Wall wrote:
> Aaron Sherman writes:
> : On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
> : > $foo.instancevar = 7;
> :
> : This should not be allowed.
>
> Well, that depends on what you mean by "this". :-)
>
> That is, in fact, calling an accessor function, and if it's not allowed,
> it's because the attribute is marked private, not because we're against
> people thinking of it as a struct.
>
> : External code should not access instance
> : variables. We did discuss the idea that accessors would be created
> : automatically, and coincidentally, you're using the correct syntax for
> : that above, but certainly there should be the ability to override the
> : default accessor and to declare an instance variable as accessor-less.
>
> By default attributes are private, which means the corresponding
> accessor name is also private. There's no need to override the
> automatic accessor merely to make something accessor-less to the
> general public.
>
> : In Perl5 C<$object{instancevar} = 7> is just frowned on. In Perl6, I
> : thought we had agreed that it would flat out be impossible.
>
> Who agreed to that? First of all, it's perfectly possible that (for a
> non-hash) that syntax is isomorphic to
>
> $object.instancevar = 7;
>
> since I've already said that any object can be used as if it were a
> hash. Plus we'll have lvalue methods in some fashion or other. Not by
> default, of course. It's up to the class to decide how much it wants
> to break encapsulation.
One of the features I like about Eiffel is what Meyer calls the Uniform
Access principle, which he describes as "All services offered by a module
should be available through a uniform notation, which does not betray
whether they are implemented through storage or through computation."
In other words, the users of my module shouldn't have to worry about
whether they are calling a method or accessing an instance variable, and
when I change my implementation from one to the other they shouldn't
have to change their code.
See http://www.elj.com/elj/v1/n1/bm/urp/ for more details.
Languages like C++ don't support this and you end up writing lots of
accessor functions. Do that in Perl 5 and you pay the price of calling
a subroutine.
It sounds as though Perl 6 is heading towards supporting this. Have we
actually got there?
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: How to default? (was Unary dot)
Oops, caught my own mistake...
In a message dated Fri, 12 Apr 2002, Trey Harris writes:
> In a message dated Fri, 12 Apr 2002, Luke Palmer writes:
> > sub printRec {
> > my $p = chomp(shift // $_);
> > print ":$_:\n"
> > }
[Should be equivalent to]
> sub printRec {
> my $p = chomp(shift // shift);
> print ":$p:\n";
> }
Actually, it should be equivalent to
sub printRec {
my $p = chomp(shift // @_[0]);
print ":$p:\n";
}
No shifting is happening just by referring to $_.
Because $_ is always the topic, which is always the first parameter to a
block, which in subroutines is @_[0], right? So in a sub, $_ == @_[0].
The only question I have is if you modify @_ with a shift, does $_
continue to point at the old @_[0], or does it now point at the new @_[0],
the original @_[1]?
Trey
Re: Fisher-Yates shuffle
--
On Fri, 12 Apr 2002 18:27:11
abigail wrote:
>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
As i understand it (Tell me if I'm wrong) This
%hash {key};
will not work, because space between the hashname and the brace was no longer allowed.
This allows for
if %hash{key} { ... }
and also
if $scalar { ... }.
The only other white space rule is that white space after the closing brace of a
closure, when that closure is the last argument of a user defined sub get's treated as
a semicolon if there is nothing else on that line. This allows custom iterators to
parse (or appear to parse) like builtins.
myforeach @arry, %hash, $scalar {
...
}
#No semicolon required!
What problems does this seem to cause - I don't see anything wrong. I don't see how
(except in the case of closure as last argument) how it matters one way or another
what kind white space appears between tokens.
What am I missing?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Fisher-Yates shuffle
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.
Hold on--why end of line? That should only make a difference if } is the
only thing on the line...
Luke
Re: How to default? (was Unary dot)
In a message dated Fri, 12 Apr 2002, Luke Palmer writes:
> Couldn't you do it with old-style Perl5 subs?
>
> sub printRec {
> my $p = chomp(shift // $_);
> print ":$_:\n"
> }
>
> Or am _I_ missing something?
That definitely won't work (aside from the $p/$_ swap which I assume is
unintentional), because $_ is now lexical. If my understanding is correct
and $_ is always the topic, and the first parameter of any block is always
the topic, that would make your code somewhat equivalent to:
sub printRec {
my $p;
if (defined @_[0]) {
$p = shift;
} else {
$p = @_[0];
}
print ":$p:\n";
}
Or is the topic of a block mutable (i.e., will a shift cause the topic to
shift as well)? If so, I guess your code is actually is equivalent to:
sub printRec {
my $p = chomp(shift // shift);
print ":$p:\n";
}
Either way, bizarre, no? What I *think* you meant to say is:
sub printRec {
my $p = chomp(shift // caller.MY{'$_'});
print ":$p:\n"
}
which should certainly work, it just makes my skin crawl--vestiges of
Perl 4 still coming to bite us, or something.
Trey
Re: How to default? (was Unary dot)
On Fri, 12 Apr 2002, Trey Harris wrote:
> I think I've missed something, even after poring over the archives for
> some hours looking for the answer. How does one write defaulting
> subroutines a la builtins like print() and chomp()? Assume the code:
>
> for <> {
> printRec;
> }
> printRec "Done!";
>
> sub printRec {
> chomp;
> print ":$_:\n";
> }
>
> Assuming the input file "1\n2\n3\n", I want to end up with:
>
> :1:
> :2:
> :3:
> :Done!:
>
> I assume I'm missing something in the "sub printRec {" line. But what?
> (I also assume, perhaps incorrectly, that I won't have to resort to
> anything so crass as checking whether my first parameter is defined...)
Couldn't you do it with old-style Perl5 subs?
sub printRec {
my $p = chomp(shift // $_);
print ":$_:\n"
}
Or am _I_ missing something?
Luke
Re: Unary dot
On Wed, Apr 10, 2002 at 08:47:17PM -0400, Melvin Smith wrote: > At 08:04 AM 4/11/2002 +1000, Damian Conway wrote: > >Of course, the problem is then: what should the name of this topicalizer > >variable be? The main options are: > > > > $self > > $me > > $I > > $this > > $invocant > > $object > > $obj > > > >And frankly, that's a very minor issue. Someone (i.e. Larry) should just > >pick one and then we can all move on. > > I'm waiting for Larry to say, "We have decided to use $me, $myself and $i. And then we also get the Perl 6 theme tune thrown in for free. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
vector processing in Perl6?
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". 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? * Are there any language constructs (pragmas?) that might be useful to add to enhance use of VPs? * Is there an abstract model that could let Perl6 take advantage of assorted VP architectures? -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm- my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: How to default? (was Unary dot)
In a message dated Fri, 12 Apr 2002, Ashley Winters writes:
> Would it would be reasonable to have given default to the caller's topic?
>
> sub printRec {
> given {
> # $_ is now the caller's topic in this scope
> }
> }
>
> Perhaps C would work as well.
Yes, something like that would be nice. Of course, you could say, C, but I think there's two separate things going on here:
1) There should probably be something in the syntax to allow for
retopicalization of the up-scope topic
2) It may be useful to have some way to allow single-parameter blocks to
take the up-scope topic as a first parameter.
Trey
RE: Defaulting params
Melvin Smith wrote:
> So we have undef and reallyundef? :)
Seems reasonable, given that we have c and c.
How about:
sub foo ( $a is optional )
{
if exists($a) { ... }
elsif defined($a) { ... }
else { ... }
}
Dave.
Re: How to default? (was Unary dot)
- Original Message -
From: "Graham Barr" <[EMAIL PROTECTED]>
> Hm, I wonder if
>
> sub printRec($rec=$_) { ... }
>
> or someother way to specify that the current topic be used
> as a default argument, might be possible
Would it would be reasonable to have given default to the caller's topic?
sub printRec {
given {
# $_ is now the caller's topic in this scope
}
}
Perhaps C would work as well.
Ashley Winters
Re: Fisher-Yates shuffle
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'll treasure my perl5 sources.
Abigail
Re: Fisher-Yates shuffle
On Fri, Apr 12, 2002 at 04:00:37PM +0100, Piers Cawley wrote:
>
> [EMAIL PROTECTED] writes:
> > As for "cleanness", this is my interpretation of how perl6 is going
> > to work:
> >
> > %foo = ();
> > if %foo {"key"} {print "Hello 1"}
> >
> > %foo = ();
> > if %foo{"key"} {print "Hello 2"}
> >
> > %foo = ();
> > if %foo{"key"}{print "Hello 3"}
> >
> > Case 1 will print "Hello 1"; this is a block after the if statement.
>
> No, it will be a syntax error. The first closing brace does not end
> the statement, probably something like "Block seen when keyword
> expected".
Now I am confused. In perl6, we can leave off the the parenthesis
around a condition, and I hope that it isn't required to have
an 'elsif' or 'else' block.
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?
> > Case 2 will not print anything. The print is in the 'then' part
> >of the if.
>
> Correct.
>
> > Case 3 will be a syntax error - an if statement with a condition,
> >but not block.
>
> It won't be a syntax error *yet*. If there's a block immediately
> following then that will be treated as the 'then' block. If it's the
> end of file, or a nonblock, then it'll be a syntax error.
Did the code show anything following it? No? Well, then assume
it isn't there. ;-)
Next time I'll show this to someone, I'll add a semicolon.
Abigail
Re: Fisher-Yates shuffle
[EMAIL PROTECTED] writes:
> On Fri, Apr 12, 2002 at 04:00:37PM +0100, Piers Cawley wrote:
>>
>> [EMAIL PROTECTED] writes:
>> > As for "cleanness", this is my interpretation of how perl6 is going
>> > to work:
>> >
>> > %foo = ();
>> > if %foo {"key"} {print "Hello 1"}
>> >
>> > %foo = ();
>> > if %foo{"key"} {print "Hello 2"}
>> >
>> > %foo = ();
>> > if %foo{"key"}{print "Hello 3"}
>> >
>> > Case 1 will print "Hello 1"; this is a block after the if statement.
>>
>> No, it will be a syntax error. The first closing brace does not end
>> the statement, probably something like "Block seen when keyword
>> expected".
>
> Now I am confused. In perl6, we can leave off the the parenthesis
> around a condition, and I hope that it isn't required to have
> an 'elsif' or 'else' block.
>
> 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.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Fisher-Yates shuffle
[EMAIL PROTECTED] writes:
> As for "cleanness", this is my interpretation of how perl6 is going
> to work:
>
> %foo = ();
> if %foo {"key"} {print "Hello 1"}
>
> %foo = ();
> if %foo{"key"} {print "Hello 2"}
>
> %foo = ();
> if %foo{"key"}{print "Hello 3"}
>
> Case 1 will print "Hello 1"; this is a block after the if statement.
No, it will be a syntax error. The first closing brace does not end
the statement, probably something like "Block seen when keyword
expected".
> Case 2 will not print anything. The print is in the 'then' part
>of the if.
Correct.
> Case 3 will be a syntax error - an if statement with a condition,
>but not block.
It won't be a syntax error *yet*. If there's a block immediately
following then that will be treated as the 'then' block. If it's the
end of file, or a nonblock, then it'll be a syntax error.
> You call this **CLEAN**? Not even in Python can a space influence
> control flow that significantly. (In fact, in Python, Java, C, Pascal,
> awk, and perl5, whitespace between an aggregates names and its index is
> optional. Not mandatory, not forbidden, no, optional).
I confess that it's not my favourite feature. But I wouldn't go so far
as to say it wasn't clean. 'Different', certainly.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: How to default? (was Unary dot)
On Fri, 2002-04-12 at 09:52, Jonathan Scott Duff wrote:
> On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
> > > sub printRec() { printRec($_) } # No args, therefore no new topic.
> > > sub printRec($rec) { .chomp; print ":$rec:\n" } # 1 arg
> >
> > I think was he was saying is that your first printRec would not have a
> > $_ available to it (lexically scoped, as I understand it).
> >
> > You've got a problem here, which I don't think there's a mechanism for.
>
> If $_ is lexical by default (did larry say this somewhere?), then I'm
> sure we can make it dynamic on request ala:
Nope, I don't think that works. If the caller of printRec has to do
something special, we're meeting the original request which is to be
able to write print, which scoops up $_ without any special case code.
Now, we can say, "you just can't ever write print." I can understand why
we would, but why NOT just allow the subroutine author to indicate that
the subroutine acquires the current topic as a parameter default? It
would seem nice and clean. Either
foo($a=$_){}
as Graham suggests, or
foo(->$a){}
which was mine. Either one works. I guess with the aliasing of $_,
Graham's seems cleaner to me.
Of course, the other conversation pending, we might end up with:
foo($a//=$_){}
which doesn't do the same thing as print, but may be the best we can do
with the syntax we have.
> I read the original posters message the same as Piers though.
Ok, what did you get from it that's different?
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 09:26:45AM +0100, Piers Cawley wrote:
> Trey Harris <[EMAIL PROTECTED]> writes:
>
> > I think I've missed something, even after poring over the archives for
> > some hours looking for the answer. How does one write defaulting
> > subroutines a la builtins like print() and chomp()? Assume the code:
> >
> > for <> {
> > printRec;
> > }
> > printRec "Done!";
> >
> > sub printRec {
> > chomp;
> > print ":$_:\n";
> > }
>
> You could take advantage of subroutine signatures and multi-dispatch
>
> sub printRec() { printRec($_) } # No args, therefore no new topic.
> sub printRec($rec) { .chomp; print ":$rec:\n" } # 1 arg
Hm, I wonder if
sub printRec($rec=$_) { ... }
or someother way to specify that the current topic be used
as a default argument, might be possible
Graham.
Re: Defaulting params
On Fri, 2002-04-12 at 00:37, Melvin Smith wrote:
> At 04:03 PM 4/11/2002 -0400, Aaron Sherman wrote:
> >Notice that we have two different types of defaulting here. The second
> >argument is the file to work on, and we set it to a reasonable default
> >if it is undefined for whatever reason. However, the third argument is
> >sensitive to undef vs no parameter. In the case of not getting a third
> >arguement, a reasonable default is set. If an argument is given, but it
> >is undef, no backup will be performed.
>
> So we have undef and reallyundef? :)
Yes, just as with any array. We always have an exists() vs defined(). We
also have a length.
An argument list has a length and each element either exists or does
not. An undefined parameter still exists, of course. Is this not basic
Perl?
> >[I don't know if you can use a parameter to default another parameter.
> >It would be nice, but I can see why you wouldn't.]
> >
> >Without an "=" operator here, you would need to add another argument to
> >flag doing backups or not (not really the Perl Tao) or you would have to
> >do the argument processing manually, which sort of defeats the whole
> >point.
>
> I would typically handle this with overloading the function instead.
> Its definitely easier for the reader to understand that way, in my opinion.
Ok, let's take my example and try to do it with overloading:
sub nukeuser ($user,$pwfile //= $pwdfl) {...}
sub nukeuser ($user,$pwfile //= $pwdfl, $backup) {...}
Question, are you proposing that this is valid? Would I need a second
//= on the $backup? Which version would nukeuser('ajs') call? Which one
would nukeuser(backup => $x, user => $y) call (I *think* that one is
obvious to me, but I don't see how it's obvious to the compiler).
You're proposing a whole lot more coding for the user than:
sub nukeuser ($user,$pwfile//=$pwdfl,$backup="$pwfile.bak") {...}
Which, seems to also be easier on the eye, at least to me. Granted, the
//= looks a little funky, but that's the syntax we already had. I'm just
proposing the simpler one be added.
> Else your function prototypes become a language of their own.
Having two operators is hardly "a language of their own" if it is, then
having the one operator is half a language? ;-)
> I wish we would stick to simple semantics, allow overloading, allow
> a single operator for a default argument, and follow the C++ style of
> ambiguity resolution.
The C++ style of ambiguity resolution does not involve passing parameter
pairs, list explosion, etc. These are all features that Perl6 will have
from the gate, so I just don't see how Perl6 can have the same approach
as C++.
What's more, in C++,
void foo(const char* a="stuff"){ ... }
foo(NULL);
will pass NULL, not "stuff". We're proposing a syntax which is incapable
of that distinction. :-(
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
> On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
> > Trey Harris <[EMAIL PROTECTED]> writes:
> >
> > > I think I've missed something, even after poring over the archives for
> > > some hours looking for the answer. How does one write defaulting
> > > subroutines a la builtins like print() and chomp()? Assume the code:
> > >
> > > for <> {
> > > printRec;
> > > }
> > > printRec "Done!";
> > >
> > > sub printRec {
> > > chomp;
> > > print ":$_:\n";
> > > }
> >
> > You could take advantage of subroutine signatures and multi-dispatch
> >
> > sub printRec() { printRec($_) } # No args, therefore no new topic.
> > sub printRec($rec) { .chomp; print ":$rec:\n" } # 1 arg
>
> I think was he was saying is that your first printRec would not have a
> $_ available to it (lexically scoped, as I understand it).
>
> You've got a problem here, which I don't think there's a mechanism for.
If $_ is lexical by default (did larry say this somewhere?), then I'm
sure we can make it dynamic on request ala:
for $_ is temp <> {
printRec;
}
I may have the syntax slightly borked but you get the idea.
I read the original posters message the same as Piers though.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: How to default? (was Unary dot)
On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
> Trey Harris <[EMAIL PROTECTED]> writes:
>
> > I think I've missed something, even after poring over the archives for
> > some hours looking for the answer. How does one write defaulting
> > subroutines a la builtins like print() and chomp()? Assume the code:
> >
> > for <> {
> > printRec;
> > }
> > printRec "Done!";
> >
> > sub printRec {
> > chomp;
> > print ":$_:\n";
> > }
>
> You could take advantage of subroutine signatures and multi-dispatch
>
> sub printRec() { printRec($_) } # No args, therefore no new topic.
> sub printRec($rec) { .chomp; print ":$rec:\n" } # 1 arg
I think was he was saying is that your first printRec would not have a
$_ available to it (lexically scoped, as I understand it).
You've got a problem here, which I don't think there's a mechanism for.
Perhaps
sub printRec(->$rec)
I'm just throwing that out, but some way to say that the argument
defaults to getting the topic would seem to be called for.
Re: How to default? (was Unary dot)
Trey Harris <[EMAIL PROTECTED]> writes:
> I think I've missed something, even after poring over the archives for
> some hours looking for the answer. How does one write defaulting
> subroutines a la builtins like print() and chomp()? Assume the code:
>
> for <> {
> printRec;
> }
> printRec "Done!";
>
> sub printRec {
> chomp;
> print ":$_:\n";
> }
You could take advantage of subroutine signatures and multi-dispatch
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print ":$rec:\n" } # 1 arg
Assuming we *get* multidispatch that is. It would be nice to hope that
the compiler could optimize that...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
How to default? (was Unary dot)
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for <> {
printRec;
}
printRec "Done!";
sub printRec {
chomp;
print ":$_:\n";
}
Assuming the input file "1\n2\n3\n", I want to end up with:
:1:
:2:
:3:
:Done!:
I assume I'm missing something in the "sub printRec {" line. But what?
(I also assume, perhaps incorrectly, that I won't have to resort to
anything so crass as checking whether my first parameter is defined...)
--
Trey Harris
Secretary and Executive
SAGE -- The System Administrators Guild (www.sage.org)
Opinions above are not necessarily those of SAGE.
