> Date: 20 Jan 2003 20:30:07 -
> From: Smylers <[EMAIL PROTECTED]>
>
> It seems that when chaining together functions, omitting C<< <~ >>
> operators gives the same result in the familiar Perl 5 standard
> function-call syntax:
>
> @foo = sort { ... } <~ map { ... } <~ grep { ... } <~ @bar;
On Monday, January 20, 2003, at 12:30 PM, Smylers wrote:
Ah. It was only on reading that (and discovering that you hadn't
previously known about the 'optional comma with closure argument' rule)
that I understood why you had previously been so in favour of proposed
new syntaxes: through a desire
[EMAIL PROTECTED] (Austin Hastings) writes:
> Let's support separable verbs.
That (http://dev.perl.org/perl6/rfc/309.html) is a really good idea.
--
Writing software is more fun than working.
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Austin Hastings:
> # Let's support separable verbs.
> #
> # Here's how:
> #
> # # Note my arbitrary selection of _ as separation indicator.
> # Feel free to replace this with something more appropriate:
> #
> # sub if($test, &block)
> # _ elsif
Austin Hastings:
# Let's support separable verbs.
#
# Here's how:
#
# # Note my arbitrary selection of _ as separation indicator.
# Feel free to replace this with something more appropriate:
#
# sub if($test, &block)
# _ elsif ($test, &block) is optional is floating is multi
# _ elsun
--- "Joseph F. Ryan" <[EMAIL PROTECTED]> wrote:
> If the final design stays the way it is now, there really won't be
> a "lexer". Instead, a perl6 grammar parses the data, and builds up
> a huge match-object as it, well, matches. This match object is then
> munged into the optree.
>
With this
Joseph F. Ryan wrote in perl.perl6.language :
>
> If the final design stays the way it is now, there really won't be
> a "lexer". Instead, a perl6 grammar parses the data, and builds up
> a huge match-object as it, well, matches. This match object is then
> munged into the optree.
Oh, yes, I re
Rafael Garcia-Suarez wrote:
Joseph F. Ryan wrote in perl.perl6.language :
I think the point of having C as a sub rather than as a separate
syntax is so the parser doesn't have to do anything special for
special keywords.
I think the goal was to simplify the compiler, but with the
discussion o
Joseph F. Ryan wrote in perl.perl6.language :
>
> I think the point of having C as a sub rather than as a separate
> syntax is so the parser doesn't have to do anything special for
> special keywords.
>
> I think the goal was to simplify the compiler, but with the
> discussion of recent weeks, it
Rafael Garcia-Suarez wrote:
Brent Dax wrote in perl.perl6.language :
Yes, I know this means that we have 'else if' instead of 'elsif', but
it's only two more characters and it makes the grammar cleaner.
The tokeniser could send two tokens "else" and "if" whenever it
recognizes the keywor
Brent Dax wrote in perl.perl6.language :
> Yes, I know this means that we have 'else if' instead of 'elsif', but
> it's only two more characters and it makes the grammar cleaner.
The tokeniser could send two tokens "else" and "if" whenever it
recognizes the keyword "elsif" -- so this isn't a probl
Michael Lazzaro wrote:
> Damian Conway wrote:
>
> > "you can leave a comma out either side of a block/closure, no matter
> > where it appears in the argument list"
>
> Hmm. I had been figuring the all conditional/loop stuff would be
> special cases within the grammar, because of their associate
Many people have pointed out the 'semicolon problem' with if and
else--that is, if Perl intuits a semicolon after every codeblock that
ends a blank line, you would have to cuddle all your elses:
if $cond {
...
} <-- Virtual semicolon here
else
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Sunday, January 19, 2003, at 09:51 PM, Luke Palmer wrote:
> >> From: "Sean O'Rourke" <[EMAIL PROTECTED]>
> >> On Sat, 18 Jan 2003, Michael Lazzaro wrote:
> >>> So 'if' and friends are just (native) subroutines with prototypes
>
> >>> like:
>
Michael Lazzaro wrote:
On Sunday, January 19, 2003, at 09:51 PM, Luke Palmer wrote:
From: "Sean O'Rourke" <[EMAIL PROTECTED]>
On Sat, 18 Jan 2003, Michael Lazzaro wrote:
So 'if' and friends are just (native) subroutines with prototypes like:
IIRC it's not that pretty, unfortunately, if you
On Monday, January 20, 2003, at 09:37 AM, Luke Palmer wrote:
Is this magic, or do coderef args construct closures, or what? How do
you avoid evaluating the argument to elsunless() when feeding it to
the
if() sub?
Oops. Good point. In this case I see no way of doing it except for
specifying m
On Sunday, January 19, 2003, at 09:51 PM, Luke Palmer wrote:
From: "Sean O'Rourke" <[EMAIL PROTECTED]>
On Sat, 18 Jan 2003, Michael Lazzaro wrote:
So 'if' and friends are just (native) subroutines with prototypes
like:
IIRC it's not that pretty, unfortunately, if you want to support this:
Tha
> Date: Mon, 20 Jan 2003 09:20:45 -0800 (PST)
> From: Austin Hastings <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
>
>
> --- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > > Date: Sat, 18 Jan 2003 15:07:56 -0800
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > Date: Sat, 18 Jan 2003 15:07:56 -0800 (PST)
> > From: "Sean O'Rourke" <[EMAIL PROTECTED]>
> > Cc: Damian Conway <[EMAIL PROTECTED]>,
> > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > X-SMTPD:
Damian Conway wrote:
> Yes, but will it junctify them con-, dis-, ab-, or in-junctively???
Probably most similar to injunctively. But sequentially. I had been
thinking of something like this:
while ()
{
print "matched $_" if $_ == for(1,2,3,4,5);
}
__DATA__
1
2
9
3
4
5
Like the old bistable
20 matches
Mail list logo
