On Thu, 21 Apr 2005, Larry Wall wrote:
: perl -lne 'print if -e :q'
It seems to me that -e «$_» would handle most of these cases, as long as
whitespace always comes in quoted so that you always end up with one word.
I would say this is hardly the case for the kind of file lists I was
referring
On Fri, Apr 22, 2005 at 09:24:51AM +0200, Michele Dondi wrote:
: Speaking of which, I like to think of (some) adverbs in terms of cmd line
: switches, and maybe it's just me, but I think it would be extremely useful
: to have a full set of tricky ones providing reasonable defaults
:
Larry Wall skribis 2005-04-21 15:50 (-0700):
There's one minor problem with -r -w $file, which is that it evaluates
right-to-left, which is going to surprise some people who think they
want to say
-e -r $file
when they really mean
-r -e $file
It doesn't have to, of course. The test
Hi,
I am making a presentation about Perl6 this week end. My point will
be: the next generation of applicative languages will be scripting
languages because they have come of age.
Alternatives don't cut it anymore. Indeed C and C++ are memory
allocation nightmare; Java and C# don't have
On Fri, 2005-04-22 at 07:46, Juerd wrote:
Can we together compile a list of accepted abbreviations, so they can be
consistently applied?
Are you suggesting that these are accepted by the compiler or by us (for
discussion)?
Some may be source of discussion, in which case I think it's better to
Aaron Sherman skribis 2005-04-22 10:00 (-0400):
On Fri, 2005-04-22 at 07:46, Juerd wrote:
Can we together compile a list of accepted abbreviations, so they can be
consistently applied?
Are you suggesting that these are accepted by the compiler or by us (for
discussion)?
By us. Mostly for
Juerd skribis 2005-04-22 16:11 (+0200):
Those are for identifiers, so we don't end up with one function using :r
and another using :read. That'd be inconsistent.
Although readline should not be made rline, and I still think both :r
and :read should work!
Bool +$read is shortr
or
On Fri, 22 Apr 2005 14:24:25 -0400, Juerd [EMAIL PROTECTED] wrote:
Because a URI scheme ends in :. It http: followed by anything other than
// should fail because it is invalid, not fall back to file handling.
IFF you're handling URIs.
multi sub open ($u of Str where /^mailto:\/\//, [EMAIL
On Fri, 22 Apr 2005 21:31:03 -0400, Larry Wall [EMAIL PROTECTED] wrote:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
That almost makes sense, given that $^a is like $_. It also points
vaguely
upward toward some antecedent. I could maybe get used
Anyway, is there any other URI scheme besides for mailto: that doesn't use
://?
It¹s optional for news:; news:comp.lang.perl is a valid URI for accessing that
Usenet newsgroup via whatever your default news server is.
There aren¹t any slashes in the aim: scheme (not part of the IANA
On Fri, Apr 22, 2005 at 09:09:21PM +0200, Juerd wrote:
: Matt skribis 2005-04-22 14:44 (-0400):
: We're talking about the *built-in* functions here, right?
:
: I don't know.
:
: Anyway, is there any other URI scheme besides for mailto: that doesn't use
: ://?
:
: I don't know, but if you
On Fri, Apr 22, 2005 at 08:13:58PM +0200, Stéphane Payrard wrote:
On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:
Thank you for your detailled answer. I still don't get what you mean
by [] pattern matching arguments.
Do you mean smart pattern matching on composite values?
On Fri, 22 Apr 2005 15:09:21 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt skribis 2005-04-22 14:44 (-0400):
mailto isn't something you can open really, for read at least.
No, but writing to it ought to simplify things :)
given open 'mailto:[EMAIL PROTECTED]' {
.say(q0:to.
Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). I wish there were more keys on my keyboard...
I know it's a bit counter-cultural, but at the moment I'm wondering
if we can make this work instead:
given open 'mailto:[EMAIL
On Fri, Apr 22, 2005 at 11:28:06AM +0200, Juerd wrote:
: Which brings me to the following: can open please use the same kind of
: $file, so that open $filehandle just checks $filehandle's mode and
: returns $filehandle again? That way, every library function that accepts
: a filename automatically
On Fri, 22 Apr 2005 11:42:10 -0400, Larry Wall [EMAIL PROTECTED] wrote:
You speak of open as if it must be a single function. We're now
living in the age of MMD, so what you're asking for is a no-brainer.
If we decided to we could even do MMD with constraints:
multi sub open ($u of Str where
Matt skribis 2005-04-22 14:20 (-0400):
Well why can't you define the functions like so:
Because a URI scheme ends in :. It http: followed by anything other than
// should fail because it is invalid, not fall back to file handling.
IFF you're handling URIs.
multi sub open ($u of Str where
Matt skribis 2005-04-22 14:44 (-0400):
We're talking about the *built-in* functions here, right?
I don't know.
Anyway, is there any other URI scheme besides for mailto: that doesn't use
://?
I don't know, but if you want to find this out,
http://www.iana.org/assignments/uri-schemes is
Larry Wall skribis 2005-04-22 8:42 (-0700):
multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns
Handle {...}
Though that would potentially be problematic if you wanted to open
a file whose name started with http:
open ./http://...;;
open file://$CWD/http://...;;
On Fri, Apr 22, 2005 at 05:53:48PM +0200, Juerd wrote:
: I kinda like the IO::All module, except for how it overloads and .
: my $page == io(http://www.wall.org/~larry;);
:
: IO used in this way denies that there's non-stream-based IO too.
How so? Where's the xor?
: Waiting for a
Larry Wall skribis 2005-04-22 9:47 (-0700):
: my $page == io(http://www.wall.org/~larry;);
: IO used in this way denies that there's non-stream-based IO too.
How so? Where's the xor?
Good point.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
21 matches
Mail list logo
