Dan Sugalski wrote:
Could one of the folks working on the perl 6 parser give us a status
update as to where it stands? Which bits of the apocalypses don't
work, and what parts of the regex definiton's not done yet? Things
have stalled a bit, and I'd like to get it going again, and the perl 6
On Wed, 8 Jan 2003, Dan Sugalski wrote:
> Could one of the folks working on the perl 6 parser give us a status
> update as to where it stands?
languages/perl6/README mostly reflects the status with respect to the
language definition of about 4-5 months ago. Differences include:
- IIRC hyper-assi
Mitchell N Charity wrote:
Summary: its slower :-(
:(
Yep
Calculating the flags position in the pool in pobject_lives() and
free_unused_pobjects() takes more time then the smaller cache foot_print
does gain. Two reasons: positions have to be calced twice and cache is
more
I am pleased to announce that LXR has been installed on perl.org to index
the source of parrot and perl5 (additional modules, such as perl6, can be
added as needed).
So, you might be asking: "What is LXR?" LXR is a source-code indexing tool
that was originally developed for the Linux kernel. With
Trey Harris wrote:
I love this.
And any class could override the <~ operator, right?
Right.
I suppose it could be done like arithmetic
overloading, if you define both <~ ("I'm being pointed at from the right")
and ~> ("I'm being pointed at from the left") in your class then Perl will
use wh
The Perl 6 Summary for the week ending 20030105
Hello and welcome to the first summary of 2003, welcome to the future.
This summary covers 2 weeks, but they've been quietish what with
Christmas and the New Year.
So, starting as usual with perl6-internals
A pile of patches to the
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Date: Wed, 08 Jan 2003 12:14:10 +0800
> > From: Damian Conway <[EMAIL PROTECTED]>
> >
> > Can I suggest that an alternative solution might be the following:
> >
> > Suppose Perl 6 had two new very low precedence operators: ~> and <~
> > (a.
Could one of the folks working on the perl 6 parser give us a status
update as to where it stands? Which bits of the apocalypses don't
work, and what parts of the regex definiton's not done yet? Things
have stalled a bit, and I'd like to get it going again, and the perl
6 tests into the standar
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Chris Dutton wrote:
>
> > Given discussions about "hyper" operators in the past, I found this
> > rather interesting in the release notes.
> >
> > http://pike.idonex.com/download/notes/7.4.10.xml
>
> Interesting, but I still feel that vectorized op
At 7:41 PM + 1/8/03, Bernhard Schmalhofer (via RT) wrote:
I have been looking into the possibility of adding complex numbers as PMCs.
When looking at core.ops I was missing some operations, where INT, NUM
and PMC interact.
For addition I found the operations:
add_i_i, add_n_n, add_p_i, add_p_n
Dave Whipp wrote:
Something else springs to mind. Consider the C syntax:
for 1,2,3 ~> foo -> $a { ... }
Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly
ones.
I think I see what
Dave Whipp wrote in perl.perl6.language :
> But with the different precedence. At last, I can assign from a list without
> using parentheses:
>
> @a = 1, 2, 3; # newbie error
> @a <~ 1, 2, 3; # would work
or :
@a <~ 1 <~ 2 <~ 3;
or :
1, 2, 3 ~> @a;
which would be also written as :
Nicholas Clark wrote in perl.perl6.language :
>> Actually I don't think you can define a grammar where two operators have
>> the same precedence but different associativity. Be it a pure BNF
>> grammar, or a classical yacc specification (using the %left and %right
>> declarations).
>
> But that wo
"Buddha Buck" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> and similarly,
>
> $a <~ ...;
>
> is equivalent to
>
> $a = ...;
But with the different precedence. At last, I can assign from a list without
using parentheses:
@a = 1, 2, 3; # newbie error
@a <~
On Wednesday, November 06, 2002, at 11:54 AM, Michael Lazzaro wrote:
> On Tuesday, November 5, 2002, at 11:18 PM, Allison Randal wrote:
> > Since you're interested in the management of the Perl 6 project, I'll
> > let you in on some of it. Let's start with a step back into a bit of
> > history:
>
At 7:29 PM -0700 1/7/03, John Williams wrote:
On Tue, 7 Jan 2003, Dan Sugalski wrote:
>2. There is a primitive "array" type that is promoted to an
>objectified Array class when needed. This would be analogous
>to the int/Int distinction for primitive numbers. This would be
>visible to progra
> Actually I don't think you can define a grammar where two operators have
> the same precedence but different associativity. Be it a pure BNF
> grammar, or a classical yacc specification (using the %left and %right
> declarations).
But that would mean only perl6 could pass perl6, which isn't much
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #19834]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19834 >
Hi,
I have been looking into the possibility of adding complex numbers as PMCs.
At 10:09 PM + 1/7/03, Jim Radford (via RT) wrote:
I found a few typos while reading through the documentation in rx.ops.
Applied, thanks.
--
Dan
--"it's like this"---
Dan Sugalski
Damian Conway wrote:
> [...] <~ and ~>
Michael Lazzaro wrote:
> I too think this idea is fabulous. You are my hero.
I also think this is semantically fabulous but syntactically slightly
dubious. '~' reads 'match' in my book, so I'm reading the operators
as 'match left' and 'match right'. Or p
On Wednesday, January 8, 2003, at 10:39 AM, Chris Dutton wrote:
I would ask, if it's possible to inherit from Array or Hash, is it
possible to inherit from one which has a constrained storage type?
my WeirdHash is int Hash { ... }
Yes, I think that was tentatively confirmed a while back. But
At 6:15 PM -0500 1/6/03, Mitchell N Charity wrote:
+pool_pmc[i] = memalign(ALIGN, SIZE*sizeof(PMC));
This is the only problem--memalign's not universal unless we build
with the malloc we provide.
Have we looked into whether we can mix this malloc with the current
memory allocation sys
Summary: its slower :-(
:(
Calculating the flags position in the pool in pobject_lives() and
free_unused_pobjects() takes more time then the smaller cache foot_print
does gain. Two reasons: positions have to be calced twice and cache is
more stressed with other things, IMHO.
Hm
On Wednesday, January 8, 2003, at 01:32 PM, Michael Lazzaro wrote:
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve C-like behavior:
class MyArray is Array { ... };
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve C-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has t
On Wednesday, January 8, 2003, at 02:17 AM, Damian Conway wrote:
Jonathan Scott Duff wrote:
On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote:
>
Which, in turn, implies that the lines:
my Foo $a; # (1)
my $a is Foo; # (2)
my Foo $a is Foo; # (3)
are all
On Tuesday, January 7, 2003, at 11:20 PM, Damian Conway wrote:
Chris Dutton wrote:
Given discussions about "hyper" operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Interesting, but I still feel that vectorized operat
-Original Message-
Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote:
> Actually I don't think you can define a grammar where two operators have
> the same precedence but different associativity. Be it a pure BNF
> grammar, or a classical yacc specification (using the %left and %right
> decl
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 08, 2003 at 05:14:06PM +0100, frederic fabbro wrote:
> > I'm not even sure how that would parse, though that:
> > @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw;
> > would go like:
> > ( @keep <~ grep /good/ <~ @list )
On Tuesday, January 7, 2003, at 08:14 PM, Damian Conway wrote:
Just when you thougth it was safe to go back on the mailing list,
Damian attempts to resurrect a dead can of worms:
And all because Mike Lazzaro wrote:
OK, but let it be known that the resulting megathread is now _your_
fault, not
Jonathan Scott Duff:
# And that, of course, leads us to sort of "unzip" were mutual
# exclusion is not a requisite:
#
# @list ~| grep length == 1 ~> @onecharthings
# ~| grep [0..29] ~> @numberslessthan30
# ~| grep /^\w+$/ ~> @words
# ~| grep $_%2==0 ~> @e
[EMAIL PROTECTED] (Brent Dax) writes:
> Is that clear enough, or should I say it a little slower?
Clear as it's going to get, I fear.
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
Simon Cozens:
# [EMAIL PROTECTED] (Damian Conway) writes:
# > There are in fact *two* types associated with any Perl variable:
#
# Is there any chance we could make this a little more
# confusing? One or two people still appear to be following you.
I'll make it a little simpler. If A is the typ
Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> Not necessarily. <~ will necessarily need to be right-associative,
> while ~> left, however.
Not sure if you aren't getting this backwards, but anyway I often find
myself confused with right and left.
> It would be logical to give them the same
> prece
--- attriel <[EMAIL PROTECTED]> wrote:
> > I'm not even sure how that would parse, though that:
> > @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw;
> > would go like:
> > ( @keep <~ grep /good/ <~ @list ) ~> grep /bad!/ ~> @throw;
> >
> > which is probably not what i wanted...
>
>
Luke Palmer wrote:
I would, from the descriptions, imagine that:
@keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw;
Would parse as:
@keep <~ grep /good/ <~ @list;
@list ~> grep /bad!/ ~> @throw;
Nope. <~ and ~> only *rearrange* arguments, so if you only type @list
once, you can only
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 8 Jan 2003 10:45:37 -0600
> From: Jonathan Scott Duff <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> Mail-Followup-To: frederic fabbro <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Content-Dispositi
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 8 Jan 2003 11:30:51 -0500 (EST)
> From: "attriel" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
>
> Note 1) This is the second time I'm typing this
> Note 2) Ctr
On Wed, Jan 08, 2003 at 08:31:51AM -0800, Austin Hastings wrote:
>
> --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > @out = @a ~> grep {...} ~> map {...} ~> sort;
> > ...
> > @out <~ sort <~ map {...} <~ grep {...} <~ @a;
For the record, I think this is great.
> Bril
On Wed, Jan 08, 2003 at 05:14:06PM +0100, frederic fabbro wrote:
> I'm not even sure how that would parse, though that:
> @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw;
> would go like:
> ( @keep <~ grep /good/ <~ @list ) ~> grep /bad!/ ~> @throw;
>
> which is probably not wha
Note 1) This is the second time I'm typing this
Note 2) Ctrl-Shift-Capslock apparently closes all current instances of
mozilla ... that was weird
> I'm not even sure how that would parse, though that:
> @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw;
> would go like:
> ( @keep
> From: frederic fabbro <[EMAIL PROTECTED]>
> Date: Wed, 8 Jan 2003 15:26:58 +0100
>
> Can one see it as a shell redirection/pipe? This may sound funny,
> but is the following ok?
>@b <~ @a ~> @c; # @c = @b = @a;
> (@b <~ @a) ~> @c; # same order i guess
Ummm, whe... that de
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> @out = @a ~> grep {...} ~> map {...} ~> sort;
> ...
> @out <~ sort <~ map {...} <~ grep {...} <~ @a;
>
> That way, everything is still a method call, the ultra-low precedence
> of
> <~ and ~> eliminate the need for parens,
# Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED]] wrote:
# frederic fabbro <[EMAIL PROTECTED]> wrote:
# > so one can also:
# >@keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw;
# >
# > is this if valid too?
# >@b ~> @a <~ @c; # push @a, @b, @c;
# > or:@b, @c ~> push @
>>(b) Can <~ and ~> be used at the same time?
>>
>>I'm not entirely sure of what functions take two array params
>>meaningfully, but could we do:
>
> Damian's proposal didn't say anything about array params. If I
> understood him correctly, then this should print "FOO" on standard out:
DOH! All
>Atriel:
>> Damian:
>> Can I suggest that an alternative solution might be the following:
>>
>> Suppose Perl 6 had two new very low precedence operators: ~> and <~
>> (a.k.a. "bind rightwards" and "bind leftwards")
>>
>> @out = @a ~> grep {...} ~> map {...} ~> sort;
>>
>> @ou
> Can I suggest that an alternative solution might be the following:
>
> Suppose Perl 6 had two new very low precedence operators: ~> and <~
> (a.k.a. "bind rightwards" and "bind leftwards")
>
> @out = @a ~> grep {...} ~> map {...} ~> sort;
>
> @out = sort <~ map {...} <~ gre
Steve Fink <[EMAIL PROTECTED]> writes:
> On Jan-04, Leopold Toetsch wrote:
>> Damian Conway wrote:
>>
>> >Piers Cawley wrote:
>> >
>> >>Acknowledgements
>> >
>> >But, of course, modesty forebade him from thanking the tireless Perl 6
>> >summarizer himself, for his sterling efforts wading through
frederic fabbro <[EMAIL PROTECTED]> wrote:
>
> Can one see it as a shell redirection/pipe? This may sound funny,
> but is the following ok?
>@b <~ @a ~> @c; # @c = @b = @a;
> (@b <~ @a) ~> @c; # same order i guess
>
> so one can also:
> @keep <~ grep /good/ <~ @list ~> gre
[EMAIL PROTECTED] (Damian Conway) writes:
> There are in fact *two* types associated with any Perl variable:
Is there any chance we could make this a little more confusing? One or
two people still appear to be following you.
--
You advocate a lot of egg sucking but you're not very forthcoming wi
Damian Conway <[EMAIL PROTECTED]> wrote:
>
> There are in fact *two* types associated with any Perl variable:
>
> 1. Its "storage type" (i.e. the type(s) of value it can hold)
> This is specified before the variable or after an C or C.
> It defaults to Scalar.
>
>
# Damian Conway wrote:
# @out = sort <~ map {...} <~ grep {...} <~ @a;
#
# Or, under a special rule for variables on the LHS:
#
# @out <~ sort <~ map {...} <~ grep {...} <~ @a;
Hello,
Can one see it as a shell redirection/pipe? This may sound funny,
but is the foll
On Tue, 07 Jan 2003 12:21:48 +0100, Rafael Garcia-Suarez wrote:
> Delegation has drawbacks compared to inheritance : you can't use
> a object that delegates to class Foo where an instance of Foo is
> expected.
That sounds more like a problem with the polymorphism implementation than an
argument a
Mitchell N Charity wrote:
The attached patch adds a scheme where:
- gc flags are in the pool, and
- pmc->pool mapping is done with aligned pools and pmc pointer masking.
Observations:
- It's fast. (The _test_ is anyway.)
I did try it and some more in realiter.
Summary: its slower :-(
Ca
Luke Palmer wrote:
> I think this is a big step towards readability. It allows you to put
> whatever part of the expression wherever you want (reminiscent of
> Latin);
You didn't think Perligata was just for *fun*, did you? ;-)
> It's a shame <~ is ambiguous. It's a lexical ambiguity, which ca
> Date: Wed, 08 Jan 2003 12:14:10 +0800
> From: Damian Conway <[EMAIL PROTECTED]>
>
> Can I suggest that an alternative solution might be the following:
>
> Suppose Perl 6 had two new very low precedence operators: ~> and <~
> (a.k.a. "bind rightwards" and "bind leftwards")
>
> Su
> From: Deborah Ariel Pickett <[EMAIL PROTECTED]>
> Date: Wed, 8 Jan 2003 09:42:18 +1100 (EST)
>
> [...] But everybody has to learn Perl once.
I agree with you entirely :)
Luke
John Williams wrote:
I'm still not buying the autoinstantiation argument. All the other
(non-M.L.) threads I have read are requiring
my $a is Foo = .new; # or some such...
Yes. You're confusing auto-instantiation of *implementation type* (good)
with autoinstantiation of *stored value* (bad
Jonathan Scott Duff wrote:
On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote:
>
Which, in turn, implies that the lines:
my Foo $a; # (1)
my $a is Foo; # (2)
my Foo $a is Foo; # (3)
are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1)
doe
Michael Lazzaro wrote:
my int @a;
my @a returns int;
my @a is Array of int;
my @a is Array returns int;
my int @a is Array;
Those lines are all absolutely synonymous, and all declare an array of
integers, right?
Right. (This week, at least ;-)
Likewise, Arrays have methods
Murat Ünalan wrote:
Then i could pray to the god of the camel herdsman, that
my DNA human size(4) ($alpha, $beta, $gamma, $delta)
= ('atgc', 'ctga', 'aatt', 'ccaa');
may be activated through perl6 custom parser options 8-)
*Any* consistent syntax may be activat
Christian Renz wrote:
Now, I might be stupid, but I keep asking myself what you would need a
property for in this example.
Yes. It's important to remember that the shiny new hammer of properties
is not necessarily the appropriate tool to beat on *every* problem. :-)
Damian
One of the wise may override my evaluation,
Or I could do it. ;-)
Can the type of a variable vary independenty of its value?
My understanding is that the type of a variable merely restricts the type
of value you can assign to it. (Well, it probably does more, but I'm not
clear on what or h
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Absolutely. It makes things generally faster and easier for perl, and
> doesn't affect python or ruby. Yeah, I know, immutable values make a
> number of static compilation things better with sufficient engineering
> resources, but we're not particularly st
In a message dated Wed, 8 Jan 2003, Damian Conway writes:
> That way, everything is still a method call, the ultra-low precedence of
> <~ and ~> eliminate the need for parens, and (best of all) the expressions
> actually *look* like processing sequences.
I love this.
And any class could override
Chris Dutton wrote:
Given discussions about "hyper" operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Interesting, but I still feel that vectorized operators give more flexibility.
For example, I'm struggling to see ho
Just when you thougth it was safe to go back on the mailing list,
Damian attempts to resurrect a dead can of worms:
And all because Mike Lazzaro wrote:
> Honestly, I still don't see what's so evil about R2L as:
>
>@out = sort given map {...} given grep {...} given @a;
A few things.
First, C
67 matches
Mail list logo