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
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
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
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
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
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
[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
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 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
>
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;
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
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
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
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
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
>
>> 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
>
>> 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
>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
Richard Proctor proposed:
>
> All of these should work:
>
> print print << EOL;
> EOL
> print
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) ) {...}
?
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
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
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 /^[^
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
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,
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
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
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
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
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
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
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
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
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
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
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
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} = ();
>
>
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
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
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
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
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
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
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
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
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
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
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
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;
}
>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
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
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
55 matches
Mail list logo
