Re: Larry's Apocalypse 1
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 this *is* done, because it forces perl 6's architecture to be solid. Only as solid as Perl 5's. And remember we're throwing that one away. :) -- By God I *KNOW* what this network is for, and you can't have it. - Russ Allbery, http://www.slacker.com/rant.html
Re: Larry's Apocalypse 1
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
"require" or "use" (or similar replacement constructs).
See also SelfTest.pm
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.
Graham.
Re: Larry's Apocalypse 1
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. I use
if ( ! caller ) {
# selftest
}
-- Johan
Re: Larry's Apocalypse 1
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 "do" at least.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Larry's Apocalypse 1
On Thu, 5 Apr 2001, Michael G Schwern wrote: One-liners run on a Perl 6 binary should just be Perl 6 code. Do we really have to worry about backwards compatibility with one liners? [ . . . ] Hmm... programs that have perl one-liners inside them might be troublesome. Yes, precisely. I often have one-liners embedded in larger shell scripts. Most of those survived the perl4-perl5 transition intact. I'd hope the same can be said for the perl5-perl6 transition. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Thu, 5 Apr 2001, Nathan Wiger wrote:
I'm unsure about the "module main" idea. I like that modules as a whole
are strict/-w by default. But the "module main" tag causes the same
problem Larry is opposed to with BASIC/PLUS "EXTEND". That is, every
Perl 6 program begins with "module main". Maybe there's a better way to
implement this? ("use 6.0" has much the same problem)
Not every p6 program...only the ones where you want the new
strict/warnings/whatever policies. And you can always put -ws on your
shebang line if you don't want to type "module main."
Dave
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
On Thu, 5 Apr 2001, John Porter wrote: Nathan Wiger wrote: the more compatible with Perl5 Perl6 is, the more likely it is to be accepted. I don't believe that's necessarily true. If Perl6 proves to be a significantly better Perl than Perl5, people will adopt it, especially if they're inclined toward the Perl philosophy anyway. (And at first, those are the only people we have to convince.) To this end, sacrificing the Virgin of Perlish Power to the God of Backward Compatibility would be unwise in the extreme. You are correct, but being backwards compatible is unlikely to _cost_ us adherents and might well gain us some. *shrug* Dave
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 01:31:40PM +0200, Paul Johnson wrote:
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 "do" at least.
Hm, I did not see that. Can someone explain what the patch changed
or give me a link to the thread.
Graham.
Re: Larry's Apocalypse 1
Andy Dougherty wrote: Yes, precisely. I often have one-liners embedded in larger shell scripts. Most of those survived the perl4-perl5 transition intact. I'd hope the same can be said for the perl5-perl6 transition. This is exactly the situation that Larry mentioned on Wednesday as an example of Something I Do Not Wish To Break. Nat
Re: Larry's Apocalypse 1
David Grove writes: : [1] Strongs is pure Koine. I'd think Larry would be more of the Ionic : type. g You might say I get a charge out of Homer. :-) Actually, I've done more Attic than Ionic. And I haven't done enough of any of them to get very far from my lexicon. But I started Greek at Seattle Pacific, and they've always stressed learning classical Greek first, even if you're planning to concentrate on Koine later. So I tend to stick with my Liddel and Scott, even when reading Koine. Even though I don't believe that a word's current meaning is defined by its etymology, I find that knowing the history of a word helps to keep one from reading meanings into a word that were probably not layered onto the word until afterwards. Apocalypse is such a word. Teachers of Koine have a bad reputation for being sloppy about these things, but I have to say that my Greek teachers did not, even when they were teaching Koine. In particular, I vividly remember a lecture by Ed Goodrick, Professor of Greek at Multnomah, in which he said: Most Greek words are vanilla words. I want you to remember that. Many of you will go out from here and become preachers. Someday I'll come visit your church, and you'll be up there preaching a stirring sermon to your congregation. And in order to fire the people up, you'll say that the Greek word "dunamai" means "dynamite". I warn you that if you do, I will stand up in the middle of your sermon and shout, "It does not!" and then I'll sit back down. So don't do that. You must always remember that "dunamai" is a vanilla word. It simply means, "I can." So anyway, I stick with Liddel and Scott, who do a decent job of covering Koine where it needs covering. If I want a strictly NT view of the word, I might occasionally dip into Bauer, Arndt and Gingrich. My Strong's got used too many times as a booster chair, and died the death, and I haven't bothered to replace it. Though I'm old enough to remember the saw: Strong's for the strong, Young's for the young, and Cruden's for the crude. And much though I despise making fun of people's names, the saying had some truth to it. Incidentally, Prof Goodrick was coauthor of the first NIV concordance, which was, as far as I know, the first that was computer-generated. Well, enough of that. Back to the future. Larry
Re: Larry's Apocalypse 1
Randal L. Schwartz writes: : "Nathan" == Nathan Wiger [EMAIL PROTECTED] writes: : : Nathan This is interesting, and in my gut I like it. Many people I've worked : Nathan with end up writing: : : Nathan@foo[0] : : Nathan Which works. : : "Works", for some odd meaning of the word "works". Ever try this: : : @foo[0] = STDIN; : : and then wonder where all the *rest* of your input went? 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, the following operator is intended to work on arrays, not scalars. Hence, :+ would be pairwise array addition. There will probably be optional modifiers before colon for various reasons. This has the result that we could distinguish an inner:* operator from and outer:* operator. (Labels would be required to have whitespace after the colon, in this scenario.) It also means that every operator has a function name, so you could call inner:*(@a, @b) or @a-inner:*(@b) or some such. It might even mean that we can have a URL literal type, if we can figure out how to parse it, and if there's any good reason to treat a URL as more than just a string: print $::OUT http://www.wall.org/~larry/index.html; But I really mustn't spill too many half-digested beans here. :-) Larry P.S. Larry's Second Law of Language Redesign: Larry gets the colon.
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 02:36:40PM -0400, John Porter wrote: Larry Wall wrote: There will probably be optional modifiers before colon for various reasons. This has the result that we could distinguish an inner:* operator from and outer:* operator. I balk at the proposition of Yet Another Namespace. Doesn't look like another namespace, but rather an extension of an existing one to me. It might even mean that we can have a URL literal type, I trust that you will think long and hard about that. Gosh I hope so ... my first reaction was that Larry had gone insane when I saw that http://... example. But let him digest those beans completely and we'll see what he comes up with. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 02:36:40PM -0400, John Porter wrote: I balk at the proposition of Yet Another Namespace. Where? It also means that every operator has a function name, I would think that would be the case, regardless of the form the general operator syntax takes. And functions have attributes, so no new namespace. -- DESPAIR: It's Always Darkest Just Before it Gets Pitch Black http://www.despair.com
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 03:52:47PM +0100, Simon Cozens wrote: On Fri, Apr 06, 2001 at 03:48:11PM +0100, Graham Barr wrote: Although Gisle's recent patch changes this for "do" at least. Hm, I did not see that. Can someone explain what the patch changed or give me a link to the thread. @foo = do "you"; now works Ah OK. So I assume that do "you"; will do the file in a void context Graham. -- I will not suffer fools gladly, but I will gladly make fools suffer. -Bimmler
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 07:55:26PM +0100, Graham Barr wrote: Ah OK. So I assume that do "you"; will do the file in a void context Theoretically, yes. (ie, probably not.) -- If computer science was a science, computer "scientists" would study what computer systems do and draw well-reasoned conclusions from it, instead of being rabid clueless wankers who've never even seen a real world system before, let alone used one. These are the kind of people that brought us pascal, folks. - Charles J Radder, asr.
Re: Larry's Apocalypse 1
It might even mean that we can have a URL literal type, I trust that you will think long and hard about that. Agreed. Saying "URL literal type" is rather bold since "URL" is an open-ended story. It is certainly nice to think of them as opaque filenames for "opening" them and doing IO on tehm but one major headache is the extensibility: the scheme part, especially. Check out http://www.w3.org/Addressing/schemes.html for the latest list. Each scheme carries with it own semantics for how the URL should be understood and which methods can be applied on it. So URLs are not literals, they have structure, and only thinking of them as filenames may be too simplistic. if there's any good reason to treat a URL as more than just a string And that is what's illuminating, imho. -- John Porter -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 07:57:28PM +0100, Simon Cozens wrote:
On Fri, Apr 06, 2001 at 07:55:26PM +0100, Graham Barr wrote:
Ah OK. So I assume that
do "you";
will do the file in a void context
Theoretically, yes. (ie, probably not.)
From bleadperl t/op/do.t:
if (open(DO, "$$.16")) {
print DO "print qq{ok 16\n} if defined wantarray not wantarray\n";
close DO;
}
my $a = do "$$.16";
if (open(DO, "$$.17")) {
print DO "print qq{ok 17\n} if defined wantarray wantarray\n";
close DO;
}
my @a = do "$$.17";
if (open(DO, "$$.18")) {
print DO "print qq{ok 18\n} if not defined wantarray\n";
close DO;
}
do "$$.18";
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: Larry's Apocalypse 1
It might even mean that we can have a URL literal type, I trust that you will think long and hard about that. Agreed. Saying "URL literal type" is rather bold since "URL" is an open-ended story. It is certainly nice to think of them as opaque filenames for "opening" them and doing IO on tehm but one major headache is the extensibility: the scheme part, especially. Check out http://www.w3.org/Addressing/schemes.html for the latest list. Each scheme carries with it own semantics for how the URL should be understood and which methods can be applied on it. So URLs are not literals, they have structure, and only thinking of them as filenames may be too simplistic. But the structure you speak of exists only on the server. A URL as accessor reference doesn't really need to know anything about the opening of that path other than the fact that it is a URL. This renders it pretty useless as a structure to be interpreted *as* a structure as far as the client is concerned. But I agree, if only to not have to configure proxy settings to get 'Configure' to work. :/ So these are actually half-digested-half-baked beans. The order of half-ities shouldn't be given any more thought ... damn, too late.
Re: Larry's Apocalypse 1
On 4/6/01 2:17 PM, Larry Wall wrote: P.S. Larry's Second Law of Language Redesign: Larry gets the colon. My initial reaction: Larry can keep it! ;) (go ahead, make me a believer... :) -John
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 01:19:30PM -0600, Dan Brian wrote:
It might even mean that we can have a URL literal type,
I trust that you will think long and hard about that.
Agreed. Saying "URL literal type" is rather bold since "URL" is an
open-ended story. It is certainly nice to think of them as opaque
filenames for "opening" them and doing IO on tehm but one major
headache is the extensibility: the scheme part, especially. Check out
http://www.w3.org/Addressing/schemes.html for the latest list. Each
scheme carries with it own semantics for how the URL should be
understood and which methods can be applied on it. So URLs are not
literals, they have structure, and only thinking of them as filenames
may be too simplistic.
But the structure you speak of exists only on the server. A URL as
accessor reference doesn't really need to know anything about the opening
of that path other than the fact that it is a URL. This renders it pretty
useless as a structure to be interpreted *as* a structure as far as the
if (open(BLAH, "mailto:[EMAIL PROTECTED]")) { ...
client is concerned. But I agree, if only to not have to configure proxy
settings to get 'Configure' to work. :/
So these are actually half-digested-half-baked beans. The order of
half-ities shouldn't be given any more thought ... damn, too late.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: Larry's Apocalypse 1
Jarkko Hietaniemi wrote: So URLs are not literals, they have structure, and only thinking of them as filenames may be too simplistic. Yeah. But Rebol manages to deal with them. I don't know if this is something we want to follow Rebol's lead on, but it's something to look at. -- John Porter
Re: Larry's Apocalypse 1
Jonathan Scott Duff wrote: Doesn't look like another namespace, but rather an extension of an existing one to me. An extension of a namespace? What's that? Either "modifiers" will be symbols in an existing namespace, or they will be in their own namespace. -- John Porter
Re: Larry's Apocalypse 1
Simon Cozens wrote: John Porter wrote: I balk at the proposition of Yet Another Namespace. Where? Modifiers. And functions have attributes, so no new namespace. You're saying modifiers and attributes will live in the same namespace? Possible, I guess, but not necessarily logical. -- John Porter
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 03:34:07PM -0400, John Porter wrote: And functions have attributes, so no new namespace. You're saying modifiers and attributes will live in the same namespace? Possible, I guess, but not necessarily logical. Hmm. No, come to think of it, that wouldn't work. Modified functions will just have to sit in a stash like everything else. No big deal. -- Sigh. I like to think it's just the Linux people who want to be on the "leading edge" so bad they walk right off the precipice. (Craig E. Groeschel)
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 03:31:56PM -0400, John Porter wrote: Jarkko Hietaniemi wrote: So URLs are not literals, they have structure, and only thinking of them as filenames may be too simplistic. Yeah. But Rebol manages to deal with them. I doubt it. telephone:? fax:? lpp:? callto:? uuid:? If Rebol can handle all of those URL schemes, why bother with Perl in the first place? I don't know if this is something we want to follow Rebol's lead on, but it's something to look at. Sounds like if there's a 'use url;' clause in use, then the standard three (mailto:, http:, ftp:) might be available, whereas other URL schemes would need different declarations (use url::dns;). Z.
Re: Larry's Apocalypse 1
if (open(BLAH, "mailto:[EMAIL PROTECTED]")) { ...
Ah yes. You did say "scheme", didn't you?
Well then, consider the PR value. ;-)
Re: Larry's Apocalypse 1
Adam Turoff wrote: If Rebol can handle all of those URL schemes, why bother with Perl in the first place? Should I legitimize that with a response? -- John Porter
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 03:37:35PM -0400, Adam Turoff wrote: On Fri, Apr 06, 2001 at 03:31:56PM -0400, John Porter wrote: Jarkko Hietaniemi wrote: So URLs are not literals, they have structure, and only thinking of them as filenames may be too simplistic. Yeah. But Rebol manages to deal with them. I doubt it. telephone:? fax:? lpp:? callto:? uuid:? If Rebol can handle all of those URL schemes, why bother with Perl in the first place? I don't know if this is something we want to follow Rebol's lead on, but it's something to look at. Sounds like if there's a 'use url;' clause in use, then the standard three (mailto:, http:, ftp:) might be available, whereas other URL schemes would need different declarations (use url::dns;). I'm not saying that having URLs wouldn't be nice, it's just that thinking of them as entity names and just practicing simple I/O (print, getline) on them is overstretching the idea. The objects behind the URLs might be messy, errr, complex. Let's say you open ftp://foo.bar/. Fine. Now what? How do you do a DIR? How do you do a GET? A PUT? A CWD? A MKDIR? Then http:// How's GET different from POST? How do you change the headers? This is starting to sound like libnet and LWP? Good. It should. There's only so much magic you can sweep under the carpet before it starts flying off at dangerous directions. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 03:32:56PM -0400, John Porter wrote: Jonathan Scott Duff wrote: Doesn't look like another namespace, but rather an extension of an existing one to me. An extension of a namespace? What's that? Either "modifiers" will be symbols in an existing namespace, or they will be in their own namespace. I was rather thinking that we could extend the subroutine namespace to include the funny symbols and that modifiers would exist there. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Larry's Apocalypse 1
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 enough @bar = @foo * 12; shouldn't assign to @bar all the elements of @foo multiplied by 12. (Though others might, of course) Reasonable, but what should @bar = @foo x 2; do? Repeat @foo twice or repeat each element twice? (its current behaviour is less than useless, other than for JAPHs) Richard -- [EMAIL PROTECTED]
Re: Larry's Apocalypse 1
Richard Proctor wrote: but what should @bar = @foo x 2; do? Repeat @foo twice or repeat each element twice? (its current behaviour is less than useless, other than for JAPHs) How is one significantly less useful than the other? -- John Porter
Re: Larry's Apocalypse 1
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
But the structure you speak of exists only on the server. A URL as
accessor reference doesn't really need to know anything about the opening
of that path other than the fact that it is a URL. This renders it pretty
useless as a structure to be interpreted *as* a structure as far as the
if (open(BLAH, "mailto:[EMAIL PROTECTED]")) { ...
You mean something like:
if (open(BLAH,":URL","mailto:[EMAIL PROTECTED]")) { ...
Now PerlIO/URL.pm has to know the semantics of /^mailto:/.
If it does it can do DNS lookup for MX record for north.pole and
presumably fail and return undef.
Oops sorry that is perl5 ;-)
--
Nick Ing-Simmons
Re: Larry's Apocalypse 1
Adam Turoff [EMAIL PROTECTED] writes: On Fri, Apr 06, 2001 at 03:31:56PM -0400, John Porter wrote: Jarkko Hietaniemi wrote: So URLs are not literals, they have structure, and only thinking of them as filenames may be too simplistic. Yeah. But Rebol manages to deal with them. I doubt it. telephone:? fax:? lpp:? callto:? uuid:? If Rebol can handle all of those URL schemes, why bother with Perl in the first place? I don't know if this is something we want to follow Rebol's lead on, but it's something to look at. Sounds like if there's a 'use url;' clause in use, then the standard three (mailto:, http:, ftp:) might be available, whereas other URL schemes would need different declarations (use url::dns;). Why not have URL.pm look for the appropriate module PerlIO::URL::fax say - as I recall that is what LWP does in the mundane perl5.003 world. Z. -- Nick Ing-Simmons
Re: Larry's Apocalypse 1
if (open(BLAH,":URL","mailto:[EMAIL PROTECTED]")) { ...
Now PerlIO/URL.pm has to know the semantics of /^mailto:/.
If it does it can do DNS lookup for MX record for north.pole and
presumably fail and return undef.
Oops sorry that is perl5 ;-)
Which part? "Presumably", "fail", "undef" ? ;-)
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 08:42:18PM +, [EMAIL PROTECTED] wrote:
Jarkko Hietaniemi [EMAIL PROTECTED] writes:
But the structure you speak of exists only on the server. A URL as
accessor reference doesn't really need to know anything about the opening
of that path other than the fact that it is a URL. This renders it pretty
useless as a structure to be interpreted *as* a structure as far as the
if (open(BLAH, "mailto:[EMAIL PROTECTED]")) { ...
You mean something like:
if (open(BLAH,":URL","mailto:[EMAIL PROTECTED]")) { ...
Now PerlIO/URL.pm has to know the semantics of /^mailto:/.
If it does it can do DNS lookup for MX record for north.pole and
presumably fail and return undef.
Oops sorry that is perl5 ;-)
Shoo! :-)
Having all that mess extensibly hidden in modules is okay.
--
Nick Ing-Simmons
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: Larry's Apocalypse 1
On Fri 06 Apr, John Porter wrote: Richard Proctor wrote: but what should @bar = @foo x 2; do? Repeat @foo twice or repeat each element twice? (its current behaviour is less than useless, other than for JAPHs) How is one significantly less useful than the other? Its current behaviour is to assign to $bar[0] the length of @foo repeated twice. DB1 @foo = (1,2,3) DB2 @bar = @foo x 2 DB3 p "@bar" 33 DB4 p $bar[0] 33 This is what I call less than useless, perhaps you are thinking of, the current behavior of @bar = (@foo) x 2 DB5 @bar = (@foo) x 2 DB6 p "@bar" 1 2 3 1 2 3 Which has real application. Richard -- [EMAIL PROTECTED]
Re: Larry's Apocalypse 1
Richard Proctor wrote: perhaps you are thinking of, the current behavior of @bar = (@foo) x 2 Yes, right. Opps. -- John Porter
Re: Larry's Apocalypse 1
Dan Brian [EMAIL PROTECTED] writes:
if (open(BLAH,":URL","mailto:[EMAIL PROTECTED]")) { ...
Now PerlIO/URL.pm has to know the semantics of /^mailto:/.
If it does it can do DNS lookup for MX record for north.pole and
presumably fail and return undef.
Oops sorry that is perl5 ;-)
Which part? "Presumably", "fail", "undef" ? ;-)
Well no one has written PerlIO::URL yet so all you get is:
nick@dromedary 507$ cd /home/perl5/perlio
nick@dromedary 508$ ./perl -Ilib -e
'open(BLAH,":URL","mailto:[EMAIL PROTECTED]") || die $!'
Can't locate PerlIO/URL.pm in @INC (@INC contains: lib
/usr/local/perl/lib/5.7.0/i686-linux-multi /usr/local/perl/lib/5.7.0
/usr/local/perl/lib/site_perl/5.7.0/i686-linux-multi
/usr/local/perl/lib/site_perl/5.7.0
/usr/local/perl/lib/site_perl/5.6.1/i686-linux-multi
/usr/local/perl/lib/site_perl/5.6.1 /usr/local/perl/lib/site_perl .) at (eval 1) line
3.
perlio: unknown layer "URL".
Of course they might want to write it in perl so that would be:
nick@dromedary 509$ ./perl -Ilib -e
'open(BLAH,":Via(URL)","mailto:[EMAIL PROTECTED]") || die $!'
Cannot find package 'URL'.
Attempt to free unreferenced scalar.
Died.
Which shows a buglet ...
and now I have mailto:santa.claus.pole which shows that I meant
"mailto:santa.claus\@north.pole" anyway ...
--
Nick Ing-Simmons
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 11:17:49AM -0700, Larry Wall wrote: Hence, :+ would be pairwise array addition. Sounds quite reasonable. There will probably be optional modifiers before colon for various reasons. This has the result that we could distinguish an inner:* operator from and outer:* operator. (Labels would be required to have whitespace after the colon, in this scenario.) It also means that every operator has a function name, so you could call inner:*(@a, @b) or @a-inner:*(@b) or some such. Hm. If I assume that s/:/::/, I like it. Otherwise, I really really don't. Why? Because it introduces more namespaces (and probably syntax) when they aren't really neccessary. If you use a ::, and make packages able to define operators straight-up, then you could do, say, $a dB::+ $b. There would be a :infixable attribute on subs, so you could make infix operators with arbitrary names: use Game::DnD 'D'; $hp = 3 D 6; It might even mean that we can have a URL literal type, if we can figure out how to parse it, and if there's any good reason to treat a URL as more than just a string: print $::OUT http://www.wall.org/~larry/index.html; Please, no! A URL isn't a /new/ type of literal, really. Either it's a wierd form of a literal list, or it's a wierd type of file name, so you should open() it. Or it's a self-quoting literal, like Packagename::. If you really want to be able to read from a URL in one line, let yourself do open(foo). But make opening a URL an explicit act. But I really mustn't spill too many half-digested beans here. :-) If you have to, at least do it in the toilet. P.S. Larry's Second Law of Language Redesign: Larry gets the colon. May He (or You) do Good Things with it. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
RE: Larry's Apocalypse 1
James Mastros wrote: print $::OUT http://www.wall.org/~larry/index.html; Please, no! A URL isn't a /new/ type of literal, really. Either it's a wierd form of a literal list, or it's a wierd type of file name, so you should open() it. Or it's a self-quoting literal, like Packagename::. If you really want to be able to read from a URL in one line, let yourself do open(foo). But make opening a URL an explicit act. I agree that an implicit "open plus get" would be a bit much. However, I see nothing wrong with defining a new form of literal, especially if everything acts like an object. It would be nice to say: $mySite = http://www.foo.bar/text.html; and then $mySite-get(...); $mySite-post(...); even: $page = $mySite; $page = http://www.foo.bar/text.html; I could go further: If I'm reading a URL of type html then, after reading it, I should be able to say: $header = $page-head; $title = $page-title; etc. I think what I'm saying is that we shouldn't think in terms of strings unless a method is evaluated in a "string context". Until its reduced to a string, a literal (or any other value) should maintain its class. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: Larry's Apocalypse 1
David Whipp wrote: It would be nice to say: $mySite = http://www.foo.bar/text.html; Vs. $mySite = new URL 'http://www.foo.bar/text.html'; I am far from convinced. -- John Porter
Re: Larry's Apocalypse 1
[EMAIL PROTECTED] wrote on 4/5/01 12.15: 2. package vs. module/class Whoa. This is so simple yet so sublime. It solves so many issues in one swoop. Cool. Assuming Perl6 will be parsing Perl5 code? Hmmm. That's interesting. Forget p52p6 and the whole 80/20 thing, we could potentially hit the 100% mark. I wonder, implementationally, if to keep Perl6 light Configure could ask "Path to Perl 5?" and then fork the Perl5 interpreter (instead of doing this natively). Maybe this is thinking too far ahead. I don't think so, because we want the symbols used in the p5 code accessible in p6. Maybe we can hack a special version of perl5 we can interfage with. Hell, we could even embed 5 into 6, if could contain the older symbols. Alternatively, since we're allowing for other parsers, maybe we could design a parser that handles Perl5.
RE: Larry's Apocalypse 1
John Porter wrote: $mySite = http://www.foo.bar/text.html; Vs. $mySite = new URL 'http://www.foo.bar/text.html'; I am far from convinced. Simon Coxens wrote A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie The obvious reply is: "There's more than one way to do it" I have to agree that there's not a huge diference between the two ways of calling a constructor. I suppose the important thing is the distinction between class and type. In the latter case, I explicitly say "make be an object of class 'URL': use the constructor named 'new' with these args". The the implicit form, you are simply using 'http:...' as a factory that creates an object of a class that conforms to the expected type. I'm sure you don't want to write "$a = new Integer '32'". Sometimes there is value in omitting trivial syntactic details. A related question is why we want to tie objects. Afterall, you can use methods on an object without ever tying it! Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: Larry's Apocalypse 1
Jarkko Hietaniemi [EMAIL PROTECTED] writes: On Wed, Apr 04, 2001 at 11:46:12PM -0700, Nathan Torkington wrote: Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Nat Me, I've been racking my brain to figure out whether Damian is Famine, War, Plague, or Death... I think he's worth every penny of the money I put up for his year working for Perl. -- Piers
Re: Larry's Apocalypse 1
Simon Cozens [EMAIL PROTECTED] writes: 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 this *is* done, because it forces perl 6's architecture to be solid. Only as solid as Perl 5's. And remember we're throwing that one away. :) 'Solid enough to parse and run Perl 5 code with no changes to that code' is very different from 'Only as solid as Perl 5'. -- Piers
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
Dave Storrs wrote: being backwards compatible is unlikely to _cost_ us adherents and might well gain us some. Yes, all other things being equal. But will they be? IOW: at what cost backwards compatibility? -- John Porter
