Aaron Sherman wrote:
See below for the S06 section I'm referring to.
I'm wondering how we should be reading the description of user-defined
operators. For example, "sub infix:<(c)>" doesn't describe
the precedence level of this new op, so how is it parsed? Is there a
default?
The default is
See below for the S06 section I'm referring to.
I'm wondering how we should be reading the description of user-defined
operators. For example, "sub infix:<(c)>" doesn't describe
the precedence level of this new op, so how is it parsed? Is there a
default?
Right now, this doesn't work as I'd expec
On Wed, Jun 30, 2010 at 4:29 AM, Richard Hainsworth wrote:
It is normally implied that a program already has a 'local' environment,
> including a 'local' filesystem. Thus the syntax
> my $fn = open('/path/to/directory/filename', :r) or die $!;
> implies a local file sytem.
>
> The idea of an impli
On Wed, Jun 30, 2010 at 10:29 AM, Richard Hainsworth
wrote:
> Would it make sense to define $*FS as the implied local file system, and
> thus that a bare 'open' is sugar for
> my $fh = $*FS.open('/path/to/directory/filename', :r);
>
> This then means that there is an implicit
> $*FS.connect();
> t
Sounds like a sound generalization to make.
On Wed, Jun 30, 2010 at 1:29 AM, Richard Hainsworth
wrote:
> This then means that there is an implicit
> $*FS.connect();
> that makes the local system available to the program.
"mount" is the jargon to make a filesystem available, looking
backwards, t
If I might offer a late viewpoint after reading the Aaron's expanded
email (attached below).
When originally I suggested using 'open' instead of 'connect', the aim
was to keep consistency with the paradigm of files on the local system.
However, as Aaron's post suggests, when dealing with remo
