On Wed, 30 Jun 2004 19:41:24 -0600, Luke Palmer <[EMAIL PROTECTED]> wrote:
Alexey Trofimenko writes:if we really about to lose C-style comma, would we have something new instead?
new C<,>,( as I've been told here by wise ones), doesn't guarantee order in which its operands will be evaluated, and even doesn't guarantee that they won't be optimised away before evaluating, if all expression is in void context.. right?
Nope, that was just silliness. Although the scalar comma is going away in favor of a list constructor, I presume that there will be no opimizing away of elements, and that they will probably still be evaluated left to right. Optimizations that you get from changing the evaluation order aren't big enough to warrant such a strange semantic effect.
BUT: the subexpressions will be evaluated in list context.
I'm thinking about C<then>, analogious to old C<,> (maybe with lower precedence than C<and> and C<or> have?)
pray_to $_ then sacrifice <$virgin> for @evil_gods
hm.. maybe C<then> should make first action in void context (I hate noise
when doing business)
That's interesting. I brought up the same thing and proposed the same solution just a few months ago. Same keyword and everything :-)
hm:) I'm sorry for idea stealing. I'm here only month.. Maybe it means this is natural solution for many people's way of thoughts?..)
Larry didn't go for it. Note, we already have an operator that puts its left side in void context and evaluates it before its right one: we call it C<;>.
Larry didn't go.. ok, that is it! I Want To Write My Own Grammar(TM) :) Just because that construct would be more useful for me than many we already have in the core. Now I'm interesting, would it be difficult. That is - would it be difficult to write operator, which evaluates it's left operand in void context, and do not tries to store results or to create lists or all the unneded activity wich C<,> will do.. (I suspicious to macroses - they could have their major caveat, we just not find it yet..)
BTW is C<;> an operator really? :) if it is, then it has lower precedence than statement modifers, and that means that they are really operators too, which leads us to thinking about several modifiers possibility (again!).. but Larry didn't go for it, I know :)
@>
do { pray_to $_; sacrifice <$virgin> } for @evil_gods;
Luke
note about C<do> - I think ret() mentioned in one of Apocalypses should be in core.. just because it's sometimes too "difficult" (i'm lazy) to place return value at the end of complicated C<do>, C<map>, C<grep> etc blocks.
If I use curlies, I place a whole program in it:)
and, again about C<,>
what about C<,,> ? what it would do? in perl5 this has no effect, but what about perl6? (something tells me that it would be compile time error probably.)
maybe (1,,2) could be the same as (1,undef,2)? but someone immediately will write subroutine callable as
mysub 1,2,3,,,,,,,4
perl gives a lot of freedom, and I like that.. but do we allow such silliness? :)
(P.S. my lazyness murmurs to me that ,, would be niccce.. oh my.. no-o!)
