Hello,

I've tried the archives and the 'Perl 6 essentials' book and I can't
find anything
about string subscripting. Since $a[0] cannot be mistaken for array subscripting
anymore, could this now be used to peep into scalars? Looks easier than using
substr or unpack. Hope I've not missed anything obvious.

Cheers
Gautam

Gautam Gopalakrishnan skribis 2004-07-08 21:12 (+1000):

$a[0] is $a.[0]. That means that if there is a @$a, it still is array
subscripting.

Accessing strings as if they are arrays was discussed recently. Please
read the archives. (groups.google.com is my favourite interface)

Juerd

Well, no, it can't really.  $a[0] now means what Perl 5 called $a->[0]
(or @$a[0]).  So it's still an array subscript, it's just subscripting
$a, not @a.

But there's talk about using the various character type methods to
return lists of characters.  So if you want the first byte of your
string, you can say:

    $str.bytes[0];

And if you want the first codepoint:

    $str.codepoints[0];

Etc.

Luke

   Are there plans in Perl 6 for string modifiers? As they are in bash
eg.:
        ${var%glob_or_regexp}
        ${var%%glob_or_regexp}
        ${var#glob_or_regexp}
        ${var##glob_or_regexp}
        ${var/pattern/string}
        ${var:[+-=]word}

    Best regards

                                        Hans Ginzel

Not exactly.  But method calls can be interpolated into strings, so most
of this is pretty straightforward:

        my $newfile = "$str.subst(rx|\.\w+$|, '')\.bin";

        say "Basename is $str.subst(rx|.*/|, '')"

        say "$str.subst(rx|foo|, 'bar')"

        # ${var:-word}
        say "You chose $($value // 'no value')";

        # ${var:=word}
        say "You chose $($value //= 'no value')";

        # ${var:?word}
        say "You chose $($value // die 'please choose a value')"

Luke

Would that not be:-

    say "Basename is $(str.subst(rx|.*/|, ''))"

I thought when you were interpolating method calls you had to put brackets
$(object.meth), so that you could still write things like:-

$fh = open "$id.txt";  # OK, maybe my open syntax isn't right

Or is it that you can do:-

say "$object.meth()";

But not:-

say "$object.meth";

And the later (...) distinguish that we are doing a method call?

Or am I completely wrong?  :-)

Thanks,

Jonathan

: Would that not be:-
:
:     say "Basename is $(str.subst(rx|.*/|, ''))"
:
: I thought when you were interpolating method calls you had to put brackets
: $(object.meth), so that you could still write things like:-
:
: $fh = open "$id.txt";  # OK, maybe my open syntax isn't right
:
: Or is it that you can do:-
:
: say "$object.meth()";
:
: But not:-
:
: say "$object.meth";
:
: And the later (...) distinguish that we are doing a method call?
:
: Or am I completely wrong?  :-)

No, just currently wrong. :-)  I changed my mind about it in A12,
partly on the assumption that $object.attr would actually be more
common than $file.ext, but also because a bogus method call is likely
to be noticed sooner than bad output data, and because noticing
goofs sooner rather than later is often construed to be a good thing.
(Though this attitude can be taken to extremes--see static typing.)

Larry

So, it should be possible to define

  method postcircumfix:[] is rw { ... }

in the String class to do the right thing? Or even to define it in some
Sequence trait that both arrays and strings share? Of course, the
putative method would have to take into account the calling context's
Unicode behaviour, but I can't see why it shouldn't be possible.

Piers Cawley skribis 2004-07-12 12:20 (+0100):

Compared to Ruby, this is very verbose.

    def [] (key)
        ...
    end

    # Okay, not entirely fair, as the Ruby version would also
    # need []= defined for the rw part.

Could methods like "[]" and "{}" *default* to "postcircumfix:"?
Array-/Hash-like access is very natural for many objects and I think
deserves simplified syntax.

    method [] ($index) { .item $index }

    method {} ($key) { .arg $key }

(And I'm assuming <<>> will be a method of Object that uses
self.postcircumfix:{}.)

Perhaps by making this popular, we can get rid of AUTOLOAD junkies ;)

Juerd

A more interesting question is "does it mean anything for them *not* to be
postcircumfix"?

After all, the only other use would be "$foo.[]($bar, $baz)", which is
practically identical. Unless you want to make [$foo] the default, and I
suspect that would be unwise.

--
Also note that i knew  _far_ more about the people that call address
mungers names like 'lusers', 'egoists' or try to make luser giraffes.
        -- Megahal (trained on asr), 1998-11-06

Simon Cozens skribis 2004-07-12 12:58 (+0100):

Not as a method, I think.

Unless I am mistaken, $foo.[]($bar, $baz) is a syntax error and to call
interpunction-methods explicitly (verbosely), the full names need to be
used: $foo.postcircumfix:[]($bar), and all other methods need to have
^<letter>\w*$ names.

Hm, circumfix operators as methods? Interesting idea, but what would
that do with [ $foo, $bar ], where $foo and $bar have a very different
circumfix:[] operator?

Juerd

Do we want Larry to spend even a picosecond thinking about how to
reduce the number of characters required to declare something like
this?

I thought operators were generally considered global multisubs, simply
because it makes life interesting when you're dereferencing $a[1, 2]
otherwise.

(Not that it matters, other than increasing the number of places that
MMD has to search for candidates.)

Regardless, I don't agree that the huffman coding of postcircumfix:[]
needs to be reduced to that of "[]". You could write a pcf:[] macro, if
you wanted to.

It seems intuitive that redefining one access would redefine the
other(s), but I want the override mechanism to be the same. I think
requiring a method definition for one notation and a multisub for the
other notation would be a mistake. So long as they are both overridden
as methods or both as subs, it's cool.

=Austin

Speaking of which, what's the cleanest way to interpolate filenames
with a fixed extension now?  "${file}.ext" ?  "$file\.ext" ?

Also, I guess that if "$foo.bar" is taken as a method call, then
"$file.$ext" is going to be trouble also, is that right?  An error?
Or will it treat the value of $ext as the name of a method, or maybe
look for a method starting with $ ?

Quite.  Perl6 is last I checked moving in the direction of giving a
more informative error message later, rather than a syntax error
sooner, which IMO is a good thing.  Not that this is a case of that,
but it demonstrates that noticing sooner isn't necessarily always the
best way to go.  (Static typing is certainly an annoying limitation,
and I'm sure there are other examples.)

However, while it's a shame not to be able to interpolate "$file.ext",
I can certainly see the argument for "$object.method" being a common
case, one that I imagine I'll use quite often.

Of course, this leaves open the question of whether there are any
fairly common filename extensions that happen to be spelled the same
as a method on Perl6's string class, that might ought to have a
warning generated...   Are there any three-letter methods on the
string class?  (Maybe there shouldn't be, in the core language...)

--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/

--- Jonadab the Unsightly One <jona...@bright.net> wrote:

Well, there was talk about the shortest-possible-name for, among
others, the codepoints and language-dependent-entities of strings.

We pretty well know that .c is a risk, and if language-dependent gets
spelled "per language", .pl might also be one. :-(

=Austin

On Sun, Jul 11, 2004 at 11:06:30PM -0400, Jonadab the Unsightly One wrote:
: Larry Wall <la...@wall.org> writes:
:
: > No, just currently wrong. :-) I changed my mind about it in A12,
: > partly on the assumption that $object.attr would actually be more
: > common than $file.ext,
:
: Speaking of which, what's the cleanest way to interpolate filenames
: with a fixed extension now?  "${file}.ext" ?  "$file\.ext" ?

Cleanliness is a relative concept, but I'd tend to go with the
backslash in this case.

Another alternative is "$( $file ).ext".  I'd tend to use that before
"${file}.ext" these days.  Perhaps that's irrational--but it was hard
to get the special-case "${name}" form to work right in the Perl 5
lexer, and that bugs me.  If we're going to get rid of the autoquoting
of $hash{shift}, we likely ought to undo the autoquoting of ${shift}
as well, even if that gives heartburn to a certain number of shell
programmers.

: Also, I guess that if "$foo.bar" is taken as a method call, then
: "$file.$ext" is going to be trouble also, is that right?  An error?
: Or will it treat the value of $ext as the name of a method, or maybe
: look for a method starting with $ ?

It will use the value of $ext as the name of the method.  Alternately,
we could simply disallow indirect method names inside interpolations.
They're very rare, and you could always say $( $file.$ext ) in that case.

: > but also because a bogus method call is likely to be noticed sooner
: > than bad output data, and because noticing goofs sooner rather than
: > later is often construed to be a good thing.  (Though this attitude
: > can be taken to extremes--see static typing.)
:
: Quite.  Perl6 is last I checked moving in the direction of giving a
: more informative error message later, rather than a syntax error
: sooner, which IMO is a good thing.  Not that this is a case of that,
: but it demonstrates that noticing sooner isn't necessarily always the
: best way to go.  (Static typing is certainly an annoying limitation,
: and I'm sure there are other examples.)

One error message that would be of great benefit to novices is if we
could guess where the missing brace is based on indentation.  (But not
*assuming* the missing brace, of course--this isn't Python...  :-)

: However, while it's a shame not to be able to interpolate "$file.ext",
: I can certainly see the argument for "$object.method" being a common
: case, one that I imagine I'll use quite often.

It's also a philosophical issue of making trying to make $object.method
look and behave exactly like a variable.  This carries through to several
other design decisions, such as allowing "temp $object.method".

: Of course, this leaves open the question of whether there are any
: fairly common filename extensions that happen to be spelled the same
: as a method on Perl6's string class, that might ought to have a
: warning generated...   Are there any three-letter methods on the
: string class?  (Maybe there shouldn't be, in the core language...)

Yes.  We might also need to be careful about doing failover from
$foo.bar(1) to bar($foo,1).  Otherwise any multimethod that allows a
string as the first argument could also be confused with an extension.

I suppose another approach is simply to declare that dot is always a
metacharacter in double quotes, and you have to use \. for a literal
dot, just as in regexen.  That approach would let us interpolate
things like .foo without a variable on the left.  That could cause
a great deal of cultural confusion in the short term, however.

On the other hand, that raises the issue of what this should match:

    /$foo.bar/

and if we let people interpolate .bar into strings, then what will they
expect this to do:

    /.bar/

Ouch.  I'm thinking we allow $foo.bar in both strings and regexen, but
not .bar in either case.  Gotta use $_.bar inside strings and regexen.
(Or $(.bar) would work too.)  Possibly we even complain about /.bar/
and force them to write /. bar/.

Likewise, /$foo.$bar/ should probably also be forcibly disambiguated
to either /$( $foo.$bar )/ or /$foo . $bar/.

Larry

: Another alternative is "$( $file ).ext".  I'd tend to use that before
: "${file}.ext" these days.  Perhaps that's irrational--but it was hard
: to get the special-case "${name}" form to work right in the Perl 5
: lexer, and that bugs me.  If we're going to get rid of the autoquoting
: of $hash{shift}, we likely ought to undo the autoquoting of ${shift}
: as well, even if that gives heartburn to a certain number of shell
: programmers.

And if we do that, I guess that means that "$«file».ext" could
be made to work as a replacement, which seems conceptually clean if
you don't think about it too hard.

Larry

Maybe I'm missing something here, but this looks just plain cruel.  Is
it easier to parse ...um... that?  It's that same debate that's been
here before, but a lot of us can't type it yet.  I probably could, but I
don't know the incantation for mozilla on windows.  If I did, it bet it
wouldn't be the same as as the raindance for notepad.  If it is the
same, then it probably isn't the same as the incantation in vi or emacs
on linux or aix.

I use "...${var}..." a lot, and unfortunately, I have to use a number of
different programs and oses.  Unfortunately, typing '«' & '»' (thank you
cut&paste) is not as portable on the keyboard as say '{' & '}' (or '&'
for that matter).

Is ${var} really that rare in real world perl?  Are we going to try to
have ascii equivalents like '<<' & '>>' in quoted strings?  (Please no.)
  Do I need to put a unicode keyboard next to the APL keyboard on my
wishlist?

Dan

Please, think of C<say "This is a sentence.  This is another
sentence.";>.  Dots with whitespace or end-of-string after them should
just be literal dots in qq strings.  Dots should always be literals in
q() strings, of course.  And dots are /already/ metacharacters in
regex^Wrules; forcing a space after the dot isn't giving the power of
formatting to the user; it's forcing formatting upon them that they
don't want.  (I don't remember if there's an adverb to treat spaces as
literals, but if not, there should be.)

I think method calls in strings should be "Foo's bar is $($foo.bar).",
plain and simple.  Dot is too useful here already.  @{[...]} needed to
be replaced with something easier to type, and with clearer (and
cleaner) semantics.  We did that; $(...) is far better.  Not requiring a
set off for method calls is Huffman coding the wrong direction, unless
you can find one that won't disturb useful things that you'd want in
double-quotes -- which includes patterns common in any natural language,
which includes even the literal versions of << / >> (which I can't type
easily at the moment).

        -=- James Mastros

Now that you put it that way, $( $file ).ext doesn't seem so bad, the
visually-distracting double $ notwithstanding.

--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/

        Hello,

   I wish to be consistent with shall, so `.' is literal dot in double
strings. I prefer "$file.ext" or "${file}.ext".

   For method calls ``$()'' could be used: "$($foo.bar)".

   Perhaps, what does "${foo.bar}" mean?

        Best regards
                                        Hans