FAQ
Hi,

Somehow the current file test syntax, 'filename' ~~ :e, looks like a not
well-though-out translation of Perl 5's syntax, -e 'filename'.

Apart from totally feeling wrong to me, there are a few points I can put
my finger on:

1) $file ~~ :s returns a number, although smartmatching usually returns
a Bool
2) As currently designed, $str ~~ :e will always be True. That's because
'$x ~~ $y' where $y is Pair is defined as $x."$y.key()" ~~ $y.value. :e
is short for :e(Bool::True), and smart-matching against True is always
True. D'oh. There might be a way to fix that, but that fact that nobody
noticed that so far only strengthens my opinion that this is not very
well thought-out so far.
3) I haven't look too closely at the list of proposed Perl 6 file test
operators, but Perl 5 has 29 of them. The idea of having 29 single
letter methods in class Str doesn't make me all that happy.

So I collected other ideas, both in my brain and in #perl6. Some of them
are:

$str.f.exists # Str.f returns an "interpret this object
$str.f.size # as a file name" object

$str.File.e # same, different names

$str.stat.exists # again

stat($str, :e) # let multi dispatch handle it for us

So, let the bikeshedding begin!

Cheers,
Moritz

Search Discussions

  • Aristotle Pagaltzis at Jul 10, 2009 at 12:50 am

    * Moritz Lenz [2009-07-10 00:25]:
    stat($str, :e) # let multi dispatch handle it for us
    This gets my vote.

    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Mark J. Reed at Jul 10, 2009 at 1:12 am
    A few months ago (or maybe more) I proposed making pathnames their own
    type, distinct from (or perhas a subclass of) strings, but easily
    constructed from strings, maybe with an operator. Having those 29
    single-letter methods on such a class would not bug me as much as
    having them on Str.
    On 7/9/09, Aristotle Pagaltzis wrote:
    * Moritz Lenz [2009-07-10 00:25]:
    stat($str, :e) # let multi dispatch handle it for us
    This gets my vote.

    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
    --
    Sent from my mobile device

    Mark J. Reed <markjreed@gmail.com>
  • Darren Duncan at Jul 10, 2009 at 1:33 am

    Mark J. Reed wrote:
    A few months ago (or maybe more) I proposed making pathnames their own
    type, distinct from (or perhas a subclass of) strings, but easily
    constructed from strings, maybe with an operator. Having those 29
    single-letter methods on such a class would not bug me as much as
    having them on Str.
    On 7/9/09, Aristotle Pagaltzis wrote:
    * Moritz Lenz [2009-07-10 00:25]:
    stat($str, :e) # let multi dispatch handle it for us
    This gets my vote.
    I agree. The built-ins of basic types like Str or Int etc need to stay pure and
    just be about dealing with local data. Having methods on basic types for going
    out into the wider environment like the file system is just plain wrong. There
    should be separate IO classes for things like stat, which *use* basic types like
    Str for their interface definitions, and the full definition of Str/etc should
    not include any file-system operations.

    If you go ahead and put stat ops in Str anyway, then you might as well put
    things like a delete_from(Hash $arg) method on Object, which is a less
    objectionable version of such backwardness.

    -- Darren Duncan
  • Buddha Buck at Jul 10, 2009 at 2:50 am
    Resent to list as I intended to in the first place....

    On Thu, Jul 9, 2009 at 9:32 PM, Darren Duncanwrote:
    Mark J. Reed wrote:
    A few months ago (or maybe more) I proposed making pathnames their own
    type, distinct from (or perhas a subclass of) strings, but easily
    constructed from strings, maybe with an operator.  Having those 29
    single-letter methods on such a class would not bug me as much as
    having them on Str.
    On 7/9/09, Aristotle Pagaltzis wrote:

    * Moritz Lenz [2009-07-10 00:25]:
    stat($str, :e)          # let multi dispatch handle it for us
    This gets my vote.
    I agree.  The built-ins of basic types like Str or Int etc need to stay pure
    and just be about dealing with local data.  Having methods on basic types
    for going out into the wider environment like the file system is just plain
    wrong.  There should be separate IO classes for things like stat, which
    *use* basic types like Str for their interface definitions, and the full
    definition of Str/etc should not include any file-system operations.
    It's unclear which you are agreeing with.  By reference, it sounds
    like you agree with the idea of a separate pathname type, but by
    context, it sounds like you are agreeing with stat($str, :e)

    Both the separate pathname type and the stat($str, :e) proposal
    salvage the purity of Str, so either would be acceptable to your
    argument.

    I have seen other language APIs have a pathname class, usually called
    FilePath or Path or similar.  Generally, I like the idea because it
    allows one to abstract away from the specific form of a filename (be
    it the /home/blaisepascal/.emacs/emacsrc of Unix, the C:\Documents and
    Settings\Users\Blaisepascal\Local Settings\GNUEmacs\emacs.rc of
    Windows, the BootDisk:Users:BlaisePascal:Settings:GNUEmacs:emacsrc of
    MacOS 9, or the DKA0:[USERS.BLAISEPASCAL.SETTINGS.GNUEMACS]EMACS.RC;1
    of VMS) to the basic components (devices, directories, and files).

    Most of the FilePath APIs I've seen allow virtual traversal of the
    path (e.g., given a FIlePath corresponding to
    /home/blaisepascal/.emacs, you can ask it for the directory portion to
    get /home/blaisepascal, or ask it to specify another layer, to get
    /home/blaisepascal/.emacs/22.18), conversion of relative paths to
    absolute paths, and perhaps even conversion of one path representation
    (like Unix-style paths) to another (like HFS-style paths).

    The annoying bit I've found with some APIs is that some of them force
    you to use a FilePath as an argument to File.Open(), and don't always
    provide an easy way to get from a string to a FilePath, forcing you to
    do things like File.Open(FilePath.CurrentWorkingDirectory.AddFileName("myFile"))
    to open ./myFile.

    I support the idea of a separate pathname type, and I trust the Perl6
    developers to make it robust but easy to use.
    If you go ahead and put stat ops in Str anyway, then you might as well put
    things like a delete_from(Hash $arg) method on Object, which is a less
    objectionable version of such backwardness.

    -- Darren Duncan
  • Darren Duncan at Jul 10, 2009 at 3:03 am

    Buddha Buck wrote:
    On Thu, Jul 9, 2009 at 9:32 PM, Darren Duncanwrote:
    Mark J. Reed wrote:
    A few months ago (or maybe more) I proposed making pathnames their own
    type, distinct from (or perhas a subclass of) strings, but easily
    constructed from strings, maybe with an operator. Having those 29
    single-letter methods on such a class would not bug me as much as
    having them on Str.
    On 7/9/09, Aristotle Pagaltzis wrote:
    * Moritz Lenz [2009-07-10 00:25]:
    stat($str, :e) # let multi dispatch handle it for us
    This gets my vote.
    I agree. The built-ins of basic types like Str or Int etc need to stay pure
    and just be about dealing with local data. Having methods on basic types
    for going out into the wider environment like the file system is just plain
    wrong. There should be separate IO classes for things like stat, which
    *use* basic types like Str for their interface definitions, and the full
    definition of Str/etc should not include any file-system operations.
    It's unclear which you are agreeing with. By reference, it sounds
    like you agree with the idea of a separate pathname type, but by
    context, it sounds like you are agreeing with stat($str, :e)

    Both the separate pathname type and the stat($str, :e) proposal
    salvage the purity of Str, so either would be acceptable to your
    argument.
    I don't see an ambiguity.

    I am saying that the Str class should not have filesystem methods.

    Routines like stat() should either be methods of a quasi-singleton FileSystem
    class, or they should be subroutines in a non-OO FileSystem module.

    Either way, a file name can still be represented by a Str.

    Now I'm not against a distinct Filename type, in fact I'm sure its a good idea,
    but I do think that users shouldn't have to use one explicitly if they don't
    want to. Eg, "FileSystem.stat($str, :e)" should just DWIM.

    But my main point is still that stat() etc should not be methods of Str.

    -- Darren Duncan
  • Daniel Ruoso at Jul 10, 2009 at 7:01 pm

    Em Qui, 2009-07-09 às 22:50 -0400, Buddha Buck escreveu:
    Both the separate pathname type and the stat($str, :e) proposal
    salvage the purity of Str, so either would be acceptable to your
    argument.
    The bigger problem of using a different type is that

    "/etc/passwd" ~~ :e

    Would dispatch to Str, which means that you'd need to

    PathName("/etc/passwd") ~~ :e

    which doesn't seem much interesting huffman-wise.

    On the other hand, a multi would allow more clear semantics, and
    wouldn't require an explicit typecast, as in:

    stat "/etc/passwd", :e

    This still allow the existance of the most specific PathName type, and a
    signature like

    multi stat(PathName $name, *%switches) { ... }

    where...

    role PathName {
    multi method ACCEPTS(Str $path where { .defined }) {
    $path ~~ /<PathName::token>/
    }
    multi method ACCEPTS(Str $path where { not .defined }) {
    1;
    }
    }

    daniel
  • Timothy S. Nelson at Jul 10, 2009 at 4:44 am

    On Thu, 9 Jul 2009, Mark J. Reed wrote:

    A few months ago (or maybe more) I proposed making pathnames their own
    type, distinct from (or perhas a subclass of) strings, but easily
    constructed from strings, maybe with an operator. Having those 29
    single-letter methods on such a class would not bug me as much as
    having them on Str.
    See S32/IO document for a rough outline I did of this some time ago.
    Feel free to hack away at it. Note that the documentation is spread across
    - IO::FSNode
    - IO::FileNode (does IO::FSNode)
    - IO::DirectoryNode (does IO::FSNode)
    - IO::LinkNode (does IO::FSNode)

    There's also an IO::FSNodeACL class for handling permissions, but
    that's only if you actually *want* to use these; the Unix ones are still there
    too.

    I got part way through speccing this, and then was told that my idea
    for Tree-related classes couldn't be part of the core, and so I'd have to
    monkey-patch them on afterwards; at that point, I went back to working on
    Tree, and left the Filesystem stuff alone.

    (Tree-related classes could be a role composed into both filesystem
    node classes, and Match thingies returned by grammars, but alas,
    monkey-patching will be necessary :) ).

    :)


    ---------------------------------------------------------------------
    Name: Tim Nelson | Because the Creator is, |
    E-mail: wayland@wayland.id.au | I am |
    ---------------------------------------------------------------------

    ----BEGIN GEEK CODE BLOCK----
    Version 3.12
    GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
    PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
    -----END GEEK CODE BLOCK-----
  • Jonathan Scott Duff at Jul 10, 2009 at 2:40 am

    On Thu, Jul 9, 2009 at 7:50 PM, Aristotle Pagaltzis wrote:

    * Moritz Lenz [2009-07-10 00:25]:
    stat($str, :e) # let multi dispatch handle it for us
    This gets my vote.

    Me too.

    -Scott
    --
    Jonathan Scott Duff
    perlpilot@gmail.com
  • Brandon S. Allbery KF8NH at Jul 10, 2009 at 2:29 am

    On Jul 9, 2009, at 18:22 , Moritz Lenz wrote:
    Somehow the current file test syntax, 'filename' ~~ :e, looks like a
    not
    well-though-out translation of Perl 5's syntax, -e 'filename'.
    That would be because it is; originally the filetests were perl5-
    style, but pugs refused to parse them because you can't combine
    operator and word characters in a single token. (I admit to wondering
    if pugs' parse problems were enough of a reason to change them,
    especially now that pugs is pretty much dead.)

    --
    brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
    system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
    electrical and computer engineering, carnegie mellon university KF8NH
  • Aaron Sherman at Jul 10, 2009 at 9:10 pm

    On Thu, Jul 9, 2009 at 6:22 PM, Moritz Lenz wrote:
    $str.File.e # same, different names

    Brainstorming a bit here....

    Str is a class that describes collections of characters (among some other
    typographical constructs, yadda, yadda, Unicode, yadda).

    There is a commonly used special case, however, where my Str is not just a
    Str. It is, instead, a key for an external datasource. Such cases include:

    * URIs.
    * Pathnames
    * Usernames
    * Variable names
    * etc.

    It makes sense to handle these cases in some regular way, and to provide
    those hooks via Str because it is relatively uniquely Str's job to hold
    these things (counter-examples include UIDs).

    OK, so we have a need for some hookable interface on Str for accessing
    external datasources by key. Let's call it "key".

    $str = "/etc/aliases"
    $str.e; # error, no such method
    $str.key(::File);
    $str.e; # works fine

    There should probably be a few standard methods that are imported in this
    way such as e, s, z and any other test operators that are universal, so that
    this makes sense:

    $user = get_user_name();
    $user.key(::Getpw)
    $user.e; # user exists?

    $url = "http://www.example.com/";
    $url.key(::URI);
    $url.s > 0; # might do a HEAD request and return the size

    The rest might be more domain specific:

    $mailbox = "Trash";
    $mailbox.key(::Mail::IMAP, $account_info);
    $mailbox.msgs > 1000;

    In this way you have not enforced the assumption that all strings are
    pathnames, but rather that all strings might be used as keys.

    I suppose this even makes sense, though it's convoluted:

    $hashkey = "Aaron";
    $hashkey.key(::Hash, %names);
    $hashkey.e

    The real beauty of this is that it can all be implemented without any
    language syntax/grammar changes.
  • Aaron Sherman at Jul 10, 2009 at 11:30 pm
    Sorry, I sent this just to Mark. Wasn't my intention.


    ---------- Forwarded message ----------
    From: Aaron Sherman <ajs@ajs.com>
    Date: Fri, Jul 10, 2009 at 6:58 PM
    Subject: Re: Re-thinking file test operations
    To: "Mark J. Reed" <markjreed@gmail.com>



    On Fri, Jul 10, 2009 at 5:31 PM, Mark J. Reed wrote:

    I'd rather see all those key types be separate classes, maybe
    subclasses of a generic KeyStr class.

    In re-thinking it, we don't need to do either. It's already built in:

    $str does Path;
    if $str.e {
    say("$str exists");
    }

    Nice and simple. All someone has to do is write the appropriate Path that
    knows what to do when it's added to a Str.

    I wonder if this works:

    if ($str but Path).e { ... }


    The question is how to specify them.
    I think stringish classes are common and useful enough to have
    special literal support available without having to customize the
    grammar. Maybe there's a registry of prefixes that can be put in
    front of the opening quote, like p'....' for a pathname, or maybe you
    have to use a q operator with a modifier.

    You've made contradictory statements, there. Either you want to change the
    grammar to add new quoting styles (then the argument ensues: is YOUR key
    type common enough to deserve a quoting semantic?) or you think that you
    shouldn't have to customize the grammar.

    I'm in favor of NOT customizing the grammar, but at the same time, I readily
    admit that strings aren't always strings, and might have much more semantic
    baggage that it would be good to be able to associate with them easily.


    On 7/10/09, Aaron Sherman wrote:
    On Thu, Jul 9, 2009 at 6:22 PM, Moritz Lenz wrote:


    $str.File.e # same, different names

    Brainstorming a bit here....

    Str is a class that describes collections of characters (among some other
    typographical constructs, yadda, yadda, Unicode, yadda).

    There is a commonly used special case, however, where my Str is not just a
    Str. It is, instead, a key for an external datasource. Such cases include:
    * URIs.
    * Pathnames
    * Usernames
    * Variable names
    * etc.

    It makes sense to handle these cases in some regular way, and to provide
    those hooks via Str because it is relatively uniquely Str's job to hold
    these things (counter-examples include UIDs).

    OK, so we have a need for some hookable interface on Str for accessing
    external datasources by key. Let's call it "key".

    $str = "/etc/aliases"
    $str.e; # error, no such method
    $str.key(::File);
    $str.e; # works fine

    There should probably be a few standard methods that are imported in this
    way such as e, s, z and any other test operators that are universal, so that
    this makes sense:

    $user = get_user_name();
    $user.key(::Getpw)
    $user.e; # user exists?

    $url = "http://www.example.com/";
    $url.key(::URI);
    $url.s > 0; # might do a HEAD request and return the size

    The rest might be more domain specific:

    $mailbox = "Trash";
    $mailbox.key(::Mail::IMAP, $account_info);
    $mailbox.msgs > 1000;

    In this way you have not enforced the assumption that all strings are
    pathnames, but rather that all strings might be used as keys.

    I suppose this even makes sense, though it's convoluted:

    $hashkey = "Aaron";
    $hashkey.key(::Hash, %names);
    $hashkey.e

    The real beauty of this is that it can all be implemented without any
    language syntax/grammar changes.
    --
    Sent from my mobile device

    Mark J. Reed <markjreed@gmail.com>
  • Mark J. Reed at Jul 11, 2009 at 12:00 am
    My reply to the message Aaron sent directly to me by mistake...


    ---------- Forwarded message ----------
    From: Mark J. Reed <markjreed@gmail.com>
    Date: Fri, Jul 10, 2009 at 7:23 PM
    Subject: Re: Re-thinking file test operations
    To: Aaron Sherman <ajs@ajs.com>


    You replied just to me, you know.
    In re-thinking it, we don't need to do either. It's already built in:

    $str does Path;
    if $str.e {
    say("$str exists");
    }
    Sure, but I was thinking that particular case might be common enough
    to warrant something with a better Huffman encoding.

    I think stringish classes are common and useful enough to have
    special literal support available without having to customize the
    grammar.  Maybe there's a registry of prefixes that can be put in
    front of the opening quote, like p'....' for a pathname, or maybe you
    have to use a q operator with a modifier.
    You've made contradictory statements, there.
    No, I just wasn't clear.
    Either you want to change the
    grammar to add new quoting styles (then the argument ensues: is YOUR key
    type common enough to deserve a quoting semantic?) or you think that you
    shouldn't have to customize the grammar.
    No, what I was talking about was changing the default grammar, but in
    a general way, so that users who wanted their own literal syntax for
    such things wouldn't have to customize the grammar themselves.  That
    is, I'm arguing for a change in the design to avoid programmers having
    to customize the grammar for this particular case.
    I'm in favor of NOT customizing the grammar, but at the same time, I readily
    admit that strings aren't always strings, and might have much more semantic
    baggage that it would be good to be able to associate with them easily.
    Agreed.
    --
    Mark J. Reed <markjreed@gmail.com>



    --
    Mark J. Reed <markjreed@gmail.com>
  • Paul Hodges at Jul 16, 2009 at 3:43 pm

    --- On Thu, 7/9/09, Moritz Lenz wrote:
    . . .
    Somehow the current file test syntax, 'filename' ~~ :e, looks like a not
    well-though-out translation of Perl 5's syntax, -e 'filename'.
    Apart from totally feeling wrong to me,
    Dunno about totally. I'm still trying to get a P6 mindset, but there's a lot to be said (evidenced by how much has been said) for having an "old-fashioned" and more familiar way to do it.

    I'm underinformed, so I won't waste everyone's time on internals I haven't checked.
    3) I haven't look too closely at the list of proposed Perl 6 file test
    operators, but Perl 5 has 29 of them. The idea of having 29 single
    letter methods in class Str doesn't make me all that happy.
    This doesn't sound ideal, but I don't panic over it. Wrap them in the class and you get some benefits. Personally, I don't mind losing some Huffmen convenience, though; I've seldom used most of them, and even for the ones I use most I don't mind having a more descriptive name that makes me hit a few extra keys. I just want to be able to accomplish whatever it is that I need to do.
    So I collected other ideas, both in my brain and in #perl6.
    Some of them are:

    $str.f.exists # Str.f returns an "interpret this object
    $str.f.size # as a file name" object

    $str.File.e # same, different names
    $str.stat.exists # again

    stat($str, :e) # let multi dispatch handle it for us
    I'd prefer $str.File.exists; I'm not crazy about $str.f.whatever.

    ===============================================================
    Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language @
categoriesperl
postedJul 9, '09 at 10:22p
activeJul 16, '09 at 3:43p
posts14
users11
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase