Re: RFC 196 (v1) More direct syntax for hashes

2000-09-08 Thread Bart Lateur
On Wed, 6 Sep 2000 22:58:05 -0400, John Porter wrote: keys %hash = @things; is defined as being equivalent to @hash{ @things } = (); Two more details to think about: %hash = ( b = 'beta', d = 'delta' ); keys %hash = qw(a b c); What happens to the values that

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

2000-09-18 Thread Bart Lateur
On Sun, 17 Sep 2000 21:59:47 -0700, Nathan Wiger wrote: Yeah, I for one think %hashes should be interpolated exactly like @arrays. It's simple and consistent. Simple and consistent would be behaviour like "@{[%hash]}" However, convenient it is not, getting all key/value pairs in one

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

2000-09-18 Thread Bart Lateur
On 17 Sep 2000 23:54:05 -0400, Chaim Frenkel wrote: What about formating the output as a value that can be used by eval? %hash = (a = 1, b = 'the world'); print "%{hash}\n"; ('a' = 1, 'b'= 'the world') So, what about arrays? Or scalars? We have Data::Dumper for that. --

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

2000-09-21 Thread Bart Lateur
On 20 Sep 2000 04:06:02 -, Perl6 RFC Librarian wrote: Ilya Zakharevich brought up the issue of a potential problem with objects which use blessed list references as their internal structure, and their use as indices. Given a Bignum class, which stores its (external) value internally as a

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

2000-09-26 Thread Bart Lateur
On Mon, 25 Sep 2000 19:26:38 -0700, Nathan Wiger wrote: I agree with both of you. It would be nice if @$ precedence worked as Bart specified, but I still think that arrays should be arrays. The problem is that $name = "myarray"; @$name = (1,2,3); print @$name[0,1]; # 1,2 Is very

$SIG{__DIE__} should be localized and cleared at the start of an eval block

2000-08-25 Thread Bart Lateur
Watch the behaviour of this code snippet in a current Perl (5.6): eval { print STDERR "Testing...\n"; warn "Oops!"; print STDERR "Still going...\n"; die "Argh!!!"; print STDERR "I died, didn't I?\n"; }; print

The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Bart Lateur
Likely this should be an RFC. I'm too lazy to write it in that format right now, but I want to send this thing out before it slips my mind again. Somebody else may pick it up, if he or she wants it. If not, I'll eventually may have to do it myself. The articial distinction between do

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

2000-08-31 Thread Bart Lateur
On Thu, 31 Aug 2000 11:21:26 -0600, Tom Christiansen wrote: One could argue that do{} should take return so it might have a value, but this will definitely annoy the C programmers. So what. "Annoying" would be to have a situation that is *less* powerful in Perl than in C, not *more*. Oh, and

Re: Final draft of RFC 120: Implicit counter in for statements

2000-09-18 Thread Bart Lateur
On Mon, 18 Sep 2000 23:11:28 +0100, John McNamara wrote: foreach $item (@array) { print $item, " is at index ", $#, "\n"; } Maybe I'm a little late... But I just thought how neat it would be if this would also extend to map() and grep(). Remember, officially the processing

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

2000-09-08 Thread Bart Lateur
On Fri, 8 Sep 2000 01:18:19 -0700 (PDT), Ask Bjoern Hansen wrote: I really don't understand why you want to have what's printed. It is handy, sometimes. But I do think that the overhead of creating a longish string every time you print something, which is then simply discarded, is not really

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

2000-09-18 Thread Bart Lateur
On Mon, 18 Sep 2000 10:57:49 +0200, H.Merijn Brand wrote: perl5 formats do NOT support lexicals Eh? It looks like it, though. my $foo; format STDOUT = @ $foo . $foo = 123; write; $foo = 45; write; It looks *so much* that

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

2000-08-24 Thread Bart Lateur
On Thu, 24 Aug 2000 13:27:01 -0700, Nathan Wiger wrote: It's a pain if you want to support both function-oriented and object-oriented calling forms, as CGI.pm does. For example, you can use both of these: print header; print $r-header; with CGI.pm. Now you need a self_of_default special

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

2000-08-28 Thread Bart Lateur
On Sun, 27 Aug 2000 06:14:00 -0700, Matt Youell wrote: So an int gets stored as two bytes and not four or eight. Gee, I thought it was more like 30. The savings in bytes don't look too impressive in this case. 4 byte addition is as fast as 2 byte addition on most pmodern platforms -- and you

Re: RFC 187 (v1) Objects : Mandatory and enhanced second argument to Cbless

2000-09-03 Thread Bart Lateur
On 1 Sep 2000 20:59:10 -, Perl6 RFC Librarian wrote: When omitted, the second argument to Cbless currently defaults to the name of the package from which the call is made. The word "from" doesn't look like it's been used 100% correctly. "Being called from" suggests that it's the name af

Re: RFC 187 (v1) Objects : Mandatory and enhanced second argument to Cbless

2000-09-03 Thread Bart Lateur
On 1 Sep 2000 20:59:10 -, Perl6 RFC Librarian wrote: This RFC proposes that the second argument to Cbless be made mandatory, and that its semantics be enhanced slightly to cover a common, ugly, and frequently buggy usage. Ooh, how about this alternative. There must be an RFC making the

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

2000-09-06 Thread Bart Lateur
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote: exists (sometimes causes autovivification, which affects Ckeys) That's not technically accurate--exists never causes autovivification. print exists $hash{foo}{bar}{baz}; use Data::Dumper; print Dumper

Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Bart Lateur
On Thu, 14 Sep 2000 18:37:22 -0500, David L. Nicol wrote: print "Today's weather will be ${weather-temp} degrees and sunny."; which would follow the "You want something funny in your interpolated scalar's name or reference, you put it in curlies" rule. I too feel that an approach like

Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Bart Lateur
On Fri, 15 Sep 2000 01:36:50 -0800, Michael Fowler wrote: Or maybe an alternative, using : "foo foo(arg, arg, arg) bar" "foo { foo(arg, arg, arg) } bar" Ah, yes, {...}, I kinda like that. Unfortunately, in regexes, /{1,3}/ means matching 1 to three ampersands. There's a slight

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

2000-09-20 Thread Bart Lateur
On Mon, 18 Sep 2000 13:26:45 -0700, Glenn Linderman wrote: Read RFC 241 for a brief overview of pseudo-hash problems. I've already read RFC 241. Re-reading in this context results in the following comments/quests for information. The remaining quotes here come from RFC 241...

Re: RFC 110 (v3) counting matches

2000-08-29 Thread Bart Lateur
On Tue, 29 Aug 2000 08:51:29 -0400, Mark-Jason Dominus wrote: There are many operations that would be simpler if there was a magic array that contained ($1, $2, $3, ...). If anyone wants to write an RFC on this, I will help. Heh. I once complained about the lack of such an array, in

Re: RFC 110 (v2) counting matches

2000-08-29 Thread Bart Lateur
On Tue, 29 Aug 2000 09:00:43 -0400, Mark-Jason Dominus wrote: And, I don't really see the need for the comma. m/.../CountInsensitive (instead of m/.../ti) I guess, but to me CountInsensitive looks like one option, not two. That goes fot this too. : m/.../iCount

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

2000-09-07 Thread Bart Lateur
On 06 Sep 2000 18:04:18 -0700, Randal L. Schwartz wrote: I think the -1 indexing for "end of array" came from there. Or at least, it was in Perl long before it was in Python, and it was in Icon before it was in Perl, so I had always presumed Larry had seen Icon. Larry? Do not assume that these

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

2000-09-14 Thread Bart Lateur
On 30 Aug 2000 02:13:38 -, Perl6 RFC Librarian wrote: Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade() Why? What's next, replace the regex syntax with something that more closely ressembles the rest of Perl? Regexes are a language within the language. And not a tiny

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

2000-09-14 Thread Bart Lateur
On Thu, 14 Sep 2000 08:47:24 -0700, Nathan Wiger wrote: One thing to remember is that regex's are already used in a number of functions: @results = grep /^VAR=\w+/, @values; You are being mislead. You might just as well say that length() is being used in other functions: @results =

Re: \z vs \Z vs $

2000-09-20 Thread Bart Lateur
On Wed, 20 Sep 2000 10:03:08 +0100, Hugo wrote: In 12839.969393548@chthon, Tom Christiansen writes: :What can be done to make $ work "better", so we don't have to :make people use /foo\z/ to mean /foo$/? They'll keep writing :the $ for things that probably oughtn't abide optional newlines. Gee

Re: RFC 110 (v6) counting matches

2000-09-21 Thread Bart Lateur
On 20 Sep 2000 21:37:03 -, Perl6 RFC Librarian wrote: Bart Lateur: '()=' is not perfect. It is also butt ugly. It is a "dirty hack". Please don't hold this against me! I was arguing for a cleaner looking generic alternative for "()=", the now defunct list() operator.

Re: RFC 308 (v1) Ban Perl hooks into regexes

2000-09-26 Thread Bart Lateur
On 25 Sep 2000 20:14:52 -, Perl6 RFC Librarian wrote: Remove C?{ code }, C??{ code } and friends. I'm putting the finishing touches on an RFC to drop (?{...}) and replace it with something far more localized, hence cleaner: assertions, also in Perl code. That way, /(?!\d)(\d+)(?{$1

Re: RFC 308 (v1) Ban Perl hooks into regexes

2000-09-26 Thread Bart Lateur
On Tue, 26 Sep 2000 13:32:37 -0400, Michael Maraist wrote: I can't believe that there currently isn't a means of killing a back-track based on perl-code. Looking through perlre it seems like you're right. There is, but as MJD wrote: "it ain't pretty". Now, semantic checks or assertions would

Re: is \1 vs $1 a necessary distinction?

2000-09-28 Thread Bart Lateur
On Wed, 27 Sep 2000 10:34:48 -0500, Jonathan Scott Duff wrote: If $1 could be made to work properly on the LHS of s///, I'd vote for that being The Way. I disagree, because \1 is different from a variable $foo in at least two ways: * $foo is compiled into /$foo/ before anything is matched. \1

Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching

2000-09-29 Thread Bart Lateur
On Fri, 29 Sep 2000 13:19:47 +0100, Hugo wrote: I think that involves rewriting your /p example something like: if (/^$pat$/z) { print "found a complete match"; } elsif (defined pos) { print "found a prefix match"; } else { print "not a match"; } Except that this isn't

Re: RFC 348 (v1) Regex assertions in plain Perl code

2000-09-30 Thread Bart Lateur
On Sat, 30 Sep 2000 00:57:47 +0100, Hugo wrote: :"local" inside embedded code will no longer be supported, nor will :consitional regexes. The Perl5 - Perl6 translator should warn if it :ever encounters one of these. I'm not convinced that removing either of these are necessary to the main

Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching

2000-09-30 Thread Bart Lateur
On Tue, 26 Sep 2000 11:55:32 +1100 (EST), Damian Conway wrote: Wouldn't this interact rather badly with the /gc option (which also leaves Cpos set on failure)? Yes. The easy way out is disallow combining /gc wit h/z. But, since this typically one of the applications it is aimed for, I should

Re: RFC 72 (v4) Variable-length lookbehind.

2000-09-30 Thread Bart Lateur
On 30 Sep 2000 19:50:27 -, Perl6 RFC Librarian wrote: In Perl6, lookbehind in regular expressions should be extended to permit not only fixed-length, but also variable-length lookbehind. I see no mention of negative lookbehind. As I wrote before, in: /(?!ab*c)x/ The lookbehind

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

2000-09-30 Thread Bart Lateur
On 28 Sep 2000 20:57:39 -, Perl6 RFC Librarian wrote: Currently, C\1 and $1 have only slightly different meanings within a regex. Let's consolidate them together, eliminate the differences, and settle on $1 as the standard. I wrote this before, but apparently you didn't hear it. Let me

redraft for v2: RFC 332 Regex: Make /$/ equivalent to /\z/ under the '/s' modifier

2000-10-01 Thread Bart Lateur
=head1 TITLE Regex: Make /$/ equivalent to /\z/ under the '/s' modifier =head1 VERSION Maintainer: Bart Lateur [EMAIL PROTECTED] Date: 1 Oct 2000 Mailing List: [EMAIL PROTECTED] Number: 332 Version: 2 Status: Developing (redraft) =head1 ABSTRACT To most Perlers, /$/ in a regex

redraft (v2) for RFC 348 Regex assertions in plain Perl code

2000-10-01 Thread Bart Lateur
=head1 TITLE Regex assertions in plain Perl code =head1 VERSION Maintainer: Bart Lateur [EMAIL PROTECTED] Date: 28 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 348 Version: 2 Status: Developing (candidate for freeze) =head1 ABSTRACT Likely the most justifiable reason to want

Re: redraft (v2) for RFC 348 Regex assertions in plain Perl code

2000-10-01 Thread Bart Lateur
On Sun, 01 Oct 2000 18:43:27 +0100, Hugo wrote: :This makes the implementation very tricky. I :wouldn't be surprised if precisely this feature is the main reason why :the current implementation is so notoriously unstable. I'm not aware of any instability caused by this. The instability is

Re: RFC 16 (v2) Keep default Perl free of constraints such as warnings and strict.

2000-09-16 Thread Bart Lateur
On Sat, 16 Sep 2000 09:39:28 -0700, Nathan Wiger wrote: But not: no strict 'refs';# on by default, disable use strict 'vars'; Which is too confusing. I wonder if 'strict' shouldn't be turned into 2 or 3 separate pragma's, instead of just one. IMO, there isn't a strong between strict

Re: Warnings, strict, and CPAN

2001-02-18 Thread Bart Lateur
On Fri, 16 Feb 2001 21:03:54 -0800, Edward Peschko wrote: It is one hell of a burden to find a missing 'use strict' or 'use warnings'. 'Well, type them then' you say. Right, and always type ';' at each line, or 1; at the end of each file. Its as unavoidable as a *syntax error*, which is the

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: Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)

2000-09-14 Thread Bart Lateur
On Wed, 13 Sep 2000 19:57:28 -0700, Nathan Wiger wrote: Perl should stop nagging about this. Perl should be smart and not bother you about uninitialized values in the following situations: - string concat - string comparison Allow me to disagree. In my case, I mostly use variables in

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

2000-09-16 Thread Bart Lateur
On Sat, 16 Sep 2000 10:26:48 +0100, Hildo Biersma wrote: length(@ary) deserves a warning Right now, the Lint back-end gives a warning in these cases (use of array in scalar context). Can we make the RFC more generic, and propose to move the Lint warnings into the core? But using arrays in a

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

2000-09-16 Thread Bart Lateur
On Sat, 16 Sep 2000 16:19:08 +0100, Hildo Biersma wrote: But using arrays in a scalar context usually isn't an error. So, we make the warnings smarter and make sure they can be turned off... And distinguish between simply an array in scalar context, and an array used as an argument for

Re: RFC 212 (v1) Make length(@array) work

2000-09-20 Thread Bart Lateur
On Tue, 19 Sep 2000 07:40:07 -0700 (PDT), Dave Storrs wrote: Doesn't this reflect C's idea of "a string is an array of characters"? Which isn't the idea behind strings in Perl. The basic idea is wrong. Therefore, making length(@array) work, would be a wrong signal. I personally do not

Re: RFC 212 (v1) Make length(@array) work

2000-09-20 Thread Bart Lateur
On Wed, 20 Sep 2000 07:03:33 -0600, Tom Christiansen wrote: I'm pretty sure it's not just the people coming from C who expect this. Uh-oh. This all points to the bug^H^H^Hdubious feature which is the sub($) context template as applied to named arrays and hashes. Requiring an explicit

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: DRAFT RFC: Enhanced Pack/Unpack

2000-08-02 Thread Bart Lateur
On Wed, 02 Aug 2000 12:22:09 -0700, Glenn Linderman wrote: [ 'bar' = 'integer32', 'baz' = 'integer32', 'count' = 'integer32' ] [ 'var1' = 'int32', 'var2' = 'int16', 'var3' = 'int8' ] That doesn't reconsider BigEndian vs. LittleEndian, AKA pack/unpack 'N' vs. pack/unpack 'V'. --

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.

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

2000-08-07 Thread Bart Lateur
On Sun, 06 Aug 2000 13:10:23 -0700, Nathan Wiger wrote: With the new date function you'll never need to call sprintf("%02d/%02d/%04d", $tm[3], $tm[4]+1, $tm[5]+1900); since you can do date(undef,"%d/%m/%Y") True, but notice that you have to specify a format. Also, why not

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 55 (v1) Compilation: Remove requirement for fina

2000-08-07 Thread Bart Lateur
On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote: A true value indicates that the file is indeed valid Perl. So is an empty file! :-) That is precisely the problem. You won't get a syntax error if this happens. Now, bringing in the million monkeys typing, again: the chances of

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: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-07 Thread Bart Lateur
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 surprised to discover that they're put in the symbol table anyway though. Check the docs again. Although not the habit, it IS allowed to use:

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

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

Against overloading || and (RFC 20) -- we just need lazy evaluation

2000-08-11 Thread Bart Lateur
I think the whole idea of overloading the '' and '||' operators is too farfetched. It's and incredibly dangerous can of worms, precedence rules changing, shortcircits not working, etc. Actually, we don't need it. All we need, is lazy evaluation. The idea comes from Lisp, where you have a

Re: RFC 76 (v1) Builtin: reduce

2000-08-11 Thread Bart Lateur
On 11 Aug 2000 09:30:03 +0300, Ariel Scolnicov wrote (and quoted): reduce avg $identity, @list This was my first point regarding Creduce -- not all functions have an identity element. One should note that in general (reduce avg $x,@list) != (reduce sum 0,@list)/@list for Iany value

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

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 48 (v2) Replace localtime() and gmtime() with da

2000-08-15 Thread Bart Lateur
On 11 Aug 2000 16:22:33 -, Perl6 RFC Librarian wrote: Currently, Perl uses the C library Clocaltime() and Cgmtime() functions for date access. However, because of many problems, these should be replaced with two new functions, Cdate() and Cgmtdate() Gee, yet again, we'll get two virtually

Re: English language basis for throw

2000-08-15 Thread Bart Lateur
On Mon, 14 Aug 2000 12:32:32 -0500, David L. Nicol wrote: I find "throw" to be a perfectly good synonym for "raise" an exception. The english language equivalent is a piece of steel machinery, when it breaks while running, which is said to "throw a rod" or "throw a bolt" depending of course on

Re: Things to remove

2000-08-21 Thread Bart Lateur
On Mon, 21 Aug 2000 06:11:02 -0600, Tom Christiansen wrote: $first = $1 if ?(^neur.*)?; $first ||= $1 if /(^neur.*)/; Now if only we had a shortcut operator which would continue only if the LHS was not defined... -- Bart.

  1   2   3   >