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
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
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
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
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/;
:
:
--- 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
On Fri, Jul 09, 2004 at 11:23:09AM -0700, Austin Hastings wrote:
: Will there be a statement modifier version of Cwhen?
:
: print, next when /stgh/;
Yes, though in this case it's indistinguishable from Cif, since //
defaults to $_ anyway. However, these are different:
print, next when
--- 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.
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
--- 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
-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 Cwhen
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
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
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.
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
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
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
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
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
Jonathan Lang [EMAIL PROTECTED] writes:
Strictly from a grammatical perspective, I'd be much more comfortable with
C, then instead of Cthen 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
David Storrs [EMAIL PROTECTED] 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
Jonathan Lang [EMAIL PROTECTED] 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 Cthen isn't very intuitive to me.
Is that an argument for changing its precedence, or for leaving it out
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,
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 -
- Original Message -
From: David Storrs [EMAIL PROTECTED]
Date: Thursday, July 1, 2004 7:55 pm
Subject: Re: if not C, then what?
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
On Thu, 1 Jul 2004 16:14:37 -0700 (PDT), Jonathan Lang
[EMAIL PROTECTED] 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 =
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
On Wed, 2004-06-30 at 21:33, chromatic wrote:
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 Cscalar, C+, C~, C? do?
Sort of a 'meh' operator?
I wonder (idly) in which circumstances
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
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
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 Cdo, Cmap, Cgrep 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
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 :)
Cthen? That's the topic of discussion...
pray_to $_ then sacrifice $virgin for
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 .,? Cthen could work alone, couldn't it?
It is a horizontal ;.
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
On Thu, 2004-07-01 at 13:35, Juerd wrote:
pray_to $_ ., then sacrifice $virgin for @evil_gods;
Sure. But what is .,? Cthen could work alone, couldn't it?
It is a horizontal ;.
Ha! I love it. Good source code should look happy.
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
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,
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
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 Cscalar, C+, C~, C? do?
Sort of a 'meh' operator?
I wonder (idly) in which circumstances the context determinator couldn't
determinate void
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
40 matches
Mail list logo
