Dan Hursh <[EMAIL PROTECTED]> 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
>
>
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 mor
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
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 lo
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 sin
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
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 ca
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
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 -
> -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 s
--- 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 wa
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: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
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;
p
--- 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 o
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/;
:
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
pri
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
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 sens
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 blac
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 wet
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
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 o
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 C isn't very intuitive to me.
Is that an argument for changing its precedence, or for leaving it o
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:
> Strictly from a grammatical perspective, I'd be much more comfortable with
> C<, then> instead of C 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. F
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
Ass
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
- 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 en
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 $
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 grammatica
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
On Thu, 2004-07-01 at 13:35, Juerd wrote:
> > > pray_to $_ ., then sacrifice <$virgin> for @evil_gods;
> > Sure. But what is .,? C could work alone, couldn't it?
>
> It is a horizontal ;.
Ha! I love it. Good source code should look happy.
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.
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 could work alone, couldn't it?
It is a horizon
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? That's the topic of discussion...
> >pray_to $_ then sacrifice <$virgin> for
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 e
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
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
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 C, C<+>, C<~>, C do?
>
> Sort of a 'meh' operator?
>
> I wonder (idly) in which circumstan
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
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, C<+>, C<~>, C do?
Sort of a 'meh' operator?
I wonder (idly) in which circumstances the context determinator couldn't
determinate void context
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
43 matches
Mail list logo
