Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping

2000-08-25 Thread Nathan Wiger
$a[$i][$j][$k] or $a[$i,$j,$k] The second one has no useful meeting, "," is just an operator which does nothing much useful in this context. Not true, at least not in the Perl I know. :-) Here's a description of what these do in Perl just to clarify: $a[0][1][2]; # get a single

Re: New variable type: matrix

2000-08-28 Thread Nathan Wiger
Doug Hunt wrote: What I meant to say (but failed, alas) was that I support the idea for a new perl variable type called compact array: $foo -- scalar @foo -- array %foo -- hash ^foo -- compact array (or whatever notation) Given this notation, you could have hashes of compact

Re: New variable type: matrix

2000-08-29 Thread Nathan Wiger
Baris wrote: Hi, ^foo = ([1, 2], [3, 4]); # I know, it's taken, I helped :-) $foo[0,0];# uh-oh Then adding a new fundamental type and syntax is not only unnecessary, but silly. Why do you think that individual elements are perl scalars? To avoid anyone

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Wiger
[EMAIL PROTECTED] wrote: I disagree. You end up with a situation where some @a * @b; are in scalar context, some not. No, everything would be in a scalar context. If you used tie() to specially tie a variable, then you might be able to overload +, *, -, etc, but this is no different

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Wiger
Nathan Torkington wrote: Actually, the only refinement I'd like to see is that boolean operators (==, , ||) be excepted from the distributive rule. This is to permit: if (@a == @b) # shallow comparison and @a = @b || @c;# @a=@b or @a=@c; # ish Yeah, I

Re: reshape() (was Re: Fw: Wrapup time)

2000-09-13 Thread Nathan Wiger
Jeremy Howard wrote: RFC 203 defines a :bounds attribute that defines the maximum index of each dimension of an array. RFC 206 provides the syntax @#array which returns these maximum indexes. For consistancy, the arguments to reshape() should be the maximum index of each dimension. A

Re: RFC 234 (v1) Data: overloading via the SECOND operand if needed

2000-09-15 Thread Nathan Wiger
This RFC proposes a support of a situation when a more-knowledgable module may steal overloading from a less-knowledgable module or visa versa; What if both modules have this :override bit set at the same time? Does the second one still win? Or does the first one win again? Either way I'm not

Re: RFC 237 (v1) hashes should interpolate in double-quoted strings

2000-09-17 Thread Nathan Wiger
The idea of interpolating a hash is cool... but is seperating each pair by $/ really useful? A comma or $" sees to make more sense. Yeah, I for one think %hashes should be interpolated exactly like @arrays. It's simple and consistent. -Nate

Re: RFC 148 (v2) Add reshape() for multi-dimensional array reshaping

2000-09-18 Thread Nathan Wiger
Sorry Nate--I know we thought we were on the same wavelength here, but it looks like we weren't at all! Would you like me to redraft this for you, or create a new RFC? It's all yours. My brain is toast, and I'm totally RFC'ed out. The only thing I care about is that the lists wind up on the

Re: RFC 234 (v1) Data: overloading via the SECOND operand if needed

2000-09-19 Thread Nathan Wiger
== Either way I'm not sure it solves the problem; if each module asserts that *they* are the smarter one then you either wind up with the same situation you have now or even worse contention.

Re: RFC 204 (v2) Arrays: Use list reference for multidimensional array access

2000-09-27 Thread Nathan Wiger
Bart Lateur wrote: The problem is that $name = "myarray"; @$name = (1,2,3); print @$name[0,1]; # 1,2 Is very consistent currently. Change one and you have to change the precedence and parsing of all symbolic refs. You are suggesting to keep a weird precedence rule, just

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

2000-09-18 Thread Nathan Wiger
Chris Nandor wrote: just assume "All Perl core functions should return objects", and hence the reason I wrote RFC 73. ;-) And it would make me stop using Perl faster than your object method could be resolved. Is your concern one of? 1. Speed 2. Bloat 3. Excess burden on the

Re: TAI and Unix epoch issues

2000-09-24 Thread Nathan Wiger
Nathan Wiger wrote: I think we should definitely maintain this in UTC, since this is how UNIX works natively. If we're standardizing on the UNIX epoch we should standardize on UTC clock as well. Blech. Now I'm not sure after re-reading the thread starting here: http://www.mail-archive.com

Re: RFC 14 (v2) Modify open() to support FileObjects and

2000-08-10 Thread Nathan Wiger
How about this? open '/etc/passwd'; # file open '/usr/local/bin/'; # directory (note the trailing '/') open 'ftp://ftp.perl.org/'; # ftp open 'http://www.yahoo.com/'; # http open 'ldap://ldap.bigfoot.com/';# ldap I think

Re: RFC 14 (v2) Modify open() to support FileObjects and

2000-08-10 Thread Nathan Wiger
This is nutso... shall we open-ssh and open-telnet and open-any_protocal_under_the_sun in the core? Well, just because the hooks are there doesn't mean all the member modules have to be in core. The idea would be, as Tom Hughes suggests: That is if the core provides a way for modules to

Re: RFC 14 (v3) Modify open() to support FileObjects and

2000-08-11 Thread Nathan Wiger
# Open a remote webpage $http = open http "http://www.perl.com/", GET; ^ 1) The URL says that it's a http resource, so why do we have to tell open to use a http handler? a) Allows custom handlers: open myhttp

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Nathan Wiger
And how do we make it easy to pass in a name to open? In an email I sent to Jarkko off-list, I suggested this: If we embedded full URI support into Perl, then people could write portable scripts using URIs, or non-portable ones using native syntax. *Internally*, both could be converted into

Re: RFC 14 (v3) Modify open() to support FileObjects and

2000-08-14 Thread Nathan Wiger
What does that mean? When the handler is invoked, what does it see? $fh = open myhttp "http://www.perl.com", "fred", "barney"; Does that result in a call like this? myhttp::open("http://www.perl.com", "fred", "barney"); Exactly. Or to be "more correct"

Re: RFC 100 (v1) Embed full URI support into Perl

2000-08-15 Thread Nathan Wiger
Sam Tregar wrote: How is this better than File::Spec's approach? File::Spec has the idea and representation dead on. However, the interface is a pain; to write portable scripts you have to go through some contortions. With URI support, you still have to contort a little, but not as much.

Re: RFC 100 (v1) Embed full URI support into Perl

2000-08-16 Thread Nathan Wiger
So, what's so portable about file:// URLs again? How do they magically know that //c/ means / on UNIX? What do they do with //z/? This is only one example. I'm not sure it's the best way. It's definitely not the only way. Chaim asked: Or for that matter "file://u/frankeh/Projects" become?

Re: RFC 30 (v2) STDIN, STDOUT, and STDERR should be renamed

2000-08-16 Thread Nathan Wiger
Graham Barr wrote: Create a new handle, like $DEFOUT. Then there would be no need for selectsaver either as you would do the equiv. of local($DEFOUT) = $newhandle; Just submitted an RFC on this exact idea. -Nate

Re: RFC 181 (v1) Formats out of core / New format syntax

2000-09-01 Thread Nathan Wiger
Have you also looked at Damian's Text::Autoformat, which has a renewed format implementation that looks *very* good a candidate for replacing perl 4/5's format. Yes, I have. It's actually very powerful. I've actually been meaning to talk to Damian about this, because at one time he had

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

2000-09-05 Thread Nathan Wiger
Jon Ericson wrote: I would want it to return @items: @sorted = sort print @items; I'd prefer a different name (tee?) and keep print as it is. Pretty much all the stuff being discussed right now can be stuck in a module: package Print::Variations; use Exporter; @EXPORT =

Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-11 Thread Nathan Wiger
[cc'ed on internals as FYI] =item 36 (v1): Structured Internal Representation of Filenames I think this should be discussed a good amount. I think URIs are cool, but too much trouble for simple stuff. I don't want to have to write "file:///etc/motd" everytime I want to address a file. Too

Standardization of Perl IO functions

2000-09-12 Thread Nathan Wiger
All- This is an idea I've been chewing on for some time. RFC 14 proposes a new syntax to open(): $FH = open dir "/usr/local/bin" or die "Badness: $!"; which is far different from the current open(). This is actually a more flexible and consistent syntax, with a cool feature I just came

Re: Cross-referencing RFC 186 with RFC 183 and RFC 79

2000-09-14 Thread Nathan Wiger
Glenn Linderman wrote: I have a number of scripts that use this sort of facility, using push/shift to populate/read the array "file". These could be made simpler and more general by wrapping the array as a file. Perhaps the open "handler" stuff could be used to implement this?

Sublist -io RFC wrap-up time

2000-09-16 Thread Nathan Wiger
[ for those on -all or -objects this is gonna look real familiar :-) ] All- As Nat has mentioned on -meta, it's time to start wrapping things up. In particular, I think the following "deadlines" should apply: 1. Any and all *new* RFC's should be submitted by Wednesday at the absolute

Re: RFC 14 (v4) Modify open() to support FileObjects and Extensibility

2000-09-17 Thread Nathan Wiger
Michael G Schwern wrote: On Sun, Sep 17, 2000 at 05:35:47AM -, Perl6 RFC Librarian wrote: $fo-untaint - Removes tainting from that data source I can guarantee this will be abused and severely water down the utility of taint mode. Well, as Tom pointed out to me this already

Re: RFC 30 (v4) STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars

2000-09-17 Thread Nathan Wiger
Tom Christiansen wrote: Scalars hold references to objects. Filehandles should, ultimately, be objects, as should directory handles. I haven't yet seen anybody yet propose bifurcating {file,directory}handles. This would certainly be nice. If I'm understanding what you mean, I believe

Re: RFC 100 (v2) Embed full URI support into Perl

2000-09-18 Thread Nathan Wiger
I'd rather see you drop (or footnote) the discussion of how the various systems are going to map content among themselves, and focus more on what the construct allows. For instance, returning to some of the original implementation ideas, that the location information be passed to the

The One True Deadline is approaching

2000-09-28 Thread Nathan Wiger
We've only got 4 days left until the One True Deadline on this whole thing. Please, go check this out: http://dev.perl.org/rfc/overdue-perl6-language-io.html And get your RFC's finished up. Remember: Oct 1st is a true deadline, coming from the powers above, meaning if your RFC is not frozen by

Re: RFC 350 (v1) Advanced I/O (AIO)

2000-09-29 Thread Nathan Wiger
you would do: $sock = AIO::Open( Host = 'www.perl.org', Port = 80 ) ; Similarly for LWP you would just do: $sock = AIO::Open( Url = 'http://www.perl.org' ) ; $event = AIO::Open( Host = 'www.perl.org', Port

Re: RFC for $ME class variable (was Re: RFC 124 (v1) Sort order forany hash)

2000-08-23 Thread Nathan Wiger
You can have your cake, but not force us to eat it too... Like $AUTOLOAD, $ME would be dynamically scoped: The first time I saw the bareword "self" keyword I almost wet myself in horror, but I would say that $AUTOLOAD is a disaster that should not be repeated. And that's the way that this

Re: RFC 159 (v1) True Polymorphic Objects

2000-08-25 Thread Nathan Wiger
/ =head1 TITLE True Polymorphic Objects =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 25 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 159 Status: Developing =head1 ABSTRACT Currently, using objects in numeric and string contexts

Re: RFC 161 (v2) OO Integration/Migration Path

2000-08-27 Thread Nathan Wiger
Nathan Torkington wrote: Are you proposing making even "normal" scalar, hash, and array access go through these methods? Wouldn't that slow everything way down? Glad you brought this up, Nat! I would say "yes and no". The reason I'd say this is because Dan S. and the internals guys are

PLEASE DISCUSS ON -objects!! (was Re: RFC 161 (v1) OO Integration/Migration Path)

2000-08-25 Thread Nathan Wiger
Please discuss this RFC on the -objects sublist. Thanks. Matt, you should probably update the Mailist List to perl6-language-objects for v2. -Nate Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE OO

Re: RFC 161 (v2) OO Integration/Migration Path

2000-08-29 Thread Nathan Wiger
"Randal L. Schwartz" wrote: That's my first gut reaction to this proposal. "If you like Python, you know where to find it, but let us have some primitive data types in Perl that act primitive so we can optimize things." Well, we're on a border here. What this RFC is really referring to is

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

2000-08-30 Thread Nathan Wiger
What, then, happens to the following code: my Dog $spot; if ($age 12) { $spot = new Doberman(); } else { $spot = new Corgi(); } This is a tricky case that deserves a lot of attention, but not exactly as written. Imagine this code block: my int ($x, $y, $z) = (4, 5, 6);

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

2000-09-01 Thread Nathan Wiger
I haven't commented on RFC 171 because I assumed it would be shot down quickly by the Major Contibutors(tm), but let me just say now that I'm firmly in this camp: Funny, I don't see much difference between RFC 171 and this RFC: 171: constructor called on object creation 189:

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread Nathan Wiger
Michael G Schwern wrote: Derived classes will never have to override a base's implementation, and all member variables should be private, and everyone will always use an accessor, and the UN will bring about world peace, and as long as I'm wishing for a perfect world, I'd like a pony. ;)

Non-inheritable and cascading methods

2000-09-04 Thread Nathan Wiger
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

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

2000-09-04 Thread Nathan Wiger
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 = "demo", _rank =

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

2000-09-05 Thread Nathan Wiger
Damian Conway wrote: attr3 = [ALL] It was (and is) a good suggestion. I suspect however that it should be attr3 = [__ALL__] Any consideration given to the :all export-like tag? attr3 = [:all]# could be uppercase too -Nate

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

2000-09-10 Thread Nathan Wiger
Michael Fowler wrote: =head3 Merge CTIESCALAR, CTIEHASH, and CTIEARRAY into CTIE I'm not so sure about this. I'm not either anymore. This will probably be removed from the next version. Instead, this RFC proposes that Ctie's operation become much more fundamental, simply translating

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: Draft RFC: new pragma: Cuse namespace

2000-09-13 Thread Nathan Wiger
use namespace 'Big::Long::Prefix'; my ::Class $object = ::Class-new; Anyone mentioned that this: $SHORT = 'Some::Huge::Obnoxious::Ridiculous::Term'; $SHORT-member; $stuff = new $SHORT; Already works? The only problem is that this: $SHORT::stuff(@args); Doesn't, but this

Re: RFC - Interpolation of method calls

2000-09-14 Thread Nathan Wiger
This topic is actually covered, albeit far less in-depth and lumped with an unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware. Yeah, I've got to split those up. I was trying cut down on the flood of RFC's that poor Larry has to sift through :-(, but they are both

Re: Draft RFC: new pragma: Cuse namespace

2000-09-14 Thread Nathan Wiger
Nathan Wiger wrote: use namespace 'Big::Long::Prefix'; my ::Class $object = ::Class-new; Assuming repairing :: precedence is a reality I don't think this proposal buys us anything. backtracking...That being said, I'm not necessarily against it. I'm just against bloat. I hadn't

Re: RFC 189 (v2) Objects : Hierarchical calls to initializers and destructors

2000-09-14 Thread Nathan Wiger
=head2 The CBUILD method =head3 The CREBUILD method Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS that we all like! :-( -Nate

Re: RFC 101 (v2) Handlers and Pseudo-classes

2000-09-13 Thread Nathan Wiger
[added -io cross-post] John Porter wrote: Just MHO, but I don't think this is the kind of thing that should go in the core. Just MHO. I think I agree. Just to clarify, the only reason it's an RFC and not just a Perl 5 module is because RFC 14 (the one on a new open()) relies on a handler

Re: RFC - Interpolation of method calls

2000-09-17 Thread Nathan Wiger
Tom Christiansen wrote: print "Today's weather will be $weather-temp degrees and sunny."; So, the - operator is supposed to get expanded in dq strings, eh? It already does, or at least appears to to users: print "Today's weather will be $weather-{temp} degrees and sunny.";

Re: RFC 163 (v2) Objects: Autoaccessors for object data structures

2000-09-18 Thread Nathan Wiger
How about also just ":access" to do both? It would seem to be the most common case. I was trying to conserve keywords, but I'm not opposed to this. =head2 Mixing autoaccessors and real subs I really don't see how this is necessary. If you have to write a custom accessor, you might as

Re: RFC 254 (v1) Class Collections: Provide the ability to overload classes

2000-09-18 Thread Nathan Wiger
[From DBI-connect()] # XXX this is inelegant but practical in the short term, sigh. if ($installed_rootclass{$class}) { $dbh-{RootClass} = $class; bless $dbh = $class.'::db'; my ($outer, $inner) = DBI::_handles($dbh); bless $inner = $class.'::db';

Re: RFC 163 (v2) Objects: Autoaccessors for object data structures

2000-09-18 Thread Nathan Wiger
All- As the sublist chair, I politely ask you to please table this discussion. Time is running short and this is really a digression. Glenn, if you have a proposal, please put one together in RFC format and post it to -objects. -Nate

Specific RFC comments for -objects

2000-09-18 Thread Nathan Wiger
All- In an attempt to nudge things in the right direction (wrap-up), I've gone through and made some specific comments on RFC's. These are my opinions from monitoring the discussions on this list since its inception. I do not claim to be infallible, but feel I have a pretty good idea of what's

Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easy programming

2000-09-19 Thread Nathan Wiger
What sets Ruby apart is a clean and consistent language design where everything is an object. I like this part. Assuming I ever finish my last RFC I'd like Perl to have embedded objects as well. The difference being Perl's wouldn't get in the way, unlike Python's. Of particular interest seems

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

2000-09-19 Thread Nathan Wiger
This RFC proposes two new keywords -- Cprivate and Cpublic -- that limit the accessibility of keys in a hash, and of methods. I still think these should be attributes across the board: my $hash{$key} : private = $val; my @hash{qw(_name _rank _snum)} : public; sub dostuff : private {

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

2000-09-19 Thread Nathan Wiger
Damian Conway wrote: The problem with specifying them as attributes is that I do not believe there is any way (or even any proposed way) of applying attributes to a hash entrie or a hash slice, nor is there any way of *retrospectively* applying an attribute to a hash that has already been

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

2000-09-20 Thread Nathan Wiger
Damian Conway wrote: I didn't see any mention of my plea that Ctie should pass the original variable being tied as one of its arguments. :-( That's because it's a dumb idea!! **Kidding!** I forgot about this, sorry. I'll add it to the next version ;-) my $x = 10; tie

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-23 Thread Nathan Wiger
package Doggie; sub isborn { bless { @_ }, self; # ;-) } sub scratches ($\@;@) { ... } package Doggie::Cute; use base 'Doggie'; use interface 'Pet'; # Our base class is 'Doggie', which does not use the 'Pet' #

Re: RFC 319 (v1) Transparently integrate Ctie

2000-09-26 Thread Nathan Wiger
I'm kind of curious to know what you think would happen with the following. I've commented where I'm confident... interface Number; sub TIESCALAR; sub STORE; sub FETCH; package integer implements Number; # I really like this notation Tangentially, yes, it is nice

New match and subst replacements for =~ and !~ (was Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.)

2000-08-25 Thread Nathan Wiger
[cc'ed to -regex b/c this is related to RFC 138] Proposed replacements for m// and s///: match /pattern/flags, $string subst /pattern/newpattern/flags, $string The more I look at that, the more I like it. Very consistent with split and join. You can now potentially match on

Re: RFC 112 (v2) Assignment within a regex

2000-08-27 Thread Nathan Wiger
if (/Time: (..):(..):(..)/) { $hours = $1; $minutes = $2; $seconds = $3; } This then becomes: /Time: (?$hours=..):(?$minutes=..):(?$seconds=..)/ This is more maintainable than counting the brackets and easier to understand for a complex regex. And

Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()

2000-08-27 Thread Nathan Wiger
Nathan Torkington wrote: Hmm. This is exactly the same situation as with chomp() and somehow chomp() can tell the difference between: $_ = "hi\n"; chomp; and @strings = (); chomp @strings; Good point. I was looking at it from the general "What's wrong with how @arrays are

Re: RFC 110 (v3) counting matches

2000-08-29 Thread Nathan Wiger
Tom Christiansen wrote: While I agree that /l is bad, I think going through the crap of "= () =" is even worse. Does it work? Yes. But is it easily usable and fun, even for non-experts? No. Oh, for crying out loud--at some point, you have to stop tossing rotting fish for the starving

Re: Overlapping RFCs 135 138 164

2000-08-29 Thread Nathan Wiger
Mark-Jason Dominus wrote: RFC135: Require explicit m on matches, even with ?? and // as delimiters. This one is along a different line from these two: RFC138: Eliminate =~ operator. RFC164: Replace =~, !~, m//, and s/// with match() and subst() Which I could see unifying. I'd ask people

Re: RFC 165 (v1) Allow Varibles in tr///

2000-08-29 Thread Nathan Wiger
Mark-Jason Dominus wrote: I think the reason this hasn't been done before it because it's *not* quite straightforward. Before everyone gets tunnel vision, let me point out one thing: Accepting variables in tr// makes no sense. It defeats the purpose of tr/// - extremely fast, known

Re: RFC 165 (v1) Allow Varibles in tr///

2000-08-29 Thread Nathan Wiger
Tom Christiansen wrote: tr///e is the same as s///g: tr/$foo/$bar/e == s/$foo/$bar/g I suggest you read up on tr///, sir. You are completely wrong. Yep, sorry. I tried to hit cancel and hit send instead. I'll shut up now. -Nate

Re: RFC 145 (alternate approach)

2000-09-05 Thread Nathan Wiger
I think it's cool too, I don't like the @^g and ^@G either. But I worry about the double-meaning of the []'s in your solution, and the fact that these: /\m[...]...\M/; /\d[...]...\D/; Will work so differently. Maybe another character like ()'s that takes a list: /\m(,[).*?\M(,])/;

Re: RFC 145 (alternate approach)

2000-09-05 Thread Nathan Wiger
Richard Proctor wrote: No ?] should match the closest ?[ it should nest the ?[s bound by any brackets in the regex and act accordingly. Good point. Also this does not work as a definition of simple bracket matching as you need ( to match ) not ( to match (. A ?[ list should specify for

XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))

2000-09-06 Thread Nathan Wiger
It would be useful (and increasingly more common) to be able to match qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those can nest as well. Something like listmatch this with list /list not this but /list this. I suspect this is going to need a ?[ and ?]

Re: What's in a Regex (was RFC 145)

2000-09-07 Thread Nathan Wiger
Mark-Jason Dominus wrote: Larry said: # Well, the fact is, I've been thinking about possible ways to get rid # of =~ for some time now, so I certainly don't mind brainstorming in # this direction. That is in [EMAIL PROTECTED] which is archived at

Re: RFC 164 (v2) Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()

2000-09-14 Thread Nathan Wiger
I'm opposed to an obligation to replace m// and s///. I won't mind the ability to give a prototype of "regex" to functions, or even *additional* functions, match and subst. As the RFC basically proposes. The idea is that s///, tr///, and m// would stay, seemingly unchanged. But they'd

Re: RFC 170 (v2) Generalize =~ to a special apply-to assignment operator

2000-09-26 Thread Nathan Wiger
Simon Cozens wrote: Looks great on scalars, but... @foo =~ shift; # @foo = $foo[0] ? @foo =~ unshift; # @foo = $foo[-1] ? Yes, if you wanted to do something that twisted. :-) It probably makes more sense to do something like these: @array =~ reverse; @vals =~ sort { $a =

Re: RFC 332 (v1) Regex: Make /$/ equivalent to /\z/ under the '/s' modifier

2000-09-28 Thread Nathan Wiger
Is $$ the only alternative, or did I miss more? I don't think I've even seen this $$ mentioned before? $$ is not a suitable alternative. It already means the current process ID. It really cannot be messed with. And ${$} is identical to $$ by definition. I still like the idea of $$, as I

Re: RFC 331 (v1) Consolidate the $1 and C\1 notations

2000-09-28 Thread Nathan Wiger
=item * C\1 goes away as a special form =item * $1 means what C\1 currently means (first match in this regex) =item * ${1} is the same as $1 (first match in this regex) =item * ${P1} means what $1 currently means (first match in last regex) Here's the big problem with this, and I

Re: Eliminate dynamic variables entirely?

2000-08-16 Thread Nathan Wiger
Kai Henningsen wrote: 1. Package variables $package::var, presumably you'd have to declare those and the default would be 2. lexical variables, Not bad, but I think #1 violates Laziness if I hear you right. Let's add a "global" or "your" keyword to do this inside a package: package

Re: language-strict WG deadline is tomorrow!

2000-08-17 Thread Nathan Wiger
This message is intended to remind us all that the deadline for this working group is _tomorrow_. Not so fast! This is not true anymore. I sent an email to K. requesting all the current sublists be made permanent. She agreed. Here's the list of *permanent* sublists: -io = ALL I/O

Re: RFC 64 (v2) New pragma 'scope' to change Perl's default scoping

2000-08-29 Thread Nathan Wiger
Tom Christiansen wrote: Perhaps you simply know inept C programmers. Is there any other kind? ;-) *Kidding*! In C, something that isn't declared auto or static is going to be global. Seeing no scoping declarations, the C programmer who knows C will come to the same conclusion as the

Re: Turn 'em on! (was Re: Warnings, strict, and CPAN)

2001-02-23 Thread Nathan Wiger
[EMAIL PROTECTED] wrote: But we can run an experiment. Warnings can be made default for the first few releases of Perl 6 and we'll see what happens. If it looks good, leave them on. If not, shut them off. Unlike most other features, this one doesn't have any serious backwards

Re: RFC 57 (v1) Subroutine prototypes and parameters

2000-08-08 Thread Nathan Wiger
True. I wonder if we could change '=' to always quote the lhs, even if prefixed by '$', '@', or '%' (maybe we should only enable this behaviour inside parameter lists?) That would allow us to do this. That's gonna take some digestion time. In the meantime, is there a reason the

Re: RFC 57 (v1) Subroutine prototypes and parameters

2000-08-08 Thread Nathan Wiger
Er, I thought we were talking about setting named parameters, not default values. sub foo ($name = 'Fred', $age = 32) { # defaults # do stuff with $name and $age } foo('Barney', 31); # Positional assignment foo($age:31,

Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default

2000-08-24 Thread Nathan Wiger
Chaim Frenkel wrote: Why this limitation? If the lvalue is a fundemental type (whatever that is) everything works as if the lvalue were actually in place sub foo { return $a } foo =~ s///;# same as $a =~ s///; This is not the type of lvalue sub that this RFC

Re: RFC 153 (v1) New pragma 'autoloader' to load modules on-demand

2000-08-24 Thread Nathan Wiger
Tom Christiansen wrote: A main goal for Perl 6 is to make it faster, more compact, and lighter weight. This means moving lots of former core functions into modules. Andy D once posted something showing empirical evidence that this hypothesis is in fact *FALSE*. Ok. Perhaps I should

Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default

2000-08-25 Thread Nathan Wiger
Chaim Frenkel wrote: NW$old = assign($var, $val); NW$old = assign($var) = $val; NW$old = assign = $var, $val; I don't think that the assigned values should be moved by perl into the argument list. You are reintroducing another version of the list flattening problem. "Where

Re: RFC 174 (v1) Parse Cfunc($obj, @args) as Cfunc $obj (@args)

2000-08-30 Thread Nathan Wiger
Tom Christiansen wrote: But I will *not* relish typing STDERR-print("darn") Agreed. The day this is required is the day Perl stops becoming fun and starts becoming C++. No matter what, I think that any basic script should be able to be written without any -'s. One goal of my RFC was

Re: RFC 174 (v1) Parse Cfunc($obj, @args) as Cfunc $obj (@args)

2000-08-30 Thread Nathan Wiger
Damian Conway wrote: Nor I. That's why I'd advocate mandatory braces on indirect objects. I'd rather: print {STDERR} "darn" any day. Sorry, I'm way against that. If you're going to force that, then just enforce: STDERR-print("darn") Same amount of typing. Indirect objects

Re: RFC 132 (v3) Subroutines should be able to return an lvalue

2000-08-31 Thread Nathan Wiger
Johan Vromans wrote: You can do that easily: sub param { my ($self, @rest) = @_; $self-{aval} = @rest if @rest; # See note lreturn $self-{aval}; } I've been thinking about this for a couple days. The only problem I see is that this doesn't allow me to do this:

Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)

2000-09-13 Thread Nathan Wiger
Nathan Torkington wrote: Turning Perl into a nagging harpie means that the really important warnings will be ignored. This line of thinking brought to you by Mark-Jason's excellent talk on data typing. I agree, and just read MJD's paper the other day (nice job, BTW), but unfortunately

Re: RFC 238 (v1) length(@ary) deserves a warning

2000-09-16 Thread Nathan Wiger
Michael G Schwern wrote: I'm surprised there hasn't be a good overhaul of the prototyping system proposeed yet. Your length() propsal wouldn't be the only think that can't be prototyped. print() is the simplest example. I think print should probably become something like what Eryq

Re: RFC 23 (v5) Higher order functions

2000-09-18 Thread Nathan Wiger
=head2 Choice of notation The placeholder notation has been chosen to be consistent with the eisting Perl scalar notation (but using a ^ prefix rather than a $): RoleScalar Placeholder var analog named

Re: RFC 23 (v5) Higher order functions

2000-09-19 Thread Nathan Wiger
Damian Conway wrote: That's it! I'm gonna take that whole section out and burn it! ;-) $1 is the *only* place in Perl where an index starts at 1. *It's* the one that's inconsistent. Fix *it*. I'd love to. But we're stuck, unless we make a $CMD which holds what $0 currently holds, which I

Re: RFC 153 (v2) New pragma 'autoload' to load functions and modules on-demand

2000-09-19 Thread Nathan Wiger
Tom Christiansen wrote: Mostly harmless. Right before raising the famous "Can't locate method ..." error, Perl should check to see if Cautoload is in effect. If so, it should read the Cautoload.conf config file and ... ***LINEARLY READ A FLAT FILE!!?!?!*** I didn't get into the guts too

Re: RFC 324 (v1) Extend AUTOLOAD functionality to AUTOGLOB

2000-09-27 Thread Nathan Wiger
The AUTOGLOB subroutine should expect to take two parameters, the invocant, and a second parameter specifying what type of item is being AUTOGLOBbed, followed by - in the case of a sub - the sub's arguments. We suggest that the second parameter should be a scalar value - 'scalar' for an

Re: RFC 324 (v2) Extend AUTOLOAD functionality to AUTOGLOB

2000-10-01 Thread Nathan Wiger
=head1 CHANGES Comments received have been that it would be better to use AUTOSCALAR, AUTOHASH etc instead of AUTOGLOB in the interests of encapsulation. The argument being that if you only want to implement AUTO scalars in your program, then doing: Cif($type_of_thing eq 'scalar') {

Re: RFC: On-the-fly tainting via $^T

2000-08-01 Thread Nathan Wiger
Ariel Scolnicov wrote: Unfortunately, this would mean your example above doesn't quite work. One possibility is to say that $^T controls taint *checking*, but not tainting itself[1]! This is actually a good distinction that's worth some more discussion. One could set the implementation so

Re: date interface (was Re: perl6 requirements, on bootstrap)

2000-08-01 Thread Nathan Wiger
C is, at times, less than logical. Witness the localtime fun: some of it's zero-based, some of it's one-based, and some of it's -1900-based. All from the same function. The localtime concept is needed, the localtime brain damage is really not. I agree completely. I take issue with changing

RFC: Reimplement Warnings and Tainting as Pragmas

2000-08-02 Thread Nathan Wiger
Wanted to get this out as an idea that could encompass lots of the concerns I'm seeing about warnings and such: =head1 TITLE Warnings and Tainting should be reimplemented as pragmas. =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 2 Aug 2000 Version: 1.0 Mailing-List: perl6

Re: RFC: Reimplement Warnings and Tainting as Pragmas

2000-08-02 Thread Nathan Wiger
Warnings and Tainting should be reimplemented as pragmas. What part of warnings(3) and perllexwarn(1) are you in disagreement with? Not yet fully-versed on everything having todo with 5.6, appears I made a bit of an oversight (i.e., as you mention 'use warnings' is already in 5.6)! So while

Re: RFC: Filehandle type-defining punctuation

2000-08-02 Thread Nathan Wiger
No: lists are the plural whatzitzes, containing zero or more singular whatzitzes. They are ordered. Arrays hold lists. I tend to agree with Tom's argument here. open() is kind of funny anyways. Why couldn't it work like this, similar to FileHandle: $fh = open $filename; print $fh

  1   2   3   4   >