> Karl Glazebrook wrote:
> > Can we not keep calling them matrices? They are just a special
> > case.
> >
> Normally I call them tensors, but this is only meaningful to a mathematics
> audience.
>
> I was using 'matrix' because both laypersons and mathematicians would know
> what the RFCs are ref
On Sun, 3 Sep 2000, Nathan Torkington wrote:
> Yes. I hadn't envisaged the sheer number of RFCs, and hence the
> traffic on the announcements list.
>
> Perhaps we rename perl6-announce to perl6-announce-rfc, then create a
> new perl6-announce (with all the subscribers of the rfc list) to hold
>
> There is a fundemental issue on how values are passed between
> threads. Does the value leave one thread and enter the other or are
> they shared.
> The idea tossed around -internals was that a value that crosses a thread
> boundary would have a wrapper/proxy attached to handle the mediation.
On Sun, Sep 03, 2000 at 09:22:55PM -0600, Nathan Torkington wrote:
> Simon Cozens is working on a perforce replacement, with some features
> that the pumpkings of perl5 have asked for. If his gets working, I'd
> love to see it integrated into SourceForge.
Its not entirely clear if you're advocat
I've been having difficulties using mail-archive's to search for
discussions on RFCs. The main problem is the search functionality, it
appears to be extremely unsophisticated.
Today I was looking for messages about RFC 6. Searching for 'RFC 6',
'"RFC 6"', 'RFC and 6', and 'RFC && 6' all turne
On Sun, Sep 03, 2000 at 09:05:07PM -0700, Russ Allbery wrote:
> I also think this may well be a good place to apply one of the ideas of XP
> (Extreme Programming, a fairly flexible small-group software design
> methodology), namely to write test cases *first* in many cases before
> writing the cod
On Sun, Sep 03, 2000 at 10:09:00PM -0600, Nathan Torkington wrote:
> True. We're still a ways off needing a place to put code
Speak for yourself, laggard. :P
> (a question for those who have done this before: do these source
> code control systems work equally well for the design and test
> d
Russ Allbery writes:
> I also think this may well be a good place to apply one of the ideas of XP
> (Extreme Programming, a fairly flexible small-group software design
> methodology), namely to write test cases *first* in many cases before
> writing the code, and to seriously consider trying to wr
Michael G Schwern writes:
> Its not entirely clear if you're advocating we wait for this Perforce
> replacement before instituting a cannoical Perl 6 repository, or just
> mentioning it.
Mentioning it, and I had been opening discussion on instituting it.
> If its the former, then as a rule of th
Nathan Torkington <[EMAIL PROTECTED]> writes:
> I picture the design process ending with a breakdown into modules, and
> then a codification of the interfaces between the modules. Then we stub
> the modules, get something that passes the compiler. Now we turn to
> implementation, and begin fill
brian d foy writes:
> i think we should have some sort of end user announcement list. a lot of
> people are being asked to be kept up to date on Perl 6, but they aren't
> the types to want to wade through development discussions or
> announcements.
>
> thoughts?
Yes. I hadn't envisaged the she
Ask Bjoern Hansen writes:
> the perl-qa people have some code they need to manage in a
> repository of some kind. For now I have directed them to
> SourceForge, but I have a 100 users license for perforce I got for
> perl, so if we can get a quick consensus that we might want to make
> a perl6 cod
> There is a fundemental issue on how values are passed between
> threads. Does the value leave one thread and enter the other or are
> they shared.
> The idea tossed around -internals was that a value that crosses a thread
> boundary would have a wrapper/proxy attached to handle the mediation.
I've always liked Perl's demo mode:
perl -demo
:-)
--tom
Have you seen http://search.cpan.org/doc/GREGOR/psh-0.008/doc/psh.pod and
the other tools it references? I haven't used it/them myself - what you
propose has never itched enough for me to scratch it with anything more
than a one-liner - but it appears to have the kind of features you
want. D
the perl-qa people have some code they need to manage in a
repository of some kind. For now I have directed them to
SourceForge, but I have a 100 users license for perforce I got for
perl, so if we can get a quick consensus that we might want to make
a perl6 code infrastructure around perforce th
| Transactions are obviously going to be expensive and complicated,
| which
| is why I suggested implementing them outside the core:
[...]
| That's not quite sufficient for full transactions either. We
| should also allow
| user code to replace the assignment op in the virtual machi
This message on perl5-porters brought an idea to mind:
Paul Marquess <[EMAIL PROTECTED]> writes:
> From: Marc Lehmann [mailto:[EMAIL PROTECTED]]
>> Actually, the perl binary links against waay too many libraries. As a
>> rule of thumb, the perl binary is linked against all libraries any
>> exte
> "MD" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
MD> The way tr/// works is that a 256-byte table is constructed at compile
MD> time that say for each input character what output character is
MD> produced.
Cancel that 256. We have to handle unicode, and I don't know anything
about it
Think of it this way: you're asking that when you write
return WHATEVER;
(for various values of WHATEVER) that *sometimes* it's context
dependent, and sometimes it's not. Right now, it always is,
which is more consistent, predictable, and explainable than the
alternative.
Or maybe you're a
>>> sub fn { return (3,5,7) }
>>> $x = fn;# I want $x==3
>Let me try once more. I want that fn() to act like
> sub fn { my @a = (3,5,7); return @a}
Oh. You want lists to act like arrays. That's a very big change.
>You are letting the scalar context of the caller to bleed through the re
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> I don't want to jam a list into anything. I want it to remain a list.
TC> Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
TC> A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
>> sub fn { return (3,5,7) }
>> $x = f
Perl6 RFC Librarian sent the following bits through the ether:
> Objects : NEXT pseudoclass for method redispatch
I really like this idea: it's quite simple and gets the job done. I'll
throw some AUTOLOAD ideas at London.pm and see what we come up
with... ;-)
Leon
--
Leon Brocard..
>I don't want to jam a list into anything. I want it to remain a list.
Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
> sub fn { return (3,5,7) }
> $x = fn;# I want $x==3
Why should it return the first o
I was wondering, should there be a split between the name and the
contents?
So that
my $a :shared;
my $b;
$b = $a = &fn;
So that access through $a is mediated. Access through $b is "don't do that".
Should perl take on the responsibility of coddling the user?
Perhaps a
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> I don't want that to change. I simply want that return (I'm not sure
>> how to phrase this) be able to return only a scalar or an aggregate.
TC> die unless wantarray;
Okay, I'll admit it, again. I find the changing of a comma in what
On 31 Aug 2000 06:22:10 -, Perl6 RFC Librarian wrote:
>Perl should have a print operator
>Perl supplies an operator for line input - angle brackets. This is no
>analogous operator for output. I propose "inverse angle brackets":
>
>>"Print this line.\n"<;
This is not symmetrical.
For
On Sun, Sep 03, 2000 at 12:42:52PM +0200, Bart Lateur wrote:
> But now you're throwing away the kid with the bathwater.
>
> my Dog $spot;
>
> initially was syntax invented so that $spot was marked as only been ably
> to reference a Dog, with as a result that code internally could be
> opti
On 1 Sep 2000 20:59:10 -, Perl6 RFC Librarian wrote:
>This RFC proposes that the second argument to C be made
>mandatory, and that its semantics be enhanced slightly to cover a
>common, ugly, and frequently buggy usage.
Ooh, how about this alternative.
There must be an RFC making the curren
On 1 Sep 2000 20:59:10 -, Perl6 RFC Librarian wrote:
>When omitted, the second argument to C currently defaults to the
>name of the package from which the call is made.
The word "from" doesn't look like it's been used 100% correctly.
"Being called from" suggests that it's the name af the ca
On Fri, 1 Sep 2000 11:59:15 -0800, Michael Fowler wrote:
>> my Dog $spot;
>> if ($input eq 'Collie') {
>> $spot = Collie->new;
>> } elsif ($input eq 'Dalmation') {
>> $spot = Dalmation->new;
>> }
>>
>> Becuase we're creating two objects when we really only want one.
>
>Yes.
31 matches
Mail list logo
