Re: scalar subscripting
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
Re: scalar subscripting
Larry Wall [EMAIL PROTECTED] writes:
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.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: scalar subscripting
Larry Wall wrote:
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 Csay 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
Re: scalar subscripting
Larry Wall [EMAIL PROTECTED] 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 ?
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//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: scalar subscripting
On Sun, Jul 11, 2004 at 11:06:30PM -0400, Jonadab the Unsightly One wrote:
: Larry Wall [EMAIL PROTECTED] 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
Re: scalar subscripting
On Wed, Jul 14, 2004 at 10:23:18AM -0700, Larry Wall wrote:
: 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
Re: scalar subscripting
Larry Wall wrote:
On Wed, Jul 14, 2004 at 10:23:18AM -0700, Larry Wall wrote:
: 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.
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
cutpaste) 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
Re: scalar subscripting
On Fri, Jul 09, 2004 at 05:02:48PM +0100, Jonathan Worthington wrote:
Are there plans in Perl 6 for string modifiers?
Not exactly. But method calls can be interpolated into strings, so most
As they are in bash eg.:
${var%glob_or_regexp}
${var%%glob_or_regexp}
my $newfile = $str.subst(rx|\.\w+$|, '')\.bin;
But what about the value of $str after interpolation?
In shall it stays it's original value! I would often need,
to use a little modified value of $str for a particular expression.
I like the way shell does it, to be able to write it such short,
without any other explicit variable.
Best regards
Hans
--
Why PHP? See man HTML::Embperl from libhtml-embperl-perl.deb!
http://perl.apache.org/embperl/
Re: scalar subscripting
my $newfile = $str.subst(rx|\.\w+$|, '')\.bin; But what about the value of $str after interpolation? In shall it stays it's original value! I would often need, to use a little modified value of $str for a particular expression. I like the way shell does it, to be able to write it such short, without any other explicit variable. Yeah, the fact that substitutions were only destructive in Perl 5 was a major kludge. I was taking the .subst method there as a functional, non modifying version. So: $str.subst(...) # returns substituted string, leaves $str alone $str.=subst(...) # modifies $str Luke
Re: scalar subscripting
Luke Palmer [EMAIL PROTECTED] writes:
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.
Re: scalar subscripting
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:?
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
Re: scalar subscripting
[EMAIL PROTECTED] (Juerd) writes:
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
Re: scalar subscripting
Simon Cozens skribis 2004-07-12 12:58 (+0100):
[EMAIL PROTECTED] (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
Re: scalar subscripting
--- Juerd [EMAIL PROTECTED] wrote:
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
Re: scalar subscripting
Luke Palmer [EMAIL PROTECTED] wrote:
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|.*/|, '')
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
${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
Re: scalar subscripting
On Fri, Jul 09, 2004 at 05:02:48PM +0100, Jonathan Worthington wrote: : 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
scalar subscripting
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
Re: scalar subscripting
Gautam Gopalakrishnan skribis 2004-07-08 21:12 (+1000): 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
Re: scalar subscripting
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. 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
Re: scalar subscripting
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? 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
Re: scalar subscripting
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|.*/|, '')
${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
