Licenses on CPAN

2000-09-10 Thread Chris Nandor
(This is a carryover from the p5p list.) I do not think we should encourage ANY specific licensing terms for CPAN content, except that it should be an open source license of some kind. Bradley Kuhn wrote: However, the Artistic license isn't legally sound enough to hold water as a free software

Re: RFC 39 (v3) Perl should have a print operator

2000-09-10 Thread Jonathan Scott Duff
On Fri, Sep 08, 2000 at 03:31:54PM -0400, Chaim Frenkel wrote: Could someone enlighten this poor soul and tell me what I _can_ do with an error return from a print or close? Surely you'd want to know if your output can't be output (print) and for close, take a look at this:

Re: perl 5.6.0 stdlib stats

2000-09-10 Thread Nathan Torkington
Leon Brocard writes: In an effort to avoid organising YAPC::Europe, I went through the 126 modules with documentation in Perl 5.6.0's lib/ directory and documented what kind of interface they provided. Not all of them follow perlstyle, and I think perl6's standard libraries should. But

Re: RFCs for thread models

2000-09-10 Thread Benjamin Stuhl
--- Chaim Frenkel [EMAIL PROTECTED] wrote: "SWM" == Steven W McDougall [EMAIL PROTECTED] writes: SWM If you actually compile a Perl program, like SWM $a = $b SWM and then look at the op tree, you won't find the symbol "$b", or "b" SWM anywhere in it. The fetch() op does not

one question about vtbls

2000-09-10 Thread Benjamin Stuhl
I have one question about vtbls that I have not been able to figure out an answer to: How does using a vtbl get rid of the switch(sv-sv_flags) with multi-valued scalars running around? That is, how does one write a vtbl function that can cope with the perl6 equivalent of perl5's

Re: Licenses on CPAN

2000-09-10 Thread Chris Nandor
At 16:42 -0700 2000.09.10, Russ Allbery wrote: Chris Nandor [EMAIL PROTECTED] writes: However, I feel the need to emphasize that licenses are not necessarily legal documents. I think this is a key point of disagreement. If the license is not a legal document, it's not a *license*; it may be

Re: Licenses on CPAN

2000-09-10 Thread Tom Christiansen
No, it is absolutely not patently false. It's entirely accurate. Perhaps you've missed what the FSF says about the Artistic License (used by itself), an opinion that I've heard is backed up by their legal counsel: The Artistic license. We cannot say that this is a free software license

Re: Licenses on CPAN

2000-09-10 Thread Tom Christiansen
That is the opinion of the FSF (and their legal counsel, who I'm not inclined to trust anyway), Gee, Christ, whyever wouldn't you be quick to trust the word of someone with the temerity to claim that where we've previously used the word "encumbered", we must now instead use the word "free"?

Re: Licenses on CPAN

2000-09-10 Thread Tom Christiansen
Like it or not, we do have to deal with the law. I see no evidence of that. --tom

Re: An attempt to be constructive

2000-09-10 Thread Tom Christiansen
In more of an attempt to be constructive, what if we identify the key aspects to the AL that people like and then, for Perl 6, find legal counsel to review and help draft a precise legal license with those key features? Here's what I like: *LARRY AND LARRY ALONE* gets to say what happens to that

RFC - Prototype RFC Implementations - Seperating the men from the boys.

2000-09-10 Thread Michael G Schwern
I've an idea to cut down and weed out the huge number of RFCs we have. Its written out below. =pod =head1 TITLE Prototype implementations for RFCs. =head1 VERSION Maintainer: Michael G Schwern [EMAIL PROTECTED] Date: Mon Sep 4 21:11:56 EDT 2000 Version:1 Mailing

Re: The Future - grim.

2000-09-10 Thread Adam Turoff
On Sun, Sep 10, 2000 at 09:58:14PM +0100, Alan Burlison wrote: I don't believe in magic. I'm an engineer by profession, not an astrologer. However, I will predict endless arguments when some of the less than coherent proposals are rejected. The RFC process was intended to bring out both

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

2000-09-10 Thread Michael G Schwern
On Mon, Sep 11, 2000 at 12:57:47AM -0400, Chaim Frenkel wrote: "MGS" == Michael G Schwern [EMAIL PROTECTED] writes: MGS =head1 ABSTRACT MGS RFCs should be followed by a prototype implementation of their MGS proposal which provides something concrete to develop the RFC from and MGS helps

Re: New Perl rewrite - embedded Perl

2000-09-10 Thread Dan Sugalski
At 09:40 PM 9/9/00 +0100, Matthew Gillman wrote: Basically, my comment is that a lot of commercial applications seem to be mixing and matching languages together (like C++ and Perl), so it would be really great if the issues such as Purify errors for embedded Perl were addressed (I realise

Re: RFCs for thread models

2000-09-10 Thread Dan Sugalski
At 10:26 PM 9/9/00 -0400, Steven W McDougall wrote: RFC 178 proposes a shared data model for Perl6 threads. In a shared data model - globals are shared unless localized - file-scoped lexicals are shared unless the thread recompiles the file - block scoped lexicals may be shared by - passing

Re: A tentative list of vtable functions

2000-09-10 Thread Dan Sugalski
At 07:58 PM 9/9/00 +, Nick Ing-Simmons wrote: Ken Fox [EMAIL PROTECTED] writes: Short circuiting should not be customizable by each type for example. We are already having that argument^Wdiscussion elsewhere ;-) But I agree variable vtables are not the place for that. As do I, up to a

Re: RFC 178 (v2) Lightweight Threads

2000-09-10 Thread Dan Sugalski
At 09:43 PM 9/9/00 -0400, Chaim Frenkel wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Right, but databases are all dealing with mainly disk access. A 1ms lock DS operation's no big deal when it takes 100ms to fetch the data being locked. DS A 1ms lock operation *is* a big deal when

Re: RFC 178 (v2) Lightweight Threads

2000-09-10 Thread Alan Burlison
Chaim Frenkel wrote: Please elaborate. How deep do you go? $h{a}{b}{c}{d}{e}{f} This is my last mail on this subject - it is a half-assed idea, and this whole thread is becoming too tedious for words. Actually, I'd extend that to the whole p6 process. In fact I think I'll just unsubscribe.

Re: The Future - grim.

2000-09-10 Thread Alan Burlison
Nathan Torkington wrote: Thanks for that grim view, Alan. I've been looking around for someone to act as the Devil's Advocate and say what might go wrong, so I was happy to see this. Glad to be of service ;-) I agree that the current brainstorming is chaotic. I feel like that's the

Re: The Future - grim.

2000-09-10 Thread Nathan Wiger
What we're doing about that: * pushing the output through Larry [Yes, this addresses only part of the problem. Any suggestions for other ways to solve this?] The RFC mountain is way, way too high to be climbed by just one person, let alone the output of the various mailing lists.

Re: Project documents

2000-09-10 Thread Chaim Frenkel
risks.html 1. Minimized by another culling phase after the RFC freeze 2. Minimized by the sub-working groups. You will notice that the discussions on the sub-groups are quite localized in people and discussions are limited. Some groups are noisy but what you are witnessing is an

The Future - grim.

2000-09-10 Thread Alan Burlison
Nathan Torkington wrote: We're lucky to have the experience of Chip to draw upon (he's already blazed some of the trails we'll be turning into fully-paved four-lane highways with Waffle Houses and Conocos), as well as a lot of people who've worked with perl5. They know what works and what

Re: Licenses on CPAN

2000-09-10 Thread Chris Nandor
At 16:24 -0700 2000.09.10, Russ Allbery wrote: Then I guess we'll have to agree to disagree, as in my opinion you didn't prove anything, I absolutely proved that the software licensed AL-only is known to be free software. I also accept that some, maybe many, people think it is not. But that

Re: An attempt to be constructive

2000-09-10 Thread Chris Nandor
At 16:32 -0700 2000.09.10, Russ Allbery wrote: In more of an attempt to be constructive, what if we identify the key aspects to the AL that people like and then, for Perl 6, find legal counsel to review and help draft a precise legal license with those key features? I think that's a good idea,

Re: Licenses on CPAN

2000-09-10 Thread Russ Allbery
Chris Nandor [EMAIL PROTECTED] writes: However, I feel the need to emphasize that licenses are not necessarily legal documents. I think this is a key point of disagreement. If the license is not a legal document, it's not a *license*; it may be a statement of permission or something else

Re: Licenses on CPAN

2000-09-10 Thread Russ Allbery
Chris Nandor [EMAIL PROTECTED] writes: I do not think we should encourage ANY specific licensing terms for CPAN content, except that it should be an open source license of some kind. I agree with this as a statement of general "official" policy; however, I'll certainly encourage people who

Re: Licenses on CPAN

2000-09-10 Thread Chris Nandor
At 14:05 -0700 2000.09.10, Russ Allbery wrote: Chris Nandor [EMAIL PROTECTED] writes: I do not think we should encourage ANY specific licensing terms for CPAN content, except that it should be an open source license of some kind. I agree with this as a statement of general "official" policy;

Re: Licenses on CPAN

2000-09-10 Thread Russ Allbery
It seems pretty clear from this response, Chris, that you're not actually interested in discussing licensing. That's certainly your perogative; I don't particularly enjoy having to work out the legal intricacies either. You are instead interested in discussing the fact that you dislike the law,

Re: Licenses on CPAN

2000-09-10 Thread Chris Nandor
At 15:31 -0700 2000.09.10, Russ Allbery wrote: It seems pretty clear from this response, Chris, that you're not actually interested in discussing licensing. That's not true. You are instead interested in discussing the fact that you dislike the law, the way the law is applied and interpreted,

Re: Licenses on CPAN

2000-09-10 Thread Russ Allbery
Chris Nandor [EMAIL PROTECTED] writes: Well, if you want to bring up specifics, you can. But you (and Bradley) said some things that were provably false, and I proved them false. Then I guess we'll have to agree to disagree, as in my opinion you didn't prove anything, simply asserted that

Re: Licenses on CPAN

2000-09-10 Thread Chris Nandor
At 19:10 -0400 2000.09.10, Chris Nandor wrote: No, I am interested in both. The fact that you didn't understand that could be my fault, but I think I made it clear enough. You know, I think I want to make this more clear. I am interested in how various licenses will be interpreted legally. I

An attempt to be constructive

2000-09-10 Thread Russ Allbery
I'm sorry about my last two messages; they may have helped me vent my spleen, but they weren't accomplishing anything productive. In more of an attempt to be constructive, what if we identify the key aspects to the AL that people like and then, for Perl 6, find legal counsel to review and help

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
On Mon, Sep 11, 2000 at 01:31:39PM +1100, Damian Conway wrote: Or, better still, pass a reference to the actual variable being tied. Good idea. Also notice that I suggested the TIE be called as a method, so that it can be inherited if necessary (maybe you had that idea already???) The tie

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Nathan Wiger
Michael G Schwern wrote: sub lock { print "Hello!" } $trans = new Lock::Ness; lock $trans; # $trans-lock That's not right. You're correct. Sorry for not double-checking my examples. the same reasons I've already pointed out. You don't want adding a method to a class to

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
On Sun, Sep 10, 2000 at 09:22:39PM -0700, Nathan Wiger wrote: Regardless of my huge error above, this doesn't change the fact that this is exactly what tie() does currently in Perl 5. That is: tie @a, 'Matrix'; push @a, $stuff; Now changes the meaning of push() in the current

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Damian Conway
It may make sense to pass a leading argument to TIE which is the type of variable being tied. tie Some::Class $foo, @args; would produce: TIE('SCALAR', 'Some::Class', @args); Or, better still, pass a reference to the actual variable being tied.

Re: RFC 127 (v1) Sane resolution to large function returns

2000-09-10 Thread Glenn Linderman
Chaim Frenkel wrote: "GL" == Glenn Linderman [EMAIL PROTECTED] writes: GL Chaim Frenkel wrote: ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1

Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-10 Thread Damian Conway
my_while { pred() } { # don't gimme no Tcl flac. ... } # no semicolon needed here! DC Just added to the RFC :-) How would the parser handle this? Some '}' would need ';' some don't. The trailing C parameter specification tells the parser that there the last

RE: RFC 199 (v2) Another question...

2000-09-10 Thread Damian Conway
Would it be possible to expand the function prototypes so that a function could be defined to take a loop block instead of a code block? I'm not sure what you mean here. Damian

Re: RFC 114 (v2) Perl resource configuration

2000-09-10 Thread Chaim Frenkel
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: but that is the user's to set. PERL_PRELOAD TC is there for the user to unset. allows the admin to globally set (in the system shell rc file) the rc files that perl will load. TC And what sorts of things might the admin care to globally

Re: $a in @b

2000-09-10 Thread Chaim Frenkel
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: grep { $_ == 1 } 1..1_000_000 grep doesn't short-circuit. TC I never did figure out why "last" {w,sh,c}ouldn't be made to do TC that very thing. Hey, I suggested that a while ago, but Randal shot it down. Something about the block not

Re: $a in @b

2000-09-10 Thread Chaim Frenkel
"DC" == Damian Conway [EMAIL PROTECTED] writes: DC I would propose that the Cgrep operation should short-circuit if the DC block throws an exception, with the value of the expection determining DC whether the final invocation of the block should accept the element it DC was filtering: Why not

Re: $a in @b

2000-09-10 Thread Randal L. Schwartz
"Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: grep { $_ == 1 } 1..1_000_000 grep doesn't short-circuit. TC I never did figure out why "last" {w,sh,c}ouldn't be made to do TC that very thing. Chaim Hey, I suggested that a while ago,

Re: $a in @b

2000-09-10 Thread Christian Soeller
Quantum::Superpositions provides this in a more flexible way by adding the 'any' and 'all' keywords. http://search.cpan.org/doc/DCONWAY/Quantum-Superpositions-1.03/lib/Quantum/ Superpositions.pm One of Damian Conway's many promised RFCs will cover

Re: RFC 179 (v1) More functions from set theory to manipulate arrays

2000-09-10 Thread Chaim Frenkel
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: But, Do you really think that all these ingenuities, to not use another term, are really natural and easy to understand to novice programmers ? TC Until you start thinking of terms of hashes, you aren't thinking TC in Perl. It serves no

Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-10 Thread Bart Lateur
On 10 Sep 2000 00:33:43 -0400, Chaim Frenkel wrote: PS Yes, please. I view the flattening of lists as a feature, not a bug, and PS it has made Perl a lot easier to understand IMHO. I view it as a mis-feature. I'm sorry to disagree. But flattening of argument lists is one of those things that

Re: RFC 103 (v1) Fix print $r-func and $pkg::$var precedence

2000-09-10 Thread Glenn Linderman
Nathan Wiger wrote: Bart Lateur wrote: Why interpolate "$obj-method" and not "Class-method"? This is a decent point worth considering. I think another way to look at it which is more accurrate is that - is special in many cases already: /$foo-{blah}/ # - special