Re: RFC 70 (v1) Allow exception-based error-reporting.

2000-08-08 Thread Uri Guttman
how does this work with RFC 63 (Exception handling syntax proposal - it wants the Error.pm syntax) written by peter scott? you should look at that and work with peter on this. and we are already discussing that rfc in flow so please followup there only. thanx, uri -- Uri Guttman -

Re: Treating filehandles like strings

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 11:44:10PM +0200, Bart Lateur wrote: On Tue, 8 Aug 2000 16:32:26 -0500, Jonathan Scott Duff wrote: I sincerely hope you really mean "Let's make ``open() or die'' optional" Exceptions should be integrated into the language but Ye Olde "returns undef on error" should

Re: RFC 57 (v1) Subroutine prototypes and parameters

2000-08-08 Thread Bart Lateur
On Tue, 8 Aug 2000 10:02:45 +0100, Andy Wardley wrote: I was trying to strike a similarity with the current style of passing named parameters as a hash ref or naked list. e.g. mysub({ first = 1, second = 2 }); or mysub( first = 1, second = 2 ); See, no prefixes! The difference is

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 57 (v1) Subroutine prototypes and parameters

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 10:14:53AM -0700, Nathan Wiger wrote: 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',

Re: RFC 57 (v1) Subroutine prototypes and parameters

2000-08-08 Thread Andy Wardley
In the meantime, is there a reason the suggestion of: foo($x := 10, $y := 20) was dropped? It seems pretty obvious to me. Or what about: No, nothing's been dropped. I'll summarise all suggestions that don't otherwise get toasted in the next version of the RFC. A

Re: RFC 57 (v1) Subroutine prototypes and parameters

2000-08-08 Thread Bart Lateur
On Tue, 08 Aug 2000 08:49:07 -0700, Nathan Wiger wrote: In the meantime, is there a reason the suggestion of: foo($x := 10, $y := 20) was dropped? It seems pretty obvious to me. It only looks obvious to you, because it's familiar from other programming languages. But Perl's equivalent to

Re: RFC: println()

2000-08-08 Thread Hildo Biersma
Ed Mills wrote: I actually saw this in the newsgroups and thought it was a neat idea. What about println $textvar; instead of print "$textvar\n"; Ever so much easier to read and write, prints the arg and appends \n. This is probably what I disliked most about Pascal - it

Re: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-08 Thread Piers Cawley
Perl6 RFC Librarian [EMAIL PROTECTED] writes: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Proposal to utilize C* as the prefix to magic subroutines I freely accept that this is not anything approaching a reasoned critique but: Yecch! --

wildcard includes

2000-08-08 Thread Peter Bevan
Just a thought, but I think it woul be a good idea to include the 'java-esqe' practice of including packages via foo.barr.* or in Perl's case Foo::Bar::* (assume that the module include syntax remains the same)... I can see that in the case of some module directories, where the modules are

Re: RFC 50 (v1) BiDirectional Support in PERL

2000-08-08 Thread Roman M . Parparov
On Mon, Aug 07, 2000 at 11:51:06PM +0200, Bart Lateur wrote: On 07 Aug 2000 17:27:55 -0400, Chaim Frenkel wrote: He mentioned two different encodings. Logical and Visual. I'm not clear which is which. One orders the characters so that the first char is first. The other reorders the

Re: wildcard includes

2000-08-08 Thread Piers Cawley
"Peter Bevan" [EMAIL PROTECTED] writes: Just a thought, but I think it woul be a good idea to include the 'java-esqe' practice of including packages via foo.barr.* or in Perl's case Foo::Bar::* (assume that the module include syntax remains the same)... I can see that in the case of some

Re: RFC 25 (v1) Multiway comparisons

2000-08-08 Thread Martyn J. Pearce
On Fri, Aug 04, 2000 at 04:48:24PM -0400, John Porter wrote: I think this should mean what it means in Icon, namely, that $x $y evaluates to false if $x = $y, and evaluates to "$y (but true)" if $x $y. This allows the operators to be nested, i.e. $x $y $z would be ( $x $y ) $z,

Re: Things to remove

2000-08-08 Thread Martyn J. Pearce
?pattern? # one-time match Oi! Scott! No! I use this in one-liners, and it's _dead_ handy. Of course, if it's modularized as Dan suggests, which has no effect at language level, I wouldn't be unhappy. Mx. -- See, the stars are shining bright Everything's all right tonight

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-08 Thread Bart Lateur
On Tue, 8 Aug 2000 13:30:22 +1000 (EST), Damian Conway wrote: As for the regexp issue, just to clarify there's only one ambiguous case we need to work out that I can see: /.*^foo/; # ok But: /.*^foo/m; #ambiguous Hold it. What does this mean? Is the whole regex gonna

Re: Things to remove

2000-08-08 Thread Leon Brocard
Martyn J. Pearce sent the following bits through the ether: I use this in one-liners, and it's _dead_ handy May I suggest that Perl6 will be a different language? I've seen the "I use it, don't change it" argument a couple of times now and it's not a strong enough argument. The whole point is

Re: Things to remove

2000-08-08 Thread Piers Cawley
Leon Brocard [EMAIL PROTECTED] writes: Martyn J. Pearce sent the following bits through the ether: I use this in one-liners, and it's _dead_ handy May I suggest that Perl6 will be a different language? I've seen the "I use it, don't change it" argument a couple of times now and it's

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-08 Thread Andy Wardley
On Aug 7, 10:12am, Nathan Torkington wrote: Is there any reason you couldn't use "die" instead? This isn't an objection to the proposal, but one example of where I'm relying on the value returned by require() for a reason other than error reporting. I'm building Perl sub-routines (from

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

2000-08-08 Thread Matt Sergeant
On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote: On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote: Basically, you don't want to go anywhere near this mess; it eats people. I agree. I see two reasonable options to

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-08 Thread Bart Lateur
On Tue, 8 Aug 2000 07:20:41 +1000, iain truskett wrote: A call to people: Who here has actually used something other than a constant '1' in a package? If so, why? (Possibly cite the code.) I have. Just for fun. 42; # the ultimate answer... # see "Hitchhiker's

Re: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-08 Thread Bart Lateur
On Mon, 07 Aug 2000 15:19:00 -0700, Peter Scott wrote: Check the docs again. [snip] Four special subroutines act as package constructors and destructors. These are the `BEGIN', `CHECK', `INIT', and `END' routines. The `sub' is optional for these routines. Drat. I propose making

Re: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-08 Thread Bart Lateur
On Tue, 08 Aug 2000 13:03:16 +0200, Bart Lateur wrote: If you mean that you MUST use "sub", I object. If you mean that the "sub" may not be used, I agree. Addendum. I would propose that BEGIN { ... } would be what it is now, and that sub BEGIN {

Re: Things to remove

2000-08-08 Thread Bryan C . Warnock
On Tue, 08 Aug 2000, Leon Brocard wrote: Martyn J. Pearce sent the following bits through the ether: I use this in one-liners, and it's _dead_ handy May I suggest that Perl6 will be a different language? I've seen the "I use it, don't change it" argument a couple of times now and it's

Re: RFC 20 (v1) Overloadable and ||

2000-08-08 Thread Martyn Pearce
On Tue, Aug 08, 2000 at 01:42:40AM +, Nate Mueller wrote: Along the same line it would be useful to be able to overload the "truth operator" (bad word, I'm sorry). It's great to be able to do: if ($var1 $var2)... But if you also want to do: if ($var1)... It

Re: wildcard includes

2000-08-08 Thread Graham Barr
On Tue, Aug 08, 2000 at 10:02:35AM +0100, Piers Cawley wrote: "Peter Bevan" [EMAIL PROTECTED] writes: Just a thought, but I think it woul be a good idea to include the 'java-esqe' practice of including packages via foo.barr.* Hey, I'm famous :) However, I do like the idea of syntactic

Re: RFC 50 (v1) BiDirectional Support in PERL

2000-08-08 Thread Bryan C . Warnock
On Tue, 08 Aug 2000, Roman M . Parparov wrote: It's not only the browser in the end. It'd expand the capabilities to any output device presumed LTR. It sounds like a hack. Should Perl support such hacks in the core? Is this sofisticated enough, or do we need something more low-level?

RFC: Perl Switch for @INC searching

2000-08-08 Thread Ed Mills
Short of writing a perlscript to do it, searching @INC for modules can be a pain. How's about a switch that searches @INC for modules matching a regex instead of executing anything (behaves like perl -v), so for example: perl -M 'spook' might return /usr/local/lib/perl5: -rw-r--r--

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-08 Thread John Porter
Damian Conway wrote: So require and do issue a warning if they require or do an empty file. Better that than meaningless 1;'s at the end of every module. If we're going to be changing these things, can't we at least ensure that use Foo 'bar'; returns the result of the

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Ted Ashton
Thus it was written in the epistle of Segher Boessenkool, The magic defined($_ = FILE) only happens if FILE is the only thing inside while(). In this case, it's not (there's a chomp() inside as well), so the magic doesn't apply. Ok. One more time . . . I'm proposing that we change

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-08 Thread William Setzer
iain truskett [EMAIL PROTECTED] writes: : : Who here has actually used something other than a constant '1' in a : package? I have. : If so, why? (Possibly cite the code.) Because it's more aesthetic (and useful) for me to see: open '/afs/bp.ncsu.edu/path/to/no_such_file': No such file or

Re: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 09:28:17AM +0100, Piers Cawley wrote: Peter Scott [EMAIL PROTECTED] writes: At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: I meant that BEGIN, END, and INIT aren't declared as subs at present but named

Re: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 09:27:24AM +0100, Piers Cawley wrote: Proposal to utilize C* as the prefix to magic subroutines I freely accept that this is not anything approaching a reasoned critique but: Yecch! That comment is as good as any :-) -Scott -- Jonathan Scott Duff [EMAIL

Re: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-08 Thread John Porter
Jonathan Scott Duff wrote: But what happens if you want multiple BEGIN blocks? The same thing that happens now. As I understand it, perl compiles and executes the BEGIN block then detroys it so that you may have as many BEGIN blocks as you want and each time perl thinks it's the first

Error handling

2000-08-08 Thread Peter Bevan
I started writing this mail by asking: Does anyone else agree that perl should have support for (but not forcefully) error handling... maybe a little like Java's?? I know that sort of thing can be acheived with eval(), but surely Which is as far as I got, because something new has

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread Michael Mathews
In a scalar context, it could produce a date object always: $date = date; However, when you went to do anything with it in a string context, it would call the appropriate method: print "$date"; # calls $date-STRING, which in this case would # print out a

RE: Error handling

2000-08-08 Thread Brust, Corwin
From: Peter Bevan [mailto:[EMAIL PROTECTED]] snip Error handling should be supported by it's own keyword i.e.: trap { #CODE } release (error) { # ERROR } /snip I think this is touched on by RFC# 3 wherein I ask for user definable error messages. With those one could presumably set an

Re: Things to remove

2000-08-08 Thread Ed Mills
As long as were culling, might want to consider removing chomp() and possibly chop(). The language provides other ways to accomplish those thru a simple regex, and if the "println" suggestion I made was "too specific" then certainly chomp() is as well. Just a thought to chomp on.. E

Re: Things to remove

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 03:46:45PM +, Ed Mills wrote: As long as were culling, might want to consider removing chomp() and possibly chop(). The language provides other ways to accomplish those thru a simple regex, and if the "println" suggestion I made was "too specific" then

Re: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-08 Thread Peter Scott
At 09:28 AM 8/8/00 +0100, Piers Cawley wrote: Peter Scott [EMAIL PROTECTED] writes: At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: I meant that BEGIN, END, and INIT aren't declared as subs at present but named blocks. I was

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

2000-08-08 Thread Nathan Wiger
While I think Time::Object is a really great module, and following these discussions I'm thinking of adding a date() function to it Aaah! Please don't. :-) Name it something else, por favor (or at least wait until this is finalized and make the interface the same). date arithmetic...not

Re: RFC: println()

2000-08-08 Thread Bart Lateur
On Tue, 08 Aug 2000 01:29:47 GMT, Ed Mills wrote: I actually saw this in the newsgroups and thought it was a neat idea. What about println $textvar; instead of print "$textvar\n"; I can currently do that with $\, and $, for strings between items. For example: ($\, $,) =

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread Nathan Wiger
How usable is this ? I may be missing something, but if every variable mentioned in an anonymous block is assumed to be declared with my, then how do you access or modify the value of any variable outside the block ? Graham. I knew someone was going to ask this; after I sent it I

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread Michael Mathews
Graham Barr said: Would result in "25" being printed out. Here's why: 1. The C$x = 10 is automatically scoped with its own Cmy. 2. The C$x = 5 inside the Banonymous block is automatically scoped with its own Cmy. 3. The C$x = 25 code, however, inside the Cif

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Larry Wall
Ted Ashton writes: : Thus it was written in the epistle of Segher Boessenkool, : : The magic defined($_ = FILE) only happens if FILE is the only thing : inside while(). : : In this case, it's not (there's a chomp() inside as well), so the magic : doesn't apply. : : Ok. One more time . .

Re: sub optional for BEGIN: bad idea

2000-08-08 Thread Peter Scott
At 10:17 AM 8/8/00 -0600, Nathan Torkington wrote: These aren't normal subroutines because of the way they stack. If I had my druthers, I'd make "sub" *forbidden* on such things. If you wanted to make that parsable, pretend that BEGIN and END are the names of functions with prototype () which

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Larry Wall
Larry Wall writes: : (Note that under Unicode, we might well have one line terminated with a : line separator, and the next line terminated with a page separator, and Make that paragraph separator. Larry

Proto-RFC: isa() function

2000-08-08 Thread jmastros
Hello all. I'm not certian if there's a sublist that this is more approprate for, if so, could someone tell me what it is? I can't see that this clearly applies to any of them. Please cc me; I'm not yet subscribed to these lists (just tried again; if this doesn't work, the listmasters will

Re: Error handling

2000-08-08 Thread Uri Guttman
please move this thread to flow as we have the error RFC posted there. thanx, uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page ---

Re: RFC 23 Higher order functions

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 01:27:48PM -0400, Andy Dougherty wrote: It strikes me that this is very fragile and limited (unless I misunderstand, which is quite possible). For one thing, it appears to only be useful if your subroutine uses each argument exactly once. If you need to use any of

default $/ (was Re: RFC: println())

2000-08-08 Thread Uri Guttman
"BL" == Bart Lateur [EMAIL PROTECTED] writes: BL On Tue, 08 Aug 2000 01:29:47 GMT, Ed Mills wrote: I actually saw this in the newsgroups and thought it was a neat idea. What about println $textvar; i am against println. it is not so useful that i would be using it a lot. BL

Re: default $/ (was Re: RFC: println())

2000-08-08 Thread Peter Scott
At 01:46 PM 8/8/00 -0400, Uri Guttman wrote: interesting point: we are all in agreement for filehandle specific $/ and $\. but what about global default values for those handles which hve not had theirs set? you can still set the global $/ and affect all handles which don't have private $/. i

Re: default $/ (was Re: RFC: println())

2000-08-08 Thread Ted Ashton
Thus it was written in the epistle of Uri Guttman, interesting point: we are all in agreement for filehandle specific $/ and $\. but what about global default values for those handles which hve not had theirs set? you can still set the global $/ and affect all handles which don't have

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Dan Sugalski
At 10:12 AM 8/8/00 -0700, Larry Wall wrote: Ted Ashton writes: : Thus it was written in the epistle of Segher Boessenkool, : : The magic defined($_ = FILE) only happens if FILE is the only thing : inside while(). : : In this case, it's not (there's a chomp() inside as well), so the magic :

Re: Things to remove

2000-08-08 Thread Ted Ashton
Thus it was written in the epistle of Jonathan Scott Duff, Someone proposed (I think I deleted that email) to make while (FH) { ... } work like while (FH) { chomp; ... } I'm not sure if I'm the someone you meant, but if so, the proposal was to make while

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Uri Guttman
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW Before we get too carried away discussing the syntax of chomp, LW let's look a bit at the semantics. What's chomp supposed to work LW on if we make $/ go away? I think any discussion of chomp without LW considering how the input

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread Dan Sugalski
At 02:18 PM 8/8/00 +, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects should have builtin stringifying STRING method =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 06 Aug 2000 Version:

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread Nathan Torkington
Dan Sugalski writes: Is this an update to the original RFC 48 with a new title? Or is it a new RFC mis-numbered? Actually, it's an update to 49 with a slightly different title, so the answer to both of your questions is "yes". The 48/49 confusion has been cleared up in the archive. Nat

Re: Things to remove

2000-08-08 Thread Hildo Biersma
Bennett Todd wrote: There are many intents and points to this project. As _I_ see them, they include, in no particular order: - cleaning up the language definition, where practical without losing the distinctive appeal of perl to happy perl programmers; - cleaning up the

Re: Things to remove

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 01:53:21PM -0400, Ted Ashton wrote: I'm not sure if I'm the someone you meant, but if so, the proposal was to make while (chomp(FH)) { ... } work like while (FH) { chomp; ... } Oh. I think I'd prefer to see chomp() go away and be replaced by

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 01:56:12PM -0400, Uri Guttman wrote: a couple of ideas. one, i proposed we keep a global $/ and $\ for default use by handles which haven't set their own. Rather than having global $/ and $\, each filehandle has their's defaulted to something reasonable. two, instead

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Ted Ashton
Thus it was written in the epistle of Jonathan Scott Duff, On Tue, Aug 08, 2000 at 01:56:12PM -0400, Uri Guttman wrote: a couple of ideas. one, i proposed we keep a global $/ and $\ for default use by handles which haven't set their own. Rather than having global $/ and $\, each

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 02:16:57PM -0400, Ted Ashton wrote: I, for one, would like to know where the assumption came from that there would be no default filehandle. I believe Larry said he was probably going to axe it. Is it necessary that instead of typing print 'Hello World.';

Re: Things to remove

2000-08-08 Thread Russ Allbery
Bennett Todd [EMAIL PROTECTED] writes: The poster you are replying to said "I use this in one-liners, and it's _dead_ handy."; that conjures up the idioms like perl -nle 'print if 1.. ?^$?' [filename] which barfs out only the header; replace "if" with "unless" and it chops the head

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Uri Guttman
"TA" == Ted Ashton [EMAIL PROTECTED] writes: TA Thus it was written in the epistle of Jonathan Scott Duff, On Tue, Aug 08, 2000 at 01:56:12PM -0400, Uri Guttman wrote: a couple of ideas. one, i proposed we keep a global $/ and $\ for default use by handles which haven't set their

RE: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Brust, Corwin
From: Ted Ashton [mailto:[EMAIL PROTECTED]] I don't particularly mind the last two - in fact they add some benefits (like not modifying the original), which are nice to have. However, that first one, frankly, drives me nuts. Please reread the proposal. chomp() called in void context

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Dan Sugalski
At 02:29 PM 8/8/00 -0400, Michael Mathews wrote: Dan Sugalski said: Which brings up the questions: * What about scalars that didn't come from filehandles? * Should the chomp function use the filehandle's current separator, or the one in effect when it was read? * Do we even want to

Re: default $/ (was Re: RFC: println())

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 01:50:35PM -0400, Ted Ashton wrote: Hear, hear! Chomp (which I still consider a useful critter :-), needs a $/ sort of thing to know what to chomp and the lines it chomps may or may not have come from a given file. Chomping *is* useful, but it's a per-filehandle

Re: default $/ (was Re: RFC: println())

2000-08-08 Thread Uri Guttman
"JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: JSD On Tue, Aug 08, 2000 at 01:46:41PM -0400, Uri Guttman wrote: interesting point: we are all in agreement for filehandle specific $/ and $\. but what about global default values for those handles which hve not had theirs set?

Re: default $/ (was Re: RFC: println())

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 02:44:59PM -0400, Uri Guttman wrote: the key word besides global is default. this would be the value used by any new filehandle created. you can override that at anytime in that filehandle. otherwise the default value for $/ for new handles will be hardcoded in %CONFIG

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

2000-08-08 Thread Damien Neil
On Tue, Aug 08, 2000 at 09:46:04AM -0700, Nathan Wiger wrote: The RFC doesn't mention localtime() for just this reason. The idea would be localtime would be GONE in Perl 6, instead moved to Time::Local. date() would replace it. Why is this a good idea? Perl programs have been using

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Ted Ashton
Thus it was written in the epistle of Brust, Corwin, From: Ted Ashton [mailto:[EMAIL PROTECTED]] I don't particularly mind the last two - in fact they add some benefits (like not modifying the original), which are nice to have. However, that first one, frankly, drives me nuts. Please

Re: sub optional for BEGIN: bad idea

2000-08-08 Thread John Porter
Nathan Torkington wrote: These aren't normal subroutines because of the way they stack. If I had my druthers, I'd make "sub" *forbidden* on such things. I like that idea. But then, they also shouldn't go into the symbol table. At least, not as CODE. If you wanted to make that parsable,

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Uri Guttman
"MM" == Michael Mathews [EMAIL PROTECTED] writes: What about a chomp($foo, '\r\n'); # or chomp(FH, '\r\n'); syntax. Looks an awful lot like: s/\r\n//; to me... MM Yep. It should-- that's all chomp does afterall. The difference is MM that the proposed chomp should be smarter

Re: sub optional for BEGIN: bad idea

2000-08-08 Thread Nathan Torkington
John Porter writes: If you wanted to make that parsable, pretend that BEGIN and END are the names of functions with prototype () which register callbacks. I agree ... except that, in perl5 at least, you'd need a terminating semicolon if that analogy were 100% accurate. I realized that

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread Ariel Scolnicov
Nathan Wiger [EMAIL PROTECTED] writes: How usable is this ? I may be missing something, but if every variable mentioned in an anonymous block is assumed to be declared with my, then how do you access or modify the value of any variable outside the block ? Graham. I knew someone

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Ted Ashton
Thus it was written in the epistle of Uri Guttman, if a ref to a scalar, it chomps in place. return the ref? the chomped char count? . . . the point of the RFC was to propose making chomp()'s behaviour change depending on context. Here's the summary so far as I can tell: One-argument

Re: Things to remove

2000-08-08 Thread Damian Conway
Most of the requests for deletion seem to begin with, "This isn't used..." To which, "*I* use it." is a very valid argument. Agreed. The real problem with ?...? is that it complicates the hell out of the parser. So long as the special magic is retained for m?...?, I would

access to pod/doc text by code

2000-08-08 Thread Uri Guttman
here's an interesting request. i want perl code to have decent access to some or all of the pod associated with that code. so, why do we need a way to get at pod (or other doc strings) in the code? one reason to have it comes from my work on stem. i want a remote module to be able to spit out a

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread Michael Fowler
On Tue, Aug 08, 2000 at 02:18:07PM -, Perl6 RFC Librarian wrote: Hooks will have to be put in Perl's string context so that if something is an object, then that object's CSTRING method is called automatically. If no CSTRING method is defined, then it should simply return undef (instead of

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Mike Pastore
On Tue, 8 Aug 2000, Ted Ashton wrote: Quite true. The two-argument one is new to me and I hadn't thought much about it. Do you have a suggestion? Hmm, chomp { /\r\n/ } @chomp_me; ala p5 map, grep, and sort? -- Mike Pastore [EMAIL PROTECTED]

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread Nathan Wiger
fluid-let should *really* be called `now'), Agreed (about the `now' part) Will this also apply to `use scope 'subs''? No. Only subs are affected, which is a clear and easy dividing line I believe. I, for one, will *never* use such a construct. It provides the user with the dangers of

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Bart Lateur
On Tue, 8 Aug 2000 10:12:49 -0700 (PDT), Larry Wall wrote: If chomp exists in Perl 6 at all, I think it would have to be some kind of method call on the string that figures out what the discipline determined to be the terminator *for the current line*. (Note that under Unicode, we might well

Re: RFC 58 (v1) Cchomp() changes.

2000-08-08 Thread Mike Pastore
On Tue, 8 Aug 2000, Bart Lateur wrote: All you'd have to do, is set a boolean flag on the "filehandle object", saying: "Oi, I want this chomped.". For example: $fh-chomped(1); Then, what $fh would do, is read one line, looking for whatever line end it accepts, finish where found,

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread Ariel Scolnicov
Nathan Wiger [EMAIL PROTECTED] writes: [...] I, for one, will *never* use such a construct. It provides the user with the dangers of `no strict' combined with the illusion of safety of `use strict'. Do you mean the whole thing, or just the `blocks' part? Any feature which subverts

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

2000-08-08 Thread Matt Sergeant
On Tue, 8 Aug 2000, Nathan Wiger wrote: While I think Time::Object is a really great module, and following these discussions I'm thinking of adding a date() function to it Aaah! Please don't. :-) Name it something else, por favor (or at least wait until this is finalized and make the

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread John Porter
Jonathan Scott Duff wrote: If we had a context coercion operator that was the opposite of want() we could do something like this: print context '*STRING', $val; # long-hand for print $val print context '*SCALAR', $val; # we're not in a string context print context

RE: RFC 67 (v1) Deep Copying, aka, cloning around.

2000-08-08 Thread Garrett Goebel
Here's a version of my own kludgey deep copy. -Updated to use our mythical -CLONE method, and watch for circular references... our %SEEN = (); our $DEPTH = 0; %a = (a = 1, b = 2, c = [{a = 1, b = [1,2,3]}, 1, 2, 3]); *b = dcopy(\%a); sub dcopy { # Dereference and return a deep copy of

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread John Porter
Ariel Scolnicov wrote: I rarely use a `now' scope, Well, 'now' is a declaration; the scope is "temporal", aka "dynamic". Variable declaration is good (except for some trivial programs)! I agree 1000%! -- John Porter

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 05:15:24PM -0400, John Porter wrote: Jonathan Scott Duff wrote: If we had a context coercion operator that was the opposite of want() we could do something like this: print context '*STRING', $val; # long-hand for print $val print context '*SCALAR',

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread John Porter
Jonathan Scott Duff wrote: And what about user-defined contexts? (my Dog $spot = some_func();) I think a context coercion operator would do just fine. Oh, I agree entirely! But the intrinsic contexts should have concise operators (e.g. scalar()). -- John Porter

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

2000-08-08 Thread Jonathan Scott Duff
On Tue, Aug 08, 2000 at 09:50:27PM +0100, Matt Sergeant wrote: All I can say to that is, ugh! I don't want to see Perl6 be so fundamentally different to perl5 that I have to translate every single script. I want some better stuff, but a new language is not what I'm looking for. All of your

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

2000-08-08 Thread Uri Guttman
"JP" == John Porter [EMAIL PROTECTED] writes: JP Matt Sergeant wrote: I don't want to see Perl6 be so fundamentally different to perl5 that I have to translate every single script. I want some better stuff, but a new language is not what I'm looking for. JP Well, I guess we

Re: RFC 67 (v1) Deep Copying, aka, cloning around.

2000-08-08 Thread Uri Guttman
"GG" == Garrett Goebel [EMAIL PROTECTED] writes: GG Oops, my circular ref code is/was screwy... and $SEEN{$_} = $rval or $SEEN = (); that last line looks screwy too! :-) assigning an empty list to a scalar? i think you meant to assign to %SEEN. but why reinvent the wheel with this

RE: RFC 67 (v1) Deep Copying, aka, cloning around.

2000-08-08 Thread Peter Scott
At 04:17 PM 8/8/00 -0500, Garrett Goebel wrote: Here's a version of my own kludgey deep copy. -Updated to use our mythical -CLONE method, and watch for circular references... Great stuff, I've put it in v2. [snip] : /^CODE$/ ? $_[0]# " (B::Deparse) [snip] I would like deep copying to

Re: Things to remove

2000-08-08 Thread Mike Pastore
Perl++ :) On Tue, 8 Aug 2000, Bryan C. Warnock wrote: On Tue, 08 Aug 2000, Bennett Todd wrote: If perl6 substantially fails to fill the important roles that perl5 fills, we should stop screwing everybody up by calling it "perl", and call it something else. Hmmm. I vote for

Re: Error handling

2000-08-08 Thread Peter Scott
At 06:45 PM 8/8/00 -0400, Bryan C. Warnock wrote: I think that Perl survived its first through fifth births because the idioms it chose to implement were familiar. One could conceivably create a semantically pure language with no platform or OS dependencies, but then no one would use it.

Re: Error handling

2000-08-08 Thread Ted Ashton
Thus it was written in the epistle of Peter Scott, I do not want a language designed by a committee, or even a democracy. This is art, not politics. Preach on, brother! Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University

RFC 62 (v1) Wildcards for multiple module imports

2000-08-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Wildcards for multiple module imports =head1 VERSION Maintainer: Peter Bevan [EMAIL PROTECTED] Date: 8 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 62 =head1 ABSTRACT It

RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE New pragma 'scope' to change Perl's default scoping =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 07 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 64 =head1

  1   2   >