On Fri, Aug 20, 2004 at 10:49:17AM -0600, Luke Palmer wrote:
: 
:     method postcircumfix:<> ($self: *%opt) returns List { 
:         scalar $self.<*%opt>, $self.<*%opt>  # [1]
:     }
: 
: [1] Look, Larry, I had to use C<scalar>!  Maybe we _do_ need to revive
: $()!

It's not clear to me that $() would have made this more readable...

I think if we ever come up with a single-character unary scalar
operator, it should be something other than '$'.  I just don't like
the look of '$($', nor the fact that the inner $ is doing something
quite different from the outside one.

Maybe we could resurrect the '_' operator to mean scalar() at the
symbolic unary precedence level.  Underline looks sufficiently
different from $.  Your example would then be:

    method postcircumfix:<> ($self: *%opt) returns List { 
        _$self.<*%opt>, $self.<*%opt>  # [1]
    }

Then I suppose binary _ would be defined as:

    $a _ $b

is the same as

    _($a, $b)

which is the same as

    [$a, $b]

Not clear what $a _ $b _ $c would mean though...

Hmm.  There's another possibility.  We just got through explaining how
the => binary operator imposes scalar on its right side.  There's no
corresponding unary operator.  So we could make one:

    method postcircumfix:<> ($self: *%opt) returns List { 
        =>$self.<*%opt>, $self.<*%opt>  # [1]
    }

then the definition of binary => is already obvious.  On the other
hand, unary =>$x probably ought to mean $_ => $x or some such (where
"some such" includes "nothing at all").  And I'd prefer to keep all
the symbolic unaries single chars.  So I lean towards _.

But something is tickling the back of my mind as a different proposed
meaning for bare _ as a token, and I can't remember what.  Placeholders
for anonymous unification, a la Prolog, maybe.  Whatever it is, it
could probably coexist with _ as a unary, much like we're thinking
of making unary * coexist with a splat slice in a multidimensional
subscript.

Since _ would primarily be used as a unary, it wouldn't suffer as
much from ambiguity as when it was proposed for string concat, where
$a_$b would be a syntax error.  It would be a problem for functions
calls, however:

    push @x, _ myfunc();

But really, that's no more characters than:

    push @x, =>myfunc();

I don't see any other single-character candidates.  It's probably
time to do an exhaustive check again.  First of all, none of the
alphabetic ones are any better than underscore, except possibly
for mnemonic value.  Unfortunately, the only obvious one, 's', is
taken.  That leaves punctuation.  Here's what my keyboard offers
in ASCII:

    say `myfunc();      # taken
    say ~myfunc();      # taken
    say !myfunc();      # taken
    say @myfunc();      # taken
    say #myfunc();      # taken
    say $myfunc();      # taken
    say %myfunc();      # taken
    say ^myfunc();      # possible, but easily confused with +^
    say &myfunc();      # taken
    say *myfunc();      # taken
    say (myfunc();      # taken
    say )myfunc();      # pragmatically impossible (breaks bracket matching)
    say -myfunc();      # taken
    say _myfunc();      # indentifer character in C culture
    say +myfunc();      # taken
    say =myfunc();      # visually and semantically confusing
    say [myfunc();      # taken
    say ]myfunc();      # pragmatically impossible (breaks bracket matching)
    say {myfunc();      # taken (and then taken some more)
    say }myfunc();      # pragmatically impossible (breaks bracket matching)
    say \myfunc();      # taken
    say |myfunc();      # visually and semantically confusing
    say ;myfunc();      # too important as expression stopper: loop ;; {...}
    say :myfunc();      # taken
    say 'myfunc();      # taken
    say "myfunc();      # taken
    say ,myfunc();      # visually and semantically confusing
    say <myfunc();      # taken, probably
    say .myfunc();      # taken
    say >myfunc();      # visually and semantically confusing
    say /myfunc();      # taken
    say ?myfunc();      # taken

If we're willing to take the Latin-1 hit, then we also have these
punctuational possibilities:

        ¡       00A1            INVERTED EXCLAMATION MARK
        ¢       00A2            CENT SIGN
        £       00A3            POUND SIGN
        ¤       00A4            CURRENCY SIGN
        ¥       00A5            YEN SIGN
        ¦       00A6            BROKEN BAR
        §       00A7            SECTION SIGN
        ¨       00A8            DIAERESIS
        ©       00A9            COPYRIGHT SIGN
        ª       00AA            FEMININE ORDINAL INDICATOR
        «       00AB            LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
        ¬       00AC            NOT SIGN
        ­       00AD            SOFT HYPHEN
        ®       00AE            REGISTERED SIGN
        ¯       00AF            MACRON
        °       00B0            DEGREE SIGN
        ±       00B1            PLUS-MINUS SIGN
        ²       00B2            SUPERSCRIPT TWO
        ³       00B3            SUPERSCRIPT THREE
        ´       00B4            ACUTE ACCENT
        µ       00B5            MICRO SIGN
        ¶       00B6            PILCROW SIGN
        ·       00B7            MIDDLE DOT
        ¸       00B8            CEDILLA
        ¹       00B9            SUPERSCRIPT ONE
        º       00BA            MASCULINE ORDINAL INDICATOR
        »       00BB            RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
        ¼       00BC            VULGAR FRACTION ONE QUARTER
        ½       00BD            VULGAR FRACTION ONE HALF
        ¾       00BE            VULGAR FRACTION THREE QUARTERS
        ¿       00BF            INVERTED QUESTION MARK
        ×       00D7            MULTIPLICATION SIGN
        ÷       00F7            DIVISION SIGN

Of those, only

    say ¢myfunc();
    say §myfunc();

strike me as both sufficiently mnemonic and sufficiently visible.  Of
the two I think I prefer the section sign.

But overall I think I still prefer _ to anything else.  For the moment...

Larry

Reply via email to