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
Sounds like a sound generalization to make.
bikeshedding
On Wed, Jun 30, 2010 at 1:29 AM, Richard Hainsworth
rich...@rusrating.ru 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
On Wed, Jun 30, 2010 at 10:29 AM, Richard Hainsworth
rich...@rusrating.ru 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
On Wed, Jun 30, 2010 at 4:29 AM, Richard Hainsworth rich...@rusrating.ruwrote:
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
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 expect
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
