Dan Sugalski wrote:
At 10:16 PM -0500 12/9/02, Joseph F. Ryan wrote:
Dan Sugalski wrote:
At 5:11 PM -0700 12/9/02, Luke Palmer wrote:
You must remember that the Perl 6 parser is one-pass now.
It is? Are you sure?
It should be;
Doesn't mean it will be. And "should" is an awfully s
At 10:16 PM -0500 12/9/02, Joseph F. Ryan wrote:
Dan Sugalski wrote:
At 5:11 PM -0700 12/9/02, Luke Palmer wrote:
You must remember that the Perl 6 parser is one-pass now.
It is? Are you sure?
It should be;
Doesn't mean it will be. And "should" is an awfully strong word...
--
Dan Sugalski wrote:
At 5:11 PM -0700 12/9/02, Luke Palmer wrote:
You must remember that the Perl 6 parser is one-pass now.
It is? Are you sure?
It should be; the raw parsed data might be treated with regular
expressions in the parse-tree processing stage, but that shouldn't
count as a sec
Adam D. Lopresto wrote:
Looks to me like with a few appropriate methods, you have left-to-right
ordering for free.
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Yes indeed.
Of course, that means that grep and sort and part are all methods of
Dave Whipp wrote:
I like the intent, but I'm not sure about the syntax -- nor the
statement about precidence: seems to me that the pipe operator
needs a very low precidence, not very high.
An existing convention for low precidence versions of operators
is to use an alphabetic name (e.g. || vs
Luke Palmer wrote:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Mon, 9 Dec 2002 23:43:44 +
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Content-Disposition: inline
From: Nicholas Clark <[EMAIL PROTECTED]>
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
On Sun, Dec 08
Brent Dax wrote:
It just occurred to me that C is almost a specialization of
C. Consider the results if you assign without binding:
sub comparator {
when /hi/ { 0 }
when /lo/ { 1 }
default { 2 }
}
@input = qw(high low hi lo glurgl);
@out1 = part comparator @input;
@out2 = sort {
Dave Storrs wrote:
My understanding was that in Perl6, you could use pretty much anything
for a hashkey--string, number, object, whatever, and that it did not
get mashed down into a string. Did I have this wrong?
Not wrong. But it's not the default. The default is Str keys only.
But I take you
Smylers wrote:
I was wondering whether it'd be better to have this specified per
C rather than per C.
I doubt it. There's no performance gain from partial caching since
you have to check the cache anyway to detect that a particular result
isn't cached.
And in those rare cases where you really
Ken Fox wrote:
> Sometimes array references behave as arrays, e.g.
>
> push $array, 1
>
> In flattening context array refs don't flatten, only arrays.
> I'm not even sure that only arrays flatten either -- it might
> be anything that begins with @. e.g.
>
> my Point @p;
> ($x, $y) := @p;
>
>
Smylers wrote:
If the initial release of Perl 6 doesn't have commonly-required
functions then people will write their own. People will do these in
incompatible ways, ensuring that when it's determined that the language
would benefit from having a particular function built in at least some
people
Michael Lazzaro wrote:
I'd suggest if we could do >> (and <<) 'piping' operators
We can't have << because heredocs and <<..>>'s are already using it.
Likewise we can't have >> because of <<..>>.
See my other post on solving the left-to-right (pseudo-)problem.
Damian
At 5:11 PM -0700 12/9/02, Luke Palmer wrote:
You must remember that the Perl 6 parser is one-pass now.
It is? Are you sure?
--
Dan
--"it's like this"---
Dan Sugalski even samurai
On Mon, Dec 09, 2002 at 08:36:20PM -, Smylers wrote:
> Last month's discussion on memoization[*0] had the consensus that
> C is the appropriate property name, used like so:
>
> sub square (Num $n) is cached { ... }
>
> I was wondering whether it'd be better to have this specified per
> C ra
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Mon, 9 Dec 2002 23:43:44 +
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Content-Disposition: inline
> From: Nicholas Clark <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> On Sun, Dec 08, 200
On Sun, Dec 08, 2002 at 03:41:22PM +1100, Damian Conway wrote:
> Nicholas Clark wrote:
> >Well, I was wondering if my function returned "CR", then
> >"\c[$(call_a_func())]" would mean that the "CR" gets run thought the
> >\c[...] conversion and a single byte ("\r") is what ends up in the string.
>
At 8:07 PM + 12/9/02, Smylers wrote:
Perl 6.0.0 can't be perfect, but please can we aim to be as close as
possible. Releasing a language with the caveat "but we've missed out
lots of important functions that we expect to add in the next version or
four" strikes me as a little odd.
I think w
> From: "Me" <[EMAIL PROTECTED]>
> Date: Mon, 9 Dec 2002 17:12:13 -0600
>
> First, I don't think it's necessary to allow
> a variable (or variables) to be anywhere other
> than the front of a chain.
>
> @var = [var|code] >> code >> code;
Agreed.
> Second, it would be nice to allow a pipeline
> suggest using >> instead of -> for now,
> as a placeholder.
I like it as the real thing too. It stands
out better in a line, among other advantages.
>@source >> @out;# 'map' or 'assignment'-like
>@source >> grep { /foo/ } >> @out; # object-method-like
Yes, several
On Mon, Dec 09, 2002 at 02:20:01PM -0800, Austin Hastings wrote:
>
> --- Paul Johnson <[EMAIL PROTECTED]> wrote:
> > On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote:
> > > Ahh. This is better. How does one implement a more sophisticated
> > > cache management strategy?
> > >
> > >
Luke Palmer [mailto:[EMAIL PROTECTED]] wrote:
> By default they're keyed by strings. You can smack a property on them
> to key them by something else, though:
>
> my %sparse is keyed(Int);
> my %anything is keyed(Object); # or UNIVERSAL
Should that be a property of the hash-object, not
> Date: Sun, 8 Dec 2002 21:52:33 -0800
> From: Dave Storrs <[EMAIL PROTECTED]>
>
> On Sat, Dec 07, 2002 at 01:28:41PM +1100, Damian Conway wrote:
> > Dave Whipp wrote:
> >
> > > I notice everyone still want Int context for eval of the block:
> > > Pease don't forget about hashes. Is there such a t
--- Paul Johnson <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote:
> > Ahh. This is better. How does one implement a more sophisticated
> > cache management strategy?
> >
> > That is, what is the mechanism for manipulating the run-time system
> > behavi
Smylers wrote:
Ken Fox wrote:
How about formalizing global namespace pollution with something like
the Usenet news group formation process? Ship Perl 6 with a very
small number of global symbols and let it grow naturally.
If the initial release of Perl 6 doesn't have commonly-required
function
On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote:
>
> --- Adam Turoff <[EMAIL PROTECTED]> wrote:
> > On Mon, Dec 09, 2002 at 08:36:20PM -, Smylers wrote:
> > > Anybody else like this, or are we better off leaving things as they
> > > were?
> >
> > I think you're trying to overo
--- Adam Turoff <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 09, 2002 at 08:36:20PM -, Smylers wrote:
> > Perhaps there are only some edge cases which require calculation;
> > or the function is liable to be called with many invalid input
> > values, which can quickly be determined yield C and so
On Monday, December 9, 2002, at 08:14 AM, Adam D. Lopresto wrote:
Looks to me like with a few appropriate methods, you have left-to-right
ordering for free.
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Hmm. Does operator precedence allow that?
In a message dated Mon, 9 Dec 2002, Adam D. Lopresto writes:
> Looks to me like with a few appropriate methods, you have left-to-right
> ordering for free.
>
> (@foo, @bar) := @a
> . grep { $_ > 0}
> . sort { $^b <=> $^b }
> . part [/foo/, /bar/];
Yes, exactly.
> Of course, that mean
On Mon, Dec 09, 2002 at 08:36:20PM -, Smylers wrote:
> I was wondering whether it'd be better to have this specified per
> C rather than per C. That'd permit something a long the
> lines of:
>
> sub days_in_month(Str $month, Int $year)
> {
>
> }
>
> Perhaps there are only some e
Last month's discussion on memoization[*0] had the consensus that
C is the appropriate property name, used like so:
sub square (Num $n) is cached { ... }
I was wondering whether it'd be better to have this specified per
C rather than per C. That'd permit something a long the
lines of:
sub d
On Sun, Dec 08, 2002 at 09:35:16PM -0800, Dave Whipp wrote:
> is to use an alphabetic name (e.g. || vs or). perhaps the we
> could name this operator C: its vaguely remenicent of the
>
>@out = @in
>pp map { foo }
>pp grep { bar }
>pp sort { $^a <=> $^b }
I like the id
Ken Fox wrote:
> If C is not a method or multimethod, then it acts like a
> reserved word or built-in, like C or C. IMHO that's name
> space pollution.
Yes, it is namespace pollution, but I don't think that's a problem in
Perl.
Many other languages have functions in the same namespace as variab
On 2002-12-06 at 17:59:33, Larry Wall wrote:
> Now all we have to do is
> convince everyone that the year 1 B.C. is the same as year 0 A.D.,
> and 2 B.C. is the same as -1 A.D., and so on.
Well, since that's already true, it hopefully won't take much
convincing. :) If you mean to convince the gen
Michael Lazzaro wrote:
> Of course, we *could* define piping such that the C is not
> necessary:
>
>@source >> /foo/ >> @out;
>
> ... by saying that a regex or closure in a pipe DWYM.
I think I'm against that because it makes it hard for somebody who sees
that in code for the first time to
On Monday, December 9, 2002, at 02:34 AM, Brent Dax wrote:
It just occurred to me that C is almost a specialization of
C. Consider the results if you assign without binding:
Which is why I really wish we had a closure-based syntax similar to
sort, but I grudgingly understand the problems wit
On Monday, December 9, 2002, at 10:37 AM, Michael Lazzaro wrote:
@source >> grep { /foo/ } >> @out;# [5] pure L-to-R
Of course, we *could* define piping such that the C is not
necessary:
@source >> /foo/ >> @out;
... by saying that a regex or closure in a pipe DWYM. Similar to
Looks to me like with a few appropriate methods, you have left-to-right
ordering for free.
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Of course, that means that grep and sort and part are all methods of the Array
class, so the standard way to
On Monday, December 9, 2002, at 01:19 AM, Me wrote:
So, I guess I'm suggesting a binary C<->> that
really is a left-to-right flow/assignment op
so that:
@data
-> grep { $_ > 0 }
-> sort { $^b <=> $^a }
-> part [/foo/, /bar/]
-> @foo, @bar;
does what you'd expect.
I like thi
On Sat, Dec 07, 2002 at 01:28:41PM +1100, Damian Conway wrote:
> Dave Whipp wrote:
>
> > I notice everyone still want Int context for eval of the block:
> > Pease don't forget about hashes. Is there such a thing as
> > 'hashkey context'?
>
> I doubt it. Unless you count Str context.
My understan
Stéphane Payrard wrote:
I would like perl6 to support left-to-right part/sort/grep pipelines.
Left to right syntax is generally good because it facilitates the flow
of reading.
[cut]
Tentative syntax:
... is an left-associative operator that has the same precedence as .
[cut]
example:
@dat
It just occurred to me that C is almost a specialization of
C. Consider the results if you assign without binding:
sub comparator {
when /hi/ { 0 }
when /lo/ { 1 }
default { 2 }
}
@input = qw(high low hi lo glurgl)
On (09/12/02 06:00), Stéphane Payrard wrote:
> Date: Mon, 9 Dec 2002 06:00:40 +0100
> From: Stéphane Payrard <[EMAIL PROTECTED]>
> To: Damian Conway <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Subject: right-to-left pipelines
>
>
> I would like perl6 to support left-to-rig
> > > '->' isn't (in my mind) "a left-to-right
> > > flow/assignment operator." It's a unary
> > > operator, synonymous with "sub" without
> > > parens required around the argument list.
> >
> given $foo -> $_ { ... }
> given $foo sub { ... }
>
> Are all equivalent (if sub topicalizes
In a message dated Mon, 9 Dec 2002, Stéphane Payrard writes:
>
>
> [snipped]
>
> > so it's easy to build up more complex right-to-left pipelines, like:
> >
> > (@foo, @bar) :=
> > part [/foo/, /bar/],
> > sort { $^b <=> $^a }
> > grep
> From: "Me" <[EMAIL PROTECTED]>
> Date: Mon, 9 Dec 2002 02:12:41 -0600
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
>
> > > [regarding -> as a left-to-right pipe-like operator]
> >
> > '->' isn't (in my mind) "a left-to-right
> > flow/ass
> > [regarding -> as a left-to-right pipe-like operator]
>
> '->' isn't (in my mind) "a left-to-right
> flow/assignment operator." It's a unary
> operator, synonymous with "sub" without
> parens required around the argument list.
You seem to be forgetting:
given $foo -> $_
and cousins.
--
r
Luke Palmer writes:
> > Date: Mon, 9 Dec 2002 06:00:40 +0100
> > From: Stéphane Payrard <[EMAIL PROTECTED]>
>
> > Damian:
> > > so it's easy to build up more complex right-to-left pipelines, like:
> > >
> > > (@foo, @bar) :=
> > > part [/foo/, /bar/],
> > > so
47 matches
Mail list logo
