Larry Wall writes:
> I think if we have to go through contortions to get at the outer topic
> by name, it's better to just name the variable on the outer loop in the
> first place. Adding -> $varname to the outer loop is safe, because it
> doesn't change the semantics of topicality--now that
Dan Sugalski wrote:
>Okay, I'm whipping together the "fancy math" section of the interpreter
>assembly language. I've got:
[...]
>
>Can anyone think of things I've forgotten? It's been a while since I've
>done numeric work.
I'm not a math weenie, but I would thing gamma(x) would be of use.
Also
Brent Dax wrote:
>On the other hand, it could stop some of the really stupid uses for
>inheritance I've seen. The dumbest one was in high school Advanced
>Placement's C++ classes--the queue and stack classes inherited from the
>array class!
Oh? How could "final classes" prevent such a travest
John Porter wrote:
>
>Dave Mitchell wrote:
>> ie by default lexicals are only in scope in their own sub, not within
>> nested subs - and you have to explicitly 'import' them to use them.
>
>No. People who write closures know what they're doing.
>
>When's the last time someone "accidentally" wrote
David L. Nicol wrote:
>
>Are there really situations where
>
> $$reference = An Expression;
>
>is clearer than
>
> $reference = \(An Expression);
>
>?
Eric is confused. I don't know about in Perl 6-to-be, but in Perl 5
those two mean totally different things:
$foo = \$bar;
On Friday, July 20, Ilya Sterin wrote:
>No, I don't think you are understanding it correctly. It's not about
>looping sequentially, but rather simultaneouly, for comparison purposes.
>
>@foo = (1,2,3);
>@bar = (1,2,3);
>for my ($foo, $bar) (@foo, @bar) #As the index for @foo increases, so
>
on Fri Jul 20, Mark REED wrote:
>I'm sorry, but I fail to see how this is a big improvement over the
>current version:
>
>while (my ($key, $val) = each %my_hash)
>{ ... }
And a workalike to
while ( ($a,$b,$c) = (@a, @b, @c) )
or
for my ($el1, $el2) (@foo, @bar)
is very e
[on David Nicol's thought that maybe references should be treated
differently than other scalar data]
>
>But $, @, and % indicate data organization, not type...
>
Perhaps it's a mistake that Perl treats numbers and strings the
same. Perhaps "$" should be broken out into two prefixes: S for
string
In a fit of insanity, at 10:14 EDT Tue May 8, I wrote:
>
>9 times out of 100, qw saves a large number of keystrokes. (The
>other 1% of the time, ...
I hope it's obvious that I meant "99 times out of 100"
--
Eric J. Roode
At 16:17 May 7, Simon Cozens wrote:
>On Mon, May 07, 2001 at 01:14:12PM -0700, Nathan Wiger wrote:
>> I think Uri's qh() suggestion is the cleanest:
>
>Interesting train of thought, since one of the ideas was that qw() is
>ugly and has to go. (Larry's been saying this for nearly two years now,
>it
Larry Wall wrote:
[wrt multiple syntaxes for Perl 6]
>
>In any event, I'm not worried about it, as long as people predeclare
>exactly which variant they're using. And I'm also not worried that
>we'll have any lack of style police trying to enforce Standard Perl 6.
>
>Larry
As a member of a con
John Porter wrote:
>
>Dan Sugalski wrote:
>> The one downside is that you'd have essentially your own private language.
>> Whether this is a bad thing or not is a separate issue, of course.
>
>IIUC, this ability is precisely what Larry was saying Perl6 would have.
I may have my history wrong her
Larry Wall wrote:
>
>Branden writes:
>: The big question is: why fix what is not broken? Why introduce Javaisms and
>: VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5
>: code (and Perl 5 programmers) for a zero net gain?
>
>It's not zero net gain, and I'm going to ignore
Nathan Wiger wrote:
>
>Here's something I was thinking about at lunch:
>
> $concated_number = "$number" + "$other_number";
> $numerical_add = $number + $other_number;
>
One major, MAJOR pet peeve I have wrt Javascript is that it uses
+ to mean concatenation as well as addition, and that it
Allow me to throw another log on the fire:
my $x;
if (something)
{
$x = 1;
}
my $y = $x;
This would give a compile-time warning under your RFC, warning the
user of a possibly uninitialized $x. Okay. Next:
my $x;
if (something)
{
$x = 1;
}
Steve Fink, via the Perl6 Librarian, wrote:
>=head2 EXAMPLE
>
>1 my ($x, $y, $z, $r);
>2 $z = 1;
>3 f(\$r);
>4 my $logfile = "/tmp/log";
>5 $x = 1 if cond();
>6 print $x+$y;
>7 undef $z;
>8 print $z;
>
[...]
>No warning is issued for C<$r> because any variable whose
Glenn Linderman wrote:
>Eric Roode wrote:
>
>> 1. You don't say in your RFC, but I'm guessing, that a null value
>> evaluates to false in a boolean context. Correct?
>
>I would expect it to be considered false. Logical expressions involving
>NULL are defined
Steve Fink wrote:
>I am merely suggesting that the compiler detect, when it can, that
>you're trying to use the value of a variable without ever having
>assigned a value to that variable. And in THAT message, you had better
>know the name of the variable, since it's the basis of the analysis. And
1. You don't say in your RFC, but I'm guessing, that a null value
evaluates to false in a boolean context. Correct?
2. In your abstract, you say that undef is used to mean that a
variable's value is undefined, which I presume means uninitialized.
You say that null would provide a useful way to i
Nathan Wiger wrote:
>
>One thing that Nat will soon be releasing is an RFC on strict typing.
>I'll also have one (hopefully) on an embedded tie-like solution that
>will allow you to create your own variable types. With these you would
>conceivably be able to say:
>
> use strict 'types';
> my p
Michael Schwern wrote:
>See, I never understood this. If you're indenting the terminator, it
>implies you're also indenting the here-doc text. I mean, this doesn't
>make any sense:
>
>{ { { {
>print gripe is. A critic is
>simply someone paid to
>render opinions
Nathan Wiger wrote:
>
>I also suggest that no whitespace stripping/appending/etc/etc be done at
>all. If I write:
[...deletia...]
>But this shouldn't be implicit in the language.
That's a good argument for having a separate operator for these
"enhanced here docs", say <<<, rather than chucking th
Richard Proctor made some excellent comments, and asked:
>When measuring whitespace how does the system treat tabs? (be realistic
>and dont FLAME)
I suggest that there be NO tab/space conversion. Not 8 columns, not
4 columns, nothing. If the here doc terminator has four tabs preceding
it, then f
Nathan Wiger wrote:
>Actually, to me this thread underscores how broken here docs are
>themselves. We already have q//, qq//, and qx// which duplicate their
>functions far more flexibly. Question: Do we really need here docs?
Yes.
Try generating lots of HTML, Javascript, Postscript, or other
lan
Garrett Goebel wrote:
>Could someone shoot down or prop up the following:
>
>* Subroutines automatically get their name as a label
Ick! Shades of Pascal! Why don't we just replace "return $value"
with "subroutine_name = $value;"!
Seriously, what is the point of
sub func1
{
func
Ariel Scolnicov wrote:
>1. It requires the perl parser know about indentation. Of course we
> all know that tabs are 8 characters wide (I myself make a point of
> bludgeoning anyone who says otherwise), but do we really want to
> open this can of worms?
Not so fast with those 8-column tabs
Glenn Linderman wrote:
>Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
>stuff after the terminator? Even the ";" afterward seems useless... the ";"
>should be at the end of the statement, not the end of the here doc. The only
>improvement to here docs I see in this
>Imagine that you could easily override the conversion of undef() into a
>string, so that when stringified it returns something like "#UNDEF#"
>instead of just an empty string. That would make debugging far more
>easy: take a look at the output, and search for this sentinel string.
This would HAV
Raptor wrote:
>
>problem can be solved again in this way i.e. shell like syntax :
>
>while $i > 10 && $i++ && print $i;
>
>mean this
>
>while ($i > 10 ) {$i++; print $i};
But:
$i=-5; while ($i<=5) && $i++ && print $i;
doesn't mean the same as:
$i=-5; while ($i<=5) {$i++; print $i}
eve
Chaim Frenkel wrote:
>
>TC> And even in those rare places where they do, to use them as such
>TC> is gratuitously counter-efficient.
>
>Why? How is
>
> @main_list = ;
> @more_stuf = ;
>
> @just_to_do_a_job{@main_list} = ();
> @just_to_do_a_job{@more_stuff} = ();
>
>
Ariel Scolnicov wrote:
>Eric Roode <[EMAIL PROTECTED]> writes:
>
>[...]
>
>> The underlying problem is that arrays don't make SENSE as an
>> implementation for sets. What is the value of:
>
>But all of the following DO make sense as implementations
Gael Pegliasco wrote:
>
>> So what if the man wants
>>
>> @foo = @bar union @baz;
>> @foo = @bar intersetcion @baz;
>>
>> This is a lot more of a direct map than the twiddling with hashes.
>>
>> How are you drawing the line. Where does giving the user more power
>> than a turing
Randal Schwartz wrote:
>We really need a clean way to distinguish those four cases:
>
>"yes" and keep going
>"no" and keep going
>"yes" and abort after this one
>"no" and abort after this one
>
>What would you have "last" do? And how would you distinguish "the
>other one"?
Sounds
Richard Proctor wrote:
>>[Eric Roode wrote]
>> Perhaps $/ and $\ should become per-filehandle variables, and
>> there should be some way to set autochomp-on-read per filehandle,
>> and auto-newline-on-output per filehandle.
>
>I can see a small benefit for autocho
Does anyone EVER use chomp() except shortly after reading a line
of input from a stream? No?
Perhaps $/ and $\ should become per-filehandle variables, and
there should be some way to set autochomp-on-read per filehandle,
and auto-newline-on-output per filehandle.
Then, if anyone ever needs to
Richard Proctor wrote:
>
>I think what is needed is something along the line of :
>
> $re = qz{ '(' \$re ')'
>| \$re \$re
>| [^()]+
> };
>
>Where qz is some hypothetical new quoting syntax
Well, we currently have qr{}, and ??{} do
I think David's on to something good here. A major problem with
holding the bracket-matching possibilities in a special variable
(or a pair of them) is that one can't figure out what the RE is
going to do just by looking at it -- you have to look elsewhere.
Nathan Wiger wrote:
>I think it's cool
I wonder if it might not be a good idea to implement a function to
compute the intersection of two sets-as-hashes.
Intersection is the only basic set function that's not trivially
implementable with perl hashes. Sure, it's not hard to do, with
a loop and a small bit of programming, but maybe it
Gael Pegliasco wrote:
>
>Yes, this is true, but the natural syntax, for me, to manipulate sets,
>is the one of arrays.
>
>It is not natural to write :
>
>%my_fruit_set = ( 1 => 'orange', 2 => 'lemon' );
>
>but it is natural to write :
>
>@my_fruit_set = ( 'orange', 'lemon' );
>
>I don't want to ha
Bart Lateur wrote:
>On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
>>No. People should learn intrinsic mechanisms with which they can
>>construct infinitely many beautiful and powerful effects. This empowers
>>them. Making them learn yet-another-function-call merely hamstrings
>>th
TomC wrote:
>In general, getting folks to write
>
>s/^\s+//s;
>s/\s+$//s; # XXX: \z
>
>is a *good* think.
Why?
Removing leading/trailing whitespace is a tremendously frequently-
performed task. Perl gives you -l on the command line to strip
newlines on input and add them on output, sim
Nathan Wiger wrote:
>In a very cool email, Bryan Warnock talked about half a dozen different
>chop-like functions that are useful but not in core:
>
>http://www.mail-archive.com/perl6-language@perl.org/msg01522.html
>
>I think chop, champ, chip, and friends should be available via the
>
> use St
My first reaction was "NOOO!!" we'll break too much code!
Now, I'm not so sure. Nearly always, chomp() is what is called for;
how often *do* you need to chop off the last character of a string?
And, as someone else pointed out, why not the first character?
"Al" wrote:
>I would actualy lik
Stephen Potter wrote:
>Personally, I would say that q/.../ and friends were a bad idea. A lot of
>non-gurus see /.../ (whatever comes before it) and their first impression
>is that it has something to do with regex. I would suggest that anything
>that isn't a regex should not use /.../. Make q,
Dan Sugalski wrote:
>At 02:49 PM 8/29/00 -0400, Andy Dougherty wrote:
>>On Tue, 29 Aug 2000, David L. Nicol wrote:
>>
>> > I'd like to see every number bundled with a "precision" attribute.
>>
>>While that might be useful for simple calculations, I expect it would
>>simply get in the way and slow
Graham Barr wrote:
>Maybe not with 3 variables, but how many people do
>
> my %hash = @_;
> { ... }
>
>so that they can process named arguments ?
>
>Having this would remove the need for the hash assignment. Also it hash been
>suggested that it could potentially replace each
>
> { ... }
I'm n
Peter Scott wrote:
>Graham Barr once allowed as how he thought it would be neat if you could say
>
> for my($x, $y, $z) (@list) { ... }
ObLanguageMinimalist:
Um. Is this so frequently-used that the above syntax is preferable to:
while ( ($x, $y, $z) = splice (@list, 0, 3) ) {...}
?
Damian Conway wrote:
>I have a draft RFC that proposes that the LIST argument of a
>grep be optional in a hash slice, and default to the key list
>of the sliced hash. So:
>
> @hash{grep /^[^_]/}
>
>gives you the public values of %hash.
And the advantage of that over
@hash{ grep /^[^
Steve Simmons wrote:
>In all the straining at gnats over whitespace, filtering, etc, I have yet
>to see a single proposal that isn't accomplished by just using variables
>and manipulating them appropriately. And it avoids all the problems with
>whitespace on the HERE word.
In many cases, I agree
Richard Proctor proposed:
>
> All of these should work:
>
> print print << EOL;
> EOL
> print
Nat wrote:
>5.6's regular expressions have (??{ ... }) to permit recursion and
>$^R to maintain state through the parsing.
In another thread, Tomc wrote:
>[...] Likewise the @+ and @- stuff.
Okay, I'm throwing my ignorance out for the whole world to see. WTF??
Sure, I'm not in the loop, as ce
>First, $`, $& and $' will be scoped just like $1 and friends. They will
>be set by the regex and be only accessible in the current block or a
>block which starts with a regex like:
>
> if ( /foo/ ) {
Good idea. $`, $&, and $' will be used immediately 99% of the time.
For the rest of the
>
>> How about \p and \P ("P" for "pairwise groupings" or just "pairs")?
>
>\p and \P already have meanings in Perl 5 also. \p{property} matches
>any single character with the specified Unicode property, and
>\P{property} is the inverse.
Crap. Okay, that's it. Perl is just gonna have to
At our company, we pronounce "www" as "dub-dub-dub". The first
syllable of the letter "w", three times.
Very easy to say quickly. "dub-dub-dub-dot-perl-dot-com". Try it.
--
Eric J. Roode, [EMAIL PROTECTED] print
>
>> What exactly is matched by \g and \G is controlled by two new special
>> variables, @^g and @^G, which are arrays of strings.
>
>These sorts of global variables have been a problem in the past.
>Since they change the meaning of the \g and \G escapes, I think they
>should be pragmas or some o
55 matches
Mail list logo
