Trey Harris wrote:
> A more practical application would be:
>
> my $foo;
> # Code which might or might not set $foo...
> $foo //= 23;
> # or
> $foo is default(23);
>
> In such a case, the C just looks plain odd to me.
It is. More than that, it's plain wrong. C properties are
compil
At 11:23 PM -0400 9/4/02, John Porter wrote:
>Dan Sugalski wrote:
>> John Porter wrote:
>> > Some folks seem to think that sufficient reason exists now.
>>
>> That's fine. You don't have to convince some folks. You have to convince me.
>
>Actually, uh, I was kinda hoping that some folks would c
Oops, I seem to have sent this direct to Dan instead of to the list.
Sorry for the duplication, Dan.
On Wed, Sep 04, 2002 at 07:42:24AM -0400, Dan Sugalski wrote:
> At 7:34 AM -0400 9/4/02, John Porter wrote:
> >Sean O'Rourke wrote:
> >> ... I don't see how giving the list a
> >> different name w
On Wed, 4 Sep 2002, Brent Dax wrote:
> Sean O'Rourke:
> # On Wed, 4 Sep 2002, Brent Dax wrote:
> # > What if (say) @b is a two-dimensional array?
> #
> # Then you get "interesting values of undef" :). Seriously, I
> # suspect one of the following:
> #
> # 1 - runtime error
> # 2 - each row (or c
Aaron Sherman:
# Ok, so without knowing what the XS-replacement will look like
# and without knowing what we're doing with
# filehandle-functions (is tell() staying or does it get
# removed in favor of $fh.tell()) and a whole lot of other
I think that sort of thing is going. IIRC, the only b
> sub hidden (str $name, int $force is aka($override))
>{ ... }
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?
sub hidden (str $name, int $force := $override)
{
Oh, BTW: Lest anyone think I'm spamming p6l for no reason, I sent the
Builtins.p6m to p6l instead of p6i because I consider this a document,
not code. When some of the questions get ironed out about the language,
then I will talk to p6i about next steps.
Sean O'Rourke:
# On Wed, 4 Sep 2002, Brent Dax wrote:
# > What if (say) @b is a two-dimensional array?
#
# Then you get "interesting values of undef" :). Seriously, I
# suspect one of the following:
#
# 1 - runtime error
# 2 - each row (or column) of @b numified to its length
# 3 - the first e
Ok, so without knowing what the XS-replacement will look like and
without knowing what we're doing with filehandle-functions (is tell()
staying or does it get removed in favor of $fh.tell()) and a whole lot
of other stuff it's impossible to translate all of the Perl 5 functions
to Perl 6. However,
Somewhere, in another thread . . .
Dr. Claw wrote . . .
>> sub hidden (str $name, int $force is aka($override))
>>{ ... }
>
>Yeah, that's what I meant.
Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem
On Wed, 4 Sep 2002, Steve Fink wrote:
> I tend to create new PMC classes frequently, and they're a pain to
> maintain without committing, because you have to touch lots of files
> to add a PMC, and in ways that are sure to cause conflicts.
Is one of these an intstack PMC, perchance?
/s
[EMAIL PROTECTED] (Dan Sugalski) writes:
[...]
> The logo as currently used suffers from scaling issues, as it looks
> like the full-size one's used with a size specified.
I fixed that. And made it png.
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
> [EMAIL PROTECTED] ?
s/dev/code/, of course.
--
John Douglas Porter
Bryan C. Warnock wrote:
> make things easier for others to get more of a community buy-in, at the
> expense of effort by the Perl folks, but there's no guarantee that those
> people will come.
[EMAIL PROTECTED] ?
--
John Douglas Porter
Dan Sugalski wrote:
> John Porter wrote:
> > But what does Larry think?
>
> Hadn't particularly asked him. Does it really matter?
Not if you say it doesn't.
--
John Douglas Porter
Dan Sugalski wrote:
> John Porter wrote:
> > Some folks seem to think that sufficient reason exists now.
>
> That's fine. You don't have to convince some folks. You have to convince me.
Actually, uh, I was kinda hoping that some folks would convince you. :-)
Anyway, whenever someone (and it see
Thanks, Steve. I agree 100% with everything you said!
Except:
> ... the best way to that
> goal is to use Perl6 as the driver, at least until something else
> shows up, because that's the only way to derive realistic requirements
> for what needs to be accomplished.
The incorrectness of that i
[EMAIL PROTECTED] (Jerome Quelin) writes:
In the works is a new mail setup where we easily can have lists at
other domains and still have them available via nntp etc. At that
point I can create a dev at parrotcode.org list or something like
that. (or when the perl6 people want to work on the int
On Wed, 2002-09-04 at 15:48, Steve Fink wrote:
> I'm actually somewhat surprised at how little Parrot is tied to Perl.
I've no clue whether I agree or not. OT1H, given its origins from the
bosom of Perl, Parrot is surprisingly independent. OTOH, compare where
Parrot is to where it *might* have
At 12:41 PM 9/4/2002 -0400, Andrew Kuchling wrote:
>[Please CC: me on any responses.]
>First reason I don't work on it very much:
>
>1. Frankly, it's not much fun. I can spend my free time writing
>Python code, an environment I like, or I can work in the unfamiliar
>and uncomfortable Parrot build
David Whipp wrote:
> But can I use a non-constant date?
You didn't show us the iso_date rule.
> Obviously we could put the onus on the module writer to write super-flexible
> rules/grammars. But will there be an easy way to force interpolative context
> onto this type of regex-valued subroutine
Dan Sugalski wrote:
> At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>> So, just to clarify, does that mean that multi-dispatch is (by
>> definition)
>> a run-time thing, and overloading is (by def) a compile time thing?
>
> No. They can be both compile time things or runtime things, dependin
On Wed, 4 Sep 2002, Brent Dax wrote:
> What if (say) @b is a two-dimensional array?
Then you get "interesting values of undef" :). Seriously, I suspect one
of the following:
1 - runtime error
2 - each row (or column) of @b numified to its length
3 - the first element of each row/col of @b
4 - t
On Wed, Sep 04, 2002 at 08:07:21PM +0200, Peter Gibbs wrote:
> For anybody who may be interested, the latest news from the
> pirate cave follows.
>
> Recent changes:
> * New aligned memory page allocator
> * Above allocator used for PMC/buffer header arenas and memory
> pool pages; this has al
> Again, it would be nice to be able to flag these to the compiler in a
> rule:
> rule thrice :count { <={.count < 4}> }
> / a? /
> Note that the C would cause the thrice count-rule to be matched
> non-greedily because the regex parser knows that it's a count, not a
> generic rule.
Going
On Wed, Sep 04, 2002 at 10:25:39PM +, Damian Conway wrote:
> Jonathan Scott Duff wrote:
>
> > It seems odd to require two syntactic elements to achieve one semantic.
> > And actually, after looking at A5, that's not what Larry wrote:
> >
> > my $x;
> > / (\S*) { let $
Sean O'Rourke:
# On Wed, 4 Sep 2002, Peter Haworth wrote:
# > Having the iteration done in the bytecode could make this simpler,
# > although at the expense of needing more bytecode.
#
# And fewer temporaries, by translating this:
#
# @a = @b ^+ @c ^+ @d;
#
# into this:
#
# for @a; @b
# New Ticket Created by Kevin Falcone
# Please include the string: [perl #17009]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17009 >
If you start with a clean parrot tree and try to run 'make shared' it
will die becaus
Oh, right. The patch. Here it is.
Index: .cvsignore
===
RCS file: /cvs/public/parrot/.cvsignore,v
retrieving revision 1.19
diff -p -u -a -r1.19 .cvsignore
--- .cvsignore 14 Jul 2002 10:25:55 - 1.19
+++ .cvsignore 4 Sep 20
# New Ticket Created by Steve Fink
# Please include the string: [perl #17008]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17008 >
I tend to create new PMC classes frequently, and they're a pain to
maintain without commi
On Wed, Sep 04, 2002 at 10:34:23PM +, Damian Conway wrote:
> Trey Harris wrote:
> > It should. I think everyone has been proceeding under the assumption that
> > they are. If you use a variable name already defined, then you set both
> > the match object's attribute of the same name (minus t
In a message dated Wed, 4 Sep 2002, Andrew Wilson writes:
> On Wed, Sep 04, 2002 at 03:48:41PM -0500, Jonathan Scott Duff wrote:
> > On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote:
> > > Only augment //= in subroutine declarations, //= would also work.
> > > I love the //= oper
On Wed, Sep 04, 2002 at 03:48:41PM -0500, Jonathan Scott Duff wrote:
> On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote:
> > Only augment //= in subroutine declarations, //= would also work.
> > I love the //= operator, but in the context of sub declarations it's
> > confusing as
Trey Harris wrote:
>>So, each time I use a hypothetical, I have to be concious of which
>>variables are currently in scope? Perl can't help be with this task
>>because how does it know if I meant to hypothetically clobber that
>>lexical or store something in the match object. This is only reall
Dan Sugalski wrote:
>> Dan, can you explain what "multimethod dispatch" is?
>
> Damian can explain it better than I can,
I thought you did a great job!
However, anyone who wants to know more about multiple dispatch
might also like to read:
http://www.samag.com/documents/s=1274/sam050
In a message dated Wed, 4 Sep 2002, Jonathan Scott Duff writes:
> The thread on hypotheticals has caused me to reread that section of A5 a
> few times now and a couple of paragraphs bother me the more I read
> them. I'll just quote the parts that bother me:
>
> ... If a regex sets a hypo
On Wed, Sep 04, 2002 at 05:06:32PM -0400, [EMAIL PROTECTED] wrote:
> Is there a general rule that a property must make sense in all contexts?
Nah, I was just being distracted by work and not thinking clearly
about your default() proposal. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Jonathan Scott Duff wrote:
> It seems odd to require two syntactic elements to achieve one semantic.
> And actually, after looking at A5, that's not what Larry wrote:
>
> my $x;
> / (\S*) { let $x = .pos } \s* foo /
A typo, I believe. He has been very consistent in d
The thread on hypotheticals has caused me to reread that section of A5 a
few times now and a couple of paragraphs bother me the more I read
them. I'll just quote the parts that bother me:
... If a regex sets a hypothetical variable that was declared
with either my or our beforeha
[EMAIL PROTECTED] wrote:
>> sub hidden (str $name, int $force, int $override is aka($force))
>> { ... }
>
>
> Would the following be simpler...?
>
> sub hidden (str $name, int $force is aka($override))
>{ ... }
Yeah, that's what I meant.
Sorry. I've travelled 14,000 miles and given 93
From: Jonathan Scott Duff [EMAIL PROTECTED]
> Oh. You want default() to be synonymous with //= but only in
> subroutine declarations. That seems a tad odd. Why not make it
> synonymous everywhere?
>
> my $foo is default(23); # same as ...
> my $foo //= 23;
Well, for "is default" to DWIM i
On Wed, 4 Sep 2002, H.Merijn Brand wrote:
> On Wed 04 Sep 2002 20:31, "Sean O'Rourke" <[EMAIL PROTECTED]> wrote:
> > And fewer temporaries, by translating this:
> >
> > @a = @b ^+ @c ^+ @d;
> >
> > into this:
> >
> > for @a; @b; @c ; @d -> $a, $b, $c, $d is rw {
> > $d = $a + $b + $c;
On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote:
> Only augment //= in subroutine declarations, //= would also work.
> I love the //= operator, but in the context of sub declarations it's
> confusing as the *only* way to default an argument.
Oh. You want default() to be synon
From: Jonathan Scott Duff [EMAIL PROTECTED]
> Or are you proposing to *only* replace //=? Or are you
> proposing to *only* replace //= in subroutine declarations?
Only augment //= in subroutine declarations, //= would also work.
> What issues did you have with //=? It seems clear and concis
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17007]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17007 >
On Wed, 9 Jan 2002, Andy Dougherty wrote:
> > >For perl5, the main makefile calls (e
On Wed, Sep 04, 2002 at 04:01:50PM -0400, [EMAIL PROTECTED] wrote:
> It was settled a while ago that sub arguments would be defaulted like this:
>
> sub load_data ($version / /=1) {...}
>
> (The space between / and / is on purpose, my emailer has problems if they
> are together) I and a few
On Wed, 2002-09-04 at 07:28, Damian Conway wrote:
> Aaron Sherman wrote:
>
> > Hmm... I had not thought of the copy aspect. Certainly, the code version
> > is more flexible. You could define C<$x> above as anything. For example:
> >
> > / (gr\w+) {let $x = Gr_Thing.new($1)} /
> >
> > Th
It was settled a while ago that sub arguments would be defaulted like this:
sub load_data ($version / /=1) {...}
(The space between / and / is on purpose, my emailer has problems if they
are together) I and a few others had issues with the slash-slash-equals
thing, but were unable to persuad
Or at least I can't get it going. Fixing it's a project for the
interested. (I'd ask Simon but, well, he doesn't do that stuff any
more)
--
Dan
--"it's like this"---
Dan Sugalski
On Wed, 2002-09-04 at 14:38, Jonathan Scott Duff wrote:
> my $x;
> / (\S*) { let $x = .pos } \s* foo /
>
> After this pattern, $x will be set to the ending position of
> $1--but only if the pattern succeeds. If it fails, $x is
> restored to und
I'm actually somewhat surprised at how little Parrot is tied to Perl.
Most of the active developers seem to be working on parrot for its
merits as a VM. Perl6, for me at least, mostly provides evidence that
this isn't just an exercise in intellectual masturbation, as Simon
would say -- there will
On Wed 04 Sep 2002 20:31, "Sean O'Rourke" <[EMAIL PROTECTED]> wrote:
> On Wed, 4 Sep 2002, Peter Haworth wrote:
> > Having the iteration done in the bytecode could make this simpler,
> > although at the expense of needing more bytecode.
>
> And fewer temporaries, by translating this:
>
> @a
In Perl5, I might write:
sub set_date {
my ($self, $date) = @_;
$date =~ /(\d{4})-(\d{2})-(\d{2})/ or croak "bad date format";
@$self{qw/year month day/} = ($1,$2,$3);
}
I could then call:
$foo->set_date('2002-09-04')
In Perl6 I can write:
sub set_date ( $date is rx/
On Wed, Sep 04, 2002 at 11:27:46AM +, Damian Conway wrote:
> This is not what Larry has said previously. He said that only
> binding can be used with C variables and that only C
> variable assignments are undone on backtracking.
It seems odd to require two syntactic elements to achieve one se
On Wed, 4 Sep 2002, Peter Haworth wrote:
> Having the iteration done in the bytecode could make this simpler,
> although at the expense of needing more bytecode.
And fewer temporaries, by translating this:
@a = @b ^+ @c ^+ @d;
into this:
for @a; @b; @c ; @d -> $a, $b, $c, $d is rw {
On Wed, 2002-09-04 at 12:41, Luke Palmer wrote:
> Aaron Sherman wrote:
> > So, for example here are some translations of existing operators:
> >
> > + <={.count > 0}>
> > * <={1}>
> > *? <={1}>?
> > <8> <={.count == 8}># No optimization possible!
>
>
On Wed, Sep 04, 2002 at 06:00:17PM +, Andy Dougherty wrote:
>
> Configure.pl's 'copy_if_diff()' function was actually calling rename()
> and moving the file. The net result was that if you tried to re-run
> Configure.pl, it failed at the MANIFEST check point because
> the config/gen/platfor
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
How does this method affect the non-parameter-based calling scheme? It
looks like it is possible to
For anybody who may be interested, the latest news from the
pirate cave follows.
Recent changes:
* New aligned memory page allocator
* Above allocator used for PMC/buffer header arenas and memory
pool pages; this has allowed removal of the pointer from buffer
headers to their pool header
* C
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17002]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17002 >
Configure.pl's 'copy_if_diff()' function was actually calling rename()
and moving the
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17000]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17000 >
On Sat, 31 Aug 2002, Steven W McDougall wrote:
> parrot t/pmc/perlhash_1.pbc
>
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
Would the following be simpler...?
sub hidden (str $name, int $force is aka($override))
{ ... }
Peter Behroozi wrote:
> Has anyone considered a syntax for allowing subroutines to have many
> different names for the same argument?
If it were allowed, it would probably be done via properties instead:
sub hidden (str $name, int $force, int $override is aka($force)) { ... }
Damian
Jonathan Scott Duff wrote:
> How can you be sure that is
> implemented as a character class instead of being some other arbitrary
> rule? An answer is that perl should know how these things are
> implemented and if you try arithmetic on something that's not a
> character class, it should carp a
Aaron Sherman wrote:
> Hmm... I had not thought of the copy aspect. Certainly, the code version
> is more flexible. You could define C<$x> above as anything. For example:
>
> / (gr\w+) {let $x = Gr_Thing.new($1)} /
>
> The binding version is just a simple, fast version of one special ca
Ken Fox wrote:
>> / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
>>
>>Shouldn't they both use C< := > ?
They should. The second version is a typo. It should be:
/ (gr\w+) { let $x := $1 } /
> Depends on what you want. The "$x :=" in the rule
[Please CC: me on any responses.]
I follow the perl6-internals list through checking the archive, and
noticed Jerome's posting. I wrote the parrot-gen.py script that he
pointed to. Here are my comments on this issue.
(Note that I do not speak for the python-dev gang as a whole, but
AFAIK I'm
Aaron Sherman wrote:
> So, for example here are some translations of existing operators:
>
> + <={.count > 0}>
> * <={1}>
> *?<={1}>?
> <8> <={.count == 8}># No optimization possible!
Could it be done this way?:
@c:=(.)* <( @c == 8 )>
Surely ineffi
On Wed, 2002-09-04 at 09:55, Markus Laire wrote:
> On 4 Sep 2002 at 0:22, Aaron Sherman wrote:
>
> > On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote:
> >
> > > None, I think. Of course, if we ignore internals, there's no
> > > difference bewteen that and "rx / | 1 | 7/".
> >
> > Then, why is
The specific definitions of these terms vary from language to
language. In Java, for instance, a method is said to be
"overloaded" and/or "overridden".
An "overloaded" method is actually two or more methods with the
same name but differing numbers/types of parameters (which Java
calls the "signa
[OSCON has left me way behind in reading my mail, so apologies for the late reply]
On Wed, 14 Aug 2002 16:45:09 -0500 (CDT), David M. Lloyd wrote:
> Here's how I'd expect these expressions to be executed internally, in
> gross pseudocode, ignoring for the moment the multimethod vaporware:
>
> $r
At 8:03 AM -0700 9/4/02, Erik Steven Harrison wrote:
>
>--
>
>On Wed, 4 Sep 2002 07:45:37
> Sean O'Rourke obviated:
>To me a language's grammar, once
>>defined, shouldn't do a lot of changing, internally or otherwise. When
>>was the last time C's grammar changed? Or even gcc's implementation
Just some thoughts (and an idea):
I have found the whole context thing in Perl5 easier to understand when I regard it as
overloading based on the return type. We all know that languages like C, C++ and Java
throw a compile-time error if two function
definitions differ in their return type only
On Wed, 2002-09-04 at 00:22, Aaron Sherman wrote:
> Then, why is there a C<+>? Why not make it C<|>?
>
> $foo = rx/ <||[cde]>|f /
This brings to mind a few big things that have been batting around in my
head about user-defined rules for a while now These things fall out
nicely from A5
--
On Wed, 4 Sep 2002 07:45:37
Sean O'Rourke obviated:
To me a language's grammar, once
>defined, shouldn't do a lot of changing, internally or otherwise. When
>was the last time C's grammar changed? Or even gcc's implementation of
>it?
Granted . . .mostly. Were talking about Perl, the
On Wed, 2002-09-04 at 04:31, Dan Sugalski wrote:
> Can I get a quick show of hands for the folks working on Parrot, even
> peripherally, who *aren't* perl folks?
I am not a perl person. I haven't done much work on parrot, and it seems
that most of what I have done is on hold or up in the air st
On Wed, 4 Sep 2002, Erik Steven Harrison wrote:
> How are we planning on dealing with this, or do the
> implementers consider it a non issue?
Well, to me this is a non-Yet issue, but a very real issue. I'm hoping
that when Perl 6 goes 1.0, the grammar will have seen a lot of testing,
and will be
From: Dan Sugalski
>
> At the moment, how many people outside the tight little club
> actually care about the name of the mailing list? And how
> many more would really care if we changed the name?
Answer: You can hardly require a realistic answer to that question because
you won't know until yo
At 7:31 AM -0700 9/4/02, David Wheeler wrote:
>On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote:
>
>>No. They can be both compile time things or runtime things,
>>depending on the characteristics of the language.
>
>So if it's compile-time for a given language, how is it differen
It seems to me that what I mostly do is wave my arms
about my head with a concern and then stay silent
whenever praise is required. Everyone - consider
yourselves praised :-)
On to the concern (which I am fairly confident someone
will obviate). I've never touched the Perl internals
(and P5P
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote:
> No. They can be both compile time things or runtime things, depending
> on the characteristics of the language.
So if it's compile-time for a given language, how is it different from
the Java concept of overloading?
And will
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>
>From: Ken Fox [EMAIL PROTECTED]
>> Over loading is what C++ has. It is not the same as
>> multi-dispatch. The trouble with over loading is that the
>> compiler uses static (compile-time) type information to
>> select the over loaded method.
From: Peter Behroozi [EMAIL PROTECTED]
> 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":
Yes. See the thread start
On 4 Sep 2002 at 0:22, Aaron Sherman wrote:
> On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote:
>
> > None, I think. Of course, if we ignore internals, there's no
> > difference bewteen that and "rx / | 1 | 7/".
>
> Then, why is there a C<+>? Why not make it C<|>?
>
> $foo = rx/ <||[cde
Dan Sugalski wrote:
> At 7:40 AM -0400 9/4/02, John Porter wrote:
> >
> >Some folks seem to think that sufficient reason exists now.
>
> That's fine. You don't have to convince some folks. You have to
> convince me.
Being ultra-pragmatic, the name change:
- costs nothing
- might make some folks
On Wed, Sep 04, 2002 at 07:42:24AM -0400, Dan Sugalski wrote:
> At 7:34 AM -0400 9/4/02, John Porter wrote:
> >Sean O'Rourke wrote:
> >> ... I don't see how giving the list a
> >> different name will have any real effect ...
> >
> >?
> >
> >It will have a huge psychological effect, at least outs
From: Ken Fox [EMAIL PROTECTED]
> Over loading is what C++ has. It is not the same as
> multi-dispatch. The trouble with over loading is that the
> compiler uses static (compile-time) type information to
> select the over loaded method. This can create subtle
> bugs when people try to re-use code
# New Ticket Created by System Attendant
# Please include the string: [perl #16993]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16993 >
ScanMail for Microsoft Exchange has blocked a file attachment(s).
Place = [EMAIL P
# New Ticket Created by Josef Höök
# Please include the string: [perl #16992]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16992 >
I've noticed that the key patch defunced some function in
multiarray ( somehow replaced
At 7:40 AM -0400 9/4/02, John Porter wrote:
>Dan Sugalski wrote:
> > Once there's sufficient reason, and I'm pretty easy on this, we'll
>> switch to a more neutral look.
>
>Some folks seem to think that sufficient reason exists now.
That's fine. You don't have to convince some folks. You have t
On Wed, 4 Sep 2002, Dan Sugalski wrote:
> Nope. What's more likely is that Parrot will accumulate bits from
> other languages--rather than losing Perl we'll gain Ruby and Python.
> Maybe others too.
Parrot: There's more than one language to do it.
Sorry but I couldn't resist,
Rod
--
"Ope
At 7:36 AM -0400 9/4/02, John Porter wrote:
>Bryan C. Warnock wrote:
>> IANADan, but he's aware of these issues, and is/has been thinking about
>> them.
>
>Fine. But what does Larry think?
Hadn't particularly asked him. Does it really matter?
--
Dan
-
At 1:31 PM + 9/3/02, Kevin Falcone (via RT) wrote:
>Someone asked on IRC this morning about what ICU is. They mentioned
>not finding it in the glossary, so here is an explanation and a link.
Applied, thanks.
--
Dan
--
At 7:34 AM -0400 9/4/02, John Porter wrote:
>Sean O'Rourke wrote:
>> ... I don't see how giving the list a
>> different name will have any real effect ...
>
>?
>
>It will have a huge psychological effect, at least outside our tight
>little club. But if that's only as far as you can see...
Real
Dan Sugalski wrote:
> What's more likely is that Parrot will accumulate bits from
> other languages--rather than losing Perl we'll gain Ruby and Python.
> Maybe others too.
But that doesn't address the real issue, which is --
Are we really serious about enabling other languages to target this
m
Bryan C. Warnock wrote:
> IANADan, but he's aware of these issues, and is/has been thinking about
> them.
Fine. But what does Larry think?
> We're not going to fool anyone that this isn't a Pet Perl Project, and
> while other communities are eyeing us, it's not clear that the amount of
> work
Sean O'Rourke wrote:
> ... I don't see how giving the list a
> different name will have any real effect ...
?
It will have a huge psychological effect, at least outside our tight
little club. But if that's only as far as you can see...
--
John Douglas Porter
At 12:30 PM +0200 9/4/02, Aldo Calpini wrote:
>whoever put the parrot logo on www.parrotcode.org,
>make your penances, because you are in sin!
Sheesh, it's an *image*. Sin's hardly the appropriate word here--it's
not like someone robbed a bank or kicked a nun or something.
>you will find attach
David Wheeler wrote:
> Ah, yes, the same thing exists in Java. I remember, now.
I thought Java only has over loading?
Over loading is what C++ has. It is not the same as
multi-dispatch. The trouble with over loading is that the
compiler uses static (compile-time) type information to
select the o
On Wed 04 Sep 2002 03:47, Richard Soderberg <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Sep 2002, Markus Laire wrote:
>
> > > * the name "perl6-internals" is really too restrictive (but this point has
> > > already been discussed last week).
>
> > Would it be possible to rename "perl6-internals" no
1 - 100 of 105 matches
Mail list logo
