Re: RFC 114 (v2) Perl resource configuration

"Greg Rollins" <[EMAIL PROTECTED]> writes: > Would the rc support module loading? In other words, a sysadmin might want > to give access to certain Perl modules to his/her users, and not to other > users. That's the only use I can think of for dynamic Perl config. BTW, > it's not something I'm

Re: Perl 6 announcement list

John Porter 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. > > Isn't there a perl-announce

Re: RFC 178 (v1) Lightweight Threads

I think we are talking about the same issues, but we can't seem to get in sync on the terminology. I'm going to try to get off the merry-go-round by recapitualting the two approaches. RFC178 - globals are shared unless localized - file-scoped lexicals are shared by all code in the file - block-s

Re: RFC 129 (v1) Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN

*finally* getting around to answering these... ;-) Jon Ericson wrote: > > This is not strictly true. <> is shorthand for . ARGV is the > special filehandle that opens each file in @ARGV. If @ARGV is empty, > $ARGV[0] is set to '-'. Thanks for the clarification. > @ARGV = ('filename'); >

Re: RFC 193 (v1) Objects : Core support for method delegation

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: PRL> use Class::Delegation >> >> shouldn't that be use delegation? i think you have a cut and paste >> error. DC> You're correct. Many thanks. DC> (That's what I get for pre-testing all the code in my RFCs! ;-) heh, you should

Re: RFC 178 (v2) Lightweight Threads

> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes: PRL> All threads see the same compiled subroutines >> >> Why? Why not allow two different threads to have a different view of >> the universe? SWM> 1. That's how it works in compiled languages. You have one .exe, and SWM> all threads

Re: Perl 6 announcement list

Nathan Torkington wrote: > 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. Isn't there

Re: RFC 178 (v1) Lightweight Threads

> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes: >> Single thingee access mediation, should be done automatically by perl. >> The multi-thingee complex mediation should have the user step in, since >> solving it (correctly and efficiently) is a complex problem. SWM> I'm not sure we

Re: Profiling

On Sat, Sep 02, 2000 at 07:22:08PM +, Nick Ing-Simmons wrote: > > This is from a perl5.7.0 (well the current perforce depot) compiled > with -pg and then run on a smallish example of my heavy OO day job app. > > The app reads 7300 lines of "verilog" and parses it with (tweaked) Parse-Yapp >

Re: RFC 178 (v1) Lightweight Threads

> Single thingee access mediation, should be done automatically by perl. > The multi-thingee complex mediation should have the user step in, since > solving it (correctly and efficiently) is a complex problem. I'm not sure we have a common understanding of the terms we are using. Can you give som

Re: RFC 178 (v2) Lightweight Threads

What I'm trying to do in RFC178 is take the thread model that you get in compiled languages like C and C++, and combine it with the Perl5 programming model in a way that makes sense. There may be reasons not to follow RFC178 in Perl6. Maybe - it's too hard to implement - there are performance pr

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword toforcelist context (like C))

I know I just promised to be quiet... but I realized something really important. If the first arg returned from want() isn't the context, then this: > In Perl 6 we switch with Ces, mister! ("Muro volente", of course ;-) > > switch (want) { > case 'LIST' { do_list_stu

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC175 (v1) Add C keyword toforcelist context (like C))

> If I said that, I was mistaken. It will always return false because > the first return value from C is an expectation count, so: Ok, here's your email cut-and-pasted, because I can't find it in the frikkin' archives and I think it's worth re-visiting: Damian Conway wrote: > >> Nathan Wige

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

Michael G Schwern wrote: > > >print < > This still leaves the problem of having to count whitespace and having > to change your regex if you reindent your code. In effect, it causes > whitespace to become significant. Bleh. How is this different from having to count the number of spaces y

Re: RFC 188 (v1) Objects : Private keys and methods

On 1 Sep 2000, Perl6 RFC Librarian wrote: > Private entries of hashes could be I accessed in packages > that inherit from the entry's package, by qualifying (i.e. prefixing) the > key with the entry's package name. For example: > > package Base; > > sub new { >

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

>This still leaves the problem of having to count whitespace and having >to change your regex if you reindent your code. In effect, it causes >whitespace to become significant. Bleh. It's much better to use the Cookbook method: it stands out better. Please observe. --tom

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword toforcelist context (like C))

> > The LIST/SCALAR/VOID distinction is always the second value returned > > (see the examples in the RFC). So your dispatcher is: > > > > my $func = lc (want)[1] . "_func"; > > return &$func(@_); > > I think I'd much rather it be the first. This seems to jiv

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

On Mon, Sep 04, 2000 at 05:36:32PM -0700, Nathan Wiger wrote: > Actually, the two started merged. :-) They were split up after there > were too many people for RFC 111 but against RFC 162. Personally, I'd > rather see the recipe method of: > >print < > I can't think of much else I'd want to c

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

Michael G Schwern wrote: > > The RFC proposes a <<< operator which would strip whitespace off the > front of the here-doc. Problem is preserving indentation. We can > merge the two. Actually, the two started merged. :-) They were split up after there were too many people for RFC 111 but agains

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword toforcelist context (like C))

Damian Conway wrote: > > The LIST/SCALAR/VOID distinction is always the second value returned > (see the examples in the RFC). So your dispatcher is: > > my $func = lc (want)[1] . "_func"; > return &$func(@_); I think I'd much rather it be the first. This seems to jive much more

Re: RFC 178 (v2) Lightweight Threads

> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> All threads see the same compiled subroutines Why? Why not allow two different threads to have a different view of the universe? PRL> All threads share the same global variables _All_ or only as requested by the user (ala :sha

Re: RFC 188 (v1) Objects : Private keys and methods

> Will "private" be a true scoping keyword? Or under strict would you have > to do this: > >private my %hash; It's not a replacement for C, though C *might* choose to overlook it. :-) Damian

Re: RFC 193 (v1) Objects : Core support for method delegation

On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote: > Objects : Core support for method delegation I like it! One gripe (of course)... > The proposed delegation mechanism would work via a pragma: > > use delegation > attr1 => [qw( method1 method2 method3 )

Re: RFC 136 (v2) Implementation of hash iterators

> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> =head2 Freezing state for keys and values efficiently PRL> I believe this problem can be solved by using the vtable for the PRL> hash to wrap any mutating functions with a completion routine that PRL> will advance the iterator t

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword toforce list context (like C))

> By RFC 21, it looks like the call would be > >if ( want 'LIST' ) { > $num_to_return = want; > # do stuff >} or, more efficiently: if ( ($num_to_return) = want 'LIST' ) { # do stuff } > However, at one time the discussion ha

Re: RFC 178 (v1) Lightweight Threads

> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes: SWM> All I want the language to guarantee is internal thread-safety. SWM> Everything else is the user's problem. Somehow I would have thought that goes without saying. But I don't agree that all the rest is a user issue, is too short

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

On Mon, Sep 04, 2000 at 09:32:00PM -, Perl6 RFC Librarian wrote: > Perl6 should ignore any whitespace before the terminator of a heredoc on any > line. Good. I don't see anything wrong with this. ***BRAIN STORM!*** RFC 162 (http://dev.perl.org/rfc/162.html) wanted to allow indented here-d

Re: RFC 188 (v1) Objects : Private keys and methods

> private $hash{key}; > private $hash{$key}; > private $hashref->{key}; > > or to a hash slice: > > private @hash{qw(_name _rank _snum)}; > > or to a complete hash (either directly, or via a reference): > > private %hash; > private { _name => "de

Re: Quantum computing

Steve Fink uddered: > Can't quite run perl yet. Not for lack of trying. ftp://cpan.valueclick.com/CPAN/authors/id/D/DC/DCONWAY/Quantum-Superpositions-1.03.tar.gz -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant

Re: RFC 192 (v1) Undef values ne value

On Mon, Sep 04, 2000 at 09:52:19PM -, Perl6 RFC Librarian wrote: > Perl winges if you compare an undefined value. This is silly and one often > has to test for the undefined case (and the empty case for == and !=), then > the equality that the programs logic calls for. If you leave warnings

Non-inheritable and cascading methods

All- I've been toying with this for a while, and I'm looking for others' input. I'm not RFC'ing it yet because (a) I already have 25 others to maintain and (b) I'm not sure if this might be covered by "my sub" or one of Damian's future RFC's. Currently, there are two big problems in defining sub

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword toforce list context (like C))

Damian Conway wrote: > > That's indeed precisely what I meant. In fact, all list-returning built-ins > ought to be optimized this way. I think we're pretty much agreed on this point, but I have a tangential question about want(). By RFC 21, it looks like the call would be if ( want 'LIST' )

Working Group Summaries online

http://dev.perl.org/summary/ Each established list/working group has a spot on this page. Weekly/Bi-weekly summaries will be posted as they arrive. Currently, only the two summaries from last week (Aug 31) are online. Earlier summaries will be posted as I find them in the archives (

Re: Message ID's?

On Mon, 4 Sep 2000, Bart Lateur wrote: > My suggestion, plain and simpl: add a custom header with the > assigned message ID. it's in the envelope sender which all decent delivery agents will put in some header for you. (commonly the Return-Path header). - ask -- ask bjoern hansen -

Re: RFC 193 (v1) Objects : Core support for method delegation

> PRL> One powerful application of delegation is as a replacement for > PRL> inheritance where the internals of a prospective base class are > PRL> inaccessible or inconvenient, or the base class was not designed > PRL> to be inherited and yet it must be. > > isn't this

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

> >Should be part of the want() context. > > It is. I interpreted Damian's remark to mean that it would be good if > readline() took advantage of it, and that should be RFC'ed. That's indeed precisely what I meant. In fact, all list-returning built-ins ought to be optimized this wa

Re: RFC 114 (v2) Perl resource configuration

Would the rc support module loading? In other words, a sysadmin might want to give access to certain Perl modules to his/her users, and not to other users. That's the only use I can think of for dynamic Perl config. BTW, it's not something I'm against, I'm just trying to find a way I could use

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

> Damian, I think it would be worth at least mentioning BLESS and REBLESS > in an "Alternative Names" section in the RFC. Enough people have voiced > concerns over this that I think these two are worth putting in there. As I mentioned in another message, I'll be doing that. > The

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

In message <[EMAIL PROTECTED]> Nathan Torkington <[EMAIL PROTECTED]> wrote: > Peter Scott writes: > > >> ($a, $b, $c) = ; > > >> or > > >> @a[4,1,5] = ; > > >> only read three lines? > > > > > >I think this is a superb idea, and look forward to someone's RFC'ing

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

> Given that is happens when bless is called and that all other builtin > methods are anmed after what is being called, not what it is being used > for, then I would say that it should be called BLESS for consistancy reason. > > this may seem confusing because you are thinking of o

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

Jeremy Howard wrote: > > The problem with making these builtins respect the number of return values > context in want() is that, as Nate mentions, the expressions may have > side-effects that are desired for the whole list. > > An alternative approach is to make these builtins respect lazy(), as

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

Nathan Wiger wrote: > Tom Christiansen wrote: > > > > Ever consider then having > > > > ($a, $b, $c) = ; > > or > > @a[4,1,5] = ; > > > > only read three lines? I mean, how many if any builtins would it > > make sense to make aware of this, and do something "different"? > > Personally, I

Re: RFC 193 (v1) Objects : Core support for method delegation

> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> One powerful application of delegation is as a replacement for PRL> inheritance where the internals of a prospective base class are PRL> inaccessible or inconvenient, or the base class was not designed PRL> to be inherit

Re: RFC 192 (v1) Undef values ne value

>If you compare a variable that is undefined with something, perl winges. Perl never whinges unless you turn on warnings. >An undefined value is not equal to a string, it should do the right thing. Comparing the undefined value against something else--that is, using undef as though it were real

RFC 193 (v1) Objects : Core support for method delegation

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects : Core support for method delegation =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 4 September 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 193 Status: De

RFC 192 (v1) Undef values ne value

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Undef values ne value =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 4 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 192 Status: Developing =head1 ABSTRACT

RFC 184 (v2) Perl should support an interactive mode.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl should support an interactive mode. =head1 VERSION Maintainer: Ariel Scolnicov <[EMAIL PROTECTED]> Date: 31 Aug 2000 Last Modified: 3 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 2 Num

RFC 178 (v2) Lightweight Threads

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Lightweight Threads =head1 VERSION Maintainer: Steven McDougall <[EMAIL PROTECTED]> Date: 30 Aug 2000 Last Modified: 02 Sep 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 178 Status:

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

I think it should be made explicit what happens if the here doc terminator itself contains comment characters or semicolons. This is my suggestion: The here doc terminator must match as a string (that is, C should match the line, where $term is the desired terminator. Otherwise the behaviour o

RFC 136 (v2) Implementation of hash iterators

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Implementation of hash iterators =head1 VERSION Maintainer: Tom Hughes <[EMAIL PROTECTED]> Date: 20 Aug 2000 Last Modified: 4 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 2 Number: 136 St

RFC 130 (v5) Transaction-enabled variables for Perl6

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Transaction-enabled variables for Perl6 =head1 VERSION Maintainer: Szabó, Balázs <[EMAIL PROTECTED]> Date: 17 Aug 2000 Last Modified: 02 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 5 Numbe

RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Here Docs Terminators (Was Whitespace and Here Docs) =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 16 Aug 2000 Last Modified: 2 Sep 2000 Mailing List:

RFC 110 (v4) counting matches

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE counting matches =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 16 Aug 2000 Last Modified: 2 Sep 2000 Version: 4 Mailing List: [EMAIL PROTECTED

RFC 52 (v3) List context return from filesystem functions

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE List context return from filesystem functions =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 6 Aug 2000 Last Modified: 3 Sep 2000 Mailing List: [EMAIL PROTECTED

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

Chaim Frenkel wrote: > > Strange thought just crossed my mind. > > Would having a time object that is understood by perl be sufficient? > It would smell and taste like an integer but would otherwise be > magical. This is something that should be easily doable if RFC 73, "All Perl core functions

Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go

>package main; >sub fn { return (3, 5, 7) } >tie $x, 'MaiTai'; >$x = fn; >$ /tmp/foo >STORE: 7 >Why don't I see three STOREs? Because Perl is too clever to bother. :-) --tom

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

At 11:54 AM 9/4/00 -0700, Nathan Wiger wrote: > > Seems a bit rare and unimportant -- until one observes how this > > would also solve the problem of people being confused by this > > gobbling up their handle: > > > > my($line) = ; > >And a nice side effect too. As Peter says, the only problem

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

Graham Barr wrote: > > Given that is happens when bless is called and that all other builtin > methods are anmed after what is being called, not what it is being used > for, then I would say that it should be called BLESS for consistancy reason. > > this may seem confusing because you are thinki

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

Tom Christiansen wrote: > > Ever consider then having > > ($a, $b, $c) = ; > or > @a[4,1,5] = ; > > only read three lines? I mean, how many if any builtins would it > make sense to make aware of this, and do something "different"? Personally, I think this would be really cool; stuff l

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

On Mon, Sep 04, 2000 at 10:25:37AM +0100, Piers Cawley wrote: > Maybe a compromise along the lines of: > >my Dog $spot = LIST; # $spot = Dog->new(LIST) >my Dog $patches; # $patches is undefined but we assert that > # it'll be a Dog. (Whether you can do >

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

Well, unless there are any wildly different points someone hasn't mentioned until now, I'm going to freeze this RFC as it is (with a few minor tweaks). Various alternate syntaxes have been suggested, but I still rather like mine. Let Larry do with it what he will. Hopefully he can take somethin

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

On Mon, Sep 04, 2000 at 10:34:37AM +0100, Piers Cawley wrote: > >> Well then, that's one nay vote. :) > > > > Make that two. > > Three. But I think Michael already knew about mine and forgot to count > it. Heh, I am not counting votes. That was simply me acknowledging his dislike for the

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

At 10:52 AM 9/4/00 -0600, Nathan Torkington wrote: >Peter Scott writes: > > >> ($a, $b, $c) = ; > > >> or > > >> @a[4,1,5] = ; > > >> only read three lines? > > > > > >I think this is a superb idea, and look forward to someone's RFC'ing it. > >Should be part of the want() c

Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go

At 06:49 AM 9/3/00 -0600, Tom Christiansen wrote: > > sub fn { return (3,5,7) } > > $x = fn;# I want $x==3 > >Why should it return the first one? It returns the last one! >It's just doing what you told it, which was: > > $x = 3; > $x = 5; > $x = 7; It does? What

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

Peter Scott writes: > >> ($a, $b, $c) = ; > >> or > >> @a[4,1,5] = ; > >> only read three lines? > > > >I think this is a superb idea, and look forward to someone's RFC'ing it. Should be part of the want() context. Permit operations to discover (as does split) how many el

Re: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

At 11:48 AM 9/3/00 +1100, Damian Conway wrote: >> Ever consider then having >> >> ($a, $b, $c) = ; >> or >> @a[4,1,5] = ; >> >> only read three lines? > >I think this is a superb idea, and look forward to someone's RFC'ing it. I like it too. Anyone working on

Re: RFC 178 (v1) Lightweight Threads

> SWM> Question: Can the interpreter determine when a variable becomes > SWM> shared? > SWM> Answer: No. Then neglecting to put a :shared attribute on a shared > SWM> variable will crash the interpreter. This doesn't seem very Perlish. > Err, no. It won't crash the interpreter. It'll make the sc

Re: RFC 184 (v1) Perl should support an interactive mode.

Peter Scott <[EMAIL PROTECTED]> writes: > 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 a

Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go

> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> You will be miserable until you learn the difference between TC> scalar and list context, because certain operators know which TC> context they are in, and return a list in contexts wanting a TC> list, but a scalar val

Re: List generation (was Re: PDL-P: No status field for Perl6 RFC 115 )

"Jeremy Howard" writes:- > Yes, I like it too, but the problem is that $end may not be reached: > > @weird = (0..5: ^0 mod 2); > > is an infinite loop under this proposal. That's not necessarily a dead-end, > but it seems pretty dangerous. Like for (;;) ? Or 1:11:-1 ! > The $num_steps pro

Re: code repository

Ask Bjoern Hansen wrote: > 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

Re: functions that deal with hash should be more liberal

> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes: NT> Casey R. Tweten writes: >> Wow. Now that, that, is lame. You're saying that keys() expects >> it's first argument to begin with a %? Why should it care what it's >> argumen begins with? NT> The keys function changes its arguments

Re: RFC 178 (v1) Lightweight Threads

> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes: >> Aha, I get it. -internals has been assuming that one _must_ specify >> the sharing. You want it to be infered. >> I think that's asking for too much DWIMery. SWM> Question: Can the interpreter determine when a variable becomes SWM

Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go

>Then please explain why scalar(return (1,2,3)) doesn't do what at first >glance it seems it should. Because X(Y) != Y(X). You should have written "return scalar" if you wanted to return a scalar. >And for the life of me I can't see how > $x=(1,2, (3,4,fn,6) ) >fn ends up in scalar co

Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go

> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> Oh. You want lists to act like arrays. That's a very big change. Do you have any objection? The intended avoidance of flattening to as late as possible might have that effect. >> You are letting the scalar context of the caller to

List generation (was Re: PDL-P: No status field for Perl6 RFC 115 )

Robin Williams wrote: > "Jeremy Howard" writes:- > > > The first version of this > > RFC had a > > > > @start..$end:&gen > > > > but it just seems too dangerous, so I removed it. I'm still willing to be > > convinced though... > > as well as @start..&gen:$num_steps ? Yes, I'd agree you'd have

Re: PDL-P: No status field for Perl6 RFC 115

[EMAIL PROTECTED] wrote: > Jeremy Howard wrote: > > > > > C<;> is particularly useful for creating slices of multidimensional arrays: > > > > my int @array = ([1,2,3], > >[4,5,6], > >[7,8,9]); > > @col2 = @array[(0..2); 1]; # @array[[0,1],[1,1],[2,1

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

On Mon, Sep 04, 2000 at 11:09:18AM +0100, Piers Cawley wrote: > Damian Conway <[EMAIL PROTECTED]> writes: > > >> But I've gotta nitpick the name. I wonder if BLESS wouldn't be better? > >> print calls PRINT, printf calls PRINTF, even if the subs don't do any > >> printing. Sure makes

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

Damian Conway <[EMAIL PROTECTED]> writes: >> But I've gotta nitpick the name. I wonder if BLESS wouldn't be better? >> print calls PRINT, printf calls PRINTF, even if the subs don't do any >> printing. Sure makes it easier to see what's going on, to me at least. > > But BLESS doesn't

Re: RFC 188 (v1) Objects : Private keys and methods

John Siracusa <[EMAIL PROTECTED]> writes: > On 9/1/00 4:59 PM, Perl6 RFC Librarian wrote: > > Once a hash has been C-ized, the only way to extend its set of > > entries is via another call to C: > > > > sub new { > > my ($class, %self) = @_; > > bless private \%self, $class; > >

Re: RFC 188 (v1) Objects : Private keys and methods

"David E. Wheeler" <[EMAIL PROTECTED]> writes: > On 1 Sep 2000, Perl6 RFC Librarian wrote: > > > This and other RFCs are available on the web at > > http://dev.perl.org/rfc/ > > > > =head1 TITLE > > > > Objects : Private keys and methods > > Here, here & amen, Damian! This one gets my insta

Re: "Counting the birds" :")

Raptor <[EMAIL PROTECTED]> writes: >What is interesting to me : > >1. "push" is used more than any of the other array ops, even than "shift" >2. "use" is very good candidate for speedup >3. We still use very much "goto" :") >4. "each" is used more than "values" and "keys" >5. Things like "hex,chr,

Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go

Damian Conway <[EMAIL PROTECTED]> writes: >> Modulo some superpositional silliness, > > Hey! I resemble that remark! And we love you for it. -- Piers

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

Michael Fowler <[EMAIL PROTECTED]> writes: > On Fri, Sep 01, 2000 at 05:23:27PM +0200, Slaven Rezic wrote: > > Often, there is the case that "my" is used before actually assigning a > > value to it. For example: > > > > my Foo $foo; > > if ($cond1) { > > $foo = new Foo 1, 2, 3; > >

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

Damian Conway <[EMAIL PROTECTED]> writes: >> > But I agree that anything beyond that is simply horrible. >> > You'll only drive more people *away* from OO, because it >> > generates so horribly inefficient code. If you want a >> > constructor called, than FGS *call* a constructor.

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

Nathan Wiger <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > > > > > First off, I think everyone is reading this RFC with the wrong mindset, > > > forgetting the concept of embedded objects in Perl 6. > > > > Ah, that dumb idea again. > > Well, if you disagree with this idea, you probably

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

Michael Fowler <[EMAIL PROTECTED]> writes: > 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 Do

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

Michael Fowler <[EMAIL PROTECTED]> writes: > On Fri, Sep 01, 2000 at 10:22:49AM +0100, Piers Cawley wrote: > > And then there's: > > > > - Makes factory methods impossible. > > my Dog $spot; > my $pub = $spot->procreate; > > Sure looks like a factory method to me. Just because you d

Matrix, array, or tensor? (was Re: n-dim matrices)

Christian Soeller wrote: > Buddha Buck wrote: > > > Tensor or Matrix > > Multidimensional list > > what should we call it? > > > > I'd vote for matrix myself. It's short and sweet > > Fine ;) Just have a section in the elusive overview RFC that defines > what we mean by matrix, e.g. not only 2

"Counting the birds" :")

hi, here is one simple script (Requires Parse::RecDescent) that count operators in scripts.(and my fisrt grammar ;") ) OK. I started this against my current perl installation. (it is not pure RH6.2 install, but many things are added) i.e. find /perl_dir -name *.pm | ./count.pl | tee allops.txt i

Message ID's?

Totday I got a message that my ISP's mail server had bounced a few mails. It looks to me as my mailbox with the ISP was a bit full. But, that's not the point of my mail here. It's this excerpt: Here are the message numbers: 5315 5320 5318

Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly

Damian Conway <[EMAIL PROTECTED]> writes: >> =head1 TITLE >> >> C should simply assert that >> C<(!defined($spot) || $spot-Eisa('Dog'))> >> >> And let them duke it out. > > You'd have my support for that...I was intending to release an RFC > in the next day or two that

Re: n-dim matrices

Buddha Buck wrote: > Tensor or Matrix > Multidimensional list > what should we call it? > > I'd vote for matrix myself. It's short and sweet Fine ;) Just have a section in the elusive overview RFC that defines what we mean by matrix, e.g. not only 2D objects of linear algebra. With all the