if not C<,> then what?

[Alexey Trofimenko]

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?

so it will be erroneous to write:

pray_to $_, sacrifice <$virgin> for @evil_gods

because it could be executed as:

sacrifice <$virgin>, pray_to $_ for @evil_gods

that is against rites;
or even "optimized away" as:

sacrifice <$virgin> for @evil_gods

which is a senseless loss of costly and rare resources.
And I can't just write

pray_to $_ and sacrifice <$virgin> for @evil_gods

because prayer result is almost always undefined, ..but who knows?

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)

P.S. of course, I can just use
for @evil_gods { ... }
but I thought there's more than one way to sacrifice It... I'm just afraid
of Repetitive Injure..
BTW, slight improvisations don't not harm in such things...

P.P.S. do we have a way to imply void context on function inside
expression, something like C<scalar>, C<+>, C<~>, C<?> do?

--
$_ = join q--, map++ $_=>split q qq, q
xitrswzmnsgdqwakzbjwodqkwoqhdrswx xor y yayys x y yxy y x print

[Chromatic]

On Wed, 2004-06-30 at 18:18, Alexey Trofimenko wrote:

> P.P.S. do we have a way to imply void context on function inside
> expression, something like C<scalar>, C<+>, C<~>, C<?> do?

Sort of a 'meh' operator?

I wonder (idly) in which circumstances the context determinator couldn't
determinate void context, though.

-- c

[Luke Palmer]

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 :-)

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<;>.

do { pray_to $_; sacrifice <$virgin> } for @evil_gods;

Luke

[Aaron Sherman]

module foo {
sub a() is export { return 1; }
sub b() is export { a() }
}

Our Huffmanization imperative tells us that this should be a longer
operator than other contextifiers, so why not just the C-like, "void"?

void foo::b();

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Perl Toolsmith
http://www.ajs.com/~ajs/resume.html

[Scott Bronson]

On Wed, 2004-06-30 at 18:41, Luke Palmer wrote:
> 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<;>.

But C<;> requires a surrounding do block, as you noted. I'm
disappointed that Larry didn't go for it. To my eyes, C<then> really
increases readability.

pray_to $_ then sacrifice <$virgin> for @evil_gods

Ah, yes. That's beautiful.

However,

do { pray_to $_; sacrifice <$virgin> } for @evil_gods;

Ouch. That bounces and jangles as you try to read it. There appears to
be some sort of deep separation between @evil_gods and sacrificial
$virgin. C<do> appears to be the most important part of this statement,
when it is in fact the _least_ important.

- Scott

[Juerd]

Scott Bronson skribis 2004-07-01 12:42 (-0700):

> But C<;> requires a surrounding do block, as you noted.

Then invent a horizontal ; operator that does not :)

> pray_to $_ then sacrifice <$virgin> for @evil_gods

pray_to $_ ., then sacrifice <$virgin> for @evil_gods;

Juerd

[Alexey Trofimenko]

On Wed, 30 Jun 2004 19:41:24 -0600, Luke Palmer <lu...@luqui.org> 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!)

[Scott Bronson]

On Thu, 2004-07-01 at 12:45, Juerd wrote:
> Scott Bronson skribis 2004-07-01 12:42 (-0700):
> > But C<;> requires a surrounding do block, as you noted.
>
> Then invent a horizontal ; operator that does not :)

C<then>? That's the topic of discussion...

> > pray_to $_ then sacrifice <$virgin> for @evil_gods
>
> pray_to $_ ., then sacrifice <$virgin> for @evil_gods;

Sure. But what is .,? C<then> could work alone, couldn't it?

[Juerd]

Scott Bronson skribis 2004-07-01 13:31 (-0700):

> > Then invent a horizontal ; operator that does not :)

> > > pray_to $_ then sacrifice <$virgin> for @evil_gods
> > pray_to $_ ., then sacrifice <$virgin> for @evil_gods;
> Sure. But what is .,? C<then> could work alone, couldn't it?

It is a horizontal ;.

See: .,

If you turn your head 90 degrees counter clockwise, you see the
horizontal semicolon and even a smiley face :)

Juerd

[Jonathan Lang]

Scott Bronson wrote:
> On Wed, 2004-06-30 at 18:41, Luke Palmer wrote:
> > 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<;>.
>
> But C<;> requires a surrounding do block, as you noted. I'm
> disappointed that Larry didn't go for it. To my eyes, C<then> really
> increases readability.

All's fair if you predeclare:

sub infix:then (&first, &last) {
&first();
return &last();
}

The only problem I see with this solution is that I don't think that you
can pass individual commands into code variables:

pray_to $_ then sacrifice <$virgin> for @evil_gods;

would be wrong, but

{pray_to $_} then {sacrifice <$virgin>} for @evil_gods;

would work. Am I right about this, or does perl 6 let you pass simple
statements as code parameters? If the former, is there a way to tell it
to do the latter?

For the record, I was mentally parsing this example as:

pray_to $_;
sacrifice <$virgin> for @evil_gods;

rather than:

{pray_to $_; sacrifice <$virgin>} for @evil_gods;

The precedence of C<then> isn't very intuitive to me.

=====
Jonathan "Dataweaver" Lang

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

[Scott Bronson]

On Thu, 2004-07-01 at 13:35, Juerd wrote:
> > > pray_to $_ ., then sacrifice <$virgin> for @evil_gods;
> > Sure. But what is .,? C<then> could work alone, couldn't it?
>
> It is a horizontal ;.

Ha! I love it. Good source code should look happy.

[Juerd]

Scott Bronson skribis 2004-07-01 14:11 (-0700):

> On Thu, 2004-07-01 at 13:35, Juerd wrote:
> > > > pray_to $_ ., then sacrifice <$virgin> for @evil_gods;

I meant it without "then", but apparently forgot to remove it.

pray to $_ ., sacrifice <$virgin> for @evil_gods;

> Ha! I love it. Good source code should look happy.

I'm glad you like it :)

Juerd

[Jonathan Lang]

Juerd wrote:
> Scott Bronson skribis 2004-07-01 14:11 (-0700):

> > Juerd wrote:
> > > > > pray_to $_ ., then sacrifice <$virgin> for @evil_gods;
>
> I meant it without "then", but apparently forgot to remove it.
>
> pray to $_ ., sacrifice <$virgin> for @evil_gods;

Strictly from a grammatical perspective, I'd be much more comfortable with
C<, then> instead of C<then> as the perl equivelent of the C-style comma:
have the "then" keyword change the preceeding comma from a list
constructor to an expression combiner. From a parsing perspective,
though, this would be a nightmare.

Actually, the whole purpose of the C-style comma is to allow you to place
multiple expressions in a place that's only designed to take one, such as
the various divisions within a loop control set ("loop ($i = 0, $j = 1; $i
< 10; $i++, $j*=2) {...}"). For something like this, you might be better
off doing something like

last($a, $b, $c)

instead of

$a then $b then $c

(where last is a sub that takes a list of arguments, evaluates them one at
a time, and returns the value of the last one). Unfortunately, "last" is
already in use by perl; so you'd have to think up another name for the
sub, such as "final".

If you're really enamoured with the infix operator syntax, consider this
possibility:

sub infix:-> ($before, $after) {
$before; # is this line redundant?
return $after;
}
print $a -> $b -> $c; # prints $c

where C[->] is read as "followed by". You could even set up a
right-to-left version, C[<-], but why bother?

=====
Jonathan "Dataweaver" Lang

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

[David Storrs]

On Thu, Jul 01, 2004 at 04:14:37PM -0700, Jonathan Lang wrote:
> Juerd wrote:
>
> If you're really enamoured with the infix operator syntax, consider this
> possibility:
>
> sub infix:-> ($before, $after) {
> $before; # is this line redundant?
> return $after;
> }
> print $a -> $b -> $c; # prints $c
>
> where C[->] is read as "followed by". You could even set up a
> right-to-left version, C[<-], but why bother?

You could do this, but you'd be overriding the current meaning of
C<< -> >> as "pointy sub".

You could also use, 'before':

# Recipe for (un)holy water that will irk the altar's god.
step_on_altar();
drop_water($_) before pray() for @water_potions;

OOC, can you define an operator that is made up of alphanumerics, or
only punctuation? e.g., is this legal?

sub infix:before ( $before, $after ){ ... }

--Dks

[Joseph Ryan]

Sure. The parser won't care what kind of characters
make up the operator, as long as its defined by the
time the operator is encountered. The "operator"
rules in the grammar will probably be as simple as this:

# where x is the type of operator; infix, prefix, etc
rule x_operator:u2 {
%*X_OPERATORS
}

- Joe

[Alexey Trofimenko]

On Thu, 1 Jul 2004 16:14:37 -0700 (PDT), Jonathan Lang
<datawe...@yahoo.com> wrote:

> Actually, the whole purpose of the C-style comma is to allow you to place
> multiple expressions in a place that's only designed to take one, such as
> the various divisions within a loop control set ("loop ($i = 0, $j = 1;
> $i
> < 10; $i++, $j*=2) {...}"). For something like this, you might be better
> off doing something like
>
> last($a, $b, $c)
>
> instead of
>
> $a then $b then $c
> (where last is a sub that takes a list of arguments, evaluates them one
> at
> a time, and returns the value of the last one).

I remember perl5 scalar:
scalar($a, $b, $c)

f.e.:

sub test {print wantarray ? "list\n"
: defined wantarray ? "scalar\n" : "void\n"}

scalar (test,test,test)

prints

void
void
scalar

...
hm.. sorry, scalar() isn't needed at all:)

2+(test,test,test)

gives the same.. it's a perl5 comma's behavior, not perl5 scalar()

...
ok, all I want is an ability to write operator which wouldn't try to
create lists or store result of first operand and will call it in _void_
context, so I could easily write short postfix loops and conditionals when
I want to.

[Luke Palmer]

Alexey Trofimenko writes:
> I remember perl5 scalar:
> scalar($a, $b, $c)

In Perl 6, I presume that means the same as:

[ $a, $b, $c ]

> hm.. sorry, scalar() isn't needed at all:)
>
> 2+(test,test,test)

Likewise, this would be:

2+[test, test, test]

Which should be:

2+3

Assuming test returns a single value.

> ok, all I want is an ability to write operator which wouldn't try to
> create lists or store result of first operand and will call it in _void_
> context, so I could easily write short postfix loops and conditionals when
> I want to.

We hear ya. It's called C<;> enclosed in a C<do> block. I know, it's a
pain sometimes, but you just have to get used to it. I've stopped using
the scalar comma in Perl 5, and the code just I<feels> cleaner to me
now. I doubt we'll be getting an operator analogous to the C comma.

It's easy to write with a macro:

macro infix:then is looser(&infix:,) ($left, $right) {
return {
$left.run;
$right.run;
}
}

Luke

[Jonadab The Unsightly One]

Jonathan Lang <datawe...@yahoo.com> writes:

> Strictly from a grammatical perspective, I'd be much more comfortable with
> C<, then> instead of C<then> as the perl equivelent of the C-style comma:
> have the "then" keyword change the preceeding comma from a list
> constructor to an expression combiner. From a parsing perspective,
> though, this would be a nightmare.

Parsing Perl was nightmarish already before work started on Perl6. If
we wanted a language that's easy to parse, we'd be using lisp, or
maybe assembly language.

Still, I'm not sure what the comma adds, other than extra[1]
punctuation.

This is different from its use in conditional sentences, since in that
case the protasis (if clause), being an introductory subordinate
clause, is usually set off from the rest of the sentence via a comma,
whether or not "then" is used to introduce the apodosis (then
clause). It is common to see a comma before "then" for this reason,
but that is entirely a different use (and meaning) of "then".

Come to think of it, the frequent use of "then" in conditionals might
make it a bad choice for use in another way.

> Actually, the whole purpose of the C-style comma is to allow you to place
> multiple expressions in a place that's only designed to take one, such as
> the various divisions within a loop control set ("loop ($i = 0, $j = 1; $i
> < 10; $i++, $j*=2) {...}"). For something like this, you might be better
> off doing something like
>
> last($a, $b, $c)
>

> (where last is a sub that takes a list of arguments, evaluates them one at
> a time, and returns the value of the last one). Unfortunately, "last" is
> already in use by perl; so you'd have to think up another name for the
> sub, such as "final".

Oh, like lisp's progn (except that final is a better name for it).

Perl5 programmers have been known to use xor for this, though of
course that is not the intended use of xor.

> where C[->] is read as "followed by". You could even set up a
> right-to-left version, C[<-], but why bother?

Oh, for aesthetic symetry, of course ;-)

[1] "Do one thing then do another" is valid SWE I think. "then" is not
a coordinating conjunction like "and"; it's a special adverb of
sorts, in a similar category with "because" (except that "because"
is a subordinator; whereas, "then" does coordinate; but it is not
a conjunction) or "so" (although "so" often is treated like a
conjunction and takes the comma, which is an odd little wrinkle --
but it does not always do this). "then" can function as a
coordinating adverb (like consequently and nonetheless and so on);
in the case wherein it joins whole independent clauses it is
preceded by a semicolon (as in "She went to the store; then she
came home." -- if there were a comma in this case it would be
after "then", not before), but it can also be used to coordinate
the parts of a compound part of speech, e.g., a compound verb with
the subject expressed only once (if at all; in the imperative mood
the subject need not be expressed); in that case no punctuation is
needed, as in "She went to the store then came home." This last
usage most closely fits the proposed way of using it in Perl, as
in " (you) Go to the store then come straight home."

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

[Jonadab The Unsightly One]

David Storrs <dst...@dstorrs.com> writes:

> e.g., is this legal?
>
> sub infix:before ( $before, $after ){ ... }

I should HOPE it would be legal to define infix:before. Some of us
don't want to use untypeable characters every time we want to define
an operator that doesn't conflict with the core language.

[Jonadab The Unsightly One]

Jonathan Lang <datawe...@yahoo.com> writes:

> For the record, I was mentally parsing this example as:
>
> pray_to $_;
> sacrifice <$virgin> for @evil_gods;

So was I, FWIW.

> The precedence of C<then> isn't very intuitive to me.

Is that an argument for changing its precedence, or for leaving it out
of the core language?

[Juerd]

Jonadab the Unsightly One skribis 2004-07-03 13:33 (-0400):

> > e.g., is this legal?
> > sub infix:before ( $before, $after ){ ... }
> I should HOPE it would be legal to define infix:before.

There already are infix:x and infix:xx. If Perl 6 will let us define our
own operators just like built in ones, infix:before should also be
possible.

And infix:¥ (for those like me who have a simple terminal that doesn't
know how to display this, or are suffering from my lack of config-fu to
get headers and encodings synched: this is Yen, created using ^KYe in
vim. I see a dashed rectangle.) will in my programs probably only be
used through infix:Y or infix:z, which I will define myself if
necessary. (zip() is not infix and thus not an *equivalent*
alternative.)

Juerd

[Larry Wall]

On Fri, Jul 02, 2004 at 03:03:49PM -0400, JOSEPH RYAN wrote:
: Sure. The parser won't care what kind of characters

: make up the operator, as long as its defined by the
: time the operator is encountered. The "operator"
: rules in the grammar will probably be as simple as this:
:
: # where x is the type of operator; infix, prefix, etc
: rule x_operator:u2 {
: %*X_OPERATORS

: }

Maybe not *quite* that simple--we have to guarantee the longest
token wins. But maybe that's how % should work in rules anyway.
We'd have to get a little fancy and generate an ordered match rule
for the current set of keys, and presumably cache that so we don't
recalculate it every time. And then we'd have to flush the cache if
the set of keys change.

Also, the :u2 would almost certainly be set at the top of the file as
a pragma rather than putting it on every rule, since bare Perl code
is always considered language-independent Unicode. (Literal strings
convert to the actual Unicode support level for data, of course.)
(It may be possible to write Perl programs in other encodings, but
those would be source-filtered into Unicode before the Perl parser
ever sees it.)

On the other hand, the default is likely "use graphemes" anyway,
so we probably don't even need the pragma in file containing the
Perl grammar at all...

Larry

[Michele Dondi]

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)

[Juerd]

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

[Michele Dondi]

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

[Juerd]

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

[Dan Hursh]

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

[Larry Wall]

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

[Austin Hastings]

Will there be a statement modifier version of C<when>?

print, next when /stgh/;

Can there reasonably be block-postfix modifiers?

{ print; next; } if|when /stgh/;

=Austin

[Larry Wall]

On Fri, Jul 09, 2004 at 11:23:09AM -0700, Austin Hastings wrote:
: Will there be a statement modifier version of C<when>?
:
: print, next when /stgh/;

Yes, though in this case it's indistinguishable from C<if>, 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

[Austin Hastings]

--- Larry Wall <la...@wall.org> 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<loop>?

do { print ; next } loop (; true ;);

=Austin

[Larry Wall]

On Fri, Jul 09, 2004 at 11:51:52AM -0700, Austin Hastings wrote:
: --- Larry Wall <la...@wall.org> 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<loop>?
:
: 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

[Austin Hastings]

--- Larry Wall <la...@wall.org> wrote:
> On Fri, Jul 09, 2004 at 11:51:52AM -0700, Austin Hastings wrote:
> : --- Larry Wall <la...@wall.org> 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<loop>?
> :
> : 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<print if even else next;>)

=Austin

[Joe Gottman]

> -----Original Message-----
> From: Larry Wall [mailto:la...@wall.org]
> Sent: Friday, July 09, 2004 2:33 PM
> To: perl6-l...@perl.org
> 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<when>?
> :
> : print, next when /stgh/;
>
> Yes, though in this case it's indistinguishable from C<if>, 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

[Alexey Trofimenko]

On Fri, 9 Jul 2004 20:14:32 -0400, Joe Gottman <jgot...@carolina.rr.com>
wrote:

hm...
does perl5ish

say "$_ => %hash{$_}" for get_random_key();

become unusable suddenly?

[Larry Wall]

On Sat, Jul 10, 2004 at 04:35:35AM +0400, Alexey Trofimenko wrote:
: On Fri, 9 Jul 2004 20:14:32 -0400, Joe Gottman <jgot...@carolina.rr.com>
: 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

[Alexey Trofimenko]

On Fri, 9 Jul 2004 13:19:46 -0700 (PDT), Austin Hastings
<austin_...@yahoo.com> wrote:

> --- Larry Wall <la...@wall.org> 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<next> or C<redo>.. 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**__ (<<look here) TRYING
TO EXECUTE C<DO> BLOCK. (look here ^^^)
because C<do> 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

[Larry Wall]

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

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

[Alexey Trofimenko]

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?

[Brent 'Dax' Royal-Gordon]

> 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 <br...@brentdax.com>
Perl and Parrot hacker

Oceania has always been at war with Eastasia.

[Larry Wall]

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

[Alexey Trofimenko]

On Fri, 9 Jul 2004 18:25:40 -0700, Larry Wall <la...@wall.org> 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:)

[Jonadab The Unsightly One]

Dan Hursh <hu...@infonet.isl.net> writes:

> 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

I like the idea here, but I don't think we need the comma...

> 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

One word: xor

Yes, this is abusing a logical operator, which was intended to test a
condition, for flow control. If that makes you feel dirty, you could
always write a traditional conditional with a block.