scalar subscripting
Gautam Gopalakrishnan
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
Juerd
> 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
$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
Luke Palmer
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
Hans Ginzel
> 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
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
Luke Palmer
> On Thu, Jul 08, 2004 at 09:12:16PM +1000, Gautam Gopalakrishnan wrote:
> > 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
>
> Are there plans in Perl 6 for string modifiers?
Not exactly. But method calls can be interpolated into strings, so most
of this is pretty straightforward:
> As they are in bash eg.:
> ${var%glob_or_regexp}
> ${var%%glob_or_regexp}
my $newfile = "$str.subst(rx|\.\w+$|, '')\.bin";
> ${var#glob_or_regexp}
> ${var##glob_or_regexp}
say "Basename is $str.subst(rx|.*/|, '')"
> ${var/pattern/string}
say "$str.subst(rx|foo|, 'bar')"
> ${var:[+-=]word}
# ${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
Jonathan Worthington
> Hans Ginzel writes:
> > On Thu, Jul 08, 2004 at 09:12:16PM +1000, Gautam Gopalakrishnan wrote:
> > > 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
> >
> > Are there plans in Perl 6 for string modifiers?
>
> Not exactly. But method calls can be interpolated into strings, so most
> of this is pretty straightforward:
>
> > As they are in bash eg.:
> > ${var%glob_or_regexp}
> > ${var%%glob_or_regexp}
>
> my $newfile = "$str.subst(rx|\.\w+$|, '')\.bin";
>
> > ${var#glob_or_regexp}
> > ${var##glob_or_regexp}
>
> say "Basename is $str.subst(rx|.*/|, '')"
>
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
Larry Wall
: 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
Piers Cawley
> Gautam Gopalakrishnan writes:
>> 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.
>
> 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.
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.
Juerd
> method postcircumfix:[] is rw { ... }
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
Simon Cozens
> Could methods like "[]" and "{}" *default* to "postcircumfix:"?
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
Juerd
> ju...@convolution.nl (Juerd) writes:
> > Could methods like "[]" and "{}" *default* to "postcircumfix:"?
> A more interesting question is "does it mean anything for them *not* to be
> postcircumfix"?
Not as a method, I think.
> After all, the only other use would be "$foo.[]($bar, $baz)", which is
> practically identical.
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.
> Unless you want to make [$foo] the default, and I suspect that would
> be unwise.
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
Austin Hastings
> Piers Cawley skribis 2004-07-12 12:20 (+0100):
> > method postcircumfix:[] is rw { ... }
>
> 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:"?
Do we want Larry to spend even a picosecond thinking about how to
reduce the number of characters required to declare something like
this?
> Array-/Hash-like access is very natural for many objects and I think
> deserves simplified syntax.
>
> method [] ($index) { .item $index }
>
> method {} ($key) { .arg $key }
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.
> (And I'm assuming <<>> will be a method of Object that uses
> self.postcircumfix:{}.)
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
Jonadab The Unsightly One
> 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" ?
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 $ ?
> 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.)
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$/
Austin Hastings
> 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...)
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
Larry Wall
: 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
Larry Wall
: 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
Dan Hursh
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
James Mastros
> 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.
>
> 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/.
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
Jonadab The Unsightly One
> 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.
Now that you put it that way, $( $file ).ext doesn't seem so bad, the
visually-distracting double $ notwithstanding.
Hans Ginzel
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