FAQ
I'm pondering what the proper syntax is for a subroutine parameter with both a
trait and a default. That is...

sub foo ($arg = 42)

and

sub foo ($arg is readonly)

together in one parameter. Would that be

sub foo ($arg = 42 is readonly)

or

sub foo ($arg is readonly = 42)

The first looks ambiguous, what if the trait is meant to apply to the default?
The second looks downright wrong.


PS Incidentally, it seems silly to have "is rw" but not "is ro". I keep
writing "is ro".


--
package Outer::Space; use Test::More tests => 9;

Search Discussions

  • Patrick R. Michaud at Sep 22, 2008 at 1:31 pm

    On Sun, Sep 21, 2008 at 07:02:37PM -0700, Michael G Schwern wrote:
    I'm pondering what the proper syntax is for a subroutine parameter with both a
    trait and a default. That is...
    sub foo ($arg = 42)
    and
    sub foo ($arg is readonly)
    together in one parameter. Would that be
    sub foo ($arg = 42 is readonly)
    or
    sub foo ($arg is readonly = 42)

    The first looks ambiguous, what if the trait is meant to apply to the default?
    The second looks downright wrong.

    The STD.pm grammar [1] shows that the second is the correct form --
    i.e., default values occur after traits. (See "token parameter"
    on or about line 2630.) I think part of the reason for this is that
    traits appearing after the default value would be applied to the
    default value instead of the parameter. A few other examples from
    the synopses seem to confirm this pattern:

    S03:2289: my Dog $fido is trained is vicious = 1
    S03:3828: constant Dog $foo is woof = 123;
    S06:1558: constant $pi is approximated = 3;
    S12:1393: has SomeType $.prop is rw = 1;

    1. http://svn.pugscode.org/pugs/src/perl6/STD.pm
    PS Incidentally, it seems silly to have "is rw" but not "is ro". I keep
    writing "is ro".
    Yes, we've also run into this problem a few times while working on Rakudo.

    Pm
  • TSa at Sep 22, 2008 at 4:08 pm
    HaloO,

    Patrick R. Michaud wrote:
    The STD.pm grammar [1] shows that the second is the correct form --
    i.e., default values occur after traits.
    IIRC, there used to be an 'is default(42)' trait that could
    be placed arbitrarily.

    PS Incidentally, it seems silly to have "is rw" but not "is ro". I keep
    writing "is ro".
    Yes, we've also run into this problem a few times while working on Rakudo.
    Not to mention the fact that 'writeonly' and 'wo' are missing
    completely even though they are required for proper contravariant
    typing of output parameters. Parameters with 'rw' have to be
    *invariant* unless we manage to split the meaning of the type slot
    in 'rw' parameter declarations between input and output.


    Regards, TSa.
    --

    "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
    "Simplicity does not precede complexity, but follows it." -- A.J. Perlis
    1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
  • Michael G Schwern at Sep 22, 2008 at 4:11 pm

    Patrick R. Michaud wrote:
    On Sun, Sep 21, 2008 at 07:02:37PM -0700, Michael G Schwern wrote:
    I'm pondering what the proper syntax is for a subroutine parameter with both a
    trait and a default. That is...
    sub foo ($arg = 42)
    and
    sub foo ($arg is readonly)
    together in one parameter. Would that be
    sub foo ($arg = 42 is readonly)
    or
    sub foo ($arg is readonly = 42)

    The first looks ambiguous, what if the trait is meant to apply to the default?
    The second looks downright wrong.

    The STD.pm grammar [1] shows that the second is the correct form --
    i.e., default values occur after traits. (See "token parameter"
    on or about line 2630.) I think part of the reason for this is that
    traits appearing after the default value would be applied to the
    default value instead of the parameter. A few other examples from
    the synopses seem to confirm this pattern:

    S03:2289: my Dog $fido is trained is vicious = 1
    S03:3828: constant Dog $foo is woof = 123;
    S06:1558: constant $pi is approximated = 3;
    S12:1393: has SomeType $.prop is rw = 1;

    1. http://svn.pugscode.org/pugs/src/perl6/STD.pm
    Ok, thanks. That does make sense.

    PS Incidentally, it seems silly to have "is rw" but not "is ro". I keep
    writing "is ro".
    Yes, we've also run into this problem a few times while working on Rakudo.
    I'm finding it so verbose that I'm going with "is ro" in Method::Signatures.


    --
    I'm pale as formica, social skills stunted small. But I'm accurate
    like a pica, I know the capital of nepal. I'm the nemesis of error,
    dreadful diction fears my skills, more inquisitive than Jim Lehrer,
    snottier than Beverly Hills.
    -- I.L.O.P. Secret Rap http://goats.com/archive/020830.html
  • John M. Dlugosz at Sep 23, 2008 at 7:14 pm

    PS Incidentally, it seems silly to have "is rw" but not "is ro". I keep
    writing "is ro".
    The synopses says "readonly". But now that it is possible, I nominate changing
    a hyphen.

    I'm not opposed to having it be "ro", but wonder why he didn't call it that in
    the first place, so there must be a reason.

    It should be possible to alias it in your own scope easily.

    --John
  • Michael G Schwern at Sep 23, 2008 at 8:32 pm

    John M. Dlugosz wrote:
    I'm not opposed to having it be "ro", but wonder why he didn't call it that
    in the first place, so there must be a reason.
    Nobody's perfect?

    My other thought is that since parameters are read-only by default it's not
    thought you'd have to write it much so clarity wins out over brevity, the flip
    side of Huffamn encoding. But that doesn't work out so good for normal
    variable declarations. The verbosity (which a hyphen would only make worse)
    discourages "const-ing", as they say in C.

    It should be possible to alias it in your own scope easily.
    Every time someone replies to a Perl 6 language design nit with "but you can
    change the grammar" *I* kill a kitten.

    *meowmmmf*


    --
    31. Not allowed to let sock puppets take responsibility for any of my
    actions.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
    http://skippyslist.com/list/
  • David Green at Sep 23, 2008 at 10:02 pm

    On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote:
    My other thought is that since parameters are read-only by default
    it's not
    thought you'd have to write it much so clarity wins out over
    brevity, the flip
    side of Huffamn encoding. But that doesn't work out so good for
    normal
    variable declarations.
    I'd call it straight Huffman encoding, because clarity is what we
    should be optimising for. (You read code more than you write it...
    unless you never make any mistakes!) Happily, brevity often aids
    clarity. The rest of the time, it should be up to one's editor; any
    editor worth its salt ought to easily auto-complete "ro" into
    "readonly".


    -David
  • Michael G Schwern at Sep 23, 2008 at 11:27 pm

    David Green wrote:
    On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote:
    My other thought is that since parameters are read-only by default
    it's not
    thought you'd have to write it much so clarity wins out over brevity,
    the flip
    side of Huffamn encoding. But that doesn't work out so good for normal
    variable declarations.
    I'd call it straight Huffman encoding, because clarity is what we should
    be optimising for. (You read code more than you write it... unless you
    never make any mistakes!) Happily, brevity often aids clarity. The
    rest of the time, it should be up to one's editor; any editor worth its
    salt ought to easily auto-complete "ro" into "readonly".
    Eeep! The "your IDE should write your verbose code for you" argument! For
    that one, I brine and roast an adorable hamster. That's just another way of
    saying that your language is too verbose for a human to write it without
    hanging themselves. See also Java.

    Anyhow, I see where you're going, and I understand the desire for no abbvs.
    But man, "ro" is pretty damn easy to remember. [1] This is even sillier when
    you hold it up against all the magic symbols we're supposed to remember.
    *@foo, :name<value>, |$arg, $arg!, $arg?, :$arg.

    If we expect the user to remember what all that means, I think they can figure
    out "$thing is ro". It would be incoherent to take a corner of the language
    design and suddenly pretend otherwise.

    The mark of a great interface is not that you know what everything is the
    first time you encounter it, but when you remember what it is the second time.
    The first time what's important is the user knows where to find instructions
    and how to play with the device. It should have a strong analogy and mesh
    clearly with the surrounding devices "ro" and "rw" have a strong analogy with
    the common read-only and read-write terms and they mesh with each other. Once
    this is known to the user, the second time it will be "obvious".

    You're only a beginner once, and if everything is done right for a short time.
    The rest of your career, you're experienced. Instead of dumbing the language
    down for beginners, the trick is to turn beginners into experienced
    programmers as quickly and painlessly as possible.

    Now I've totally digressed.</rant>


    --
    s7ank: i want to be one of those guys that types "s/j&jd//.^$ueu*///djsls/sm."
    and it's a perl script that turns dog crap into gold.
  • David Green at Sep 24, 2008 at 9:45 pm

    On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote:
    David Green wrote:
    Happily, brevity often aids clarity. The rest of the time, it
    should be up to one's editor; any editor worth its salt ought to
    easily auto-complete "ro" into "readonly".
    Eeep! The "your IDE should write your verbose code for you"
    argument! For that one, I brine and roast an adorable hamster.
    Fair enough. As long as you remember to share with the rest of us!!
    That's just another way of saying that your language is too verbose
    for a human to write it without hanging themselves. See also Java.
    But the problem with Java isn't just that it's too verbose to write;
    it's that it's too verbose to read, too. Why shouldn't your editor
    help with verbosity? The amount of typing shouldn't be a main concern
    in language design, because your editor can mostly compensate for
    that; there are other, better reasons to decide how verbose something
    should be.
    Anyhow, I see where you're going, and I understand the desire for no
    abbvs. But man, "ro" is pretty damn easy to remember. [1] This is
    even sillier when you hold it up against all the magic symbols we're
    supposed to remember. *@foo, :name<value>, |$arg, $arg!, $arg?, :
    $arg.
    As a bear of limited recall, I sometimes feel a bit overwhelmed by all
    the stuff there is to remember. I'm certainly not against all
    abbreviations. I have a deeply ingrained instinct to name my
    variables x, y, and z, and to name files... x, y, and z. My shell
    profile is full of one-letter aliases (I don't have time to waste
    typing 2-char command names!). However experience has taught me the
    value of more robust names for anything but one-liners.

    I bet we actually don't disagree much; I'm not really against "ro" --
    I'm just not against "readonly" because of its length. If I were
    writing casually, I'd use "rw" and "ro"; formally, I'd use "read only"
    and "read/write" (or even "readable and writable"). At an in-between
    level, which is where I believe we should be aiming, I think I'd put
    "rw" and "read-only". I'm not entirely sure why. Maybe
    psychologically, "ro" looks like it could be a word, whereas the
    unpronounceable "rw" has to be an abbreviation? Or maybe it's just
    because I see "rw" every day in ls output, but "ro" not so much. At
    any rate, if I wanted to argue in favour of "ro", I think symmetry
    (which you already mentioned) is the strongest argument.
    You're only a beginner once, and if everything is done right for a
    short time.
    The rest of your career, you're experienced.
    Ooh, now that I completely agree with! Software that thinks "user-
    friendly" means "dumbed-down" drives me nuts.


    -David
  • Brandon S. Allbery KF8NH at Sep 24, 2008 at 11:16 pm

    On 2008 Sep 24, at 17:45, David Green wrote:
    On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote:
    David Green wrote:
    Happily, brevity often aids clarity. The rest of the time, it
    should be up to one's editor; any editor worth its salt ought to
    easily auto-complete "ro" into "readonly".
    Eeep! The "your IDE should write your verbose code for you"
    argument! For that one, I brine and roast an adorable hamster.
    Fair enough. As long as you remember to share with the rest of us!!
    I would argue that if you need your editor to expand verbose language
    constructs to make the language usable or to express common idioms,
    then the language has a design deficiency.

    --
    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
  • Michael G Schwern at Sep 26, 2008 at 5:38 am

    David Green wrote:
    I bet we actually don't disagree much; I'm not really against "ro" --
    I'm just not against "readonly" because of its length. If I were
    writing casually, I'd use "rw" and "ro"; formally, I'd use "read only"
    and "read/write" (or even "readable and writable"). At an in-between
    level, which is where I believe we should be aiming, I think I'd put
    "rw" and "read-only". I'm not entirely sure why. Maybe
    psychologically, "ro" looks like it could be a word, whereas the
    unpronounceable "rw" has to be an abbreviation? Or maybe it's just
    because I see "rw" every day in ls output, but "ro" not so much. At any
    rate, if I wanted to argue in favour of "ro", I think symmetry (which
    you already mentioned) is the strongest argument.
    Yes indeed, symmetry. It's powerful. Once you see "rw" you're going to
    assume the other is "ro". Same with "readonly" and "readwrite". And
    vice-versa and con-versa and any other versas you can think of.

    rw/readonly is the worst choice. It has that double wammy of bad interfaces:
    rote learning and counter-intuitiveness. Not only do you have to memorize
    that "read-only" is "readonly" and "read/write" is "ro" but you have to
    actively fight your intuition that they should be symmetrical. This generates
    mistakes. Constant mistakes.

    rw/ro makes similar things similar. So does readwrite/readonly. Pick one of
    them. Asymmetry will cause far more problems than too little or too much
    verbosity.
  • John M. Dlugosz at Sep 24, 2008 at 4:40 am

    Michael G Schwern schwern-at-pobox.com |Perl 6| wrote:
    It should be possible to alias it in your own scope easily.
    Every time someone replies to a Perl 6 language design nit with "but you can
    change the grammar" *I* kill a kitten.

    *meowmmmf*

    That would not be a change in the grammar. Merely deciding for yourself
    which names should be short based on your own usage.

    Since readonly is a class name, the equivalent of a typedef would be
    used. I think that should be

    my ::ro ::= readonly;

    but I have some technical points that still need to be addressed/worked out.

    --John
  • John M. Dlugosz at Sep 24, 2008 at 4:45 am

    Michael G Schwern schwern-at-pobox.com |Perl 6| wrote:
    John M. Dlugosz wrote:
    I'm not opposed to having it be "ro", but wonder why he didn't call it that
    in the first place, so there must be a reason.
    Nobody's perfect?

    My other thought is that since parameters are read-only by default it's not
    thought you'd have to write it much so clarity wins out over brevity, the flip
    side of Huffamn encoding. But that doesn't work out so good for normal
    variable declarations. The verbosity (which a hyphen would only make worse)
    discourages "const-ing", as they say in C.
    Perhaps he was thinking that 'constant' would be used there. But I
    agree, it's not the same thing. In C++ I often use const for things
    that are in 'auto' scope and initialized in the normal flow sequence.

    Anyway, was 'ro' rejected for some good reason, $Larry, or was it simply
    considerate as not to waste a short word on a rare use since that's the
    default (for parameters)?

    I agree that knowing 'rw', and that being common, if I wanted the other
    one and didn't use it every day, I would =guess= that it should be
    called 'ro' to match.

    --John

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language @
categoriesperl
postedSep 22, '08 at 2:03a
activeSep 26, '08 at 5:38a
posts13
users6
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase