Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, 7 Aug 2000, Tim Jenness wrote: > Is localtime() used often enough to justify being part of > the language? You're kidding, right? We wouldn't have had all those script kiddies complaining about year 19100 bugs and month-being-off-by-one errors if localtime() wasn't being used all of the time, whether in CGI code or not. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: RFC 90 (v1) Builtins: zip() and unzip()
On 11 Aug 2000, Perl6 RFC Librarian wrote: > its arguments. C would reverse this operation. [...] > In order to reverse this operation we need an C function: > > @zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6) > @unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6]) Would it not be more natural to pass the *number* of lists to unzip, rather than the desired length? This way, unzip() would know to pick off elements two-at-a-time, three-at-a-time, etc., rather than having to go through the zipped list, count the elements, divide by $list_size, etc. Unless 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 94 (v1) Rename @ARGV to @ARGS
On 11 Aug 2000, Perl6 RFC Librarian wrote: > @ARGS is a better choice for several reasons: > >1. It's closer to a word and so is faster to read [1] > >2. It's easier to explain and remember "Your command-line > args are contained in @ARGS" > >3. When you say "$var = $ARGS[2]" it's easier to glance > at and tell what you're getting quickly > >4. It makes it more consistent with other word-like > Perl vars like $VERSION. > >5. There's no expectation that it works 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 48 (v2) Replace localtime() and gmtime() with da
On 11 Aug 2000, Perl6 RFC Librarian wrote: > In the past, Perl has provided access to date and time information > through the C library C and C functions. > Unfortunately, these functions have several "really bad things" about > them: > >1. some values are 0-indexed while others are 1-indexed >2. they return massive lists as their only interface >3. minute and second values aren't 0-padded >4. the year has to have 1900 added to it to be correct. > > While some of these are perhaps understandable, that last one just plain > doesn't make I sense Number 1 is good for indexing, and number 3 is the way it is because numbers aren't 0-padded -- after all, you didn't write "01." to "04.". (And number 4 is for hysterical raisins, of course.) > =head2 Return Values > > The return values are dependent on the context within which C is > called. For all contexts, the following are the values and their ranges: > >$hour = 0 .. 24 >$min = 00 .. 59 # 0-padded >$sec = 00 .. 59 # 0-padded >$fsec = 0 .. 1 # fractional seconds per hw clock I assume $hour, $min, $sec would be dual-valued, a la $!, so that $min might be 9 in numeric context and "09" in string context. This would save a string-to-number conversion if I want to calculate with the value of the variable -- Perl wouldn't have to translate "09" to 9 because it *is* already 9. Oh, and what about leap seconds? Shouldn't $sec's range be 00 .. 61? >$mon = 1 .. 12# hooray! >$mday = 1 .. 31 >$year = 1 .. # 4-digit! While you're at the padding job, make $hour, $mon, and $mday zero-padded to two decimal places as well, for consistency. If you say "those who want 04.07. for the Fourth of July can use sprintf", then zero-padding $min and $sec makes no sense to me, either. So, 04.07.2000 03:06:02, please. (If you want to be really consistent, zero-pad $year to four places, though that will give a Y10K problem.) > I'm still a little uneasy about C<$wday> starting with 1 == Sunday, just > because Monday seems like the first day of the week to me. But I'm not > the one writing the calendars, and it seems silly to only have one value > that's 0-indexed. Oh, well. :-) So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan', 'Feb') or qw(dummy Jan Feb)... oh well. > =head3 LIST Context > > A list of date/time values is returned. The ordering and format of these > values has been radically changed to reflect what most of us probably > view as "ordinary": > >($year, $mon, $mday, $hour, $min, $sec, $fsec, > $wday, $yday, $isdst, $isgmt, $tz) = date; > > This ordering follows the predictable pattern of being in increasing > granularity and so should be easy to remember. Just think of a > computer-esque timestamp: > >2000/11/4 12:03:09 The previous ordering follows the predictable pattern of being in decreasing granularity and so is extermely easy to remember. It also has the advantage that it goes from more specific 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 48 (v2) Replace localtime() and gmtime() with da
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:
>
>$d = date;
>print "today is ", $d->date('%A'); # Friday
This doesn't solve the problem for those who want 'F', or 'Fri', or even
'Freitag' or 'Vendredi'.
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
Re: RFC 83 (v1) Make constants look like variables
On Fri, 11 Aug 2000, Mike Pastore wrote: > $'bar = 'unchanging'; # klingon? Of course, this is impossible unless Perl6 (finally?) drops compatibility with the old Perl4 package separator '. Now, $'bar eq $::bar, and package D'oh is package D::oh. Has 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
On Fri, 11 Aug 2000, Nathan Wiger wrote: > To me, the real question is which date() should we use: > >$date = date $seconds_since_epoch; # uses time() >$date = date $modified_julian_date; # non-Unix > > If we can make it work, the second one seems a lot more > platform-independent. After all, the epoch has no meaning to those on > Macs, PCs, or BeOS machines (except maybe historical trivia). (Careful; architecture ne OS -- there are PCs running Unix, for example, and their epoch would be 1 January 1970.) Well, they have their own epoch; for example, MS-DOS's epoch is 1 January 1980 AFAIK. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: command line option: $|++
On Tue, 15 Aug 2000, Casey R. Tweten wrote: > cat /etc/passwd | perl -nfe 'print((split/:/)[0])' > > -f is just like $|=1 or, for example, $fh->autoflush(1); When did -f come into being? Or was this just a proposed new switch? > This, by the way (even as a test) was 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. Presto, instant newlines after every print! Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: RFC 110 (v1) counting matches
On 16 Aug 2000, Perl6 RFC Librarian wrote: > Have you ever wanted to count the number of matches of a patten? s///g > returns the number of matches it finds. m//g just returns 1 for matching. > Counts can be made using s//$&/g but this is wastefull, or by putting some > counting 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 -- Philip Newton <[EMAIL PROTECTED]>
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
On 16 Aug 2000, Chaim Frenkel wrote: > >>>>> "BB" == Buddha Buck <[EMAIL PROTECTED]> writes: > > BB> I am assuming that the system clocks are set accurately to UTC (or some > BB> derivative, like (US) Eastern Standard Time). UTC is what time-servers > BB> report. UTC has leap seconds, which are inserted (or, theoretically, > BB> deleted) at the end of December 31st and June 30th, as needed. > > Oh, I was under the impression that they only occur at Dec 31. Nope. > BB> This means that 86400 seconds (one day) after 2000 Dec 31, 12:00:00 UTC > BB> is not necessarily 2001 Jan 1, 12:00:00 -- it could be 11:59:59 or > BB> 12:00:01 as well. And there is no way to know that ahead of time. > > Hmm, there are negative leap seconds? I believe there haven't been any yet, and it is not likely 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 111 (v1) Whitespace and Here Docs
On Tue, 15 Aug 2000, Michael Fowler wrote:
> So what's insufficient about:
>
> print <<"EOF";
> Stuff
> More stuff
> Even more stuff
> EOF
Others have already mentioned the "have to count the number of spaces"
argument. Another one that comes to mind is: assume the above is inside a
350-line block. Now I want to put an if($foo==$bar) { ... } around that
block. To make the inner block look nice, I >% in vi -- shift the whole
block over by one indent (a tab, two spaces, whatever). Presto, the thing
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 111 (v2) Here Docs Terminators (Was Whitespace and HereDocs)
On 27 Aug 2000, Perl6 RFC Librarian wrote: Don't know if anyone's picked this up or not, but I think it was in the first version, too. > =head1 ABSTRACT > > With a here doc print < text of the here doc, is processed verbatum. This results in the terminator > sticking 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 162 (v1) Filtering Here Docs
On 27 Aug 2000, Perl6 RFC Librarian wrote: > With a here doc print <
Re: RFC 215 (v1) More defaulting to C<$_>.
On 13 Sep 2000, Perl6 RFC Librarian wrote: > An inconsistency between "C" and "<>" bugs me: "C" means > "C" so it seems like "<>" should mean "C<$_ = > <>". > I can't yet think of code that this extension would break. Minor formatting nit: modern pod parsers accept not only C<> but also C<<>>, C<<<>>>, etc. allowing for nested < and >, as long as the number of adjacent < is less than the number used in the bracket. This also ignores leading and trailing whitespace, AFAIK. So you could re-write this paragraph as: An inconsistency between "C" and "C<< <> >>" bugs me: "C" means "C", so it seems that "C<< <> >>" should mean "C<< $_ = <> >>". 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 215 (v2) More defaulting to $_
On 13 Sep 2000, Perl6 RFC Librarian wrote: > An inconsistency between "C" and "<>" bugs me: "C" means > "C" so it seems like "<>" should mean "C<$_ = > <>". > This would break code prompting for "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 (v2) More defaulting to $_
On 13 Sep 2000, Perl6 RFC Librarian wrote: > =head1 DESCRIPTION > > $_ is the default scalar for a small set of operations and functions. > Most of these operations and functions are ones that use C<=~>. Er, no. Quite a few others also use $_. The ones I found: -X filehandle tests (except for -t), abs, alarm, chomp, chop, chr, chroot, cos, defined, eval, exp, glob, hex, int, lc, lcfirst, length, log, lstat, oct, ord, pos, print, quotemeta, readlink, ref, require, rmdir, sin, split, sqrt, stat, study, uc, ucfirst, unlink. None of those uses C<=~>. > Problem: > since <> has a different behavior in a list context, does > "C<(> <> C<);>" break, or does it mean something like "C<@_ => <>c<;>" ? Eek. This is really ugly. I propose: since C<< <> >> has a different behavior 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 226 (v2) Selective interpolation in single quotish context.
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 include a section on
COMPATIBILITY, noting that people might be using \I in single-quoted
strings already -- this would break. For example, some misguided
DOS user with a filename such as C:\INCLUDE\SYS$HEADER\ERRNO.H
(horribly contrived, I know -- not even sure whether $ is legal in a
DOS path, but I think it is) might be surprised if he got an error
message about $HEADER being undef.
What about \Itext\E, where text does not contain a scalar? Is this the
same as "text"? How about \Ibefore${var}after\E -- is that the same
as "before${var}after"? Does @foo interpolate inside \I...\E? (With
join $"?) What about backslashes inside \I...\E (as in the above funny
filename)?
Cheers,
Philip
Re: RFC 226 (v2) Selective interpolation in single quotish context.
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 > quote semantics good for escaping all those $ VMS requires. Well, we who are > forced to use Windoze find single quote semantics good for escaping all those \ > used in NT file names. So this proposal as now written blows that away: > > $x = 'C:\IN\MY\DIRECTORY\THERE\IS\A\FILE\NAMED\$FOO'; This becomes fun with UNC names, which have two backslashes at the beginning. But \\ in a single-quoted string becomes one backslash, so the filename is 'SERVER\SHARE\ONLY\ONE\SLASH\NOW' :-) Cheers, Philip
Re: RFC 223 (v1) Objects: C pragma
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 you don't shudder at this, I would argue you > probably don't maintain enough of others' code. *ANNOYNATE = *ARGV; use English; I remember reading a bit of example code somewhere from someone who religiously used English. It was fairly annoying seeing functions operate on $ARG instead of $_, and subroutine were passed @ARG Cheers, Philip
Re: RFC 226 (v2) Selective interpolation in single quotish context.
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 263 (v1) Add null() keyword and fundamental data type
On 20 Sep 2000, Russ Allbery wrote:
> About the only piece of code of mine that this would affect are places
> where I use ++ on an undef value, and that's not a bad thing to avoid as a
> matter of style anyway (usually I'm just setting a flag and = 1 would work
> just as well; either that, or it's easy enough to explicitly initialize
> the counter to 0).
Depends. While it is possible to initialise counters in the canonical
"have I seen this before" situation, it's more convenient the way it is at
the moment:
$seen{$word}++;
looks, to me, 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 263 (v1) Add null() keyword and fundamental data type
On Thu, 21 Sep 2000, Tom Christiansen wrote:
> < Philip:
>
> >$seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1;
>
> er, flip that.
Er, yes. Thanks.
> Larry wrote (in Camel-3) that
>
> ...the autoincrement will never warn that you're using undefined values,
> because autoincrement is an accepted way to define undefined values.
> ^^^
>
> So I think you're safe there.
I'm glad about that -- it's a very convenient feature.
Having $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]>
perl6storm #0010: kill all defaults
On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0010 > > Allow a way to kill *all* defaults at compile time. Or warn about them. > > no defaults; > use defaults 'none'; > use warnings 'defaults'; > > this is for 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]>
perl6storm #0011: interactive perl mode
On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0011 > > perl w/o args with stdin and out ttys should be perl -de 0. > saves novices from typing "perl" and getting confuddled. I think it should print out a banner message, too. A couple of times I was 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 been nice. But that's just me. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: PERL6STORM - tchrist's brainstorm list for perl6
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 #0050
On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0050 > > Radical notion: consider removing precedence. > Wrong precedence makes people miserable. (Some people already suggest that Perl only has two precedence rules: (1) multiplication and division come before addition and subtraction, and (2) parenthesize everything else.) This would make Perl more like Lisp, I suppose. But it would make code less ambiguous, probaly at the cost of readability. Arguably, some (most?) of the precedence levels already work the way people expect them to (for example, == binds more tightly than || or &&), so fewer "cluttering" parentheses are needed to make things readable while still being correct. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
perl6storm #0060: formats
On Thu, 21 Sep 2000, Tom Christiansen wrote:
> =item perl6storm #0060
>
> formats and html doesn't mix nicely (not wysiwig). Neither do any
> hidden chars, like ESC-blah. Can we do more for generating simple
> clean transparent xml?
Talking of ESC-blah, I've sometimes wanted to have a way to use formats
that can print embedded printer control sequences -- that is, formats that
know that length("\e*(3B") == 0. However, this is probably impossible to
generalise or get right (specifically because escape sequences are
variable length, and the set of escape sequences cannot be defined
beforehand).
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
perl6storm #0073
On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0073 > > kill bareword strings entirely. Including in places such as use? Well, I suppose we can get used to use 'strict'; . Any other "famous" incidences of barewords? (Maybe 'Foo::Blurf'->meth().) Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: perl6storm #0050
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 curlies by using > indentation to define block structure. What an idea! I wonder why no language has tried this before. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: perl6storm #0050
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 parenthesis is one "token". The more tokens you need to process, to more you need to think. (Especially if there is little whitespace, but to some extent also if not.) > What is your definition of readable? "I know it when I see it". I don't have a definition that I can put in words. But it probably involves whitespace between tokens and the number of tokens. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: RFC 320 (v1) Allow grouping of -X file tests and add C builtin
On Tue, 26 Sep 2000, Nathan Wiger wrote: > John Porter wrote: > > > > Yeah, not to mention the fact that many modules, notably CGI.pm, > > are arranged to allow to use unquoted strings of the form -name: > > > > print textfield( -name => 'description' ); > > Well, this one's not an issue, because => auto-quotes the LHS. It's the > same as this: > > print textfield( "-name", 'description' ); Actually, more like this: print textfield( -'name', 'description' ); Try putting it through -MO=Deparse. I guess the quoting behaviour of => "binds" more strongly than the hyphen, so that "-name =>" is interpreted as unary minus + bareword 'name' + big arrow, leading to unary minus + quoted bareword 'name' + 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: RFC 288 (v2) First-Class CGI Support
On Wed, 27 Sep 2000, iain truskett wrote: > Is order important for @HEADERS? Would it be better to have %HEADERS > instead that does such auto-formatting? In my opinion, no, for the reasons given before. Hashes are unordered, and if you want to order the keys, you need to know the possibly keys and in which order they come. Then, if HTTP/4.2 comes out with the Toast: light|medium|dark header, which has to come after the new Breakfast: header but before any (already existing) Content-Transfer-Encoding: headers, you need to upgrade Perl to get a new one that know about Toast headers. 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 288 (v2) First-Class CGI Support
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 which requires the order; I'd probably want to access them randomly. But that I send out has to follow the protocol. In other words, the input has an order (the order in which the user- agent sent the headers), but I'm not necessarily interested in it (frequent CGI programmers may have different needs); the output also has an order, and *someone* has to provide for that order, and I believe it is not good for Perl to do so (for the reasons given before). Cheers, Philip
Re: RFC 333 (v1) Add C and C funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote:
> The C function would work very similarly to C's:
>
>@HEADERS = header(content_type => 'text/html',
> author => 'Nathan Wiger',
> last_modified => $date,
> accept => [qw(text/html text/plain)]);
>
> This would produce an array of the following:
>
>@HEADERS = ("Content-Type: text/html\n",
>"Author: Nathan Wiger\n",
>"Last-Modified: Wed Sep 27 13:31:06 PDT 2000\n",
>"Accept: text/html, text/plain\n",
>"\n");
>
> Notice that the last element is a "\n" by itself, providing the
> necessary blank line separating headers and content.
Hm. This makes it difficult to construct a header incrementally -- for
example, @HEADERS=(); push @HEADERS, header(content_type=>'a',
author=>'b'); # 75 lines later; push @HEADERS, header(last_modified=>'c',
accept=>'d');
Since in this case, there would be two "blank" head lines instead of just
one.
> The C function would simply:
>
>1. uc the first letter of each tag token and lc the rest
Du you want to use the word "ucfirst" here?
> That is, the process that C does is exactly reversed, including
> stripping of trailing newlines, 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 as when you built the hash. So you
might feed in an @in with "Foo: bar" and "Hello: world", unheader it into
a hash, header it back into an array, and get "Hello: world" followed by
"Foo: bar". This may or may not be a problem.
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
Re: RFC 333 (v1) Add C and C funtions to coredistribution
On Fri, 29 Sep 2000, Nathan Wiger wrote: > > > 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 as when you built the hash. > > Actually, it does. Remember, a hash is just a list. unheader just > returns an ordered list of the headers. So this: > >@out = header unheader @in; > > Will always result in identity because it's actually the same as: > >@temp = unheader @in; >@out = header @temp; > > It's only once you assign to a hash explicitly that everything gets out > of whack. D'oh! Yes, of course. For some reason I got carried away with the hash thing. You were doing @out = header (@temp = unheader @in); and I thought you were doing @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 288 (v2) First-Class CGI Support
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, since they'd be required in order as well? > > > I don't care, because I don't work with this much. > > It's a case of: if you're going to have the output order, then you > should provide for the input to be ordered. *As well as* unordered. Sorry, I don't follow your line of reasoning. Why should having the output ordered influence what I want to see the input as? They're two different things; the output is aimed for the HTTP user agent, and the input is aimed (at the web server and then) for me. Two different sets of requirements. > > And I don't know whether I'd need to bear in mind the protocol which > > requires the order; I'd probably want to access them randomly. But > > that I send out has to follow the protocol. > > A future protocol could well require things in order. Hence you're > having the output headers in order. Therefore you should have the input > ones available in order as well. I want to order output headers because I have no control over what's on the other end. The only fixed point of reference I have is what the protocol specifies. So I want to stick to the protocol. However, the protocol on incoming headers is mainly significant between the HTTP user agent and the web server; once it gets to me, I don't care about the protocol any more -- the web server took care of that already. So the input headers can be unordered for all I care. Again, I don't do CGI much -- there may be people who want the exact headers in the exact order. For me, knowing what the "User- Agent:" header and what the "Accept-Charset:" header (or whatever) say is sufficient, and I don't care whether one is before or after the other. > I'm thinking a $headers_in and a $headers_out type thing is needed No comment on this one. Might be good, might not be; don't want to evaluate it right now. I just didn't want to snip it. > Having a %HTTP and a @HEADERS is rather simplistic and not really that > accommodating for potential modifications to the protocols for HTTP and > CGI. Possibly true. However, I believe that headers will still follow the "Key: Value" style, so @HEADERS should not be affected (if the programmer has to specify the order, that is -- then she can still do so in the future). And %HTTP may not need to be ordered. > > In other words, the input has an order (the order in which the user- > > agent sent the headers), but I'm not necessarily interested in it > > (frequent CGI programmers may have different needs); > > Precisely. So theoretically, we should provide for both situations. Well, if you provide it ordered, you *are* providing for both situations -- those who want it ordered have it ordered, and those who don't care about the order will be happy, too. After all, I didn't say "I explicitly want it unordered" or "ordered according to the hash of each header field". Cheers, Philip
Re: RFC 358 (v1) Keep dump capability.
On 1 Oct 2000, Perl6 RFC Librarian wrote: > =head1 ABSTRACT > > To simplify distribution of programs in binary form, > support for dump should be kept. > > =head1 DESCRIPTION > > This would immensely aid distribution of code from one Linux, Windows, > etc. machine to others without requiring all the recipients to be able > to install Perl, compile and install modules required by the program, > and configure their hosts so that Perl find the modules. There are > also times when pre-loading and pre-processing large amounts of data > are desirable. You're kidding, right? Have you ever used this capability? If so, you should have spoken up when the RFC to remove 'dump' was distributed. As far as I know, it's rather difficult to turn a core dump into an executable, so I don't think it "immensely aids distribution of code". I'm willing to be proved wrong, though; if someone can provide a recipe to do so and/or point out somewhere this is used, I'd be interested. > =head1 IMPLEMENTATION > > RFC 267 wants dump eliminated mainly because it is a common name for > user subroutines, bit also because it can be accomplished with a kill > signal. I really do not care if dump is renamed, but I believe keeping > the capability is in perl's interest for greater acceptance and use. Funny, most other languages don't have a 'dump' command, yet that doesn't stop 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
[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 02:47]: > > However, the protocol on incoming headers is mainly significant > > between the HTTP user agent and the web server; once it gets to me, I > > don't care about the protocol any more -- the web server took care of > > that already. So the input headers can be unordered for all I care. > > For all your care, yes. Others may have different requirements, and > those requirements may change with new HTTP revisions. Fair enough. Which is why I tried to indicate that these were my needs I was stating. > > Again, I don't do CGI much -- there may be people who want the exact > > headers in the exact order. For me, knowing what the "User-Agent:" > > header and what the "Accept-Charset:" header (or whatever) say is > > sufficient, and I don't care whether one is before or after the other. > > Again --- that's you. This RFC is for all of us. At the very least, > include the opposing arguments so that Larry can see that there were > multiple factions. I include opposing arguments? I'm not the one writing the RFC that Larry sees. Do you have me confused with someone? I was just presenting my side of the argument for the RFC author to notice (hopefully); it's up to him to agree or disagree, and to include my side in the RFC or not. > > > Having a %HTTP and a @HEADERS is rather simplistic and not really > > > that accommodating for potential modifications to the protocols for > > > HTTP and CGI. > > > Possibly true. However, I believe that headers will still follow the > > "Key: Value" style, so @HEADERS should not be affected (if the > > programmer has to specify the order, that is -- then she can still do > > so in the future). And %HTTP may not need to be ordered. > > So you're saying that @HEADERS (the output one) can quite happily be > ordered (which it is by default) or unordered, erring on the side of > ordered; while on the other hand you're saying that %HTTP (input) may > not need to be ordered (just as it may need to be ordered), erring on > the side of unordered. No, that's not what I was saying. I think the output headers should be ordered, while the input can be ordered or unordered, with no preference. If it's more useful for them to be ordered (for programs that rely on the order, perhaps because they want to deal with the CGI or HTTP spec rather than leaving that up to the web server), that's fine with me. However, in that case, we can't use a(n untied) hash. A hash would be nice, because it gives you random access and an easy way to query exists(); however, if ordering is desired, some other method would have to be used. Which I'm fine with. > Don't take this the wrong way, but you are being hypocritical in your > treatment of input and output headers. Maybe you misunderstood me :). If not, please point out wherein you believe my hypocrisy lies. > > > > In other words, the input has an order (the order in which the > > > > user- agent sent the headers), but I'm not necessarily interested > > > > in it (frequent CGI programmers may have different needs); > > > > > > Precisely. So theoretically, we should provide for both situations. > > > Well, if you provide it ordered, you *are* providing for both > > situations -- those who want it ordered have it ordered, and those who > > don't care about the order will be happy, too. After all, I didn't say > > "I explicitly want it unordered" or "ordered according to the hash of > > each header field". > > But a %HTTP is the only variable you're giving us, which (by its nature) > is unordered. *I* am not giving you anything. I think you have me confused with the author of the RFC again. I agree with you, though, that hashes are unordered, and that if order is desirable, this interface is not very useful. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD
On Sun, 1 Oct 2000, Adam Turoff wrote: > POD has three mighty significant advantages over XML: > - it is easy to learn > - it is to write > - it is easy to ignore, if you're spelunking for Perl code > Try and do that, when interferes with syntactically. [snip] > Moving towards a system that adds any friction to the documentation > process is a *>HUGE<* mistake. [snip] > Increasing author effort may make for more beautiful documentation > for the reader, but it also inhibits authoring content in the first > place. It's quite possible that switching to an XML docset produces > a beautiful, unmaintained set of documentation that is of no use > to anyone. I like these three paragraphs especially (because I agree with them). One of the stated(?) goals of POD was to have a syntax so simple that it's easy to do documentation. Everyone knows that programmers hate to document stuff. So by providing them with a fairly minimal framework, the amount of learning effort and the number of decisions required are fairly small, increasing the chance that code will be documented. If people don't have to worry about what should be fixed and what not (relying instead on smart POD translators), they'll be more likely to go ahead an write. I'm not sure that this bit of the third quoted paragraphs is correct: "It's quite possible that switching to an XML docset produces a beautiful, unmaintained 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 document structure and produce lovely docs. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> I appreciate copies of replies to my messages to Perl6 lists.
RE: Perl already allows XML for documentation (was Re: RFC 357 (v1) Perl should use XML for documentation instead of POD)
On 2 Oct 2000, at 10:35, Garrett Goebel wrote: > From: John Porter [mailto:[EMAIL PROTECTED]] > > > > It would be very detrimental to perl's performance to have to do an > > XML parse of every input source file. > > if the parser can skip between: > > =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 stuff before and after the tags. 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
On 2 Oct 2000, at 21:04, Adam Turoff wrote: > If you want to use XML, Latex, Texinfo or raw *roff for your docs, > then by all means do so. Understand that Perl can't be made to > magically ignore embedded Texinfo, and Perl contributors realistically > can't be made to understand/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 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
On 4 Oct 2000, at 14:06, John Porter wrote: > I am of the opinion that any documentation which requires, or at least > would significantly benefit from, the use of something heavy like SGML > is best done OUTSIDE THE CODE. There's no reason you can't have > document files accompanying the perl code files, for gosh sakes. I disagree slightly. One of the benefits of Pod is that it can be intermingled with Perl code; there's no need to have it be all in one piece. This can be used to good advantage by having the pod for each function be places just above that function, thus simultaneously helping to document the code. If the pod (or whatever) is in a separate file, this advantage is lost. However, I don't think this is necessarily a strong reason against abandoning pod if there are other advantages to other solutions; I just think it should be kept in mind. 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?
On 23 Oct 2000, at 15:40, Peter Scott wrote: > At 09:54 PM 10/23/00 +0100, Simon Cozens wrote: > >On Mon, Oct 23, 2000 at 04:38:12PM -0400, Dan Sugalski wrote: > > > Runtime string eval, do, and require are a serious pain in the butt. > > > They're the one set of things that'll force a real interpreter into a > > program. > > > >*nodnod*. This is really tricky; if there's no eval in the program, we can > >make all sorts of interesting optimizations: forego the whole SV process, and > >just use ints and char*s and whatever. If there's an eval, you've got to throw > >everything back into Perl-space, embed an interpreter, and all that jazz. > > What about introducing a pragma which either (a) promises not to use such > things, or (b) throws an exception if the program does use such constructs, > and say "if you want your programs to be compilable (or compile to > something a heck of a lot lighter), say 'use strict "compilation"' or > whatever"? Hm, but such code (for non-trivial programs) will re-invent the wheel a whole lot, won't 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: defined: Short-cutting on || with undef only.
On 15 Feb 2001, at 20:52, [EMAIL PROTECTED] wrote: > On Thu, Feb 15, 2001 at 10:31:34AM -0300, Branden wrote: > > With Perl 6, it will (probably) be possible to have values with boolean > > value independent of integer or string values, so that it will be possible > > to have a value that when viewed as string or number will be "" or 0, but > > will evaluate as true in a condition. > > You mean the beaten-to-death ??, formely known as |||, operator? > > It has torn p5p to shreds repeatedly. Perhaps Branden should take up the issue on the Perl-defop mailing list, which was set up for discussion of this operator. However, the last two postings I have in my archive are from August 1999 and October 2000 (this one being Ask proposing closing the mailinglist since it seemed to be receiving no traffic). But yes, it's been discussed 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: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Dan Sugalski wrote:
> While I don't know if Larry will mandate it, I would like this code:
>
>open PAGE, "http://www.perl.org";
>while () {
> print $_;
>}
>
> to dump the HTML for the main page of www.perl.org to get dumped to stdout.
I once created, on a Unix box, a directory named 'http:' and inside it, a
file named www.datenrevision.de. This enabled me to open
'http://www.datenrevision.de' and read from it (since multiple
consecutive slashes are generally treated as one slash on Unix) -- 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]>
