RE: Larry's Apocalypse 1

2001-04-10 Thread Philip Newton
-- a little playful fun. Would your proposal imply that I would not be able to open this file any more without resorting to "tricks" such as sysopen or './http://blabla'? Just wondering. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: defined: Short-cutting on || with undef only.

2001-02-16 Thread Philip Newton
ssed in p5p several times. There was even code posted to p5p at one point that would introduce the operator (spelled, I believe, |||) into the sources. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> I appreciate copies of replies to my messages to Perl6 lists.

Re: What will the Perl6 code name be?

2000-10-24 Thread Philip Newton
it? Since "use" includes a "require". (On the other hand, it's a require in a BEGIN block, so that may not be a problem after all.) Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

2000-10-05 Thread Philip Newton
be kept in mind. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> I appreciate copies of replies to my messages to Perl6 lists.

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

2000-10-04 Thread Philip Newton
derstand/patch/correct multiple markup formats. I believe Perl can still embed raw *roff. IIRC, in Perl 1, POD hadn't been invented, and Larry used raw *roff inside Perl code. However, I don't think this practice is encouraged these days ;) Cheers, Philip -- Philip Newton <[EMAIL

RE: Perl already allows XML for documentation (was Re: RFC 357 (v1) Perl should use XML for documentation instead of POD)

2000-10-04 Thread Philip Newton
pod > > =cut > > it can certainly be made to skip between: > > > Skipping between =pod and =cut is a lot easier than between and when you are reading a line at a time; you can simply strcmp them and not have to worry about what happens if there's other stu

Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD

2000-10-04 Thread Philip Newton
d set of documentation that is of no use to anyone." I think it's more likely that switching to an XML docset produces very little documentation, and what there is will be of widely varying quality. Not everyone will want to expend the effort involved to plan out, carefully, their documen

Re: RFC 288 (v2) First-Class CGI Support

2000-10-04 Thread Philip Newton
[Iain, I'd really appreciate it if you'd copy me on your replies to my posts. The volume is so high that I don't always get time to grovel through the digests in a timely manner.] On Sat, 30 Sep 2000, iain truskett wrote: > * Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 0

Re: RFC 358 (v1) Keep dump capability.

2000-10-02 Thread Philip Newton
top them from being accepted. Maybe you want a way to get free-standing executables; well, there's an RFC for that, too. I just don't think dump is the road to that. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 288 (v2) First-Class CGI Support

2000-09-29 Thread Philip Newton
On 28 Sep 2000, at 21:36, iain truskett wrote: > * Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]: > > On 27 Sep 2000, at 23:48, iain truskett wrote: > > > > So surely you'd want %HTTP (the input headers) to also be an array > > > rather than a hash, s

Re: RFC 333 (v1) Add C and C funtions to coredistribution

2000-09-29 Thread Philip Newton
@out = header (%temp = unheader @in); If you just take unheader's output and feed it to header, the order will be the same. Thanks for bearing with me ;) Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 333 (v1) Add C and C funtions to coredistribution

2000-09-29 Thread Philip Newton
s, conversion to lowercase, and so forth. > So, this call: > >@out = header unheader @in; > > Should result in C<@out> being exactly equivalent to C<@in>. It cannot, of course, since the order of hash keys obtained by flattening the hash is not necessarily the same

Re: RFC 288 (v2) First-Class CGI Support

2000-09-28 Thread Philip Newton
On 27 Sep 2000, at 23:48, iain truskett wrote: > So surely you'd want %HTTP (the input headers) to also be an array > rather than a hash, since they'd be required in order as well? I don't care, because I don't work with this much. And I don't know whether I'd need to bear in mind the protocol

Re: RFC 288 (v2) First-Class CGI Support

2000-09-27 Thread Philip Newton
Better to have something that's either (a) pluggable without having to replace all of Perl, or (b) header-agnostic, so you have to specify your own ordering -- which also means you *can* specify your own ordering. Cheers, philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 320 (v1) Allow grouping of -X file tests and add C builtin

2000-09-27 Thread Philip Newton
big arrow, which is equivalent to - "name" and a comma. Fortunately, - "string" doesn't convert "string" to a number (0) and then apply negation but results in "-string" (`perldoc perlop` says: "If the operand is an identifier, a string consisting of a minus sign concatenated with the identifier is returned. [...] One effect of these rules is that `-bareword' is equivalent to `"-bareword"'." Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: perl6storm #0050

2000-09-27 Thread Philip Newton
On 26 Sep 2000, Johan Vromans wrote: > Philip Newton <[EMAIL PROTECTED]> writes: > > > so fewer "cluttering" > > parentheses are needed to make things readable while still being correct. > > Since when do parentheses make things less readable? Each par

Re: perl6storm #0050

2000-09-27 Thread Philip Newton
On 26 Sep 2000, Johan Vromans wrote: > Philip Newton <[EMAIL PROTECTED]> writes: > > > so fewer "cluttering" > > parentheses are needed to make things readable while still being correct. > > By the same reasoning, you can reduce the use of curlie

perl6storm #0073

2000-09-23 Thread Philip Newton
::Blurf'->meth().) Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

perl6storm #0060: formats

2000-09-23 Thread Philip Newton
escape sequences cannot be defined beforehand). Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

perl6storm #0050

2000-09-23 Thread Philip Newton
more tightly than || or &&), so fewer "cluttering" parentheses are needed to make things readable while still being correct. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: PERL6STORM - tchrist's brainstorm list for perl6

2000-09-23 Thread Philip Newton
On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0035 > > Make A->B place A in string context, like => does. > That way no A()->B naughtiness. While still allowing explicit A()->B? Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

perl6storm #0011: interactive perl mode

2000-09-23 Thread Philip Newton
wondering whether perl was installed on a machine and typed 'perl' to see -- and "nothing happened". (I suppose either of `which perl` or `perl -v` would be a better way to find out, but still.) Having Perl tell me 'this is perl5.7.0\n> ' or similar would have be

perl6storm #0010: kill all defaults

2000-09-23 Thread Philip Newton
anal python folks. What are defaults, in this context? Things like abs taking $_ if no variable is specified? Or localtime taking time()? Or what? Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Philip Newton
ng $seen{$word}++ turn $seen{$word} to undef is bad, if (undef)++ assumes NULL semantics everywhere, hence "one more than unknown" = "still unknown". Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Philip Newton
nicer than $seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1; or if(defined($seen{$word})) { $seen{$word}++ } else { $seen{$word} = 1 } or similar. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-18 Thread Philip Newton
On 15 Sep 2000, at 11:25, Steve Fink wrote: > Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? While 'foo\\' ne 'foo\' :-) (specifically, the former is not a syntax error :-) Cheers, Philip

Re: RFC 223 (v1) Objects: C pragma

2000-09-15 Thread Philip Newton
On 14 Sep 2000, at 14:18, Nathan Wiger wrote: > Before you balk at #1 in favor of religious flexibility, please consider > how unmaintainable Perl code would be if @ARGV, or $AUTOLOAD, or STDERR, > or @INC, or chomp(), or split(), or any other widely-used variable or > function was renameable. If

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Philip Newton
On 14 Sep 2000, at 21:06, Glenn Linderman wrote: > I _like_ the conceptual idea, here. But I think we need a different kind of > quoting, not extend single quote semantics. Single quote semantics are really, > really, good for exact quoting. I'm sure you (since you mention VMS) find single > q

Re: RFC 226 (v2) Selective interpolation in single quotish context.

2000-09-15 Thread Philip Newton
On 15 Sep 2000, at 1:10, Perl6 RFC Librarian wrote: > With this proposal, the scalar C<$filename> can be tagged to be interpolated > by the C<\I...\E> pair and the double quotish context replaced by single > quotish context resulting in the following: Definitely with this change, you should incl

Re: RFC 215 (v2) More defaulting to $_

2000-09-14 Thread Philip Newton
or in a list context, does "C<< (<>); >>" break, or does it mean something like "C>> @_ = <>; >>" ? I especially wonder about your c<;> escape. > =head2 3: For Functions In General > > "C;", "C", and many others could use C<$_>. Er, they already do. man perlfunc, and/or see my list above. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 215 (v2) More defaulting to $_

2000-09-14 Thread Philip Newton
t;Press any key" and wasting the > input. I suggest again: s/"<>"/"C<< <> >>"/g; s/C<$_ = > <>/C<< $_ = <> >>/; Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 215 (v1) More defaulting to C<$_>.

2000-09-13 Thread Philip Newton
>". I can't yet think of code that this extension would break. And by the way, this would break code that uses <>; to discard a line of input but wishes to preserve $_. (For example: print "Press Enter to continue\n"; ; print "Continuing to operate on '$_'\n";) Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 162 (v1) Filtering Here Docs

2000-08-29 Thread Philip Newton
On 27 Aug 2000, Perl6 RFC Librarian wrote: > With a here doc print <

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and HereDocs)

2000-08-29 Thread Philip Newton
ng out in the body of the document, makes indenting blocks of text > difficult and causes errors and confusion. s/verbatum/verbatim/; Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-17 Thread Philip Newton
stops working. I think the above method (having to add your own spaces, in the exact number required at the moment) is too fragile. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

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

2000-08-17 Thread Philip Newton
ikely that there will be any in the near future, but that there is provision for them. The IERS (International Earth Rotation Service) monitors things and sends out a bulletin twice a year, saying whether there will, or will not, be a leap second on 30 June or 31 December (and which sign it will have if there is one). Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 110 (v1) counting matches

2000-08-16 Thread Philip Newton
ing loop round a m//g. But this all seams rather messy. $count = () = $variable =~ m/foo/g; The () puts the match into list context (so the matches themselves are returned), and that list assignment evaluated in scalar context, giving the number of values assigned to the list. Cheers, Philip -

Re: command line option: $|++

2000-08-15 Thread Philip Newton
agravating to me because in order to > get decent output I really had to do this: > > cat /etc/passwd | perl -nfe '$\="\n";print((split/:/)[0])' > > or > > cat /etc/passwd | perl -nfe 'print((split/:/)[0]."\n")' So add -l to your line.

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

2000-08-12 Thread Philip Newton
ple, MS-DOS's epoch is 1 January 1980 AFAIK. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 83 (v1) Make constants look like variables

2000-08-12 Thread Philip Newton
there ever been an RFC discussing retention or deletion of this backwards-compatibility feature? Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

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

2000-08-12 Thread Philip Newton
On Fri, 11 Aug 2000, Nathan Wiger wrote: > Philip Newton wrote: > > So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan', > > 'Feb') or qw(dummy Jan Feb)... oh well. > > Far better, use the new builtin object methods: >

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

2000-08-11 Thread Philip Newton
pecific to more general, so if you don't want the general bits (for example, only the time), you just assign to ($sec, $min, $hr) = localtime; . > Note that the month, day, and year are not 0-padded. Apparently, neither is hour. And why not, pray? I'd like to see the justification for this decision. >8. Reverted to GMT from UTC since most systems are internally > maintained in GMT, not UTC. What's the difference? Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 94 (v1) Rename @ARGV to @ARGS

2000-08-11 Thread Philip Newton
s like or should > be used like C's argv/argc 6. (arguable) This way, $ARGV (name of current file while reading from <>) will not collid with @ARGS if sigils were dropped (aka Highlander notation). Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

Re: RFC 90 (v1) Builtins: zip() and unzip()

2000-08-11 Thread Philip Newton
I misunderstood the example and you wanted the result to be ([1,2,3], [4,5,6]) in which case unzip would not have to do nearly as much work. But then (1..7) would unzip(3) into ([1,2,3], [4,5,6], [7]). Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

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

2000-08-07 Thread Philip Newton
7;t being used all of the time, whether in CGI code or not. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>