Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-11 Thread Bart Lateur
On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote: I find nothing in the documentation that suggests that = is anything other than a plain comma operator, yet you call it a "first-argument-stringifying comma operator". In fact, the documentation explicitly claims "=" is a synonym of ","

Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-11 Thread Bart Lateur
On Fri, 11 Aug 2000 11:01:30 -0400 (EDT), Simply Hao wrote: What about with -w: read = $value What warning? Oh, you're probably using a pre-5.005 Perl. 5.004 (the latest MacPerl, for example) still had that warning. 5.005 and later, do not, any more. -- Bart.

Re: RFC 74 (v1) Proposal to rename Cimport and Cunimp

2000-08-11 Thread Bart Lateur
On Fri, 11 Aug 2000 02:38:24 -0700, Nathan Wiger wrote: The problem with this is that they rely on the indirect object notation, same as new(). So: import Module; # calls Module-import new Module;# calls Module-new bob Module;# calls Module-bob So import and

Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-11 Thread Bart Lateur
On Fri, 11 Aug 2000 15:27:03 +0200, Bart Lateur wrote: I kinda like it. I'm not sure any more if I still like it as much. As proposed, it seems very unperlish (as we know Perl today). It would virtually turn Perl into a whole different language. Well, half a different language. ;-) I, too

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

2000-08-10 Thread Bart Lateur
On Wed, 9 Aug 2000 22:57:34 -0500, Jonathan Scott Duff wrote: By "local timezone" do you mean that some sort of inspection happens to determine the local timezone and the date() intrinsically knows about it? What about daylight savings time? I presume the ability to specify an offset from GMT

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-10 Thread Bart Lateur
On Thu, 10 Aug 2000 13:22:46 +1000 (EST), Damian Conway wrote: The RFC I'm writing specifies that if the subroutine being called has a lazy context specifier on a given argument, that argument is only evaluated when the value of the corresponding element of @_ is fetched, stored, or eval'd. So

Re: Proposal for \v and \V, the small- and large- cut regex opera tors.

2000-08-10 Thread Bart Lateur
On Thu, 10 Aug 2000 04:42:56 -0400, Ilya Zakharevich wrote: Variable interpolation can be handled using Damian's curried expressions. On XRay: Summary for query "curried;Damian": found 0 matches in 0 files. Look up RFC 23 on http://dev.perl.org/rfc/: "Higher order functions". --

Re: Things to remove

2000-08-10 Thread Bart Lateur
On Sat, 5 Aug 2000 09:44:47 -0500, Jonathan Scott Duff wrote: Here in my pre-caffiene morning trance it occurs to me that a few of the "fringe" features of perl should be removed from the langauge. Here's a few things that I would venture to say that none of the "perl5 is my first perl" people

Re: Portable upper/lower case regexp matches

2000-08-10 Thread Bart Lateur
On Thu, 10 Aug 2000 17:21:44 +0300, Jason Elbaum wrote: \x match lowercase alpha char \X match uppercase alpha char Thus /\X\x*/ would match all capitalized words, while /\X+/ would match acronyms, and /(\X\x+)+/ would match Java class names. You've got my vote, apart

Re: RFC 80 (v1): Exception objects and classes for builtins

2000-08-10 Thread Bart Lateur
On Thu, 10 Aug 2000 09:34:43 -0700, Peter Scott wrote: Do you propose this solely to conserve keywords, or is there another advantage? I find try { # } catch Exception::Thingy with { # } catch Exception::Whatsit with { # }

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

2000-08-10 Thread Bart Lateur
On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote: people in Newfoundland are going to expect to be able to pass in -0230 and have that work, and that's interestingly hard. What's so hard? Subtracting 2 hours and 30 minutes from the official referential time (GMT)? Or the Daylight

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

2000-08-09 Thread Bart Lateur
On Wed, 9 Aug 2000 09:23:02 -0400, John Porter wrote: That is way too simplistic. I for one think the current behavior of chomp() is ideal for its simplicity. while() { /foo/ and next; # why bother chomping? if ( /bar/ ) { print; #

Re: RFC 71 (v1) Legacy Perl $pkg'var should die

2000-08-09 Thread Bart Lateur
On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote: D'oh! ;-) Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with this appropriate name any more. http://search.cpan.org/search?mode=modulequery=d%3A%3Aoh OTOH, try this: $hash{a'b} = 1; print keys

Re: chomp unchomp

2000-08-09 Thread Bart Lateur
On Wed, 9 Aug 2000 15:42:24 -0400, John Porter wrote: Bryan C. Warnock wrote: Chomp removes one or more line separators from the end. It does? You're using a different version of Perl than I am. Try setting $/ to the empty string. (not undef!) -- Bart.

Re: RFC 76 (v1) Builtin: reduce

2000-08-09 Thread Bart Lateur
On 09 Aug 2000 13:49:24 -0400, Chaim Frenkel wrote: Assuming a "use tristate", undef + number = undef This might require that the reduce function be able to ignore undefs. Either always under the tristate pragma. Or on a case by case basis. grep defined, LIST -- Bart.

Re: Things to remove

2000-08-09 Thread Bart Lateur
On Tue, 8 Aug 2000 11:25:56 -0500, Jonathan Scott Duff wrote: Someone proposed (I think I deleted that email) to make while (FH) { ... } work like while (FH) { chomp; ... } Guilty. I've benchmarked the above codes, with '...' replaced by nothing, chomp vs. the -l command

Re: RFC 78 (v1) Improved Module Versioning And Searching

2000-08-09 Thread Bart Lateur
On 9 Aug 2000 15:03:40 -, Perl6 RFC Librarian wrote: Improved Module Versioning And Searching [About loading different versions of a module at the same time] The whole thing sounds whacky to me. I don't really mind that @INC is searched for the most recent version of a module, but

vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)

2000-08-09 Thread Bart Lateur
On Wed, 09 Aug 2000 09:41:22 -0400, Dan Sugalski wrote: @foo = @bar * 12; @foo = map { $_ * 12 } @bar; I don't see the need for a new notation. Well, compactness for one. With a scalar on one side it's less odd (it was a bad example). When funkier, though: @foo = @bar * @baz;

Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)

2000-08-09 Thread Bart Lateur
On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote: @foo = @bar * @baz; Given that the default action of the multiply routine for an array in non-scalar context would be to die, allowing user-overrides of the functions would probably be a good idea... :) [Is this still -internals? Or

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 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: 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: 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 tha

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 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: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

2000-08-08 Thread Bart Lateur
On Tue, 8 Aug 2000 11:51:36 -0700, Damien Neil wrote: 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 localtime() for over a decade. Why do we suddenly want to make them all

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

2000-08-08 Thread Bart Lateur
On Tue, 8 Aug 2000 18:35:46 -0400, Michael Mathews wrote: I frequently use chomp in ways that have nothing to do with "reading from files" and I would bet this is true for everyone here too. For example: use CGI; $cgi = new CGI; $foo = $cgi-param('foo'); #as part of doing stuff to the user

Re: RFC 49 (v1) Objects should have builtin string SCALA

2000-08-07 Thread Bart Lateur
On Sun, 6 Aug 2000 18:28:29 -0800, Michael Fowler wrote: print $pw; print scalar $pw; These resulting in a $pw-STRINGIFY or $pw-TO_STRING call is also confusing; neither are being used as strings. Oh yes they are. $^W = 1; my $x; print $x; This complains of

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

2000-08-07 Thread Bart Lateur
On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote: I think the concept's great, just that the notation is really hard to read, and doesn't necessarily scream "function" to me (especially since _ is from stat already). I don't see why you can't simply use _. From the context, you clearly

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

2000-08-07 Thread Bart Lateur
On Sun, 06 Aug 2000 21:54:47 -0700, Nathan Wiger wrote: Seems to me that a leading _ is worse for this than ^ Whatever prefix you choose, it should NEVER EVER be a \w character. And the general rule, until now at least, is that only characters from the ASCII repertoire are acceptable for

Re: RFC 50 (v1) BiDirectional Support in PERL

2000-08-07 Thread Bart Lateur
On Mon, 7 Aug 2000 12:04:11 +0300, Roman M . Parparov wrote: I wrote a WWW mail program with hebrew support once. Pain in the ass to invent and reinvent functions for printing Hebrew correctly. Moreover, a lot of self-written reversing and replacing reduces the performance from what it would be

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

2000-08-07 Thread Bart Lateur
On 7 Aug 2000 14:28:03 -, Perl6 RFC Librarian wrote: Compilation: Remove requirement for final true value in require'd and do'ed files Er... "do'ne" files? Anyway, There is at least one case where you need this true value: if the file accidently is empty (or equivalent). I've had that

Re: DRAFT RFC: Enhanced Pack/Unpack

2000-08-07 Thread Bart Lateur
On Mon, 7 Aug 2000 13:52:09 -0400, John Porter wrote: Right, VAX is strictly little-endian. I.e. the address of a *word is the address of its least significant byte. (That's little-endian, isn't it?) Right. Why you people don't call it "Intel" vs. "Motorola", like the rest of the civilised

Re: RFC 22 (v1) Builtin switch statement

2000-08-07 Thread Bart Lateur
On 4 Aug 2000 14:59:06 -, Perl6 RFC Librarian wrote: %special = ( woohoo = 1, d'oh = 1 ); while () { switch ($_) { case (%special) { print "homer\n"; last } # if $special{$_} Hold it. Is that if($special{$_}) { ...

Re: RFC 50 (v1) BiDirectional Support in PERL

2000-08-07 Thread Bart Lateur
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 characters to correctly display on a device that can not understand rtl

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

2000-08-07 Thread Bart Lateur
On 7 Aug 2000 16:06:44 -, Perl6 RFC Librarian wrote: This RFC contains two proposed changes. First, as it is common to want to removed newlines upon reading a file, while (chomp(FILEHANDLE)) { . . . } should become the equivalent of while (FILEHANDLE) { chomp; . . .

Re: Language RFC Summary 4th August 2000

2000-08-06 Thread Bart Lateur
On Sun, 06 Aug 2000 01:38:13 -0400, Dan Sugalski wrote: Even in perl5 an XS module can do _anything at all_. It can't access data the lexer's already tossed out. That's where the current format format (so to speak) runs you into trouble. Only if you insist on the identical syntax as it has

Re: RFC: Filehandle type-defining punctuation

2000-08-05 Thread Bart Lateur
On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote: If we've decided that chomp isn't going to return the clippings, would it not seem prudent to make while (chomp(ARGV)) work like while (ARGV) You mean, like, the -l command line switch? (see perlrun) chomp() on input, append newlines

Re: RFC 17 (v1) Organization and Rationalization of Perl

2000-08-05 Thread Bart Lateur
On Fri, 04 Aug 2000 00:47:06 -0500, J. David Blackstone wrote: As another example, at work we are in love with the $/ variable, since we often deal in multi-line records delimited with control-Y's. However, changing this variable affects _everything_, meaning modules you want to use might not

Re: RFC: Rename local() operator

2000-08-05 Thread Bart Lateur
On Fri, 4 Aug 2000 10:54:16 -0500, Jonathan Scott Duff wrote: Csave If I had my druthers, save() would be it. I'm against it. Why? Because it suggests that all it does is save the value for later retrieval. It does not: the value is cleared as well. It masks the previous global value, as if

Re: RFC: lexical variables made default

2000-08-04 Thread Bart Lateur
On Thu, 3 Aug 2000 10:48:17 -0400, John Porter wrote: OTOH, being fun (which I admit it is) is one of the reasons many people don't want to think Perl is a serious language. I don't agree. The problem is somewhere else, namely the problem that Ilya Z. brought up: the fact that there is no

Re: RFC 2 (v1) Request For New Pragma: Implicit

2000-08-04 Thread Bart Lateur
On 03 Aug 2000 22:23:08 -0400, Chaim Frenkel wrote: What would be the method to _avoid_ emitting something? What would be the result of open(Foo, "Bar")# Prints FILEHANDLE=0xdeadbeef $x++; # Prints 3 Exactly. I can think of even more cases: * What do

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

2000-08-02 Thread Bart Lateur
On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote: I used to be a C programmer myself (well OK, I was a C++ programmer...), but I'd rather any day type "localtime-year" than "(localtime)[5]". And what would you type instead of (localtime)[3, 4, 5] ? localtime-(day, month,

Re: multiline comments

2000-08-02 Thread Bart Lateur
On Wed, 2 Aug 2000 12:51:10 -0400, John Porter wrote: At the risk getting too exotic how about: #EOC; some comments EOC Just introduce a new function which is a bit bucket: # works in perl5. sub comment(@) { } comment q{ comments... }; "Function"? Who needs a function?

Re: perl 6 requirements

2000-08-02 Thread Bart Lateur
On 02 Aug 2000 16:42:35 -0700, Randal L. Schwartz wrote: Steve We could add a 'then' keyword. We have one. It's called "comma in a scalar context". :) Now do the same with a print command. Aren't you trying to hard leaning backwards? -- Bart.

<    1   2   3