Re: Larry's Apocalypse 1

[Graham Barr]

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

[Johan Vromans]

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

[Paul Johnson]

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

[Andy Dougherty]

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

[Dave Storrs]

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)

[Dave Storrs]

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

[Graham Barr]

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

[Simon Cozens]

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

-- 
I will not suffer fools gladly, but I will gladly make fools suffer. -Bimmler

Re: Larry's Apocalypse 1

[Nathan Torkington]

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

[Larry Wall]

David Grove writes:
: [1] Strongs is pure Koine. I'd think Larry would be more of the Ionic
: type. 

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

[Larry Wall]

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] = ;
: 
: 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] := ;

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

[John Porter]

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.


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


> It might even mean that we can have a URL literal type, 

I trust that you will think long and hard about that.


> 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

Re: Larry's Apocalypse 1

[Jonathan Scott Duff]

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

[Simon Cozens]

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

[Graham Barr]

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

[Simon Cozens]

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

[Jarkko Hietaniemi]

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

[Jarkko Hietaniemi]

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

[Dan Brian]

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

[John Siracusa]

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

[Jarkko Hietaniemi]

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

[John Porter]

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

[John Porter]

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

[John Porter]

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

[Simon Cozens]

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

[Adam Turoff]

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

[Dan Brian]

> 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

[John Porter]

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

[Jarkko Hietaniemi]

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

[Jonathan Scott Duff]

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

[Dan Sugalski]

At 11:17 AM 4/6/2001 -0700, Larry Wall wrote:
>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] = ;
>:
>: 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] := ;
>
>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.

This is, I presume, in addition to any sort of inherent DWIMmery? I don't 
see any reason that:

@foo[1,2] = ;

shouldn't read just two lines from that filehandle, for example, nor why

@bar = @foo * 12;

shouldn't assign to @bar all the elements of @foo multiplied by 12. (Though 
others might, of course)


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Larry's Apocalypse 1

[Richard Proctor]

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] = ;
> 
> 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

[John Porter]

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

[nick]

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

[nick]

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

[Dan Brian]

>  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

[Jarkko Hietaniemi]

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

[Richard Proctor]

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.

  DB<1> @foo = (1,2,3)

  DB<2> @bar = @foo x 2

  DB<3> p "@bar"
33
  DB<4> 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

  DB<5> @bar = (@foo) x 2

  DB<6> p "@bar"
1 2 3 1 2 3

Which has real application.

Richard
-- 

[EMAIL PROTECTED]

Re: Larry's Apocalypse 1

[John Porter]

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

[nick]

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

[James Mastros]

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

[David Whipp]

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 .  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 = ;

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

[John Porter]

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

[Simon Cozens]

On Fri, Apr 06, 2001 at 03:08:39PM -0700, David Whipp wrote:
> 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;

A language that doesn't have everything is actually easier to program
in than some that do.
-- Dennis M. Ritchie

-- 
And tomorrow will be like today, only more so.
-- Isaiah 56:12, New Standard Version

Re: Larry's Apocalypse 1

[Brent Dax]

[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

[David Whipp]

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

[Piers Cawley]

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

[Piers Cawley]

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)

[John Porter]

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