In lists.projects.perl.language, you wrote:
It's likely to work better in Perl 6. To mean what it currently
means, you'll probably have to write something like:
@foo[0] := STDIN;
The colon here is not functioning merely to make the assignment look
like Pascal. It means, in this case,
At 08:01 PM 4/23/2001 -0500, David L. Nicol wrote:
Larry Wall wrote:
David L. Nicol writes:
:
: [this parser switch thing]
: sounds a lot like an exec system call: there are some things
: which remain in effect (open file handles, current directory,
: environment) but there are many
Dan Sugalski wrote:
Most of the parser switching is going to be of the nesting variety. Every
time the parser processes a double-quoted string constant or a regular
expression you're going to be jumping parsers. That's all temporary, and we
really do want them to nest. (You really don't want
At 06:40 PM 4/24/2001 -0500, David L. Nicol wrote:
Dan Sugalski wrote:
[BTW, was this meant to be CC'd to one of the perl 6 lists? My copy wasn't]
yeah, I have perl6-language as a alias but not language by itself
Fixed.
At 05:55 PM 4/24/2001 -0500, David L. Nicol wrote:
Dan Sugalski
Dan Sugalski wrote:
I'm not a parser guy by any means (unfortunately) but we have
the distinct possibility of completely replacing all of the
parser rules after token X appears, whatever that token might
be. (Heck, we may have the possibility of replacing the entire
parser) There's no
David L. Nicol writes:
: Dan Sugalski wrote:
: I'm not a parser guy by any means (unfortunately) but we have
: the distinct possibility of completely replacing all of the
: parser rules after token X appears, whatever that token might
: be. (Heck, we may have the possibility of replacing the
Larry Wall wrote:
David L. Nicol writes:
:
: [this parser switch thing]
: sounds a lot like an exec system call: there are some things
: which remain in effect (open file handles, current directory,
: environment) but there are many others which do not. Maybe
: switching parsers is best
What I see as needed is a designated meta-token that will be
reserved, in some form or another, as the switch-parser command.
.
.
.
What about a hash-bang? Maybe putting a hash-bang in the middle
of the text (outside of quoted literals, of course) could indicate
that the referenced program is
Brent Dax wrote:
Yes, that is exactly what I had in mind, thanks for
the validation. Only the comment syntax would have to
come back to a designated module, with another hashbang.
#!comment
yadda yadda yadda
blah blah blah
foo bar baz
#!VB6
Why would it?
Someone posited a nested stack of parsers, this thread is discussing the
abandonment of one parser when going to the next. Really, the claim
that it should be up to the invoked parser to determine where to go next
allows the invoked parser to have syntax to return to the prior
At 12:17 AM 4/20/2001 -0500, David L. Nicol wrote:
Simon Cozens wrote:
On Thu, Apr 12, 2001 at 05:39:12PM -0400, Dan Sugalski wrote:
[We have FOO:BAR]
While this is reasonably true (and reasonably reasonable) it's not
entirely
to the point. If we're going to provide a mechanism to
Dan Sugalski writes:
: At 12:17 AM 4/20/2001 -0500, David L. Nicol wrote:
: Recursive parsing is not needed. We have the HERE string, which can
: include anything in with the rest of the code, by looking for the
: end-token. The perl5 Inline module works that way.
Indeed, Perl 5 works that
Simon Cozens wrote:
On Thu, Apr 12, 2001 at 05:39:12PM -0400, Dan Sugalski wrote:
[We have FOO:BAR]
While this is reasonably true (and reasonably reasonable) it's not entirely
to the point. If we're going to provide a mechanism to define the syntax of
a mini-language (or a maxi one, I
On Tue, 17 Apr 2001, Tim Bunce wrote:
[...]
That beautiful code will be beautifully _open_ to _external_ extensions.
And that is how I imagine that Perl 5 support should be implemented.
Exactly. I am pretty sure that already at the meeting in Monterey
someone suggested that Perl5 should be
On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote:
I don't get it.
The first and foremost duty of Perl 6 is to parse and execute Perl 6.
If it doesn't, it's not Perl 6. I will call this the Prime Directive.
Great, but don't loose sight of the fact that a key feature of
On Mon, 16 Apr 2001 10:29:41 PDT, Jeff Okamoto [EMAIL PROTECTED] wrote:
The
timescales of corporations like Sun are not the same as those commonly
encountered in the open software arena.
Ditto for HP.
Which is more extreme (HP9000/L1000, HP-UX 11.00 + March 2001 patches):
%
Tim Bunce wrote:
If the file doesn't start with Perl 6 thingy then
it's Perl 5. Period.
To mandate the impossible is to mandate failure.
"Nothing can parse perl like Perl."
Why is that?
My reading of Larry's comments is that it won't be "in" our "new
beautiful code". [Umm, pride before
On Tue, Apr 17, 2001 at 09:23:56AM -0400, John Porter wrote:
"Nothing can parse perl like Perl."
Just saying it doesn't make it true, you know.
--
Keep the number of passes in a compiler to a minimum.
-- D. Gries
The
timescales of corporations like Sun are not the same as those commonly
encountered in the open software arena.
Ditto for HP.
Which is more extreme (HP9000/L1000, HP-UX 11.00 + March 2001 patches):
% /usr/contrib/bin/perl -v
This is perl, version 4.0
$RCSfile:
Dan Sugalski writes:
: At 10:16 AM 4/17/2001 +0100, Tim Bunce wrote:
: On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote:
: People seem to think that telling Perl 5 apart from Perl 6 is trivial.
:
: My reading of Larry's comments is that it will be _made_ trivial at the
: file
On Tue, Apr 17, 2001 at 09:23:56AM -0400, John Porter wrote:
Tim Bunce wrote:
If the file doesn't start with Perl 6 thingy then
it's Perl 5. Period.
To mandate the impossible is to mandate failure.
"Nothing can parse perl like Perl."
Why is that?
Because perl has a bunch of special
On Sat, Apr 14, 2001 at 10:39:55AM -0400, Dan Sugalski wrote:
To solve this versioning issue, is there a way Perl 6 compiler can just
figure out what's being fed?
Why?
i) To make things easier for the programmer. (That's kinda the point of
Perl.)
ii) Because Larry said so, *and* declared
At 02:58 PM 4/15/2001 +0100, Simon Cozens wrote:
On Sat, Apr 14, 2001 at 10:39:55AM -0400, Dan Sugalski wrote:
To solve this versioning issue, is there a way Perl 6 compiler can just
figure out what's being fed?
Why?
i) To make things easier for the programmer. (That's kinda the point of
On Mon, Apr 16, 2001 at 12:11:41PM -0400, Dan Sugalski wrote:
I hereby declare that a package declaration at the front of a file
unambiguously indicates you are parsing Perl 5 code.
^^^
Grand. To play devil's advocate here for a moment, that
At 05:20 PM 4/16/2001 +0100, Simon Cozens wrote:
On Mon, Apr 16, 2001 at 12:11:41PM -0400, Dan Sugalski wrote:
I hereby declare that a package declaration at the front of a file
unambiguously indicates you are parsing Perl 5 code.
^^^
On Mon, Apr 16, 2001 at 12:25:15PM -0400, Dan Sugalski wrote:
*cough*
s/parse/interpret/;
Seems a bit of a shame to parse it and then not do anything with it,
especially if we're trying to push Perl 6 as a common language runtime
for running all sorts of bytecode-compiled languages. :)
--
At 12:11 PM 4/16/01 -0400, Dan Sugalski wrote:
There are a number of reasons to *not* claim to parse perl 5 code.
*) We won't load any perl 5 XS code
*) We won't be getting the corner cases, and perl5 has a *lot*.
*) It complicates the interpreter if we need to add code to support things
that
The
timescales of corporations like Sun are not the same as those commonly
encountered in the open software arena.
Ditto for HP.
Jeff
At 09:47 AM 4/16/2001 -0700, Peter Scott wrote:
At 12:11 PM 4/16/01 -0400, Dan Sugalski wrote:
There are a number of reasons to *not* claim to parse perl 5 code.
*) We won't load any perl 5 XS code
*) We won't be getting the corner cases, and perl5 has a *lot*.
*) It complicates the interpreter
On Mon, Apr 16, 2001 at 09:58:05AM -0500, Brian Wheeler wrote:
Name tricks are ugly, but useful. Perhaps the best solution would
be to call the new interpreter perl6. If it finds itself being
called 'perl' or 'perl5' then it should assume perl 5 code
I just worry about users not being aware
At 02:33 PM 4/16/01 -0400, Dan Sugalski wrote:
At 09:47 AM 4/16/2001 -0700, Peter Scott wrote:
As a very low-tech solution, why not bundle perl 5 *with* perl 6 so that
once perl 6 detects that it's been fed perl 5 code, it can send it to the
perl 5 compiler/interpreter.
Besides the size and
At 12:19 PM 4/16/2001 -0700, Peter Scott wrote:
Or were you espousing the notion that perl 6 programs should be able to
contain sections of perl 5 code? That gives me strange palpitations.
This is what I've been arguing against. Unless I misunderstand (and it
wouldn't be the first time... :)
Dan Sugalski wrote
At 12:19 PM 4/16/2001 -0700, Peter Scott wrote:
Or were you espousing the notion that perl 6 programs should
be able to contain sections of perl 5 code? That gives me
strange palpitations.
This is what I've been arguing against. Unless I misunderstand
(and it
I don't get it.
The first and foremost duty of Perl 6 is to parse and execute Perl 6.
If it doesn't, it's not Perl 6. I will call this the Prime Directive.
I think as the first approximation the implementation of Perl 6 should
get that "simple" task right. If it doesn't, all our talk and work
At 02:49 PM 4/16/2001 -0500, Jarkko Hietaniemi wrote:
Thinking about the 5-6 migration and coexistence is good and useful,
but since that doesn't advance the Prime Directive, thinking about it
*too* much now or fighting over the niggly details is somewhat wasted
effort.
We have been stuck in a
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS We have been stuck in a sort of Gilbert and Sullivan debate,
DS haven't we? Silly, definitely silly.
o/' perl6 is the very model of a modern major interpreter o/'
:-)
uri
--
Uri Guttman - [EMAIL PROTECTED] --
On Mon, Apr 16, 2001 at 12:19:38PM -0700, Peter Scott wrote:
Er, I don't get it. I'm proposing that if perl 6 determines it's been
given perl 5 code, it does "exec perl5 $0". So thereafter it's as though
perl 6 never existed as far as that code is concerned; whatever it wants to
do
Given that Perl 5 internals post 5.004 caused the need for a rewrite
anyway, I'd imagine that this would be a particularly horrid idea. The
Perl 5 path is almost dead: adventurers and Win32 users are the vast
majority using it at all. Add Solaris 8 1/01 to the list of OS's that have
completely
On Sun, 15 Apr 2001, David Grove wrote:
The Perl 5 path is almost dead: adventurers and Win32 users are the
vast majority using it at all.
Since when?
Add Solaris 8 1/01 to the list of OS's that have completely rejected
5.6, as I discovered last night, and I'd imagine that there are more.
Dan Sugalski [EMAIL PROTECTED] writes:
At 08:23 PM 4/13/2001 -0700, jc vazquez wrote:
On Thu, 12 Apr 2001, Dave Storrs wrote:
...
We could then just add a -7 flag.
Or, just use:
#!/usr/bin/perl6
To solve this versioning issue, is there a way Perl 6 compiler can just
Dan Sugalski [EMAIL PROTECTED] writes:
Why? We don't ask this of any other compiler, so why ask it of perl?
(You won't find this in a C, or Fortran, or Ada compiler...)
Yes, but my compiled C binaries in /usr/bin don't break when I upgrade
gcc. A binary is largely independent of its compiler
John Porter [EMAIL PROTECTED] writes:
Piers Cawley wrote:
Unless you can get at every single one of those and add a '-M5' switch,
then they aren't going to work. Which could be very bad indeed.
The analogous situation with p4-p5 wasn't so bad. People just kept
their p4 binaries around for
On Sun, 15 Apr 2001, David Grove wrote:
Add Solaris 8 1/01 to the list of OS's that have
completely rejected 5.6, as I discovered last night,
This is quite unfair. Sun has supported perl nicely and Sun employees
have actively contributed to 5.6.0 and beyond. That
At 08:23 PM 4/13/2001 -0700, jc vazquez wrote:
On Thu, 12 Apr 2001, Dave Storrs wrote:
...
We could then just add a -7 flag.
Or, just use:
#!/usr/bin/perl6
To solve this versioning issue, is there a way Perl 6 compiler can just
figure out what's being fed? I mean, without
Dan Sugalski wrote:
I personally would rather that perl 6 handle perl 6 code only, and leave
the compilation and interpretation of perl 5 code to perl 5.
FWIW, I agree 100% with Dan.
--
John Porter
On Sat, Apr 14, 2001 at 12:11:12PM -0400, John Porter wrote:
Dan Sugalski wrote:
I personally would rather that perl 6 handle perl 6 code only, and leave
the compilation and interpretation of perl 5 code to perl 5.
FWIW, I agree 100% with Dan.
I'm curious to see how mutt will handle
On Thu, 12 Apr 2001, Dave Storrs wrote:
On Mon, 9 Apr 2001, Peter Scott wrote:
At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote:
One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go
the multiflagged way, why not reflect `-e' to get the `-6' flag? At
the very least,
On Thu, 12 Apr 2001, Dave Storrs wrote:
...
We could then just add a -7 flag.
Or, just use:
#!/usr/bin/perl6
To solve this versioning issue, is there a way Perl 6 compiler can just
figure out what's being fed? I mean, without saying anything using options
or pragmas. There must be a
On Mon, 9 Apr 2001, Peter Scott wrote:
At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote:
One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go
the multiflagged way, why not reflect `-e' to get the `-6' flag? At
the very least, I want a short flag!
But by the time
On Thu, 12 Apr 2001, Dave Storrs wrote:
We could then just add a -7 flag. That's not necessarily bad;
Perl 7 will probably face the same issue...it needs to be able to eat Perl
[567] code without barfing, but it needs to know what it's getting. Also,
the flag would be a good choice
David Whipp writes:
: You may be right that there are no useful literals other than
: strings, integers, reals and lists. OTOH, if we are going to
: construct a meta-language which supports multiple syntaxes,
: then it is very likely that each application-specific language
: would have its own
At 10:48 PM 4/12/2001 +0100, Simon Cozens wrote:
On Thu, Apr 12, 2001 at 05:39:12PM -0400, Dan Sugalski wrote:
[We have FOO:BAR]
While this is reasonably true (and reasonably reasonable) it's not
entirely
to the point. If we're going to provide a mechanism to define the
syntax of
a
On Thu, Apr 12, 2001 at 06:02:16PM -0400, Dan Sugalski wrote:
D'oh! I was thinking more along the lines of:
START(FORTH) {
$baz $foo $bar + =
}
where the entire parser was coopted. I wasn't considering the smaller (and
probably more common) case where only a tiny piece was
Greg Boug wrote:
use lib "CPAN::HTML::Module";
which goes and grabs the module in question from CPAN for
use. Picking, the closest mirror, of course.
We should not attempt to resurrect this poor dead horse,
only to beat it to death again. See the perl6-language archives.
you could
Dan Sugalski wrote:
At 09:40 PM 4/6/2001 +0100, Richard Proctor wrote:
On Fri 06 Apr, Dan Sugalski wrote:
This is, I presume, in addition to any sort of inherent DWIMmery? I
don't
see any reason that:
@foo[1,2] = STDIN;
shouldn't read just two lines from that filehandle,
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 (PAGE) {
print $_;
}
to dump the HTML for the main page of www.perl.org to get dumped to stdout.
I once created, on a
On Mon, Apr 09, 2001 at 10:03:31AM -0400, 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 (PAGE) {
print $_;
}
to dump the HTML for the main page of www.perl.org to get dumped to stdout.
Trond Michelsen [EMAIL PROTECTED] writes:
On Mon, Apr 09, 2001 at 10:03:31AM -0400, 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 (PAGE) {
print $_;
}
to dump the HTML for the main
At 01:46 PM 4/10/2001 +0200, Trond Michelsen wrote:
On Mon, Apr 09, 2001 at 10:03:31AM -0400, 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 (PAGE) {
print $_;
}
to dump the HTML for
At 05:14 PM 4/9/2001 -0700, jc vazquez wrote:
From: "Dan Sugalski" [EMAIL PROTECTED]
While I don't know if Larry will mandate it, I would like this code:
open PAGE, "http://www.perl.org";
while (PAGE) {
print $_;
}
to dump the HTML for the main page of
At 04:23 AM 4/10/2001 -0400, Philip Newton wrote:
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
At 09:56 AM 4/10/2001 +1000, Greg Boug wrote:
*knock knock* Hello? Abstraction? Are you there
Don't forget that human language expresses concrete things as
much or more than it does abstract things. Perl is at least
partially a human language.
True... But the ability to say "This is
Dan Sugalski wrote:
if (-M "http://www.perl.com/" -M "http://www.python.org/") {...}
Nope. Doesn't work with other magic filenames, why should it with these?
Because Perl6 will be better than Perl5.
I wouldn't mind (in fact I would expect) to see the magic power
level increase
On Tue, Apr 10, 2001 at 09:28:29AM -0400, John Porter wrote:
Dan Sugalski wrote:
if (-M "http://www.perl.com/" -M "http://www.python.org/") {...}
Nope. Doesn't work with other magic filenames, why should it with these?
Because Perl6 will be better than Perl5.
I wouldn't mind (in
At 12:36 PM 4/10/2001 -0500, Jarkko Hietaniemi wrote:
On Tue, Apr 10, 2001 at 09:28:29AM -0400, John Porter wrote:
Dan Sugalski wrote:
if (-M "http://www.perl.com/" -M "http://www.python.org/") {...}
Nope. Doesn't work with other magic filenames, why should it with these?
Of course all of this has been discussed. (See
http://archive.develooper.com/perl6-language-io%40perl.org/,
especially RFCs 100 and 14.)
And is already available in a nearby parallel dimension:
http://www.yetanother.org/damian/Perl5+i/open.html
;-)
Damian
While I don't know if Larry will mandate it, I would like this code:
open PAGE, "http://www.perl.org";
while (PAGE) {
print $_;
}
to dump the HTML for the main page of www.perl.org to get
dumped to stdout.
Well, this seems innocent enough, but how far do you
At 09:45 AM 4/11/01 +1000, Greg Boug wrote:
Hrmm... It'd have interesting repercussions for CPAN... :-)
How about doing something like:
use lib "CPAN::HTML::Module";
which goes and grabs the module in question from CPAN for
use. Picking, the closest mirror, of course.
Would be interesting,
John Porter [EMAIL PROTECTED] wrote:
David Whipp wrote:
A language that doesn't have everything is actually easier to
program
in than some that do.
The obvious reply is: "There's more than one way to do it"
To which the obvious reply is:
'Although the Perl Slogan is
At 12:31 PM 4/9/2001 +1000, Greg Boug wrote:
David Whipp wrote:
IOW, simply to have AWTDI is one of the worst reasons to add a
feature. If it doesn't make the language *better*, LEAVE IT OUT.
The same is true for anything... Sometimes a minimalist approach
is the right way to do it... The
Greg Boug wrote:
Sometimes a minimalist approach
is the right way to do it...
If one believes that, wrt programming languages, then one
is opposed to the philosophy of Perl. Oh well.
The problem is to make sure when
using a minimalist approach that you don't make it too small...
If you
Dan Sugalski wrote:
I, for
one, would like to bundle code to handle all the common protocols (SMTP,
NNTP, NNTP, Mail, HTTP, and SOAP, at least) in with perl 6, or with the
perl 6 common library.
Absolutely. Can we engrave that in a PDD sometime soon?
open PAGE,
David Grove wrote:
Does your "A" stand for "A" or "Another"?
The latter. Sorry, guess I shouldn't have abbreviated it.
The second point is that, John, you forget that Rebol actually did have
some degree of kewlness to it
I don't think I'm forgetting that. I'm just resisting the
On Mon, Apr 09, 2001 at 10:37:19AM -0400, John Porter wrote:
Greg Boug wrote:
Sometimes a minimalist approach
is the right way to do it...
If one believes that, wrt programming languages, then one
is opposed to the philosophy of Perl. Oh well.
Uhm, no. Not at all. Just because there's
On Mon, Apr 09, 2001 at 11:48:43AM -0400, John Porter wrote:
Yes, we could throw damned well everything into
Perl, and you might want to consider that "equally valid".
I might, but I wouldn't. That's precisely why I'm arguing
against adding URLs as an intrinsic type!
Then you are
At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote:
Hmm... programs that have perl one-liners inside them might be
troublesome.
Why not:
perl -e 'perl 5 one-liner'
perl --cmd 'perl 6 one-liner'
i.e. maintain the "-e" switch as a backward compatibility flag, with a new
cmd
At 05:21 PM 4/9/2001 +0100, Simon Cozens wrote:
On Mon, Apr 09, 2001 at 11:48:43AM -0400, John Porter wrote:
Yes, we could throw damned well everything into
Perl, and you might want to consider that "equally valid".
I might, but I wouldn't. That's precisely why I'm arguing
against
On Mon, 9 Apr 2001, Peter Scott wrote:
I'm still trying to figure out why the flag needs to change. What's wrong
with -e? It seems perfectly serviceable.
Because Larry said that by default Perl 6 would assume that its input was
in Perl 5...? So we need a way to tell it that it isn't.
At 09:48 AM 4/9/2001 -0700, Peter Scott wrote:
At 12:38 PM 4/9/01 -0400, Dan Sugalski wrote:
One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go
the multiflagged way, why not reflect `-e' to get the `-6' flag? At
the very least, I want a short flag!
But by the time people
I'm still trying to figure out why the flag needs to change. What's wrong
with -e? It seems perfectly serviceable.
Because Larry said that by default Perl 6 would assume that its input was
in Perl 5...? So we need a way to tell it that it isn't.
This one here's been bugging me for a
This one here's been bugging me for a bit. Larry never said that perl 6
would assume its input code was perl 5. Perl 6 will always assume its input
is perl 6. The said (and I'm still trying to dig up the quote) is that
we'll be enabling warnings and strict by default (as opposed to the off
At 11:16 AM 4/9/2001 -0600, Dan Brian wrote:
This one here's been bugging me for a bit. Larry never said that perl 6
would assume its input code was perl 5. Perl 6 will always assume its
input
is perl 6. The said (and I'm still trying to dig up the quote) is that
we'll be enabling
Still, I'll be really, *really* surprised if most perl code require any
rewriting to run under perl 6. TomC's got quite a cache of old perl code,
and I've got some mildly hairy perl 5 code that I want perl 6 to eat
without complaint.
OK. But by the current thread, this ability of perl6 to
At 12:02 PM 4/9/2001 -0600, Dan Brian wrote:
Still, I'll be really, *really* surprised if most perl code require any
rewriting to run under perl 6. TomC's got quite a cache of old perl code,
and I've got some mildly hairy perl 5 code that I want perl 6 to eat
without complaint.
OK. But
There won't be any magic toggles to make typeglobs come back if they go
away, or anything of that sort. Default behaviours like warning and
strictness may vary depending on whether perl thinks it's parsing a module
specifically written for perl 6 or not, but that's a far cry from parsing
At 12:31 PM 4/9/2001 -0600, Dan Brian wrote:
There won't be any magic toggles to make typeglobs come back if they go
away, or anything of that sort. Default behaviours like warning and
strictness may vary depending on whether perl thinks it's parsing a module
specifically written for perl
John Porter wrote
I'm sure you don't want to write "$a = new Integer '32'".
Of course. That would be unbearably absurd.
But how often do you have to write expressions that
operate on three or more URLs? Or even two?
How many perl instrinsics return URLs? How many
perl intrinsics
On Mon, Apr 09, 2001 at 12:58:23PM -0400, Andy Dougherty wrote:
Let's leave -e alone for now and worry about handling specific
incompatibilities when we in fact have some specific incompatibilities to
worry about.
Amen.
Tim.
The same is true for anything... Sometimes a minimalist approach
is the right way to do it... The problem is to make sure when
using a minimalist approach that you don't make it too small...
I think the more important thing is to not add completely redundant
features without a really good
From: "Dan Sugalski" [EMAIL PROTECTED]
While I don't know if Larry will mandate it, I would like this code:
open PAGE, "http://www.perl.org";
while (PAGE) {
print $_;
}
to dump the HTML for the main page of www.perl.org to get dumped to
stdout.
Now I would like to get
"Greg Boug" [EMAIL PROTECTED] writes:
So open has to parse the string for a URL and magically use
a http protocol? Not sure I like that idea... Granted, from a
programmatical point of view that looks neater... But what
about the case where you have a file called "http:" (a legal
filename
At 11:39 AM 4/10/2001 +1000, Damian Conway wrote:
Of course all of this has been discussed. (See
http://archive.develooper.com/perl6-language-io%40perl.org/,
especially RFCs 100 and 14.)
And is already available in a nearby parallel dimension:
I don't think that extreme positions (minimalist! bloater!)
helps here. I think the important question to ask about any given
feature is: what will it let me do? Features with no good answer to
this question obviously have no place in core. Attempting to align
with one or another
Simon Cozens wrote:
Uhm, no. Not at all. Just because there's more than one way to do it,
doesn't mean that one must consider *all* ways equally worthy when one
simple solution presents itself.
Huh? If I'm against one extreme, I must be for the other?
No, I'm reasonable. Like you.
(I
David Whipp wrote:
A language that doesn't have everything is actually easier to program
in than some that do.
The obvious reply is: "There's more than one way to do it"
To which the obvious reply is:
'Although the Perl Slogan is "There's More Than One Way
to Do It", I hesitate to
At 09:40 PM 4/6/2001 +0100, Richard Proctor wrote:
On Fri 06 Apr, Dan Sugalski wrote:
This is, I presume, in addition to any sort of inherent DWIMmery? I don't
see any reason that:
@foo[1,2] = STDIN;
shouldn't read just two lines from that filehandle, for example, nor why
Fair
On Thu, Apr 05, 2001 at 01:33:22PM -0700, Edward Peschko wrote:
I'd really rather not, and I don't think that was Larry's intention. I
think rather it was "perl 5 warning/strict levels", not "parse as perl 5
code". At least I hope that's the case...
well, personally I would rather that
On Thu, Apr 05, 2001 at 10:10:47PM +0100, Michael G Schwern wrote:
Then it might be easier to write modules that are testable without a test
driver. If you run the module directly, some distinguished block of code
could be executed that wouldn't be if the module were "included" via
Graham Barr [EMAIL PROTECTED] writes:
I have not looked at SelfTest, but I have always done this with
unless (defined wantarray) {
# Self Test
}
This works because whenever a file is use'd, require'd etc. it is
evaluated in a scalar context. The main file is in a void context.
Nice.
On Fri, Apr 06, 2001 at 10:01:47AM +0100, Graham Barr wrote:
unless (defined wantarray) {
# Self Test
}
This works because whenever a file is use'd, require'd etc. it is
evaluated in a scalar context. The main file is in a void context.
Although Gisle's recent patch changes this for
1 - 100 of 179 matches
Mail list logo
