On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote:
> On Tue, 3 Sep 2002, Luke Palmer wrote:
>
> > On Tue, 3 Sep 2002, Brent Dax wrote:
> >
> > > Damian Conway:
> > > # $roundor7 = rx /<+[17]>/
> > > #
> > > # That is: the union of the two character classes.
> > >
> > > How can you be sur
On Tue, Sep 03, 2002 at 09:57:31PM -0600, Luke Palmer wrote:
> On Tue, 3 Sep 2002, Brent Dax wrote:
>
> > Damian Conway:
> > # Neither. You need:
> > #
> > # $roundor7 = rx /<+[17]>/
> > #
> > # That is: the union of the two character classes.
> >
> > How can you be sure that is impl
On Tue, 3 Sep 2002, Luke Palmer wrote:
> On Tue, 3 Sep 2002, Brent Dax wrote:
>
> > Damian Conway:
> > # Neither. You need:
> > #
> > # $roundor7 = rx /<+[17]>/
> > #
> > # That is: the union of the two character classes.
> >
> > How can you be sure that is implemented as a character
>
On Tue, 3 Sep 2002, Brent Dax wrote:
> Damian Conway:
> # Neither. You need:
> #
> # $roundor7 = rx /<+[17]>/
> #
> # That is: the union of the two character classes.
>
> How can you be sure that is implemented as a character
> class, as opposed to (say) an alternation?
What's the d
Damian Conway:
# Neither. You need:
#
# $roundor7 = rx /<+[17]>/
#
# That is: the union of the two character classes.
How can you be sure that is implemented as a character
class, as opposed to (say) an alternation?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embeddin
On Tuesday, September 3, 2002, at 06:12 PM, Dan Sugalski wrote:
> Damian can explain it better than I can, but it's essentially when you
> dispatch based on sub or method signature. You're allowed to have
> multiple versions of a single sub as long as they differ in their
> parameter signatur
Hello All,
Has anyone considered a syntax for allowing subroutines to have many
different names for the same argument? For example, in CGI.pm, many
methods support the "-override" parameter but can also accept the alias
of "-force":
$cgi->hidden(-name => "a", -override => 1); #same as
$cgi->hi
At 5:41 PM -0700 9/3/02, David Wheeler wrote:
>On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote:
>
>>We call that concept "multimethod dispatch". That's what you're asking for.
>
>Dan, can you explain what "multimethod dispatch" is?
Damian can explain it better than I can, but it's
On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote:
> We call that concept "multimethod dispatch". That's what you're asking
> for.
Dan, can you explain what "multimethod dispatch" is?
Thanks!
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTE
At 7:48 PM -0400 9/3/02, Miko O'Sullivan wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
>> How about a JPEG object? Might take a string with the image data, an
>> array with byte data, a filehandle that's got the data to it.
>
>But those situations are all covered by the #= concept:
We call t
> my Date $date .= new('June 25, 2002');
If we're assuming that C creates an C
object, then that object should be able to overload its assignment operator.
I don't know what the perl6 syntax will be, but something along the lines of
class Date
{
method operator= ($value is rx//)
{
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> How about a JPEG object? Might take a string with the image data, an
> array with byte data, a filehandle that's got the data to it.
But those situations are all covered by the #= concept: call the new method
passing the right argument. So for a JPEG th
At 6:03 PM -0400 9/3/02, [EMAIL PROTECTED] wrote:
>From: Dan Sugalski [EMAIL PROTECTED]
>> This will potentially get out of hand quickly
>
>I don't think this is a case where out-of-hand-generalization is necessary.
>I'm only saying that there could be a handy shorthand for a single very
>common
Damian Conway:
# Though I expect he probably will, since treating classes as
# "first class" entities in Perl 6 implies that capability
# (amongst many others).
I fear we're treading a little too close to classes being the "new
filehandles"--relatively limited entities with no sigils that confu
From: Dan Sugalski [EMAIL PROTECTED]
> This will potentially get out of hand quickly
I don't think this is a case where out-of-hand-generalization is necessary.
I'm only saying that there could be a handy shorthand for a single very
common case. Nevertheless, I'll simplify the proposal. Oh, and
On Tue, Sep 03, 2002 at 04:04:13PM -0400, [EMAIL PROTECTED] wrote:
> Looks pretty groovy to me too. It looks like the .=
> operator, no longer being employed as a string appender,
> now means "use the class I just mentioned".
Er, not quite. It's just like the other X= operators:
$a
> On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>
> >> my Date $date .= new('Jun 25, 20002');
> >
> > H. That's a very interesting idea.
> > I like it.
>
> Looks pretty groovy to me too. It looks like the .=
> operator, no longer being employed as a string appender,
> no
At 4:21 PM -0400 9/3/02, [EMAIL PROTECTED] wrote:
>From: Trey Harris [EMAIL PROTECTED]
>> no strict 'refs';
>> my Date $date;
>> $date .= 'Sep 21, 1963';
>>
>> There is a method name there--'Date::Sep 21, 1963'.
>
>But that's my point. You wouldn't have to put the method name or t
Trey Harris wrote:
> In a message dated Tue, 3 Sep 2002, Buddha Buck writes:
>
>>I suspect that, if it makes sense to say
>>
>>$foo = &$date.method;
>>
>>then it would also make sense to say
>>
>>$date .= $foo;
>>
>>as well.
>
>
> Interesting, that first line
> $foo = &$date.method;
>
> I ne
In a message dated Tue, 3 Sep 2002, Buddha Buck writes:
> I suspect that, if it makes sense to say
>
> $foo = &$date.method;
>
> then it would also make sense to say
>
> $date .= $foo;
>
> as well.
Interesting, that first line
$foo = &$date.method;
I need a bit of a refresher here, as my searc
[EMAIL PROTECTED] wrote:
> From: Trey Harris [EMAIL PROTECTED]
>
>>no strict 'refs';
>> my Date $date;
>> $date .= 'Sep 21, 1963';
>>
>>There is a method name there--'Date::Sep 21, 1963'.
>
>
> But that's my point. You wouldn't have to put the method name or the
class
> be
From: Trey Harris [EMAIL PROTECTED]
> no strict 'refs';
> my Date $date;
> $date .= 'Sep 21, 1963';
>
> There is a method name there--'Date::Sep 21, 1963'.
But that's my point. You wouldn't have to put the method name or the class
because the compiler would understand what to ca
In a message dated Tue, 3 Sep 2002, [EMAIL PROTECTED] writes:
> On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>
> >> my Date $date .= new('Jun 25, 20002');
> >
> > H. That's a very interesting idea.
> > I like it.
>
> Looks pretty groovy to me too. It looks like the .=
> o
On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>> my Date $date .= new('Jun 25, 20002');
>
> H. That's a very interesting idea.
> I like it.
Looks pretty groovy to me too. It looks like the .=
operator, no longer being employed as a string appender,
now means "use the cla
On Tue, 2002-09-03 at 11:35, Ken Fox wrote:
> Peter Haworth wrote:
> > Also the different operators used (:= inside the rule, = inside the code)
> > seems a bit confusing to me; I can't see that they're really doing anything
> > different:
> >
> > / $x := (gr\w+) /vs/ (gr\w+) { let $
In a message dated Tue, 3 Sep 2002, Trey Harris writes:
> > So what again is wrong with:
> >
> > my Date $date = 'June 25, 2002';
>
> Nothing--if Date is tieable and implements a STORE method which
> instantiates a new object.
Well, now that I re-read my own comments, I have to retract this, beca
In a message dated Tue, 3 Sep 2002, Garrett Goebel writes:
> Don't the following statements have identical meaning?
>
> my Date $date;
> my Date $date = Date->new();
Not at all. The first declares that $date is a variable containing Date
objects, the second does the same, plus instantiates a ne
From: Damian Conway
> But I must say I now like Adam's
>
> my Date $date .= new('June 25, 2002');
>
> much more than my own proposal.
This thread appears to have wound down, but I'm still a little confused. I
understand the above syntax could be used to pass initialization data to the
con
At 8:48 AM -0600 9/3/02, Luke Palmer wrote:
> > Hmm... I think I'd rather see
>>
>>my $foo is Bag = @array.as('Bag');
>>
>> The idea being that one could treat hashes and arrays as syntactic
>> vitamins meaning 'Dictionary' (to use the Smalltalk term) and
>> 'OrderedCollection', but all Co
Peter Haworth wrote:
> Also the different operators used (:= inside the rule, = inside the code)
> seems a bit confusing to me; I can't see that they're really doing anything
> different:
>
> / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
>
> Shouldn't they both use C< := > ?
Depen
> Hmm... I think I'd rather see
>
> my $foo is Bag = @array.as('Bag');
>
> The idea being that one could treat hashes and arrays as syntactic
> vitamins meaning 'Dictionary' (to use the Smalltalk term) and
> 'OrderedCollection', but all Collections would implement an C
> method allowing conve
On Mon, 2 Sep 2002 23:50:18 -0400 (EDT), Trey Harris wrote:
> In a message dated 2 Sep 2002, Aaron Sherman writes:
> > {
> > my $x = 2;
> > my $y = "The grass is green";
> > $y =~ /(gr\w+) {let $x = $1}/;
> > }
>
> Yes. $0{x} would be set to "grass".
Hi team.,
thanx in advance
Can you provide me a link or a zip file where i can download perl6 or
perl 5.6 for solaris 7 or solaris 8
Would be appreciated..
cheers
venkat
-Original Message-
From: Piers Cawley [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 03, 2002 4:57 PM
To:
Perl6 Summary for the week ending 2002-09-01
Well, it's been a week. Damian came to London and made our heads spin;
perl6-language erupted in a flurry of interesting, high signal/noise
threads; Parrot reached its 0.0.8 release; Larry made many of his
wonderfully unexpected but obvi
Damian Conway <[EMAIL PROTECTED]> writes:
> Uri Guttman wrote:
>
>> but what simon was saying (and i agree) is the the pair IS a single
>> item. it becomes the key and its value is 'scalars'.
>
> No. If it's a PAIR, then its key is the key and its value is the value.
>
>
>> hashes can now take ob
This came up in a discussion on London.pm about Damian's Perl 6 talk,
which led us to wonder about control exceptions and how they're
handled. At the moment, control exceptions fall into the 'vaguely
handwavy' category, and what follows is my attempt to work out how I
think they should behave...
David Whipp <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Maybe we should just say 'sod it' and implement the entire Smalltalk
>> Collection hierarchy and have done with it? Sets, bags, hashes
>> (dictionaries for the Smalltalker), whatever, all have their uses...
>
> I'm not sure if you w
37 matches
Mail list logo
