Re: "=>" brother
Alexey Trofimenko writes:
> >Arguably, the :shiftÂvalue syntax makes it easier to quote both
> >sides of a pair, so perhaps there's a little less need for an
> >autoquoting =>. But I think that generating non-quoted keys for
> >subscripting happens a lot more often than non-quoted keys for pairs,
> >so I'm inclined to leave the autoquoting of => in for now.
> >
> >Larry
>
> strange, but :shiftÂvalue looks a little more noisy to me than shift =>
> 'value',
For some reason, it looks that way to me, too. Perhaps:
:shift value Â
I *think* that's better...
>
> oh.. I have a question.
> in
>
> %hash := { :keyÂvalue :key2Âvalue :key3}
>
> there's no need to put comma between, right?
Right.
> I wonder about mixed synax:
>
> %hash = ( :keyÂvalueÂ
>:key2ÂvalueÂ
>:key3
>key4 => 'value',
>'key5','value',
>Âkey6 value key7 value )
>
> Did I make mistakes here?
I don't think so.
> if all was right, than I can figure that :key Âvalue (with whitespace
> between) is outlawed.. Bad Thing for people who like to write pairs
> in columns.
Well, not necessarily:
:foo bar Â
:ziph zam Â
:split spork Â
Although I'll admit that looks a little strange. Anyway, I suspect I'll
still be writing hashes perl5-style, while I'll use the new style for
named arguments.
> ah.. sorry about messing up all question in one post, but I have one more:)
> if key could be of any type, not only strings, than what will be with
> numeric keys? would they be converted to strings automatically?
It's Perl: what's the difference?
Luke
Re: "=>" brother
On Fri, 9 Jul 2004 18:00:44 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
On Sun, Jun 20, 2004 at 03:41:41AM +0400, Alexey Trofimenko wrote:
: There was some talks about hash keys autoquoting and barewords.. later
are
: gone and former is disambigued by forcing to write %hash{'key'} or
: %hashÂkey ( as opposite to %hash{key} which is now %hash{key()} )..
: right?..
: that's almost ok to me, if there's any hope that  will have a
_standard_
: way to type accross all the editors:) (btw, I also hope I would never
: happen to mantain a perl6 program written by Chineese programmer, who
: thinks that chineese identifiers are cool)..
:
: but now I'm curious what you gonna do with => autoquoting behavior:
:
: shift => 'value' is the same as
: shift() => 'value'or
: 'shift' => 'value'in perl6?
:
: or in this particular case consistancy doesn't matter? ,)
Well, consistency with *what* is the question. The default Perl 6
design rule is that, unless we've said otherwise, Perl 6 is consistent
with Perl 5. So for the moment, => still autoquotes its left side.
only if it does look like an outlawed bareword?.. ah.. 100% perl5 syntax.
I like that:)
Arguably, the :shiftÂvalue syntax makes it easier to quote both
sides of a pair, so perhaps there's a little less need for an
autoquoting =>. But I think that generating non-quoted keys for
subscripting happens a lot more often than non-quoted keys for pairs,
so I'm inclined to leave the autoquoting of => in for now.
Larry
strange, but :shiftÂvalue looks a little more noisy to me than shift =>
'value',
oh.. I have a question.
in
%hash := { :keyÂvalue :key2Âvalue :key3}
there's no need to put comma between, right?
I wonder about mixed synax:
%hash = ( :keyÂvalueÂ
:key2ÂvalueÂ
:key3
key4 => 'value',
'key5','value',
Âkey6 value key7 value )
Did I make mistakes here?
if all was right, than I can figure that :key Âvalue (with whitespace
between) is outlawed..
Bad Thing for people who like to write pairs in columns.
ah.. sorry about messing up all question in one post, but I have one more:)
if key could be of any type, not only strings, than what will be with
numeric keys? would they be converted to strings automatically?
Re: if not C<,> then what?
On Fri, 9 Jul 2004 18:25:40 -0700, Larry Wall <[EMAIL PROTECTED]> wrote: On Sat, Jul 10, 2004 at 05:12:54AM +0400, Alexey Trofimenko wrote: : perl is filled with functions which do different things in different : contexts. It seems that in perl6 with plenty of "new contexts", it will : be even more stimuls for that habit. So real question is: : in expression C< a(),b(),c() >, used in void context, what context is : given to a() and b()? is there any issues which do not allow us to imply : void context instead of list context here? Not that I'm aware of, unless the actual creation of the list in list context has some side effects that wouldn't happen in void context. But maybe functions will be written to treat void context as a funny form of list context, and do the side effects without generating the list. And in a sense, since a list context wants 0 arguments or more, and we'll probably support list contexts that want a specific number of arguments max, void context is just a list context with a max of 0 values wanted. But then maybe it wouldn't be expected to generate all the side effects for the whole list... I'm thinking about cases when generating list is expensive, and function is smart enough to do not bother itself for such an overhead when it not asked to. And also about /.../ which does something totally different when it called in void context. If primary purpose for C<,> in void context is using in statements with modifiers, then it's just a funny C<;> with just a little higher precedence, and any programmer would be expecting the same behavior - void context for all operands.. In any event, I'd say that if we're gonna call a() and b() in void context, we should probably also call c() in void context too, since we're breaking the basic asymmetry of C's comma operator. that was assumed:)
Re: if not C<,> then what?
On Sat, Jul 10, 2004 at 05:12:54AM +0400, Alexey Trofimenko wrote: : perl is filled with functions which do different things in different : contexts. It seems that in perl6 with plenty of "new contexts", it will : be even more stimuls for that habit. So real question is: : in expression C< a(),b(),c() >, used in void context, what context is : given to a() and b()? is there any issues which do not allow us to imply : void context instead of list context here? Not that I'm aware of, unless the actual creation of the list in list context has some side effects that wouldn't happen in void context. But maybe functions will be written to treat void context as a funny form of list context, and do the side effects without generating the list. And in a sense, since a list context wants 0 arguments or more, and we'll probably support list contexts that want a specific number of arguments max, void context is just a list context with a max of 0 values wanted. But then maybe it wouldn't be expected to generate all the side effects for the whole list... In any event, I'd say that if we're gonna call a() and b() in void context, we should probably also call c() in void context too, since we're breaking the basic asymmetry of C's comma operator. Larry
Re: if not C<,> then what?
Except people don't actually read the documentation, and when they
do read it, they don't understand it, and when they do understand it,
they'll write it wrong anyway out of habit. You might as well write
your warning in Russian for all the good it'll do. :-)
So we'll force people who want any loop that exits other than at the
top to use:
loop {
...
last if CONDITION;
...
}
And that means we disallow modifier loops on do-{}.
Makes me wonder if we shouldn't rename do {}...
run { foo; bar } while baz;# uses a valuable identifier
exec { foo; bar } while baz; # assuming we rename exec
execute { foo; bar } while baz;# longer, still stupid
eval { foo; bar } while baz; # we just escaped overloaded eval
{ foo; bar }() while baz; # bare-bones
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: if not C<,> then what?
On Fri, 9 Jul 2004 11:13:29 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
On Fri, Jul 09, 2004 at 10:39:56AM +0200, Michele Dondi wrote:
: On Thu, 1 Jul 2004, Alexey Trofimenko wrote:
:
: > if we really about to lose C-style comma, would we have something new
: > instead?
:
: A late thought, but since I am one of thow whose' keen on the
:
: print,next if /stgh/;
:
: kinda syntax too, and I, for one, will regret not having it anymore, I
: wonder wether something vaguely like the following example could (be
made
: to) work:
:
: print.then{next} if /stgh/;
That's unnecessary--the comma still works perfectly fine for this,
since comma still evaluates its arguments left-to-right. The *only*
difference about comma is what it returns in scalar context. Most uses
of the so-called C-style comma (including this one) are actually in
void context, and in that case whether the return value is a list or
the final value Doesn't Really Matter.
Larry
perl is filled with functions which do different things in different
contexts. It seems that in perl6 with plenty of "new contexts", it will
be even more stimuls for that habit. So real question is:
in expression C< a(),b(),c() >, used in void context, what context is
given to a() and b()? is there any issues which do not allow us to imply
void context instead of list context here?
Re: if not C<,> then what?
On Sat, Jul 10, 2004 at 04:58:49AM +0400, Alexey Trofimenko wrote:
: On Fri, 9 Jul 2004 13:19:46 -0700 (PDT), Austin Hastings
: <[EMAIL PROTECTED]> wrote:
:
: >--- Larry Wall <[EMAIL PROTECTED]> wrote:
: >>If there reasonably can be block modifiers, I will unreasonably
: >>declare that there can't be. You can always say:
: >> do { print; next; } if|when /stgh/;
: >>(It's still the case that do-while is specifically disallowed, however.)
:
: >But I also want do/while to work, solely because repeat/until sucks.
: >What's the big deal there?
: >
:
: hm..
:
: do {...} while ...
:
: sucks much more:) just because it used as loop, but it isn't really a
: loop, so you cannot use C or C.. but IMNSHO to "specifically
: disallow" it is somewhat unnatural, even if it could save from mistakes
: many of us, who will think it works perl5ish way... maybe it just should
: be written with BIG letters in perl6syn:
:
: W A R N I N G ! ! !
: do {...} while ...
:DOES CHECK CONDITION (look here>>) __**BEFORE**__ (< BLOCK. (look here ^^^)
:because C isn't something special anymore. So just use repeat/until
:(or something)
:
: (I correctly guessed true reasons for that, did I? :)
Except people don't actually read the documentation, and when they
do read it, they don't understand it, and when they do understand it,
they'll write it wrong anyway out of habit. You might as well write
your warning in Russian for all the good it'll do. :-)
So we'll force people who want any loop that exits other than at the
top to use:
loop {
...
last if CONDITION;
...
}
And that means we disallow modifier loops on do-{}.
Larry
Re: "=>" brother
On Sun, Jun 20, 2004 at 03:41:41AM +0400, Alexey Trofimenko wrote:
: There was some talks about hash keys autoquoting and barewords.. later are
: gone and former is disambigued by forcing to write %hash{'key'} or
: %hash«key» ( as opposite to %hash{key} which is now %hash{key()} )..
: right?..
: that's almost ok to me, if there's any hope that « will have a _standard_
: way to type accross all the editors:) (btw, I also hope I would never
: happen to mantain a perl6 program written by Chineese programmer, who
: thinks that chineese identifiers are cool)..
:
: but now I'm curious what you gonna do with => autoquoting behavior:
:
: shift => 'value' is the same as
: shift() => 'value'or
: 'shift' => 'value'in perl6?
:
: or in this particular case consistancy doesn't matter? ,)
Well, consistency with *what* is the question. The default Perl 6
design rule is that, unless we've said otherwise, Perl 6 is consistent
with Perl 5. So for the moment, => still autoquotes its left side.
Arguably, the :shift«value» syntax makes it easier to quote both
sides of a pair, so perhaps there's a little less need for an
autoquoting =>. But I think that generating non-quoted keys for
subscripting happens a lot more often than non-quoted keys for pairs,
so I'm inclined to leave the autoquoting of => in for now.
Larry
Re: if not C<,> then what?
On Fri, 9 Jul 2004 13:19:46 -0700 (PDT), Austin Hastings
<[EMAIL PROTECTED]> wrote:
--- Larry Wall <[EMAIL PROTECTED]> wrote:
If there reasonably can be block modifiers, I will unreasonably
declare that there can't be. You can always say:
do { print; next; } if|when /stgh/;
(It's still the case that do-while is specifically disallowed, however.)
But I also want do/while to work, solely because repeat/until sucks.
What's the big deal there?
hm..
do {...} while ...
sucks much more:) just because it used as loop, but it isn't really a
loop, so you cannot use C or C.. but IMNSHO to "specifically
disallow" it is somewhat unnatural, even if it could save from mistakes
many of us, who will think it works perl5ish way... maybe it just should
be written with BIG letters in perl6syn:
W A R N I N G ! ! !
do {...} while ...
DOES CHECK CONDITION (look here>>) __**BEFORE**__ (< BLOCK. (look here ^^^)
because C isn't something special anymore. So just use repeat/until
(or something)
(I correctly guessed true reasons for that, did I? :)
--
plz, ekskuze ma french.
Alexey
Re: if not C<,> then what?
On Sat, Jul 10, 2004 at 04:35:35AM +0400, Alexey Trofimenko wrote:
: On Fri, 9 Jul 2004 20:14:32 -0400, Joe Gottman <[EMAIL PROTECTED]>
: wrote:
: > Will given be a statement modifier also? This would be useful for
: >quick
: >topicalization:
: >
: > say "$_ => %hash{$_}" given get_random_key();
: >
: >Joe Gottman
: >
: >
: hm...
: does perl5ish
:
: say "$_ => %hash{$_}" for get_random_key();
:
: become unusable suddenly?
Those are both okay. We can probably even make them implicitly declare
a lexical $_ for the statement, as if the left side were really a
-> $_ { ... }
or some such, only without the braces. Topicalizers have to behave
like people expect.
It's the explicit declarations in a statement modifier that I think
are completely misleading, and should probably be disallowed, or at
least discouraged. The alternative is to complicate what "my" means,
and I don't really want to do that when we just went to a lot of trouble
to simplify it from Perl 5's rules.
Larry
Re: if not C<,> then what?
On Fri, 9 Jul 2004 20:14:32 -0400, Joe Gottman <[EMAIL PROTECTED]>
wrote:
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
Sent: Friday, July 09, 2004 2:33 PM
To: [EMAIL PROTECTED]
Subject: Re: if not C<,> then what?
On Fri, Jul 09, 2004 at 11:23:09AM -0700, Austin Hastings wrote:
: Will there be a statement modifier version of C?
:
: print, next when /stgh/;
Yes, though in this case it's indistinguishable from C, since //
defaults to $_ anyway. However, these are different:
print, next when 3;
print, next if 3;
Will given be a statement modifier also? This would be useful for
quick
topicalization:
say "$_ => %hash{$_}" given get_random_key();
Joe Gottman
hm...
does perl5ish
say "$_ => %hash{$_}" for get_random_key();
become unusable suddenly?
RE: if not C<,> then what?
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 09, 2004 2:33 PM
> To: [EMAIL PROTECTED]
> Subject: Re: if not C<,> then what?
>
> On Fri, Jul 09, 2004 at 11:23:09AM -0700, Austin Hastings wrote:
> : Will there be a statement modifier version of C?
> :
> : print, next when /stgh/;
>
> Yes, though in this case it's indistinguishable from C, since //
> defaults to $_ anyway. However, these are different:
>
> print, next when 3;
> print, next if 3;
Will given be a statement modifier also? This would be useful for quick
topicalization:
say "$_ => %hash{$_}" given get_random_key();
Joe Gottman
Re: question regarding rules and bytes vs characters
On Tue, Jun 01, 2004 at 07:56:41AM +0200, Ph. Marek wrote:
: Hello everybody,
:
: I'm about to learn myself perl6 (after using perl5 for some time).
I'm also trying to learn perl6 after using perl5 for some time. :-)
: One of my first questions deals with regexes.
:
:
: I'd like to parse data of the form
: Len: 15\n
: (15 bytes data)\n
: Len: 5\n
: (5 bytes data)\n
: \n
: OtherTag: some value here\n
: and so on, where the data can (and will) be binary.
:
: I'd try for something like
: my $data_tag= rule {
: Len\: $len:=(\d) \n
: $data:=([:u0 .]<$len>)\n # these are bytes
: };
:
: Is that correct?
Pretty close. The way it's set up currently, $len is a reference
to a variable external to the rule, so $len is likely to fail under
stricture unless you've declared "my $len" somewhere. To make the
variable automatically scope to the rule, you have to use $?len
these days.
: And furthermore is perl6 said to be unicode-ready.
: So I put the :u0-modifier in the data-regex; will that DWIM if I try to match
: a unicode-string with that rule?
It should. However (and this is a really big however), you'll have
to be very careful that something earlier hasn't converted one form
of Unicode to another on you. For instance, if your string came in
as UTF-8, and your I/O layer translated it internally to UTF-32 or
some such, you're just completely hosed. When you're working at the
bytes level, you must know the encoding of your string.
So the natural reaction is to open your I/O handle :raw to get binary
data into your string. Then you try to match Unicode graphemes with [
:u2 . ] and discover that *that* doesn't work. Which is obvious when
you consider that Perl has no way of knowing which Unicode encoding
the binary data is in, so it's gonna consider it to be something like
Latin-1 unless you tell it otherwise. So you'll probably have to
cast the binary string to whatever its actual encoding is (potentially
lying about the binary parts, which we may or may not get away with,
depending on who validates the string when), or maybe we just need
to define rules like and for use
under the :u0 regime.
: Is anything known about the internals of pattern matching whether the
: hypothetical variables will consume (double) space?
: I'm asking because I imagine getting a tag like "Len: 2" and then
: having problems with 256MB RAM. Matching shouldn't be a problem according to
: apo 5 (see the chapter "RFC 093: Regex: Support for incremental pattern
: matching") but I'll maybe have troubles using the matched data?
My understanding is that Parrot implements copy-on-write, so you should
be okay there.
: Thank you for all answers!
Even the late ones? :-)
Larry
Re: if not C<,> then what?
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 09, 2004 at 11:51:52AM -0700, Austin Hastings wrote:
> : --- Larry Wall <[EMAIL PROTECTED]> wrote:
> : > If there reasonably can be block modifiers, I will unreasonably
> : > declare that there can't be.
> :
> : Be as unreasonable as you want -- the grammar's open. :)
>
> Darn it, when did that misfeature sneak in? :-)
I can't recall the day, but I'm pretty sure it ended with 'y'.
>
> : > You can always say:
> : >
> : > do { print; next; } if|when /stgh/;
> : >
> : > (It's still the case that do-while is specifically disallowed,
> : > however.)
> :
> : What about C?
> :
> : do { print ; next } loop (; true ;);
>
> I don't see much utility in that, and plenty of room for confusion.
> Does the "next" apply to the statement modifier? How often do you
> want to explain why
>
> do { print $i } loop (my $i = 0; $i < 10; $i++);
>
> doesn't work?
I want it to work. (I'm about to ask for a <- binding operator, to boot
:)
But I also want do/while to work, solely because repeat/until sucks.
What's the big deal there?
> All leaving out the fact that it doesn't read like English, which is
> a requirement for statement modifiers.
Yeah. What idiot picked 'loop' for a keyword? :)
OTOH, there's a whole slew of prepositions out there. What's the
mechanism for adding them as statement modifiers?
++$_ throughout @a;
> Of course, the grammar's open...
>
> But let me put this on the record: I specifically disrecommend use of
> grammar tweaks that will incite lynch mobs. You have been warned.
One man's syntactic sugar is another man's "get a rope." I'm sure
someone will implement C++ style I/O using some number of < and >
characters (it won't be me).
(And there's the separable keyword issue, natch. "...up with which I
shall not put" in perl? C)
=Austin
Re: if not C<,> then what?
On Fri, Jul 09, 2004 at 11:51:52AM -0700, Austin Hastings wrote:
: --- Larry Wall <[EMAIL PROTECTED]> wrote:
: > On Fri, Jul 09, 2004 at 11:23:09AM -0700, Austin Hastings wrote:
: > : Can there reasonably be block-postfix modifiers?
: > :
: > : { print; next; } if|when /stgh/;
: >
: > If there reasonably can be block modifiers, I will unreasonably
: > declare that there can't be.
:
: Be as unreasonable as you want -- the grammar's open. :)
Darn it, when did that misfeature sneak in? :-)
: > You can always say:
: >
: > do { print; next; } if|when /stgh/;
: >
: > (It's still the case that do-while is specifically disallowed,
: > however.)
:
: What about C?
:
: do { print ; next } loop (; true ;);
I don't see much utility in that, and plenty of room for confusion.
Does the "next" apply to the statement modifier? How often do you
want to explain why
do { print $i } loop (my $i = 0; $i < 10; $i++);
doesn't work?
All leaving out the fact that it doesn't read like English, which is
a requirement for statement modifiers.
Of course, the grammar's open...
But let me put this on the record: I specifically disrecommend use of
grammar tweaks that will incite lynch mobs. You have been warned. :-)
Larry
Re: if not C<,> then what?
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 09, 2004 at 11:23:09AM -0700, Austin Hastings wrote:
> : Can there reasonably be block-postfix modifiers?
> :
> : { print; next; } if|when /stgh/;
>
> If there reasonably can be block modifiers, I will unreasonably
> declare that there can't be.
Be as unreasonable as you want -- the grammar's open. :)
> You can always say:
>
> do { print; next; } if|when /stgh/;
>
> (It's still the case that do-while is specifically disallowed,
> however.)
What about C?
do { print ; next } loop (; true ;);
=Austin
Re: if not C<,> then what?
On Fri, Jul 09, 2004 at 11:23:09AM -0700, Austin Hastings wrote:
: Will there be a statement modifier version of C?
:
: print, next when /stgh/;
Yes, though in this case it's indistinguishable from C, since //
defaults to $_ anyway. However, these are different:
print, next when 3;
print, next if 3;
: Can there reasonably be block-postfix modifiers?
:
: { print; next; } if|when /stgh/;
If there reasonably can be block modifiers, I will unreasonably
declare that there can't be. You can always say:
do { print; next; } if|when /stgh/;
(It's still the case that do-while is specifically disallowed, however.)
Larry
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
Re: if not C<,> then what?
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 09, 2004 at 10:39:56AM +0200, Michele Dondi wrote:
> : On Thu, 1 Jul 2004, Alexey Trofimenko wrote:
> :
> : > if we really about to lose C-style comma, would we have something
> new
> : > instead?
> :
> : A late thought, but since I am one of thow whose' keen on the
> :
> : print,next if /stgh/;
> :
> : kinda syntax too, and I, for one, will regret not having it
> anymore, I
> : wonder wether something vaguely like the following example could
> (be made
> : to) work:
> :
> : print.then{next} if /stgh/;
>
> That's unnecessary--the comma still works perfectly fine for this,
> since comma still evaluates its arguments left-to-right. The *only*
> difference about comma is what it returns in scalar context. Most
> uses of the so-called C-style comma (including this one) are
> actually in void context, and in that case whether the return value
> is a list or the final value Doesn't Really Matter.
Will there be a statement modifier version of C?
print, next when /stgh/;
Can there reasonably be block-postfix modifiers?
{ print; next; } if|when /stgh/;
=Austin
Re: if not C<,> then what?
On Fri, Jul 09, 2004 at 10:39:56AM +0200, Michele Dondi wrote:
: On Thu, 1 Jul 2004, Alexey Trofimenko wrote:
:
: > if we really about to lose C-style comma, would we have something new
: > instead?
:
: A late thought, but since I am one of thow whose' keen on the
:
: print,next if /stgh/;
:
: kinda syntax too, and I, for one, will regret not having it anymore, I
: wonder wether something vaguely like the following example could (be made
: to) work:
:
: print.then{next} if /stgh/;
That's unnecessary--the comma still works perfectly fine for this,
since comma still evaluates its arguments left-to-right. The *only*
difference about comma is what it returns in scalar context. Most uses
of the so-called C-style comma (including this one) are actually in
void context, and in that case whether the return value is a list or
the final value Doesn't Really Matter.
Larry
Re: if not C<,> then what?
Michele Dondi wrote:
A late thought, but since I am one of thow whose' keen on the
print,next if /stgh/;
Ouch. I hadn't thought of that. I'm a big fan of litering loops with
discard(),next if dontCareBecause(); # it don't matter here
type constructs. I was going to suggest
print and next if /stgh/;
but there is a difference that will probably bite you when you least
expect it. You could say
(print or 1) and next if /stgh/;
but not we are in the areas of pointlessy ugly hacks. I could live with
do{print;next} if /stgh/;
but the do just feels over verbose. So do the braces. Can next be used
in numeric context?
(print) + (next) if /stgh/;
hmm. ug. Never mind. Oh! I've got it!
eval "print;next" if /stgh/;
no. That as bad as do, 'cept differnt. I give up.
Dan
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: if not C<,> then what?
Michele Dondi skribis 2004-07-09 11:39 (+0200): > > - then as a method of print makes sense > then as a method of everything How does then as a method make sense? A method has to be somehow related to the object. Don't use methods for syntactic sugar, Perl 6 has plenty of ways to add sugar without abusing things that normally mean something else. Juerd
Re: if not C<,> then what?
On Fri, 9 Jul 2004, Juerd wrote:
> > wonder wether something vaguely like the following example could (be made
> > to) work:
> > print.then{next} if /stgh/;
>
> Ehm. It can probably be made to work with sufficient black magic, but I
> fail to see how:
>
> - then as a method of print makes sense
then as a method of everything
> - a hash returned by that method makes sense
it doesnt: "something vaguely like the following"...
Michele
--
> Devo cambiare le porte del mio appartamento e mi piacerebbe metterle in
> legno con vetro.
> Mi sono informato e tutti mi dicono che costano.
> Qualcuno ha qualche idea di prezzo.
Dipende dal motore e dal radiocomando.
- Piero "Giops" Giorgi su it.hobby.modellismo
Re: if not C<,> then what?
Michele Dondi skribis 2004-07-09 10:39 (+0200):
> kinda syntax too, and I, for one, will regret not having it anymore, I
> wonder wether something vaguely like the following example could (be made
> to) work:
> print.then{next} if /stgh/;
Ehm. It can probably be made to work with sufficient black magic, but I
fail to see how:
- then as a method of print makes sense
- a hash returned by that method makes sense
If evaluation of hash keys is delayed until necessary, all you have to
do is make print return an object that has a then method. And it doesn't
have to do anything, even.
I think "then" as an infix operator is the way to go, if comma really
won't allow us to write this. "then" as a method my brain won't grok.
Juerd
Re: if not C<,> then what?
On Thu, 1 Jul 2004, Alexey Trofimenko wrote:
> if we really about to lose C-style comma, would we have something new
> instead?
A late thought, but since I am one of thow whose' keen on the
print,next if /stgh/;
kinda syntax too, and I, for one, will regret not having it anymore, I
wonder wether something vaguely like the following example could (be made
to) work:
print.then{next} if /stgh/;
Michele
--
> 4 words: it-was-a-joke!
4 words: he-has-no-clue!!
- Uri Guttman on clpmisc (slightly edited)
