On Oct-05, Luke Palmer wrote:
Steve Fink writes:
Ok, I'm back to argument passing. I'm starting a new thread because
I'm lazy and I have to scroll back too far in my mailer to see the old
arg passing thread. :-) And yes, most of this message should also be
on -languages.
Which it now
On Sep-21, Gerrit P. Haase wrote:
Hallo again,
http://cpan.perl.org/authors/id/S/SF/SFINK/parrot-0.0.11.1.tar.gz
And all we need now is a 0.0.11.2, with patches to allow four-element
version numbers...
[...]
Ouch, better take this:
$ diff -urd parrot-0.0.11.1/VERSION~
At long last, Parrot-0.0.11 Doubloon has been released!
This release features direct generation of executable binaries,
dramatically improved documentation, and a built-in bread maker! Get
it while it's hot at
http://www.cpan.org/authors/id/S/SF/SFINK/parrot-0.0.11.tar.gz, or
join the party by
On Sep-20, Steve Fink wrote:
At long last, Parrot-0.0.11 Doubloon has been released!
And so has Parrot-0.0.11.1, for those of you who want correct native
bytecode tests!
http://cpan.perl.org/authors/id/S/SF/SFINK/parrot-0.0.11.1.tar.gz
Hmm... for symmetry, I'm now thinking I ought to have
The Parrot team is proud to announce the release of Parrot version
0.0.10, code named Juice (based on the new -Oj optimization flag).
It is downloadable from
http://www.cpan.org/authors/id/S/SF/SFINK/parrot-0.0.10.tar.gz. If
you would like to check the latest copy out from CVS, see the
The Parrot team is proud to announce the release of Parrot version
0.0.9, code named Nazgul. It is downloadable from
http://www.cpan.org/authors/id/S/SF/SFINK/parrot-0.0.9.tar.gz. If
you would like to check the latest copy out from CVS, see the
instructions at http://dev.perl.org/cvs/.
Try it out
On Sun, Sep 22, 2002 at 01:39:29PM -0500, Me wrote:
So, how about something like:
: # lock in current atom, ie as now
:] # lock in surrounding group, currently ::
: # lock in surrounding rule, currently :::
:/ # lock in top level rule,
On Mon, Sep 16, 2002 at 10:32:17AM +0300, Markus Laire wrote:
On 15 Sep 2002 at 22:41, Steve Fink wrote:
Your code seems to backtrack to the beginning at every failure. First
code only backtracks one char at time.
Huh? What implementation is that? I think my naive implementation
gives
On Wed, Sep 18, 2002 at 05:01:35PM +0200, Damian Conway wrote:
Steve Fink wrote:
What possible outputs are legal for this:
aaa =~ /( a { print 1 } | a { print 2 })* { print \n } x/
Unless Larry specifies a required semantics, there are potentially very
many acceptable outputs from
On Wed, Aug 28, 2002 at 12:55:44PM -0400, Deven T. Corzine wrote:
On Wed, 28 Aug 2002, Dan Sugalski wrote:
At 10:57 AM -0400 8/28/02, Deven T. Corzine wrote:
On the other hand, :, ::, ::: and commit don't necessarily need to be a
problem if they can be treated as hints that can be
Wow. Since you went to the trouble of writing all this up, it really
ought to go in a FAQ somewhere.
On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote:
Finite state machines can match regular expressions whose only operations
are closure (*), alternation (|), and grouping. Some of
On Fri, Aug 09, 2002 at 09:50:00PM -0400, Mark J. Reed wrote:
On Fri, Aug 09, 2002 at 05:23:58PM -0700, Steve Fink wrote:
On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote:
Finite state machines can match regular expressions whose only operations
are closure (*), alternation
On Tue, Apr 16, 2002 at 02:00:33PM -0400, Mike Lambert wrote:
Speaking of which, how do we ensure the immutability of keys being put
into the hash? I think Perl copied the string, so that:
RFC266 talks about these issues, though it was just really my take on
the problem at the time.
On Thu, Feb 07, 2002 at 06:13:47AM -0800, Ask Bjoern Hansen wrote:
Hi,
I am tired of people thinking that we are not getting anywhere at
all, so if (some|any|every)one can send me a reasonably updated text
for the Where are we section at http://www.parrotcode.org/ and
likewise for
On Sun, Jan 27, 2002 at 10:43:08PM -, Rafael Garcia-Suarez wrote:
Melvin Smith wrote in perl6-language:
Besides no one has commented on Steve Fink's (I think it was him) idea
to store the result of the most recently executed conditional in $?. I
kinda like that idea myself. It makes
On Fri, Jan 25, 2002 at 11:31:13PM -0500, Melvin Smith wrote:
At 11:40 AM 1/25/2002 -0600, Jonathan Scott Duff wrote:
On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote:
On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote:
What we're cleaning up is the ickiness of having
On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote:
In most other languages, you wouldn't even have the opportunity to put
a declaration into the conditional. You'd have to say something like:
my $line = $in;
if $line ne { ... }
Since
if my $line = $in { ... }
[EMAIL PROTECTED] wrote:
On Sat, Jul 21, 2001 at 02:47:43PM -0700, Dave Storrs wrote:
I discovered today that I had forgotten to put 'use strict' at the top of
one of my modules...it was in the script that _used_ the module, but not
in the module itself. Putting it in instantly caught
On my wishlist is forbidding the use of # just about anywhere but as a
comment starter and in strings or regular expressions. Not a big deal,
but it would make it easier to write 90% correct perl syntax parsers.
It's a pain dealing with q#not a comment# and m#still not# and
s(even)#this#.
Michael G Schwern wrote:
On Mon, Jul 09, 2001 at 08:54:49PM -0700, Steve Fink wrote:
my Num $x = 3.0;
$x++;
my Int $y = $x;
Could be compile-time, if you do constant folding first.
Alot of how much checking we can do at compile-time depends on how
long we have to compile, and thus
[EMAIL PROTECTED] wrote:
Here's me thinking out loud. I'm thinking about how to avoid alot of
explicit type casting without entering a maze of twisty typecasing
rules, all different.
Imagine we have a typing system where types are allowed to
automatically cast AS LONG AS NO INFORMATION
Most of the time, perl's performance is a total non-issue for me. When
it is, I'm generally doing the same things as Dan (ie, things resembling
dd if=/dev/hda | perl -e ...). I posted some vague benchmarky ideas to
perl6-meta at one point. Here they are again:
-
You did ask at one point for
Eric Roode wrote:
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 issu
Michael Fowler wrote:
Ok, at this point I'm trying to clear up misunderstandings. I believe you
know where I stand with relation to your RFC.
Thanks, you caught several of my mistakes.
On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
Michael Fowler wrote:
Except
Dave Storrs wrote:
On Wed, 20 Sep 2000, Eric Roode wrote:
foo();
print $x;
Generate a warning, or not? Which one? Remember, foo() may initialize $x.
My suggest (FWIW) would be that, if there is no execution path
which leads to $x being defined in the second line,
Eric Roode wrote:
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:
Yes.
my $x;
if
Tom Christiansen wrote:
The warning for the use of an unassigned variable should be "use of
uninitialized variable C$x".
The problem with that idea, now as before, is that this check happens
where Perl is looking at a value, not a variable. Even were it possible
to arduously modify Perl
Eric Roode wrote:
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
Michael Fowler wrote:
On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
"VARIABLE used only once: possible typo" should be replaced with
warnings on uses of uninitialized variables (including lexicals).
$x = 3
I don't understand, who's to say you didn't misspell
Tom Christiansen wrote:
And what about $$x?
Dang, are we back to this incredible confusion about what it is to be
defined in Perl.?
undef $a;
That is now UNINITIALIZED. So is this:
$a = undef;
You have initialized it to undef. There is no reasonable difference.
Michael Fowler wrote:
On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
complains, but
$x = 3; $x = 3
As it shouldn't; you've mentioned $x twice, which means you probably didn't
misspell it. That your mentioning twice in this manner is silly is beyond
perl's
Tom Christiansen wrote:
It happens when I don't bother to declare something. My company has
several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
a pain. As is $My::Package::Name::x.
Far, far easier to fix behavioral problems than to hack Perl.
--tom
Not sure what
Tom Christiansen wrote:
Anything else? Any opinion on whether eval "" should do what it does
now, and be invisible for the purposes of this analysis; or if it should
be assumed to instead both use and initialize all visible variables? The
former produces more spurious warnings, the latter
Michael Fowler wrote:
On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
$foobal = 3;
if (@ARGV) {
$foobar = @ARGV;
}
print $foobar;
Only warn me that $foobar is uninitialized? I always prefer it when the
actual source of my problem
Tom Christiansen wrote:
Tom Christiansen wrote:
It happens when I don't bother to declare something. My company has
several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
a pain. As is $My::Package::Name::x.
Far, far easier to fix behavioral problems than to hack
Tom Christiansen wrote:
Tom Christiansen wrote:
Anything else? Any opinion on whether eval "" should do what it does
now, and be invisible for the purposes of this analysis; or if it should
be assumed to instead both use and initialize all visible variables? The
former produces more
This reminds me of a related but rather opposite desire I have had
more than once: a quotish context that would be otherwise like q() but
with some minimal extra typing I could mark a scalar or an array to be
expanded as in qq().
I have wanted that also, although I don't remember why
Jarkko Hietaniemi wrote:
Allow me to repeat: instead of trying to shoehorn (or piledrive) new
semantics onto existing keywords/syntax, let's create something new.
The blocks of grep/map/... are special. They are not quite looping
blocks, they are not quite sub blocks, they are different.
Mark-Jason Dominus wrote:
Maybe I should also mention that last week I had a dream in which I
had a brilliant idea for adding strong compile-time type checking to
Perl, but when I woke up I realized it wasn't going to work.
What do you see as the major obstructions?
eval "" isn't too bad,
Nathan Wiger wrote:
Foo::Bar-stickysnort()
Right, knew I forgot something...
I wonder whether the "I want to expand arbitrary expressions within
strings even when there aren't any $ or @ symbols about" people
just need better familiarity with the alternatives.
This was all
for reality here. That should be written more like:
1 while FH; $burp = $.;
or even:
for ($burp = 0; my $line = FH; $burp++) {}
I'd go for
my $burp = 0; $burp++ while FH;
This proposal should be dropped.
I read your message and agree. Not that I liked the
Can't quite run perl yet.
http://www.tomshardware.com/cpu/00q3/000901/index.html
[redirected to perl6-language]
Tom Christiansen wrote:
Note the difference between
my $var = func();
and
my($var) = func();
Those are completely different in that they call func() in scalar
and list contexts. Why? Because of hte presence or absence of (),
of course.
Tom Christiansen wrote:
I happen to strongly appreciate that the invocant in
$a-blah
can be of either sort; that is:
$a = "MyClass";
$a-blah;
or
$a = MyClass-generate();
$a-blah();
In fact, who knows what generate() returned? It could have
been a class
(Off-topic for this list, but I'm not sure where else to send it)
Could we have a discussion somewhere of useful filtering rules for all
these perl6 lists? Specifically, I'm looking to steal other people's
.procmailrc snippets. I imagine that a lot of people have written their
own, and
(thread intentionally broken)
Nathan Torkington wrote:
Steve Fink writes:
True. Would anyone mourn @$scalar_containing_variable_name if it died?
I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
notice $x="var"; print @$x either -- it'll complain if you me
Thanks! Ok, from a type inferencing perspective...
Nathan Torkington wrote:
Symbolic references are used for dynamic function generation:
foreach my $func (qw(red green blue)) {
*$func = sub { "FONT COLOR=$func@_/FONT" }
}
Probably have to punt on checking user code in a main
Damien Neil wrote:
On Thu, Aug 17, 2000 at 03:10:44PM -0700, Steve Fink wrote:
My proposal would be what I implemented for perl5 a while back (Sarathy
didn't dislike it, but wasn't convinced enough to put it in): all
dereferencing can be done with -.
$x-@ is the same as @$x
$x
Nathan Torkington wrote:
Steve Fink writes:
We are NOT here to construct a radically better language. We are here to
design the underpinnings of one.
Perhaps. And by "perhaps", I mean "no".
We're here to say what we'd like to see in the next version of Perl.
The
"Casey R. Tweten" wrote:
This looks counter intuitive, my brain says to dereference the reference at the
begining, just like you make the reference, in other words, keep it all the
same:
$hashref-{key}-@ # Deref
$hashref-{key}-$ # Deref
$hashref-{key}-% # Deref
$hashref-{key}-* # Deref
Damian Conway wrote:
It was simply attempting to explain why I choose to ignore what are (to
me, at least) trivial implementation issues, well documented in the
compiler literature. I choose to ignore them because I *have* to ignore
them or my brain is going to melt.
So perhaps you should
Jeremy Howard wrote:
Steve Fink writes:
And both those examples apply to the underpinnings. Ok, maybe I have an
unusually broad definition of the word "underpinnings". Think "anything
that can't be done with a pure perl module".
Say "anything that c
Ted Ashton wrote:
Thus it was written in the epistle of Russ Allbery,
This falls firmly in the category of things that are powerful for
experienced users of the language but may be somewhat difficult to learn.
I don't think Perl has being easy to learn as it's primary goal, nor
On Thu, Aug 17, 2000 at 01:07:30PM -0400, Stephen P. Potter wrote:
* Replace Cm//, Ctr///, and Cs/// with equivalent regularized
functions that take mulitple arguments instead of using specialized
syntax. It would be best if the names could be more "complete", like
match(),
Ted Ashton wrote:
But the most direct way to measure how well the
language slides into people's heads is by seeing how hard it is for them
to get the hang of it.
Nope. I've yet to be convinced that "fits in your head" is the same as
"went in easily". Hang it all,
Karl Glazebrook wrote:
Ariel Scolnicov wrote:
Karl Glazebrook [EMAIL PROTECTED] writes:
[...]
o Why do I think perl has too much line noise? Because of code like this:
@{$x-{$$fred{Blah}}}[1..3]
This is indeed horrible. However, I fail to see how cutting out the
Nathan Wiger wrote:
We're getting deluged with RFC's and emails. We should start thinking
"will this RFC or idea *add value* to Perl 6?". If not, and it just
makes something work differently, it _might_ not be worth an RFC.
I disagree completely. For one thing, there's no such thing as
Decklin Foster wrote:
[replying from here since this is the only way I received it]
"Myers, Dirk" wrote:
$line/pattern/ ;
/pattern/ ($line) ;
I don't think these should be changed. Here's how I tend to pronouce
things:
$x = 'foo'; # "x gets foo"
Russ Allbery wrote:
All variables should be C$x. They should behave appropriately
according to their object types and methods.
No thanks. I frequently use variables $foo, @foo, and %foo at the same
time when they contain the same information in different formats. For
example:
What about updating RFCs? Should I increment the version number and send
each new revision to perl-rfc? Do I need to be careful about the RFC
number when submitting updates?
Also, I assumed the intention of the RFCs was to stimulate focused
discussion and to keep a record of the decisions made
Hey, this RFC stuff is fun!
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink [EMAIL PROTECTED] for now
Date: 2 Aug 2000
Version: 0 (unreleased)
Mailing List: [EMAIL PROTECTED]
Number: (unassigned)
=head1 ABSTRACT
"VARIABLE used only once: possible
Tom Christiansen wrote:
The warning message "use of uninitialized value" should also
disappear, to be replaced with "use of undefined value", and the
warning for the purpose described in this RFC should be "use of
uninitialized variable C$x".
What about if there's only an expr, not a
Updated RFC.
---
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink [EMAIL PROTECTED] for now
Date: 2 Aug 2000
Version: 0.2 (unreleased)
Mailing List: [EMAIL PROTECTED]
Number: (unassigned)
=head1 ABSTRACT
"VARIABLE used only
Tom Christiansen wrote:
"symbol $main::x used only once" - "use of uninitialized variable
$main::x"
"use of uninitialized value" - "use of undefined value"
Perhaps then
"use of uninitialized value" - "use of undef as discrete value"
or
"use of uninitialized value" - "discrete
"Randal L. Schwartz" wrote:
"Martyn" == Martyn Pearce [EMAIL PROTECTED] writes:
Martyn Possibly, although I must ask: since everything is up-for-grabs, I ask
Martyn (without implying any feeling one-way-or-tother):
Martyn How useful is the , operator in it's C-style statement separator,
65 matches
Mail list logo
