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 6:58 PM -0500 12/9/02, David Robins wrote:
On Mon, 9 Dec 2002, Dan Sugalski wrote:
At 12:27 AM + 12/7/02, Alex Gough wrote:
>That is to say, in "if ( !exp1 ) { ... }", !exp1 merely has to be true
>or false, while $foo = !exp1 leaves !exp1 needing to be all manner of
>things.
D'oh! N
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
At 9:58 AM -0800 12/9/02, Steve Fink wrote:
On Dec-09, David Robins wrote:
If I may be so bold as to say it, maybe the PMC design shouldn't be closed
just yet.
I don't think it is. I may be wrong, but I think the only thing Dan
was trying to close was the internal structure of PMCs, not the e
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
At 7:55 PM -0800 12/8/02, Steve Fink wrote:
I've gotten tired of endlessly clicking on tinderbox links to try to
figure out what's generally going wrong, so I made my computer do it
for me. Yes, I should have just made a script that runs on the
tinderbox machine or something instead of parsing Dat
> 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 Mon, 9 Dec 2002, Dan Sugalski wrote:
> At 12:27 AM + 12/7/02, Alex Gough wrote:
> >That is to say, in "if ( !exp1 ) { ... }", !exp1 merely has to be true
> >or false, while $foo = !exp1 leaves !exp1 needing to be all manner of
> >things.
>
> D'oh! Now it's obvious.
> I've been conflating th
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
If memory serves me right, Dan Sugalski wrote:
> What I'd like is for folks to take the next day or three to think of
> the things that they need parrot to do that aren't working or
> designed yet, and throw them at the list. (Try against the latest
> CVS, just to make sure that it's not gotten
At 6:30 PM +0100 12/4/02, Jerome Quelin wrote:
On Mardi 3 Décembre 2002 23:24, Nicholas Clark wrote:
The perl foundation was able to provide some grants towards work on
this project and perl6. However, fund raising wasn't sufficient to
keep grants going full time.
About two months ago, I ask
At 4:45 PM + 12/5/02, Leon Brocard wrote:
Leon Brocard sent the following bits through the ether:
Now to get the hand of the signatures...
Ah, well, I gave up on SDL as it was a little complicated. Instead, I
played with curses. Please find attached a cute little curses life
program load
While some folks have been putting in heroic effort (thanks Leo!)
things have been languishing a bit. That's my fault, I've not been
getting things moving as I should. So, I'm working on compiling a
list of things that need doing, both within the realm of the current
design and outside it.
Wha
At 12:27 AM + 12/7/02, Alex Gough wrote:
That is to say, in "if ( !exp1 ) { ... }", !exp1 merely has to be true
or false, while $foo = !exp1 leaves !exp1 needing to be all manner of
things.
D'oh! Now it's obvious.
I've been conflating the two, which is wrong.
The get_bool vtable method is
I've only been following IMCC activity from a distance, so this might
be a useless comment, but...
When IMCC does any sort of optimization, it needs to be careful to
not optimize away fetches that we actually have to have. (Perhaps an
attribute on fetches that are required, for example) We don'
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
On Sun, Dec 08, 2002 at 07:55:01PM -0800, Steve Fink wrote:
> glastig, drinky-drinky, and one of the frivolous configurations (?)
> need to have their checkouts blown away, or just have their
> parrot/languages/CVS/Entries file edited to delete the D/brainfuck
> line.
For good measure, I wiped
Call for help: can anyone with a Tru64 machine take a look the test
failures? They aren't crashing, but they're getting the wrong values
out of multidimensional array accesses.
On Dec-09, David Robins wrote:
> If I may be so bold as to say it, maybe the PMC design shouldn't be closed
> just yet.
I don't think it is. I may be wrong, but I think the only thing Dan
was trying to close was the internal structure of PMCs, not the exact
implementations. I think there are alrea
Venables, Robin (via RT) wrote:
# New Ticket Created by "Venables, Robin"
# Please include the string: [perl #18987]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18987 >
Thanks for reporting,
will be included in the upc
I will start $subject soon. This will generate a lot of changes in CVS.
The basic common structure will be a Parrot Object or PObj for short.
To get there, the first step will be hiding affected structure members
inside some accessor macros and unification of PMC/Buffer flags.
(When this is done
# New Ticket Created by "Venables, Robin"
# Please include the string: [perl #18987]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18987 >
Hi
Trying to make IMCC gives the following error on AIX 4.3.3 with IBM's C
compile
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
The next upcoming change in imcc will fix the until yet not "carved in
stone" rules:
global labels MUST start with an underscore
local labels SHOULD NOT start with an underscore
global labels are subject to address fixup, which is done for subroutine
calls (bsr) and for the "set_addr" op, but n
On Sat, 7 Dec 2002, Alex Gough wrote:
> [Fri, Dec 06, 2002 at 05:01:21PM -0500: Dan Sugalski]
> > >- have not P0, P1 set P0 to $1->get_bool ? true : false
> >
> > Sure, that works. I can't think of a good reason to have PMCs be able
> > to return something fancier than true or false when
> 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
On Fri, 6 Dec 2002, Dan Sugalski wrote:
> At 5:47 PM -0500 12/3/02, David Robins wrote:
> >Adding an extra knob doesn't seem like all that good a solution (seems
> >you'd run into weird issues, like a boolean PMC that was both true and
> >false at the same time, or an undef value that was tru
> > [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
66 matches
Mail list logo
