Larry Wall wrote:
On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote:
: Thus:
:
: eval read :file("foo");
:
: There you have it.
The problem being that it will now report errors in some random
temporary string rather than at some line number in a file. Not good.
Orthogonality strike
Larry Wall wrote:
On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote:
: Thus:
:
: eval read :file("foo");
:
: There you have it.
The problem being that it will now report errors in some random
temporary string rather than at some line number in a file. Not good.
Orthogonality strike
John Macdonald wrote:
On Thu, Mar 17, 2005 at 09:18:45PM -0800, Larry Wall wrote:
On Thu, Mar 17, 2005 at 06:11:09PM -0500, Aaron Sherman wrote:
: Chop removes the last character from a string. Is that no longer useful,
: or has chomp simply replaced its most common usage?
I expect chop still ha
On Fri, 18 Mar 2005 11:27:56 +0100, Juerd <[EMAIL PROTECTED]> wrote:
> Larry Wall skribis 2005-03-17 21:06 (-0800):
> > oct and hex are arguably misnamed, since most functions are named by
> > what they produce, not by what they take as input. I don't know what
> > the replacement should be, thoug
On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
: What it doesn't solve is the $.method vs .method issue. They look similar
: but one works on the invocant and one works on $_. Still a trap.
Yes, and that's probably the killer of the "oc" idea. So much for
Sleep Brain, heh, h
On Fri, Mar 18, 2005 at 09:24:43AM -0800, Larry Wall wrote:
> [...] And if
> chomp is chomping and returning the terminator as determined by the
> line input layer, then chimp would have to return the actual line and
> leave just the terminator. :-)
With the mnemonic "Don't monkey around with my
On Fri, Mar 18, 2005 at 12:00:32PM -0500, John Macdonald wrote:
: Generally when I do this I am not only deleting the character
: from the string, but also moving it to another scaler to use;
: so substr isn't a simple replacement because you'd have to
: use it twice.
Well, not lately. There's
On Fri, Mar 18, 2005 at 08:21:07AM -0500, John Siracusa wrote:
: On 3/18/05 12:18 AM, Larry Wall wrote:
: > Autochomping is one of the motivations for switching from "while" to
: > "for" for the normal line input method, since "while" might think a
: > blank line is false, while "for" only cares wh
On Fri, Mar 18, 2005 at 05:01:50AM -0600, Rod Adams wrote:
: I'll try to come up with something decent, if no one beats me to it.
: Sadly, the C style hex2int, oct2int might be the least confusing, but
: heinously ugly.
Yes, though there are two difficulties right there in the names:
hardwiring
On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote:
: Thus:
:
: eval read :file("foo");
:
: There you have it.
The problem being that it will now report errors in some random
temporary string rather than at some line number in a file. Not good.
Orthogonality strikes again.
Lar
> eval read :file("foo")
How about:
eval slurp "foo";
Paul Seamons
> Right. I believe the times one will want to do a method call on $_ when it
> is *not* the invocant will be greatly outnumbered by the times when you
> want to do a method call on the invocant. Thus adding ambiguity to .method
> is not worth it.
I think this boils it all down nicely. It seems
On Thu, Mar 17, 2005 at 09:18:45PM -0800, Larry Wall wrote:
> On Thu, Mar 17, 2005 at 06:11:09PM -0500, Aaron Sherman wrote:
> : Chop removes the last character from a string. Is that no longer useful,
> : or has chomp simply replaced its most common usage?
>
> I expect chop still has its uses.
I
On Fri, 2005-03-18 at 10:28, Aaron Sherman wrote:
> On Fri, 2005-03-18 at 05:42, Rod Adams wrote:
>
> > Hmm. maybe we just need a function that loads an entire file and returns
> > a string of it, then feeds that to eval.
>
> Well, I wasn't getting into the IO stuff, but since you said it, this
On Fri, 2005-03-18 at 05:42, Rod Adams wrote:
> Hmm. maybe we just need a function that loads an entire file and returns
> a string of it, then feeds that to eval.
Well, I wasn't getting into the IO stuff, but since you said it, this
crosses a line with many related IO operations. I would call t
On 3/18/05 12:18 AM, Larry Wall wrote:
> Autochomping is one of the motivations for switching from "while" to
> "for" for the normal line input method, since "while" might think a
> blank line is false, while "for" only cares whether the next value
> is defined.
Speaking of which (ha), does that m
> "MD" == Matt Diephouse <[EMAIL PROTECTED]> writes:
MD> Uri Guttman <[EMAIL PROTECTED]> wrote:
>> > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> oct and hex are arguably misnamed, since most functions are named by
LW> what they produce, not by what they take as input. I don
Juerd wrote:
+"0x$_" # hex
+"0o$_" # oct
+"0b$_" # bin (does not exist in Perl 5)
This does require that strings numify the same way literals do, but I
think that's a sane approach anyhow. Now that leading 0 no longer means
the number is octal, I can't think of a good reason to keep the contrast
Larry Wall wrote:
On Thu, Mar 17, 2005 at 10:31:07PM -0600, Rod Adams wrote:
: Aaron Sherman wrote:
: >>Methods on numeric values (should be defined as pseudo-methods on
: >>unboxed numbers):
: >>
: >> chr
: >> hex
: >>oct
: >>
: >>
: >
: >Sigh... well, now I know what Ctrl-Return do
Brent 'Dax' Royal-Gordon wrote:
Larry Wall <[EMAIL PROTECTED]> wrote:
: C I'll tackle at the same time as C. It's likely
: staying in some form. I use it from time to time when I'm patching
: together several automation scripts. (Remember that Perl gets used for
: the quick and dirty as well as
Michael G Schwern skribis 2005-03-17 14:42 (-0800):
> Because $_ can change.
> method bar ($_:) {
> .foo;
> map { .baz } 1..10; # whoops
> }
The problem here is not specific to methods.
It is generic to all nested uses $_. We used to see this mostly with
n
Larry Wall skribis 2005-03-17 21:06 (-0800):
> oct and hex are arguably misnamed, since most functions are named by
> what they produce, not by what they take as input. I don't know what
> the replacement should be, though. Maybe it's not worth fixing.
+"0x$_" # hex
+"0o$_" # oct
+"0b$_" # bi
hi, all
is there any way to import constants from other modules without
specifying scope everytime?
such like this:
module A;
use constant { PI => 3.14, VER => 1.1 }
...
module B;
my $var = A::PI; # this way is fine when A is 'short' or rare
imagination
module C;
use constant tag {
Err, wait, I don't think we are discussing whether $_ is to be outlawed
in map {}. I think the proposal is for .method always mean $invocant.method
and make it illegal when there is no invocants in sight, mush as $.attr
would be illegal without an invocant. To use $_.foo, write $_.foo.
Luke is dis
[ Sorry if my replies to this thread have seemed a little disjoint. I just
realized I'd unsubscribed myself from p6l last year when I started a $job$
and never resubscribed. So I'd only been seeing fragments of the
conversation. Catching up from the archives...
]
Larry's idea of making $
This drifed off list but I don't think that was intentional.
- Forwarded message from Yuval Kogman <[EMAIL PROTECTED]> -
From: Yuval Kogman <[EMAIL PROTECTED]>
Date: Fri, 18 Mar 2005 01:12:42 +0200
To: Michael G Schwern <[EMAIL PROTECTED]>
Subject: Re: .method == $self.method or $_.method
On Thu, Mar 17, 2005 at 11:46:52PM +0200, Yuval Kogman wrote:
> I think this should mean $_, and if the user really really really
> wants to do .foo on the invocant, then why not just say:
>
> method bar ($_:) {
> .foo;
> }
Because $_ can change.
method bar ($_:) {
I was just informed by IRC that 'return' propagates the context of the caller.
If that's the case, then we can just drop this discussion, problems solved.
Sorry for wasting your time.
-- Darren Duncan
At 12:07 AM -0800 3/18/05, Darren Duncan wrote:
I suppose, generally ignore most of my last commen
I suppose, generally ignore most of my last comments as they seem to
be ill-informed.
There's just one thing I need to know that will make everything clear:
Does 'return' always impose a scalar context on its arguments? Has
this been decided for sure, or is it still under debate?
If it does, t
On Fri, 18 Mar 2005 00:20:57 -0500, Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> LW> oct and hex are arguably misnamed, since most functions are named by
> LW> what they produce, not by what they take as input. I don't know what
> LW> the
30 matches
Mail list logo
