Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
Paul Seamons wrote:
So then, to get back to the invocant...  I can't say that I liked many of the 
proposals.  The one that seemed to have merit though was $^.  I'd propose the 

  meth foo {
 $_.meth; # defaults to the invocant
 .meth; # operates on $_ which defaults to the invocant
 $^.meth;  # is the invocant
 $^1.meth; # is the first invocant
 $^2.meth; # is the second invocant
I'm starting to get confused at the need for all these special 
variables. I vote that we steal from prior art in numerous other 
languages and just auto-set $SELF or $THIS or whatever and call it done.

Having .method assume $SELF is an added nicety, but if it introduces 
added parsing problems then it's hardly worth it.

OR, choose $^ and don't set $SELF (or $?SELF or whatever), but having 
dup short and long names is a waste, since people will always chose the 
short one (who uses English in Perl 5, really?)


Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
Paul Seamons wrote:
 meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth;  # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get confused at the need for all these special
variables. I vote that we steal from prior art in numerous other
languages and just auto-set $SELF or $THIS or whatever and call it done.

The problem is that there is no globally safe name to use that uses letters 
only.  Also there is a certain line noise problem (which may not really be a 
problem - but looks like one once we have a more concise alternative):
I understand the purported problem, but what I'm saying is that it 
really isn't one. Variables magically coming into existence doesn't seem 
to be a problem for any language but Perl 6. Many other languages set 
this automagically.

 method foo {
   $SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
   $SELF.say(Hello  ~ $SELF.prop);
I'm not sure the point of this block; it's hardly horrific. Any external 
script would have to say:

   $invocation = new Class;
   $invocation.meth($invocation.get_foo, $invocation.get_bar);
If the point is that $^ saves typing over $?SELF then I agree; my point 
is simply that we pick one or the other, instead of both/aliases/etc.


Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of

But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
Then I suggest use English for Perl 6 too. I think you'll find that, 
like Perl 5, people always use the short forms.

Has ANYONE on this list ever done something like this?
   use English;
   if ($OSNAME =~ /MSWin32/) {
   local $WARNING = 0;
   print Windoze\n or die Can't print: $OS_ERROR;
I'd bet everyone would write that as:
   if ($^O =~ /MSWin32/) {
   local $^W = 0;
   print Windoze\n or die Can't print: $!;
Crap, I had to open the Camel just to find the long names. :-)
P.S. I know this is the first time I've spoken up on Perl 6
 in 5-ish years, so nice to see you all once again

ALLCAPS subs, properties, etc (Re: Multiple classifications)

2001-06-27 Thread Nathan Wiger

* Damian Conway [EMAIL PROTECTED] [06/25/2001 13:20]:
 But one could also imagine that Perl 6 might allow individual objects to
 have an CISA property that pre-empted their class's C@ISA array.

At some point, it is probably worth talking about Perl's ALLCAPS subs
for special methods. For example, if we're taking the 3-tiered
method/value/prop hierarchy, then maybe DESTROY and PUSH don't make
sense any more? It seems that it would behoove us to make all this stuff
fit into one framework.

There are a couple alternatives I can think of:

   1. Make them all lowercase. They just happen to conflict
  with names you may like. Hm. Backwards compat, anyone?

   2. Make them like Python, with __underscoresgalore__. Doesn't 
  really solve the problem, though.

   3. Give them a special attribute, like 

  sub push ($proto, @type) : handler {   }
  sub barks ($dog) : property {   }

  But what to do with similarly-named subs? Have a priority

   4. Let the user name them whatever they want:

  use tie push = myPushHandler,
  pop  = myPopHandler;

  use handler create = I_Live;
The problem with leaving them ALLCAPS is if you have:

   push @a, $element;

And we do a more extensible tie framework, and you have an @a.push
method already, there's a collision there.


~ for concat / negation (Re: The Perl 6 Emulator)

2001-06-21 Thread Nathan Wiger

* Simon Cozens [EMAIL PROTECTED] [06/14/2001 15:16]:

 OK, I've been teasing people about this for weeks, and it's time to stop.
 This is the current state of the Perl 6 emulator; it applies most things
 that Damian talked about in his keynote yesterday, and most of the things
 I've picked up in perl6-language. It does:
 $a ~ $b for concat
 ^ $afor negation

I just want to briefly register a formal complaint that I do not like
this, and I suspect I'm not the only one. I just think many have stopped
trying to fight it out of exhaustion.

I don't like ~ for binary concat. For one thing, it means that the
equivalent of .= is now:

   $a ~= $b

Does anyone else see a problem with =~ ? Plus, it makes the
pre-plus-concat that many desire impossible, since =~ is taken.

Second, even if ~ *is* used for concat, then I *still* don't think that
~ should be changed from unary negation. There's no reason for it. Every
other major modern language I can think of uses ~ for unary negation. An
operator can change its meaning based on context, just consider .

In summary:

   1. I don't like ~ for concat 

   2. But if it does become concat, then we still shouldn't
  change ~'s current unary meaning

Thanks for listening.


Re: properties

2001-05-21 Thread Nathan Wiger

* Jonathan Scott Duff [EMAIL PROTECTED] [05/21/2001 09:39]:
 If anything, all variables should have a value property that evaluates
 to its, well, value and only that property would be considered in
 conditionals.  Then these would be equivalent:
   print keys (+$foo).prop;
   print keys $foo.value.prop;

Damn, this is really starting to look like JavaScript, and that's just
plain scary. ;-)

I think we should step back and think: Why would we want these to have
separate spaces? Regardless of the syntax, semantically why would you
want to have separate value/variable properties?

The more I've been thinking about it, it seems that properties should
really just be declared as value-dependent or independent. That is, some
are permanent (compiler hints, types, etc) and others change based on
the value assigned to the var (truth, etc).

   # Whatever the syntax is...

   module Dog;

   property barks { ... }   # or is permanent ?
   property true is value_dependent { ... }

So if you said:

   my Dog $spot is true, barks = new Terrier;

   $spot = 1;

   print Spot is alive! if $spot;# prints
   print Spot barks! if $spot.barks; # prints

   $spot = 0;

   print Spot is alive! if $spot;# DOES NOT print
   print Spot barks! if $spot.barks; # prints

Really, what you want is some properties to be clobbered by value
assignment, and others to be permanent. That way you get the correct
semantics by just saying:

   if ( $spot.true ) { ... }

Instead of the inevitable:

   if ( $spot.true || $spot.value.true ) { ... }

If they were kept separate.


Separate as keyword? (Re: 'is' and action at a distance)

2001-05-18 Thread Nathan Wiger

* Michael G Schwern [EMAIL PROTECTED] [05/18/2001 12:32]:
 Let me see if I understand this...
   $Foo is true;
   # Meanwhile, in another part of the city...
   $Foo = 0;
   print My spider sense is tingling if $Foo;
 Does that print or not?

Maybe there are two different features being conflated here. First, we
have is, which is really for assigning permanent properties:

   my $PI is constant = '3.1415927';
   my $int is integer;
   $int = 5.4;  # error, or something...

So, those make sense, and we'd want them to remain through assignment.
However, the true, error, false, etc, really are *temporary*
conditions.  Maybe we need a separate keyword - as - for this:

   return $zero as true;
   return $fh as error(Internal Blah Blah Blah: $!);

For stuff declared with this as keyword, it would last until next
assignment or other value change. That is, these are value dependent and
designed to pass extra information along. By definition, though, when
the value changes we'll want these properties to change as well.

So, Schwern's example would be work as follows:

   $Foo is true;
   $Foo = 0;
   print Stuff if $Foo;   # would not print - is assigns a
# permanent true property

   $Foo as true = ;
   $Foo = 0;
   print Stuff if $Foo;   # would print - as is reset by
# value assignment since is temporary


Re: Separate as keyword? (Re: 'is' and action at a distance)

2001-05-18 Thread Nathan Wiger

Dammit, I got the example exactly backwards. Try this:

$Foo is true;
$Foo = 0;
print Stuff if $Foo;   # *WOULD* print - is assigns a
 # permanent true property
$Foo as true = ;
$Foo = 0;
print Stuff if $Foo;   # *WOULD NOT* print - as is reset by
 # value assignment since is temporary

Re: Exegesis2 and the is keyword

2001-05-16 Thread Nathan Wiger

* Michael G Schwern [EMAIL PROTECTED] [05/15/2001 17:49]:
 Is that autochomp as a keyword or autochomp as an indirect method call
 on $*ARGS?

Who cares? ;-)

  The thing I worry about is this: I don't think actions should be
  declared using is, necessarily.
 $STDERR is flushed;
 $var = $ARGS is read;
 $STDOUT is printed to Hello, World!\n;
 This could be argued 'round and 'round as to what's an action and
 what's a property.  'chomped' and 'flushed' make sense as properties
 as they are descriptive.  You're setting a property which the variable
 will take into account in its actions.  Whereas things like 'read' and
 'printed' are immediate actions.

I guess my main problem is the the 'is' keyword is optional where it
can be inferred part. That's a whole indirect-object-like can of worms,
and I don't think we should be adding more of those. This could easily
be fixed by writing Damian's example:

   $*ARGS prompts(Search? );

As a past-tense verb:

   $*ARGS is prompted(Search? );

It ends up being the same effective tense. I just really don't think
that is should be sometimes-optional.

 Put down the indirect object syntax and step away from the keyboard
 with your hands up! ;)



Re: apology (was Re: Exegesis2 and the is keyword)

2001-05-16 Thread Nathan Wiger

* Dave Storrs [EMAIL PROTECTED] [05/16/2001 11:25]:
   I recently received the following email from someone whose name I
 have snipped.
  * Dave Storrs [EMAIL PROTECTED] [05/16/2001 08:11]:
   Ok, this is basically a bunch of me too!s.
  Keep the snide comments to yourself. Thanks.
   This was regarding a reply I had made to one of Nathan Wiger's
 posts in the Re: Exegesis2 and the is keyword thread.
   This is a case of miscommunication; the bunch of me toos was
 referring to what _I_ was writing...that is, I was saying that the
 majority of my email consisted of agreeing with what Nathan had written,
 which I thought was very well constructed and well thought
 out.  Obviously, I was not clear enough, for which I apologize.


No reason to publicly apologize, this was as much a result of my
misreading your statements as anything else. I thought we had resolved
this quite satisfactorily offline, but I sincerely appreciate the public

I must admit I've gotten a little on-edge reading this list lately. It
seems many would like to turn many issues into flamewars. I hope that
people begin to abide by Nat's requests to tone things down a little.

I think a lot of people are unsure and afraid of where Perl's going,
which is understandable in a way because we're in the middle of doing
some big redesign, but it's not a reason to overreact and assume
everyone else on the list is out to destroy Perl.

I do agree, however, that we need to make sure people can still program
in a subset of Perl effectively.


Exegesis2 and the is keyword

2001-05-15 Thread Nathan Wiger

So, I finally got around to reading the link Nat sent out:

First off, nice job Damian (as always), it looks excellent. I like the
examples of stuff like this:

   my int ($pre, $in, $post) is constant = (0..2);

Awesome. Simple, Perlish, easy to read, etc. Also, I see you took the
suggestion of:

   Access through...   Perl 5  Perl 6
   =   ==  ==
   Array slice @foo[@ns]   @foo[@ns]
   Hash slice  @foo{@ks}   %foo{@ks}

Which is kewl since it makes a good amount of sense IMO.

The only worry/problem/etc that I wonder about is the potential overuse
of the is keyword. It is a very nice syntactic tool, but when I see
something like this:

   $*ARGS is chomped;

I wonder if that wouldn't be better phrased as:

   autochomp $*ARGS;# $ARGS.autochomp

Or, if :: meant CORE, even:

   autochomp $::ARGS;

The thing I worry about is this: I don't think actions should be
declared using is, necessarily. I know, one could argue that actions
are just a type of property, but I don't know if that's the most
sensible. In particular, it puts the action in the passive voice, and it
could also go too far:

   $STDERR is flushed;
   $var = $ARGS is read;
   $STDOUT is printed to Hello, World!\n;

It seems actions should be active functions, so:

   autoflush $STDERR;   # $STDERR.autoflush
   $var = read $ARGS;
   print $STDOUT Hello, World!\n;

Plus, this part bothers me a little:

:$ARGS prompts(Search? );  # Perl 6
:while ($ARGS) {
: Technically, that should be:
:$ARGS is prompts(Search? );
: but that grates unbearably. Fortunately, the is is optional in 
: contexts -- such as this one -- where it can be inferred.

I'd think I'd rather see that as:

   prompt $ARGS Search? ; # $ARGS.prompt(Search? )

Without the extra new ambiguity. Thoughts?


Perl5 Compatibility, take 2 (Re: Perl, the new generation)

2001-05-11 Thread Nathan Wiger

* Dan Sugalski [EMAIL PROTECTED] [05/11/2001 07:19]:
   I think you're in violent agreement here.  This has been declared a
   goal of Perl 6 from almost day one.
 Ok, fair enough, but until just a little bit ago I was hearing stuff different
 from Dan. That has been changed, apparently recently, so I guess we are in
 violent agreement.
 Yep. Dan *still* doesn't like the idea, and I really don't want to have to 
 deal with the extra code that's inevitably involved, the complexity in the 
 parser to correctly identify perl 5 or perl 6 code, or with the errors and 
 compatibility problems that'll crop up. I'd much rather we had a standalone 
 utility that plugged into perl 5 somehow and leave perl 5 completely out of 
 the perl 6 core. (Heck, out of the perl 6 distribution) Given what Larry's 
 break^Wchanging, though, I don't think it's feasable. :(

Well, I think we should take a step back and answer a few key questions:

1. Do we want to be able to use Perl 5 modules in a
   Perl 6 program (without conversion)?

2. Do we want to be able to switch between Perl 5 and
   Perl 6 in a single file (by using module to dictate
   P6 and package P5)?

3. Do we want to assume Perl 5 or Perl 6 code? If we
   assume P5, then we have to look for module somewhere.
   If we assume P6, we can look for a number of differences,
   such as $foo[1], $foo{bar}, etc to identify P5 code.

4. Do we want to be able claim 100% compatibility, or
   99% except typeglobs, in which case if *foo is
   seen we just drop with Typeglobs not supported?

The more we answer yes then the more complex it is. ;-)


Re: Apoc2 - STDIN concerns

2001-05-08 Thread Nathan Wiger

* Larry Wall [EMAIL PROTECTED] [05/08/2001 09:36]:

 Taking history into account is good, though I'd argue that now is the
 proper time to change history, if we're going to change.  Perl would
 never have been accepted in the first place had it been too different
 from what came before, but now that Perl has its own momentum, we can
 now look at how our own history gets in our way, and maybe do something
 about it.

Very true. To this end I just would add that I think many JAPHs are used
to and like  as readline. I know I do. I'm not going to harp on this
point endlessly, but this is one aspect that I do like about Perl. And
keep in mind that unlike - vs . , *everyone* knows about FILEHANDLE.
It is as pervasive as $ and @.

That being said, I'm open to the idea of simply replacing  with  and
tweaking the semantics a little. For one thing, it's a char shorter. For
another, there's a  equivalent. So:

   $x = $STDIN;# read from STDIN.more

So  could mean more and  could mean less. Or something like that.
Whether or not  was implemented in 6.0 is unknown, but having that
analogous functionality may be interesting.

   @a = $STDIN[0..3];  # @a = ($STDIN.more)[0..3]
   @b = $STDIN[0..3];  # @a = ($STDIN.less)[0..3]

more and less could be inverses, more reading from the current
position forward and less from the current position backwards. This 
notion could be generalized to files/networks/stacks/datastructs/etc/etc.

 I think someone mentioned qh() for hash.  That's a possibility, but I'd
 still love to have enough brackets to give all of these standard shortcuts.

It is worth noting that qr// has no true shortcut. That is these:

   $x = /\w+/;
   $x = \w+;

Are definitely not the same as this:

   $x = qr/\w+/;

I also think that looking at qr// or qw// as being in the same class as
qq// is not 100% accurate. Really, qw// is a special type of q// that
also splits on whitespace.

 :  We don't actually have a good
 :  notation for forcing a scalar context yet, let alone a scalar context
 :  wanting a certain number of arguments.
 : Personally, I'd look at it differently. I don't think that getting a number
 : of arguments out of a scalar context makes sense. Rather, I think you need
 : to call a member function or do whatever to get a list, then lazily evaluate
 : that.
 :@a = $STDIN;# @a gets a single element - $STDIN
 :@b = $STDIN;  # @b gets the entire contents of $STDIN
 :# iterations via calls to more()
 You don't actually get the entire contents of $STDIN.  You get a value
 of $STDIN marked as a placeholder in the list assigned to @b, and that
 placeholder says the RHS requested expansion of this in a manner
 appropriate to the context supplied by the LHS.

 Assuming Perl 5 semantics of = continue, a similar thing will happen
 when you say:
 @a = @b;
 push(@c, @b);
 Perl 6 might not put all the elements of @b on the stack as a temporary
 list.  Rather, it might just put \@b marked as expandable.  (It might
 also have to put some kind of copy-on-write lock on @b to keep it from
 changing out from under, depending on how lazy the assignment (or
 subroutine) actually gets about reading out the array.)


 In this view, * and  could just be two different kinds of expandable flags.
 But I'm uncomfortable with that, because I'd like to be able to say
 lazy_sub($STDIN, $STDIN, $STDIN, $STDIN)

 to feed four lines to lazy_sub without defeating the prototype, er,
 signature checking.  Maybe you have to us *$STDIN to do both.  But that
 would probably say to slurp the whole rest of the file.

That would be my guess. Assuming  instead of , how about

   lazy_sub($STDIN[0..3]); # same as ($STDIN.more)[0..3]
   lazy_sub(*$STDIN);  # same as ($STDIN.more)[0..-1]

I would define * and  as:

   *  - greedy glob/list flattener
 - more iterator
 - less iterator
All of those are unary, of course. 

 : Basically,  is left as direct access to the iterator, but it's not
 : magically called except where it clearly make sense (and I don't think
 : normal variable manip like passing into subs and hashes should be in this
 : category).
 :  $$STDIN # Return one element regardless of context.
 :   $STDIN # Return number of element wanted by context.
 :  @$STDIN # Return all element regardless of context.
 :  or some other casting mechanism yet to be devised.
 : I'd do a variation on the above. Looking from a functional perspective:
 :  $STDIN.more  # context-dependent
 : ($STDIN.more)[0..3]   # just selected elements (lazily)
 : ($STDIN.more)[0..-1]  # forced all
 : Then we'd have the following shorcuts as a side-effect:
 : $STDIN  # context-dependent
 :($STDIN)[0..3]   # just selected elements (lazily)
 :($STDIN)[0..-1]  # forced all
 : Seems to be easy and clean, without lots of new syntax.
 I'd lose the 

Re: Apoc2 - Context and variables

2001-05-08 Thread Nathan Wiger

* Larry Wall [EMAIL PROTECTED] [05/08/2001 10:11]:

 Nathan Wiger writes:
 : First off, before I forget to mention it, nice job on Apoc2 Larry! You are
 : the man. I know alot of us on p6l can seem like harsh critics at times, but
 : it's only because we love Perl so much. ;-)
 We'll have to do something about that.  :-)

Yes, please, it's taking up my life writing so much of it! ;-)

[stuff that sounds great deleted]

 : Also, I like the *@b prototype slurping idea a lot, but I do worry about
 : potential confusion with the @*b special class notation. I'm wondering if
 : the latter can't be @::b?
 I wanted to keep true globals out of Main (presuming for the sake of
 argument that the bare :: still indicates the user's main package).

I guess that's what I was getting at: do we want :: to mean main? Is
this more useful that meaning CORE? The vast majority of the time I've
seen bare :: used I've seen stuff like this:

   @::ARGV = @something;
   unshift @::INC, '/my/lib';

If these are all going to be in CORE (personally, I'd much prefer a
different namespace than main), then it seems like a better use of ::
would be meaning CORE. It would actually reduce user confusion, since
@::INC and @::ARGV would mean the same thing in P6 as P5 (the package
will just have changed transparently).


Re: Apoc2 - STDIN concerns

2001-05-07 Thread Nathan Wiger

* Simon Cozens [EMAIL PROTECTED] [05/05/2001 17:51]:

  %foo = ( foo = 1, bar = 1, '=' = 'baz' )
 Of course, that could be spelt

   %foo = +foo +bar =(baz);

Actually, it couldn't be because the  in = would end the parsing.
Same problem that the POD  chars have.

I think Uri's qh() suggestion is the cleanest:

   use CGI qh(:standard !h2 !h3 version = 1.4);

And it would make hash declarations cleaner:

   %hash = qh(
jim = 'bob'

Plus maybe even a pragma to set the default value:

use default hashval = 'closed';
%dotcoms = qh(
 amazon = 'open'
 nettaxi = 'life support'

In fact use default could set stuff like what should mean truth too:

   use default false = qw(0 ),
true = qw(!undef);

Or something like that. That last one might help take care of the |||


Re: Apoc2 - STDIN concerns

2001-05-07 Thread Nathan Wiger

* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:17]:
 Bother. Well, you'd have to quote it, but then you wouldn't really have
 a hash key called = that often, either.

Yeah, but you couldn't make use of a way to assign alternate values without
some specialized syntax. I don't think this:

   %h = foo bar baz(2);

Is any cleaner than this:

   %h = qh(foo bar baz = 2);

It's just different. And in fact will require much more explanation than
the simple qw is 'quote words', qh is 'quote hash'. You can use any
delimiters you want.

  I think Uri's qh() suggestion is the cleanest:
 Interesting train of thought, since one of the ideas was that qw() is
 ugly and has to go. (Larry's been saying this for nearly two years now,
 it's just that people sometimes don't listen. :) Let's keep it and add
 something similarly ugly to keep it company!

 And the fact is, I've always loathed qw(), despite the fact that I
 invented it myself.  :-)
  -- Larry Wall in [EMAIL PROTECTED]

Yeah, that's too bad. ;-) But I still don't think that we're gaining
anything by introducing a non-extensible, special-cased op into the
language. Isn't this just the type of thing we're trying to get rid of?

I'm not against a cleaner way to do qw() in principle, but I
definitely think  is not it for a lot of reasons (glob, readline,
can't use =, iterators, ...)


Re: Apoc2 - STDIN concerns

2001-05-07 Thread Nathan Wiger

* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:33]:

  I'm not against a cleaner way to do qw() in principle, but I
  definitely think  is not it for a lot of reasons (glob, readline,
  can't use =, iterators, ...)
 Sheesh. Yes, those would be problems with using  in Perl 5.
 However, we are not designing Perl 5.

I know.

My point is there's a lot of lessons that have been learned from the
years of Perl development. They're coordinated into qw() in Perl 5. It
works very well, as do the other q-ops. Incredibly well, actually.

And = in  is still a problem for any parser, even Perl 6's.

To quote you:

: Perl 6 is our opportunity to give Perl a good spring clean. When
: you're spring cleaning a house, you throw out the trash and dust
: down the ornaments, but you don't burn it down and build a shopping
: mall instead.
: I think it's reasonably fair to assume that we're all Bprimarily
: working on Perl 6 because we like Perl and we want to make it better,
: not because language design is a fun thing to do of an evening. If
: that's the case, nobody wins if we bend the Perl language out of all
: recognition, because it won't be Perl any more. So let's not do this.
: Let's keep Perl recognisably the language we know and love; let's
: enhance it, by all means, but let's not turn it into something it 
: isn't.

I'm not trying to be a jerk at all, but I think at times we're losing
sight of the above.


Re: Apoc2 - STDIN concerns

2001-05-07 Thread Nathan Wiger

* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:46]:

  To quote you:
  I'm not trying to be a jerk at all, but I think at times we're losing
  sight of the above.
 I hope not, since it was primarily written with you in mind. :)

Hmm, that's odd. As I recall I was one of the most fervent proponents of
RFC 28:

Or did you mean something else?

If you read my RFC's with a this guy loves Perl mindset I think you'll
find most all of them are not actually that radical. The only ones that
are really out there are ones like RFC 159, but even that's designed
to be hidden under the hood.

But I think we're getting a little off-topic...


Re: Apoc2 - STDIN concerns

2001-05-05 Thread Nathan Wiger

 :$FH = open $file or die Can't open $file: $!;
 :$line = next $FH;
 : If so, I can live with that.
 Yes, that's the reason it's Cnext, and not something more specific
 like Creadline, which isn't even true in Perl 5 when $/ is mungled.

 I dunno. Color me unconvinced--I do use the  enough in non-while context
 (and in non-implied while context) to make the whole idea of next feel
 rather... nasty. And $ Yuck.

You know, I was just thinking about this, and I agree with Dan. Actually,
there's some big problems in trying to get rid of  and make Perl do the
right thing in boolean context (like the while loop example). Consider:

   $FH = open /etc/motd;
   die No good unless ($FH);# ???

What does that do? Per the proposal, $FH in a boolean context is supposed to
call its next() method to get the next line. So, does that fail because the
handle wasn't opened (and hence $FH was never defined) or because /etc/motd
is zero-length?

And having to write $line = next $FH is already getting cumbersome, to be

I say we should combine the two concepts. Why not make  a shortcut to the
proposed new general-purpose-iterator concept? So:

   $line = $;# yuck, I agree with Dan
   $line = next $FOO;# better...
   $line = $FOO;   # aaah :-)

   print while ($FOO);   # infinite, assuming $FOO defined
   print while ($;  # while reading the file
   print while ($FOO); # still my favorite

Otherwise, it seems like there's a lot of Black Magic with calling next()
automatically, and for something as fundamental as I/O that makes me really


Re: Apoc2 - STDIN concerns

2001-05-05 Thread Nathan Wiger

Ok, this is long, so here goes...

 I expect the real choice is between $FOO and $FOO.  I can convince
 myself pretty easily that a unary  is just another name for next, or
 more, or something.  On the other hand $FOO has history.  And if
 one special-cases $..., we could also have foo bar baz as a qw()
 replacement.  All we'd be doing is taking that syntax away from
 globbing, and giving it to qw, more or less.  (Less, because I'd like
 foo bar baz($xyz) to mean {foo = 1, bar = 1, baz = $xyz} or some
 such, where the 1's are negotiable.)

One thing I think we should avoid is as many special cases as possible.
This is already why people hate  currently - because it does both glob()
and readline().

I would say that  having history is actually a good thing. It's a
foundation, really, since readline() is an iterator of sorts. All we'd be
doing is generalizing the notion. Not only does it apply to files, but it's
a shortcut to more() wherever you feel like using it.

As for  as a qw() replacement, I think there are really two issues here.
First, you're not really talking about a replacement, since you're
mentioning different semantics. So qw() will still be widely used. I suggest
that we simply create another q-op to do the qw-ish things you're proposing.
Perhaps qi() for interpolate or something else. Plus  has the terrible
problem that the POD C stuff does w/ embedded  chars. The really nice
thing about the q's is you can choose any bracket you want. I think fleshing
out this series of constructs makes the most sense.

 For a circumfix, you could just treat  as funny parens:

 $line = somefunc();

 On the other hand, I wouldn't want to go so far as to require


 merely to make the iterator iterate.  Saying


 ought to be enough clue.

Yes, I think that  could just be shortcut to wherever you wanted more()
called. Just like .. with a different notation:

   @foo = $BAR;
   @foo = @bar[1..10];
   @foo[0..4] = $BAR;

This is nice because it looks Perlish, but fundamentally it could be reduced
to a single iterator concept.

 But does that mean that


 should read one value or all of them?

I would say that this should return only one thing - the $STDIN variable. No
automatic iteration should be done. Otherwise you run into problems with how
to pass filehandles around as variables. I think iteration needs to be

If you want iteration:

   %foo{$STDIN};   # poll the iterator
   %foo{$STDIN.more};# same thing

The iterator is just a member function, and you have to call it if you want

   $FOO = open bar;
   do_stuff($FOO);# filehandle passed, not contents
   do_more_stuff($FOO); # now filehandle is iterated (lazily)
   do_more_stuff($FOO.more);  # same thing
   %holding_stuff{$FOO.more};  # same thing, just into a var
   close $FOO;

I think these semantics make sense.

 Obviously, given a list flattener *, we'd expect


 to return all the values.  Maybe then


 returns exactly one value, and



I'd so this differently, as hinted at above:

   %foo{$STDIN};# return all values
   %foo{$STDIN); # return one value
   %foo{$STDIN};  # pass the $STDIN variable

This is assuming that we want  to exist and have a different semantics. But
I'm not sure that's a good idea. For one thing, you'd have to mention it
several times if you want a couple values. I think there's got to be a
better way to request the number of lines based on context.

   %foo{$STDIN};  # the whole thing
   %foo{ (1..2) = $STDIN };   # anonymous list request?
   %foo{ $STDIN[1..2] };  # or notate it as a list?
   %foo{ ($STDIN.more)[1..2] }; # same thing

The last one seems to make sense (it's got those (localtime)[2,3] roots),
with the third one as a shortcut.

 Looking at it from the iterator object end, there might really be three

 $ # Return one element regardless of context.
 $STDIN.more # Return number of element wanted by context.
 $STDIN.all # Return all element regardless of context.

 Or maybe there's only a more method, and you simply have to force the
 context if you don't want it to guess.

I think one method is the way to go. Let the subs and other contexts request
the number of elements to get back using lazy evaluation:

   @foo[1..10] = $STDIN; # get 10 iterations
   $bar = $STDIN;# next one
   lazy_sub($STDIN);# lazily


   sub lazy_sub ($a, $b, $c, $d) {   }

Then the last line above would lazily grab the next four lines.

 We don't actually have a good
 notation for forcing a scalar context yet, let alone a scalar context
 wanting a certain number of arguments.

Personally, I'd look at it differently. I don't think that getting a number
of arguments out of a scalar context makes sense. Rather, I think you need
to call a member function or do whatever to get a list, then lazily evaluate

Apoc2 - STDIN concerns

2001-05-04 Thread Nathan Wiger

There's a lot of good stuff in Apoc2, but I did have at least one
semantic concern. In it, there's this proposal:

: There is likely to be no need for an explicit input operator in Perl 6,
: and I want the angles for something else. I/O handles are a subclass of
: iterators, and I think general iterator variables will serve the purpose
: formerly served by the input operator, particularly since they can
: be made to do the right Thing in context. For instance, to read from
: standard input, it will suffice to say
:  while ($STDIN) { ... }

I'm wondering what this will do?

   $thingy = $STDIN;

This seems to have two possibilities:

   1. Make a copy of $STDIN

   2. Read a line from $STDIN

To be semantically coherent, it seems that the first one should be the way
it works, like with other variables. That is:

   $FILE = open /etc/motd;

   $DUP = $FILE;# dup input stream
   $line = $FILE; # or $FILE.readline

This gives you some niceties:

   $STDERR = $STDOUT;   # redirect

Or, it could be that simple assignment instead grabs the iterator:

   $line = $FILE;   # grabs $FILE.readline, which is next line
   $DUP = $FILE.dup;# must call dup() to duplicate filehandle

If it's the latter, then  is free. However, if it's the former then
we'll still need them. Personally, that latter one scares me a little,
but I'm open-minded.


Apoc2 - STDIN concerns

2001-05-04 Thread Nathan Wiger

[apologies if this is a duplicate, but my mail's been dropping]

There's a lot of good stuff in Apoc2, but I did have at least one
semantic concern. In it, there's this proposal:

: There is likely to be no need for an explicit input operator in Perl 6,
: and I want the angles for something else. I/O handles are a subclass of
: iterators, and I think general iterator variables will serve the purpose
: formerly served by the input operator, particularly since they can
: be made to do the right Thing in context. For instance, to read from
: standard input, it will suffice to say
:  while ($STDIN) { ... }

I'm wondering what this will do?

   $thingy = $STDIN;

This seems to have two possibilities:

   1. Make a copy of $STDIN

   2. Read a line from $STDIN

To be semantically coherent, it seems that the first one should be the way
it works, like with other variables. That is:

   $FILE = open $file;

   $DUP = $FILE;# dup input stream
   $line = $FILE; # or $FILE.readline

This gives you some niceties:

   $STDERR = $STDOUT;   # redirect

Or, it could be that simple assignment instead grabs the iterator:

   $line = $FILE;   # grabs $FILE.readline, which is next line
   $DUP = $FILE.dup;# must call dup() to duplicate filehandle

If it's the latter, then  is free. However, if it's the former then
we'll still need them. Personally, that latter one scares me a little,
but I'm open-minded.

Re: Apoc2 - STDIN concerns

2001-05-04 Thread Nathan Wiger

 : This one. I see a filehandle in *boolean* context meaning read to $_,
 : just like the current while (FOO) magic we all know and occasionally
 : love. I'd expect $FOO.readln (or something less Pascalish) to do an
 : explicit readline to a variable other than $_

 It would be $, but yes, that's the basic idea.  It's possible
 that iterator variables should be more syntactically distinquished than
 that.  One could, I suppose, make up something about $FOO or $FOO
 meaning the same thing thing as $, for people who are homesick
 for the angles, but I haven't thought that out, and don't even dare to
 mention it here for fear someone will take it as a promise.  Er, oops...

So, just to clarify, the thought is:

   print while ($FOO);# like Perl 5 FOO
   $var = $;  # like Perl 5 $var = FOO;

I assume that this is indicative of a more general iterator syntax, and
subject to indirect objects?

   $FH = open $file or die Can't open $file: $!;
   $line = next $FH;

If so, I can live with that.


Re: Apoc2 - STDIN concerns

2001-05-04 Thread Nathan Wiger

 While perhaps inconsistent, I'd really rather it did #2.  Here's the
 basic argument... compare how often you dup a filehandle with how
 often you read from one.  Duping is swamped by several orders of
 magnitude.  Dup with $fh = $STDIN.copy; (or whatever).  $line =
 $ should still work normally.

You know, I hear what you're saying, but it really makes the little hairs on
my neck stand up. Just imaging trying to teach this:

   $a = $b;# assignment or readline?

It's really spooky. You're changing what = does, indeed what method it calls
(copy vs next), based on the contents of the variable. I'd much rather have
to do:

   $a = next $b;

Truthfully, I've always liked the 's (and personally don't think we need a
qw alternative), so I'd rather we stay with:

   $a = $b;   # same as next $b or $

Hey, maybe we can convince Larry... ;-)


Apoc2 - Context and variables

2001-05-04 Thread Nathan Wiger

First off, before I forget to mention it, nice job on Apoc2 Larry! You are
the man. I know alot of us on p6l can seem like harsh critics at times, but
it's only because we love Perl so much. ;-)

Anyways, in addition to the $ stuff, I'm curious about a few
clarifications on the new semantics of arrays and hashes. Overall it looks
outstanding. I'm interested in what happens with interactions:

   $a = @b;

Does this:

   1. Get the length (doesn't seem to make sense now)
   2. Pull a reference to @b (like Perl5's $a = \@b)
   3. Get the first element of @b

Similarly, how about:

   %c = @d;

Does this:

   1. Create a hash w/ alternating keys/vals like Perl5
   2. Do the equivalent of %c = \@d in Perl5
   3. Or the mystery meat behind Door #3

Also, I like the *@b prototype slurping idea a lot, but I do worry about
potential confusion with the @*b special class notation. I'm wondering if
the latter can't be @::b?


Re: Apoc2 - Context and variables

2001-05-04 Thread Nathan Wiger

$a = @b;

2. Pull a reference to @b (like Perl5's $a = \@b)

 Yep. Scalar context eval of arrays, hashes, and subs produces a reference.


 Similarly, how about:

%c = @d;

 Does this:

1. Create a hash w/ alternating keys/vals like Perl5
2. Do the equivalent of %c = \@d in Perl5
3. Or the mystery meat behind Door #3

 This one's still less-than-certain. Definitely either 1 or 3 though.

The more I was thinking about it, it seems like #1 makes a good amount of
sense. If you think about it, you're talking likes-to-likes. When you assign
scalars, you're copying the single values. When you're copying list data
structs, you're copying multiple values.

  %a = @b;# same as Perl 5
  @c = %d;# same as Perl 5
  $e = $f;# same as Perl 5
  $g = @h;# Perl 5 $e = \@c

The real trick is what to do with these:

  %a = (%b, %c);
  %d = (@e, @f);

Or, horrors:

  %i = ($j, %k, @l);
  ($m, @n, $o) = (@p, $q, %r);

Jeez, this is getting complicated. ;-)


Re: Apoc2 - STDIN concerns

2001-05-04 Thread Nathan Wiger

 We do have to worry about the Cnext loop control function though.
 It's possible that in

 FOO: while (1) {
 next FOO if /foo/;

 the CFOO label is actually being recognized as a pseudo-package
 name!  The loop could well be an object whose full name is CMY::FOO.
 Or something like that.  But maybe that's a gross hack.  Seems a bit
 odd to overload Cnext like that.  Maybe we need a different word.

I don't want to get accused of too much bikeshed-painting :-), but seems
like more would work:

   $line = more $FOO;

This also connotes generalized incrementing, so it serves that purpose too.

And, hey, there's less for decrementing too!


Re: Apoc2 - Context and variables

2001-05-04 Thread Nathan Wiger

 Horrors is right. The default perl5 behaviour is *useful*. I use the
 metaphor all of the time.

 Why not just keep it simple? And perl5-ish. Two contexts, scalar and list,
 hashes NOT a context of its own.

I agree. But what to do with:

   (%a, %b) = (%c, %d);

Surely that shouldn't act too differently from:

   %a = (%c, %d);

It seems either the list should be flattened or not.

Maybe we need a new flattening operator. I don't think the proposed := by
itself would do everything we need to do. Maybe we need a way to say
flatten these together. I'm going to throw out a new : op here:

   %a = (%b, %c); # same as %a = %b
   %a = (%b : %c);# flattened like Perl 5
   (%a, %b) = (%c, %d);   # kept separate
   (%a, %b) = (%c : %d);  # %a slurps all of flattened %c and %d,
  # %b gets nothin'

This allows you added functionality to flatten stuff as you see fit:

   (%a, %b) = (%c : %d, @e : @f);
   (@a, @b) = ($c : $d : $e : $f, @g : $f);

Hmmm... I kinda like that... Am I missing anything?


Re: a modest proposal Re: s/./~/g

2001-04-26 Thread Nathan Wiger

Graham Barr wrote:
 You don't get it.
 We are not looking for a single char to replace -
 We WANT to use .

With complete respect here, I'm still not convinced this is true.
Specifically, what the value of we is. It hardly sounds like
everyone's united on this point. In fact, I've counted more postings of
the tone Why would we change - ?! than the other way around.

Now, it may be that all the We should use . people are just keeping
quiet, or think it's obvious why this is a benefit, but I'm unconvinced.
Again, I'm open-minded, but the only argument I've really heard is to
make Perl more Java/Python-like. This doesn't sway me at all. Are there
other reasons?


Curious: - vs .

2001-04-25 Thread Nathan Wiger

I'm just gonna post this, then back off and listen (been yapping too

The previous discussions about string concat and how to replace . have
revealed that people are somewhat divided over whether replacing - with
. is actually good thing or not.

I'm just curious what the arguments for and against it are. PLEASE don't
turn this into an unproductive religious flamewar. I'm open-minded about
it, but I at least need a little convincing. Whether or not this has any
impact on Larry's decision is unknown, but it seems like it's good to at
least have the pros and cons clearly on the table.

Just to start it off, here are some of the arguments against changing
this that I know of. If you know of others, or are on the for side of
things, feel free speak up. Politely, PLEASE.

   Arguments Against Changing - and .
   - It gains superficial similarity to other HLL's,
 yet Perl is fundamentally semantically different
 from all of them. Plus, this is not the only
 syntactic difference.

   - JAPH compatibility. Thousands of people already
 know how deref and concat work, and they're the
 target audience for Perl 6, after all. Sure, we'd
 closer to Python, but we'd be further from Perl 5.

   - C compatibility. One of Perl's great strengths
 over other HLL's is C compatibility. Though
 this is still arguably not as good as it can be, 
 why distance ourselves from the language we're
 trying to interact with?

   - Dissimilarity between Perl and languages like
 JavaScript can actually be beneficial. If you're
 generating code, this makes it easier to scan
 and see where your Perl ends and your Java begins.

   - Two keys less to press? Ever heard of macros? :-)

Sane + string concat proposal

2001-04-24 Thread Nathan Wiger

probably already rolling your eyes. However, I searched p5p all the way
back to 1997 and could not find this proposal anywhere. Even though it
looks similar to the standard Java + concat overload stuff, it is not,
so please try to keep an open mind.

Everyone agrees that keeping string and numeric ops semantically
separate is a Good Thing. As Dave nicely explained, this allows us to
twist our scalars into strings or numbers based on the operators,
instead of the other way around. This allows a single scalar type. This
is not something we want to lose.

Under this proposal, string concatenation would be acheived by the
*combination* of  and +. So, in Perl 5 you would have something like

   $string3 = $string1 . $string2;

In Perl 6, you would do this like so:

   $string3 = $string1 + $string2;

Here's the key: The quotes are REQUIRED. 100%. Always. If you left them
off, you'd get numeric addition. Always. There is no magic type 

Think of this like using $ and [] to get an array element. You can't
just say 'array[1]' or '$array' and expect to get the right thing.
Rather, you have to combine the two. Same here, you have to combine 
and +.

The win here with Perl is that having $prefixes actually allows us to
expand variables in  still. No other HLL can do that. As such, other
languages have to overload their operators based on type. In Perl, we
can maintain the semantics of a separate string concat by requiring
quotes. This is hardly a far cry from current; in fact, it's quite
logical (since  is already string context) and very close
syntactically to other HLL's.

So, here's a little table:

   Perl 5  Perl 6
   --- ---
   -  .
   +   +
   .and +

You get a Java/Python/etc syntax while retaining the semantics of
separate string and numeric ops.

More Details

Ok, if you're still reading, cool. Let's get down to the nitty-gritty.
Here are some more examples of code:

   Perl 5Perl 6
   $res = $var + $var2;  $res = $var + $var2;
   $name = This . that;  $name = This + that;
   $name = This . $that;   $name = This + $that;
   print Next is  . $i + 1;print Next is  + $i + 1;
   $me = $name . getpwuid($);   $me = $name + getpwuid($);   

That last one is important. Notice that the  on the $name means that
the next + becomes a string concat. The getpwuid call is then concat'ed
onto that. If, instead, you wrote:

   $me = $name + getpwuid($);

You would get numeric addition. Always. In this way, you maintain a
reliable semantic separation of string concat and numeric addition,
while gaining a syntax that is similar to other HLL's. Having $var
expand $var is the reason this is possible.

Anyways, what do you think? (Please try to resist knee-jerk Java
reactions :).


P.S. I've got many more examples, but didn't want to flood the list with
a massive proposal. I'm pretty sure all the bases are covered, but am
interested in potential gotcha's...

P.P.S. I'm also not some Java newbie who's complaining about . and
eq, so don't even go there.

Re: Sane + string concat proposal

2001-04-24 Thread Nathan Wiger

Stephen P. Potter wrote:
 | In Perl 6, you would do this like so:
 |$string3 = $string1 + $string2;
 Once you go this route, you've pretty much destroyed the usefulness of
 having a concat operator.  It is far less typing to do
$string3 = $string1$string2;

Agreed. The point wasn't to get rid of that usage by any means, but
rather to propose an alternative to . since that will likely get
gobbled up as a replacement for -.

The only reason you'd have to use the op form of a string concat is when
you have to add stuff in that isn't evaluated inside quotes, like funcs.


Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-24 Thread Nathan Wiger

Michael G Schwern wrote:
 On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
  ok, well.. I've heard arguments for '+' (namely that its intuitive, other
  language compatible, etc...) so what are the arguments against it?
 This one seems to have slipped by...

From that email:

 Consider the following...

sub foo { $_[0] + $_[1] }

 What do the following return?

foo(1,1);   obviously 2
foo(this, that) obvious thisthat

 Those are simple enough.

foo(1, 1);is that 11 or 2?
foo(undef, 1);  1 or 1?

 Those can be solved by definining precidence, but its still a bit

foo($foo, $bar);who knows?

Based on what I posted, my position would be: foo returns numeric

Again, don't think of + as a dual-natured op. That's not what I'm
saying. It remains numeric addition. The C + operator is your string

If you wanted foo to return a string concat, you would have to say:

   sub foo { $_[0] + $_[1] }

(or use $_[1], either way). Without the quotes you're not properly
using the operator.

I'm not really fighting for what I posted per se, but I do want to
emphasize it's not the same as what's been discussed before.


Re: YA string concat proposal

2001-04-24 Thread Nathan Wiger

Michael G Schwern wrote:
 cc and ce
 Perl 5  Perl 6
 print foo . bar;print foo cc bar;
 print 2 . 4;print 2 cc 4;
 print foo  . ($i + 1);print foo  cc ($i + 1);
 $foo .= bar ; $foo ce bar;

 It also has the nice side-effect of preserving '.=' functionality,
 which I'd rather not lose (especially after having made fun of
 $foo = $foo . 'bar'; type code).

While we're brainstorming a wish-list, here's something I've always
wanted, a replacement for:

   $a = $b . $a;

Under the above plan, maybe this is:

   $a ca $b;

For concat after?


Re: Sane + string concat proposal

2001-04-24 Thread Nathan Wiger

Michael G Schwern wrote:
 Oh, not to seed the clouds or anything, but what about += and .=?
 Any proposal will have to deal with those.

Under what I originally posted:

   $a += $b;# string
   $a += $b;  # numeric

Seems easy enough...


Re: YA string concat proposal

2001-04-24 Thread Nathan Wiger

Uri Guttman wrote:
 on the other hand, i use .= all the time and wouldn't like to lose
 it. schwern idea of ce doesn't work for me as only the op= stuff means
 assignment and ce would break that (e for = isn't visual enough).

I was just thinking, too bad that Larry's claiming the colon

   $str = $a : $b : $i + 1;
   $a := $b : $c;
   $name = $p-param('first') : $p-param('last');

Maybe it's just me, but I like that.

There is, of course, the possibility others have mentioned which is to
make , in a scalar context do something perceived as more useful:

   $str = $a, $b, $i + 1;
   $a ,= $b, $c;
   $name = $p-param('first'), $p-param('last');

But that second one is a little weird. Plus, this:

   ($a, $b) = ($1 . $2, $3 . $4);

Is now not possible.

 .= could still be left working as that is a complete separate op from
 method invocation. i can live with most any other form of . including
 none. join is fine for that.

Possible, but my gut reaction is that this could be confusing,
especially assuming that you're going to see . all over your code
meaning object deref now.


Re: Sane + string concat proposal

2001-04-24 Thread Nathan Wiger

Stephen P. Potter wrote:
 You still haven't given a good explanation of
 $a += sub();  # is it a string or a number?
 Does your plan mean that we can no longer have subs that are context

No, Schwern asked me this same thing off list, here's what I said:

One possibility:

   $a += foo();

And for the multi-function version I'd say:

   $result = join  , func1(), func2();

I don't see a solution for that with the C + proposal, so this is
one issue. Any ideas?

Summarizing, here are the pros/cons of this approach. Please let me know
if I've left any out:


- Similar syntax to other HLL's (like .-deref)
- Semantically separate string concat and
  numeric addition maintained
- Most functionality maintained


- Lose some important . stuff, like with functions
- The C + concept actually changes precedence
  of + in certain circumstances, which is weird
- Parsing C + as an op just ain't that easy

Anyways, I'm not sure of what the fate of this concept is going to be,
and I'm not going to try and fight for it per se. Truthfully, I'd rather
we keep - and . as-is. I rather like them that way.

However, if Larry decides that .-deref is happening, then this is at
least one alternative of several to ponder, if for no other reason than
it bridges Perl to other HLL's with a syntax/semantics that mostly


Regexp::Func (Re: YA string concat proposal)

2001-04-24 Thread Nathan Wiger

Stephen P. Potter wrote:
 Oh, and since it hasn't been mentioned for awhile, I'd still prefer if =~
 and !~ went away and were replaced by match(string, [pattern], options),
 replace(string, [pattern], options) and trans(string, [pattern], options)
 or some such.  This is one place where I think PHP had a really good idea,
 but missed the mark a little.  ereg_* and eregi_* and preg_* and pregi_*,

I'm working on Regexp::Func in another vi window that does this very
thing right now. Although, the syntax I'm working with is a little
different from what you describe above:

   $result = match /pat/flags, $strings ...;
   $result = replace /from/to/flags, $strings ...;
   $result = trade /from/to/, $strings ...;

The advantage to this syntax is you can do whole lists inline. See also
RFC 164. Suggestions welcome, and anyone wanting to test this *very*
welcome (off-list is probably best, this is OT).


Re: Tying Overloading

2001-04-23 Thread Nathan Wiger

Larry Wall wrote:
 : I _really_ think dot-syntax would make perl prettier as well as make it
 : more acceptable to the world of javacsharpbasic droids. Which is some
 : kind of goal, no?
 Consider it a given that we'll be using . for dereferencing.  (Possibly
 with - as a synonym, just for Dan. :-)


 + is out because it will add numbers.

FWIW, if we're going to go all the way and make Perl's objects .-based
(which I personally dread, but oh well), then we should adopt the +
for string concat as well. Yes, I know that string concat isn't
commutative and all the other stuff, but who cares? Sometimes taking
what other languages do just because it's widely used is worthwhile. I
personally don't know of any other language that uses ~ for string
concat. Does anyone else?

Besides, if everything's an object and you have a vtable/whatever PLUS
method, then why shouldn't:

   print The next loop will be  + $i + 1 + \n;


As a segue for a second, we should keep in mind which types of people
we're trying to satisfy. I personally don't care at all if Perl 6 is
more popular with Java and C# people than Perl 5. But I definitely don't
want it to be less popular with Perl folks (like me). With the proposed
changes in this thread so far, you've got:

   P5  P6
   --- ---
   -  .
   .   ~

For no net gain. I know we're just brainstorming still, but - is not an
oddity to Perl. There are other languages (like C) that use this. And
personally I think Perl is far more effective as a C-sh/cgi glue than a
Java-.Net glue. The latter space is already populated w/ Java and C#,
and Sun and MS have a little bit of marketing cash.

Just my own personal feelings. I don't want Perl 6 to be a complete
disregard for Perl 5, but rather an improvement over it (RFC 28, you


Strings vs Numbers (Re: Tying Overloading)

2001-04-23 Thread Nathan Wiger

Larry Wall wrote:
 The . is just syntax.  Do you mean something semantic by .-based?

No, but I think just syntax is a little misleading. I do agree that we
well, Perl 5 did it this way is not a sufficient design decision at
this point. However, if you changed Perl's syntax too radically you
would almost certainly lose programmers. You drop the $'s, change - to
., do this/that/etc and pretty soon it looks like Java, which people
like myself really dislike. One of the reasons I program in Perl as my
primary language is *because of* the syntax.
 I don't care about commutative either, but what you are proposing is to
 throw away a particularly useful feature of Perl, which is its
 autoconversion between numbers and strings.  That we're not going
 to lose.  This implies that string operators must stay distinct
 from numeric operators.

I don't think that this is necessarily true (more below).
 Doesn't ~ look like a piece of string to you?  :-)
 I think it kind of looks like a stitch.

It looks like a bitwise op to me, personally. I've never seen it used
anywhere as a string concat. Again, that's not to say it can't be in
Perl 6, but it would be a real oddity.
 Then how do you concatenate a number?

Here's something I was thinking about at lunch:

   $concated_number = $number + $other_number;
   $numerical_add   = $number + $other_number;

Why not require  in the case when you want to forcible concat a number
as a string? Most people write:

   $string = $number$other_number;

Already anyways. You would only have to disambiguate if one of the args
was not a string. So here would be some equivalents:

   Perl 5Perl 6
   This . that   This + that
   $this . that$this + that
   $maybe_a_num . $that  $maybe_a_num + $that
   $i++  $i++
   $i + 1$i + 1

I know this isn't the first time something like this has been suggested.
And the problem isn't necessarily with the above, but with stuff like

   die Nope unless ($i == 0);# eq 0 ??

But I'd argue all you have to do is use :

   die Nope unless ($i == 0);   # str eq
   die Nope unless ($i == 0);   # same
   die Nope unless ($i == 0); # num ==

Unlike Java and other languages, Perl has an advantage with $'s: You can
use quotes to disambiguate, since $var will still expand $var (unlike
var). This opens up a whole bunch of interesting alternatives.

 Me either.  But then you propose to break one of the most endearing
 features of Perl 5.

No, not by any means. Sorry if I wasn't clear.
 There are many people who would prefer . to -, if for no other reason
 than it's cleaner looking and is one less character to type.  The fact
 that it's become the industry standard for method call syntax is also
 a point in its favor.

I do agree with that, but by this logic then we should look seriously
into using + for string concat. Otherwise, all we're doing is trading
one oddity for another. Sure, . now means object deref, but why (says
the JavaDrone) do I use ~ for string concat? That's weird.

Plus, you're now requiring all the Perl hackers to relearn two major
tenets of Perl: - and .. 

Again, if this is going to be done, IMO it needs to be done wholesale
otherwise it will be detrimental to language.
 : I know we're just brainstorming still,
 Well, maybe we are, at that.  But I feel as though I've been in design
 mode for a while now.  That is, any brainstorming I'm doing at this
 point is merely to feel my way into the ramifications of making some of
 the hard-nosed decisions that have to be made.

All I meant was that just because an email comes out that says I think
we should rename @foo to ^bar doesn't mean it's set in stone...yet.

 I think Perl is still suboptimal as C glue, and we can improve it.  If
 it becomes better VM glue at the same time, all the better.  But I fail
 to see how . notation can be much of a political issue, unless people
 choose to turn it into one.

No, I don't think it's a political issue at all. But syntax is a big
part of a language. You could argue that this code:

   using System;
   void public static Main () {
Console.Print(Hello, World!\n);

Is just syntax too, but that doesn't mean it's easy or fun. Perl is
both, and syntax is a huge chunk of that.

 : The latter space is already populated w/ Java and C#,
 : and Sun and MS have a little bit of marketing cash.
 And because they have better marketing we should therefore concede in
 the technical sphere?  I don't follow.

No, but if Perl looks 95% like Java or C#, my prediction would be it
will lose. If you throw out everything from the tens of previous years
of Perl, then you cause a whole bunch of JAPH's to relearn lots. And
then, these people might be prompted to say Hey, if I have to relearn
all this, let me check out some alternatives. At which point you lose
people to Java or C# or other similar languages.

Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-23 Thread Nathan Wiger

John Porter wrote:
  One of the reasons I program in Perl as my
  primary language is *because of* the syntax.
 With all due respect, I don't believe that's why you,
 or anyone else, likes to program in Perl.

I *really* don't want this to turn into a religious argument, which it's
fast becoming. I will tell you that my statement above is completely
truthful, coming from a sh/C background. If you don't believe me, well,
I don't know what to say.

Here is all I'm saying:

The argument for changing - to . is because it gains us compatibility
with other languages that are HLL, like Java, Python, C#, C++, etc, etc.
THIS IS GOOD. I agree.

However, if we are to do this, then I say we go the whole 9 nine yards
and figure out how to make + do correct string concat. That is, make
sure we maintain the auto-conversion from strings - numbers. Here,
we're be one-upping Java and other clones. We already (via overloading)
have $var != $var, so let's look into using this.

Now, please don't quasi-flame me and claim that I'm saying we can't have
~ mean string concat because it's odd. But, if we're trying to get
closer to other languages with - vs ., then adding ~ works against
that goal. This is made worse by the fact that *everyone* - Perl hackers
and Java programmers alike - will perceive this as different from all
other languages. It runs directly counter to the original goal: Making
Perl syntax more consistent with other languages.

Anyways, I'm really not on either side of the fence - please don't
misunderstand me. All I'm saying is that we should figure out the goal
and try to achieve that. Think of how cool it could be if we could
*extend* the Java . and + operators with better DWIMmery!


Perl 5 compatibility (Re: Larry's Apocalypse 1)

2001-04-05 Thread Nathan Wiger

Ted Ashton wrote:
 Thus it was written in the epistle of Michael G Schwern,
  I think [Nate]'s saying that its annoying to have to write any tag
  that says "Hey, I'm starting a new Perl 6 program here!" at the top of
  every single program, much in the same way its tiresome to write "int
  main(...)" in every C program.  Then again, we already have to do the
  #! thing.
 Not only is it tiresome, it really gets in the way of writing perl6

Right, exactly.

 Perhaps it could be
   1) If the code uses "module" or
   2) If the executable called ends in 6.

Yep, something like this would be cool. But as Dan suggested we'll
probably have to let Larry clarify his intent here. I read it as "it
would be cool to assume that we're getting real Perl 5 code", rather
than as just assuming Perl 5 non-strict policies, but actual Perl 6

I agree with Ed that, if you think about it, parsing Perl 5 in the Perl
6 detachable-lexer-parser model shouldn't (hopefully) be any harder than
parsing Python (or Parrot :) syntax. Assuming this, then in one way
Perl5 compatibility could be a "no-brainer". But the real question is
how to distinguish Perl 5 vs 6 reliably. We could have "module main",
but like Schwern, my left eye starts twitching and I get hot flashes
with "int main" hallucinations. 

Anyways, it's probably something worth pondering, as the more compatible
with Perl5 Perl6 is, the more likely it is to be accepted. The more I've
been thinking about the p52p6 translator, the more it bothers me. I just
think of the different Fortran versions and that whole mess.


Re: Turn 'em on! (was Re: Warnings, strict, and CPAN)

2001-02-23 Thread Nathan Wiger

 But we can run an experiment.  Warnings can be made default for the
 first few releases of Perl 6 and we'll see what happens.  If it looks
 good, leave them on.  If not, shut them off. Unlike most other
 features, this one doesn't have any serious backwards compatibility

Ummm, I'm not too sure about this. There are, actually, backwards
compatibility concerns. Unless I'm mistaken, warnings go to stderr,
correct? Meaning that a program which may have lots of "unitialized
variables" and "variable only used once" warnings in them, *and* which
rely on outputting useful information to stderr (like "real" warnings
that the user put in the program) will have that polluted with lots of
Perl gunk.

This doesn't break code, but it does break the usability and behavior of
the program. So to do this effectively and transparently p52p6 should
really stick a "no warnings" in a p5 script to make sure that stderr
isn't polluted. But then we're back to where we are now

Maybe what we really should be talking about is a way to let site users
customize what flags are on by default? Just like customizing which
modules are dynamically vs. statically loaded. I know this issue got
beaten to death in the language RFC process already, but... if there are
truly 2 groups with opposing viewpoints, why not add to Configure:

  Command-line flags on by default [-T -Mstrict -Mwarnings]:



The binding of my (Re: Closures and default lexical-scope for subs)

2001-02-16 Thread Nathan Wiger

Branden wrote:
 As to the second item b), I would say I withdraw my complaints about `my' if
 my other proposal of `use scope' gets approved (since then I don't need `my'
 anymore!). I guess I would be happier with `use scope', and I also think it
 would make you happier, since it wouldn't bother the current way `my' works,
 and all you'd have to do is not bothering the `scope' pragma exists.

I wouldn't be so hasty to withdraw from the my binding argument. There's
many uses of "my" that are required even with the "use scope" pragma (at
least as I described it in RFC 64, but feel free to point it out if I
missed an application). I think there's some good chugging on the my
binding concept going on, so let's not kill it quite yet.

To rehash, all this discussion should involve is the possibility of
making "my" swallow its list args:

   my $x, $y, $z;   # same as  my($x, $y, $z)

That's it. No changing the way lists and , and = work in Perl. If you
want to use split you still have to say:

   my($name, $passwd) = split ':';

As far as I can tell, these are the current arguments for/against my
being changed to bind less tightly:

 1. It becomes more consistent with other Perl functions

 2. It makes certain uses easier to write and understand,
such as when declaring lots of variables on the same
line. Many expect this:

 my $x, $y, $z;

to DWIM.

 1. This is a change that will make mixing type declarations
in the same line of code harder to do, such as:

   (my $x, our $y) = @_;

 2. In certain situations, such as trying to declare a variable
inline as a list arg, it requires an extra set of ()'s.
For example:

tie my $shoe, $string;
no longer works as written, since my will gobble the vars
and tie will complain "not enough arguments".

Once point of consideration: What if my() returned its
argument list verbatim, similar to how bless() does

 3. This is a change which will break existing Perl code.

Although overall I support the "FOR" (I think?), those are some pretty
big "AGAINST" arguments that we need to consider.


Re: Closures and default lexical-scope for subs

2001-02-15 Thread Nathan Wiger

Peter Scott wrote:
 At 01:15 PM 2/15/01 -0500, John Porter wrote:
   my $a, $b, $c;# only $a is lexically scoped
 Quite.  But on a tangent, I see no good reason why this shouldn't be given
 the same interpretation as "my ($a, $b, $c)" on the grounds that functions
 taking list arguments that omit their parentheses swallow up the following
 list.  And if the retort is, "my isn't a function," then I would like to
 know what it really is and why it's listed in perlfunc along with other
 things that aren't functions.

I agree with this statement. Perhaps someone who was around during the
initial 'my' discussions can shed some light on why it binds so tightly.
I have observed you can do something like this:

   my $OUTER = '';

   if ( $some_value ) {
  # 'my' only on the first one
  (my $inner, $OUTER) = split;
  # more code that uses $inner ...

   if ( $OUTER ) {
  # $inner not here, but that's fine...

But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.

Also, as the author of RFC 64, let me say that while I think it's cute
and nifty, I think it's also true from the discussions that it causes
far more problems than it solves. I no longer think it's a good idea, at
least not in its current incantation. There may be other ways to
approach it, but I can't think of any that aren't more complex than (a
possibly modified) "my".


Re: Closures and default lexical-scope for subs

2001-02-15 Thread Nathan Wiger

Peter Scott wrote:
 And in any case, make '-e' have the additional connotation that implies
 'no strict', and 'no warn'.
 no 'warnings'
   Seems simple enough to me.
 Yes, that's what I thought; but this has generated more heat than light, at
 least on the times I've brought it up, e.g.,

Please, let's not retrace this argument. It's really become apparent to
me that there's two types of folks on this:

   1) the quick and dirty users / utility scripters

   2) the instructors and massive code maintainers

(Depending on your project at the time, you may switch between roles).

The former vehemently support "RFC 16: Keep default Perl free of
constraints such as warnings and strict", under various mantras from
"Make things easy" to "Hey, one liners!"

The latter vehemently support the concept of "use strict" and "use
warnings" being on by default. The justification is that it helps people
write cleaner code, catch errors faster, etc, and all you have to do is
say "my" in front of all your variables. (However, let's not forget
about strict refs!)

I personally think that this is something Larry is going to have to
decide. However, I would like to note that leaving these off by default
lowers the transition curve to Perl 6 immensely for those people that
use Perl as a glue/scripting/sysadmin language.

Key: Not everyone becomes a Perl expert. Many people never leave
novice/intermediate level. This doesn't mean that we should design the
language for these people, but it also doesn't mean we should thumb our
noses at them.


Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

2001-02-15 Thread Nathan Wiger

[resent to perl6-language, sorry for any duplicates]

Edward Peschko wrote:
  I personally think that this is something Larry is going to have to
  decide. However, I would like to note that leaving these off by default
  lowers the transition curve to Perl 6 immensely for those people that
  use Perl as a glue/scripting/sysadmin language.
 Right, but what I don't understand is that its two extra characters at the end
 of a command line... whats the big deal about typing '-q' on one line in
 scripts? Its easy enough to advertise '-q' and put it in big lights...

Yes and no, I think. As Alan Burlinson pointed out earlier, this is
*not* a purely clean-slate we have here to work with. There are lots and
lots and lots of users who know how Perl works. Many of these users
don't even know that you can do this:

   my $x = 5;

Let alone that this:

   my $x, $y, $z;

Doesn't DWIM, again according to what most people think.

  Key: Not everyone becomes a Perl expert. Many people never leave
  novice/intermediate level. This doesn't mean that we should design the
  language for these people, but it also doesn't mean we should thumb our
  noses at them.
 So - why is it a religious issue then? I respect the fact that you want to
 write scripts without 'use strict'. I do this all the time. But I really think
 that its a small price to pay to put '-q' on the #!/usr/bin/perl command line
 for the vast benefits that it would give us all as far as CPAN goes.

Let's separate the CPAN thing out for a moment. "use strict" and "use
warnings" are not the universal solutions to CPAN quality issues, at
least as far as I'm aware.

As for the -q thing, I think it is far *less* of a burden to add "use
strict" and "use warnings" when you're writing a big piece of code. When
you're writing 5 lines, every extra character counts. When you're
writing 500 or 5000 lines, 2 lines of "use" statements are nothing.

 So - in the place of a '-q', would you support a mechanism for making
 sure that CPAN is '-w' clean? If so, how would you enforce it?

Absolutely, 100%. But this is a separate issue. For example, a big
problem with CPAN is also packaging. There's lots of modules that don't
use the h2xs/Makefile.PL approach. Also, many modules on CPAN have been
in beta for years, and not just 0.99 beta but 0.02 beta, broken and
uninstallable. There's also a lot of modules that don't run under -T.
But "strict" won't fix these issues.

If we're interested in increased CPAN quality, there's a bunch of stuff
we can do. We can have a standard test suite that's run against every
module uploaded to check if it's installable and compiles basically. We
can check for -w, -T, use strict, and tons of other stuff. We can check
for the packaging to make sure that "perl -MCPAN -e shell" will install
the stuff cleanly. If there's simple problems (misnamed tar files, a
$VERSION split onto multiple lines), we can even auto-fix this. Then
send all the results to the user who uploaded the module.

Heck, I'd even volunteer to head up a project to do this. But I think
it's a separate issue from "use strict" and "use warnings", let's not
confuse the two.


Re: Really auto autoloaded modules

2001-02-05 Thread Nathan Wiger

Dan Sugalski wrote:
   The parser needs to have it in a standard system-wide place.
 Hmmm. I see what you mean, but why couldn't it be in @INC, first one
 wins? The file could be named or something.
 That strikes me as very much too high level a thing. I'm figuring there
 will be no more than one file, and we may well go so far as to weld the
 processed version of it into a shareable library that gets loaded in as
 part of perl's startup.

Yeah, I suspect there are two different ideas here trying to be
satisfied by the same thing:

   1. moving ops out of core

   2. autoloading user-level modules

Regarding #1, if there's no need to make it extensible by users, why
have a file at all? This shouldn't change after Perl is built, right?
And all of the stuff that's going to be "autoloaded" in this way will be
included in the core dist, right? Sounds like some #defines would work
better for this.

Regarding #2, it sounds like or or something
else, along with some better hooks or even just a friendlier XS
substitute (Inline?), would probably fit the bill. Then there could be
sub-classes that handled Class::Contract type stuff, service registries,
and anything else that people wanted.

I think that and fit in category #2. If anything,
this discussion has convinced me that trying to autoload these by
default is *not* a good idea. People already have to "use FileHandle"
and "use Fcntl" for certain functionality. A few more modules doesn't
stike me as terrible, especially if it will result in Perl being faster
(and by "faster" I mean faster than if it had to read the
"autoload.conf" file at every startup, not necessarily faster than if
these were in CORE).

Plus, some people might prefer Text::Autoformat to anyways, so
why bother adding overhead to check for format() on every startup if a
user doesn't really care? And then there's the idea of "use Perl5" to
handle the transition, p52p6, etc.

 I would assume that 'use' would be done before 'autouse', so any 'use
 lib' statements would already be taken into account? I'm probably
 missing something super-obvious, so please point it out if so.
 Doubt it. They'll likely be done as they're encountered, though that does
 mean that your libs will be set before you need them, unless you order your
 source really strangely.

Yep, that's actually basically what I meant. Thanks for clarifying.


Re: Really auto autoloaded modules

2001-02-05 Thread Nathan Wiger

Dan Sugalski wrote:
 Regarding #1, if there's no need to make it extensible by users, why
 have a file at all? This shouldn't change after Perl is built, right?
 And all of the stuff that's going to be "autoloaded" in this way will be
 included in the core dist, right? Sounds like some #defines would work
 better for this.
 But we may well add in things after perl has been built, or upgrade modules
 that come with perl and do this after the fact. (If, say, someone redoes
 Socket to handle IPv6, it'd be nice to be able to upgrade perl's socket
 handling code without having to actually upgrade perl, assuming an
 upgrade's even available)

But, the problem I see here is that now we're back to loading user-level
modules. See if I'm making any sense here. Basically, the example you
describe boils down to writing Socket::IPv6 or fixing,

In this case, if we forget about the autoloading for just a second, then
the problem simply boils down to the Perl 5 construct:

   use Socket;

and assuming that the user has upgraded properly, the new code
is automatically imported. So, the autoloading thing, really, is
designed to get around a user having to use "use", know what module
something is in, etc. A user doesn't have to care about
because it's autoloaded. And the autoloading keeps it modular and
upgradeable, as you point out.

But regarding the upgrade issue, what if I use to add the new into ~/perl/lib, because my sysadmin won't? How does the
autoloader handle this? If there's one config file, how can I specify
different conditions? What if I want to distribute my script, and want
the convenience of the autoloader, but also want to ensure that supports IPv6 because I need version 2.03? How can I
do this?

At this point, I think we should take a look at something like
AnyLoader, and what would be required to make it reasonably extensible
so that conditions, versions, import lists, etc can be specified. And I
think that at the end of this road lies something like AnyLoader +
Damian's proposed JAPH syntax, which is easily extensible.

I'm not trying to harp, I'm just trying to clarify, because I think
there's some fine-line distinctions that are important to this
discussion. What's the likely difference between ops and subs in Perl 6?
Is the goal "subs as fast as ops" still? In this case, does autoloading
an op in post-build have any benefit over autoloading a module in

Again, let me stress that I really like the autoloading concept (I wrote
RFC 153 :-), but I think that the current ideas might be too limiting,
and may be addressing the wrong issues. Fast is good, and faster is way
better, so maybe autoloading shouldn't be default-worthy and should be

   # Allow autoloading of any needed functions
   use autoload qw(:all);

Then any additional overhead for parsing a more extensible config file
could be justified.


Re: Really auto autoloaded modules

2001-02-02 Thread Nathan Wiger

Damian Conway wrote:
 Where should this info be maintained? In a module in @INC (sort of like
 CPAN/ Or in a special file that's only written to via a
 module install? Or in a block atop each module that's yanked out via
 MakeMaker? Or???
 The parser needs to have it in a standard system-wide place.

Hmmm. I see what you mean, but why couldn't it be in @INC, first one
wins? The file could be named or something.

I would assume that 'use' would be done before 'autouse', so any 'use
lib' statements would already be taken into account? I'm probably
missing something super-obvious, so please point it out if so.

 I wasn't actually proposing it as a replacement mechanism for Exporter,
 but if that standard configuration file included the line:
 autouse STD::autouse { 1 }
 then I suppose any other module could replace:
 @EXPORT = qw( foo bar );
 autouse foo {1}
 autouse bar {1}

What about making it into a 'use overload' style declaration to decrease
the tedium? No need for multi-value foreach necessarily:

   autouse foo = {1}, bar = {1};


 @EXPORT_OK = qw( only by request );
 autouse only{requested},
 by  {requested},
 request {requested},
 H. Tidy, but too tedious perhaps?

Yeah, a little too tedious. For the EXPORT thingy it seems a different
pragma would be more fitting:

   use export always = [qw(you get this)],
  request = [qw(only by request)],
  tags = { cgi = [qw(param etc)] };

Then the key request would point to the applicable thingies. Just like
@EXPORT_OK but w/ a pragma.

I actually wasn't proposing that autouse replace @EXPORT either, but
this is may be a worthwhile brainstorming thread...


Re: Really auto autoloaded modules

2001-02-01 Thread Nathan Wiger

Dan Sugalski wrote:
 At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote:
 Have a look at AnyLoader in CPAN.
 Looks pretty close to what's needed. Care to flesh it out (and streamline
 it where needed) to a PDD?

There's also autouse, a pragma that ships with Perl. Again, not exactly
right but getting there.

There's the big problem of overlapping function names. If I say:

   $name = param('name');

I probably mean "use CGI". But maybe there's some other module that has
param() also? What if I really mean "use CGI::Minimal"?

There's also RFC 153: "New pragma 'autoload' to load functions and
modules on-demand", which I authored. I don't think that the exact
mechanism for it is correct at all, but it does talk about some of these

Michael if you want any help on the PDD let me know.


Re: Really auto autoloaded modules

2001-02-01 Thread Nathan Wiger

Ted Ashton wrote:
 It appears to me that there's a focus problem here.  After all,
 if I want to use CGI or CGI::Minimal, I can already do that. 
 The auto-autoloading, unless I am sorely mistaken (which is
 quite possible :-), is for the purpose of moving things out
 of the core and yet allowing them to act like they are
 still in (a process which has been decried as basically useless
 when it is simply limited to things such as time(), but which
 might be more significant if it also related to major pieces
 of functionality such as formats or "complex regexen" or some

I think you're right, but it's probably also the same underlying
mechanism. For stuff like formats, it seems that there will likely be a that now handles the stuff described in Damian's RFC 230.

So, I don't think that there's any difference between loading
Format::format() and CGI::param(). The same mechanism should work for
both. I picked CGI because it was obvious but perhaps Format or Socket
would have been more appropriate.


UNIX epoch issues (Re: Why shouldn't sleep(0.5) DWIM?)

2001-01-30 Thread Nathan Wiger

Jarkko Hietaniemi wrote:
 As I said the problem isn't the p52p6 doing that kind of transformation.
 The problem is someone familiar with perl5 writing code in perl6:
 if (my $fh = open("/tmp/$$".time())) {
 and later something crashing and burning because some other place expects
 to find a filename of the form /^\d+\d+$/, or someone printing into log files
 like this
 print LOG time() . ": gorkulator borked.  Please investigate."
 and someone splitting on /\./, etc.

Good point, this is a problem with changing time() from UNIX epoch (or
anything else which provides sub-second granularity or otherwise
introduces a ".").

  probably gonna change in perl6, since it's UNIX-based now and i think
  we no longer have to know how many seconds have passed since mid-night
  january 1st 1970, do we?
 Some sort of less C/UNIX-centric way would be nice, yes.

We had a whole ton of discussions on this regarding "what epoch is the
right one", and the general consensus was that we should keep time()
as-is. The basic argument went like this:

   1. All epochs are arbitrary

   2. The UNIX epoch is well-known and understood

   3. Therefore let's not mess with it

In fact RFC 99 proposed the reverse - that all platforms should use the
UNIX epoch. There was about a 50/50 split, some said "Why mess with
MacOS?" and others said "This would help Perl cross-platform." See RFC
99 at

The full discussions, which included ponderings of Modified Julian, the
ISO format, etc, can be found starting at the following places:

Original proposal to use MJD and introduce mjdate(), which
resulted in much heated slashing and burning:

Reintroduction as standardizing on UNIX epoch:

General slashing and burning of the UNIX epoch idea:

Since there were many replies your best bet is to read the "Follow-ups"
at the bottom rather than hitting the "Next Thread" button.


Re: Why shouldn't sleep(0.5) DWIM?

2001-01-30 Thread Nathan Wiger

"Stephen P. Potter" wrote:
 Why do we have to worry about changing time()?  There's a real parallel
 between sleep() and alarm(), so we would want to do both if we did either,
 but time() really has no relation to them.
 Or, should we just implement usleep() and (for lack of a better name)

One thing that was discussed on the archives that I sent out was
introducing a parallel mjdate() (or isodate() or whatever) which gave
access to the internal means of maintaining time in Perl. Then Perl's
internal clock could be sub-second ticks since 4152 BC, Modified Julian,
etc, etc.

So time() could remain unchanged (from a language/user perspective, at
least), but sleep() and alarm() could use the internal sub-second
methods of timekeeping to DWIM. The user gets sleep(0.5) and time() is
still epoch seconds.

But the big problem is that there's a lot of stuff that's based off of
time() right now, like stat(), lstat(), etc, etc. When you think of the
cascading effects of changing Perl's timekeeping it gets really, really

If the internal timekeeping were changed, one thing that's apparent from
the discussions is that there would *have* to be a core way of providing
exactly what time() does currently or lots of stuff would break really
badly. Someone can certainly chime in if they see an easy way around
this, but as I recall there was little disagreement on this point.


Re: What will be the Perl6 code name ?!!

2000-10-19 Thread Nathan Wiger

Simon Cozens wrote:
 On Thu, Oct 19, 2000 at 04:47:10PM +0100, raptor wrote:
  What will be the Perl6 code name ?
 I vote for "Perl 6".

How about "P2L6" - or even "P36"? (kidding) ;-) 


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

2000-10-04 Thread Nathan Wiger

 =head1 TITLE
 Perl should use XML for documentation instead of POD

 =head1 VERSION

   Status: Frozen

I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's
like this when the following is true:

 A lot of good, heated discussion was generated on the mailing lists. The
 majority seems against using XML-DTD documentation, but granted there are
 deficiencies in POD. 

Is absolutely, 100% against the entire idea of the RFC process. They're
"Requests for Comments". The comments received were overwhelmingly "This
is a Bad Idea".

This RFC should either be retracted, or revised into:

   POD to XML translation should be easier


   POD should be made more flexible


   Here are some deficiencies in POD that need to be fixed

But freezing something that everyone's against is a waste of everyone's
time. Sorry, but it is.

And yes, I've retracted 7 of my own RFC's because the community was
against them. The whole point of this Perl 6 process is to develop a
language that the community thinks is the right direction, right?
Sometimes that means accepting that no matter how much you like your
idea, other Perl'ers don't.


Re: RFC 357 (v2) Perl should use XML for documentation insteadof POD

2000-10-04 Thread Nathan Wiger

 Retracting would have been easier, but could very well be seen as giving up
 on pointing out PODs deficiencies.

Pointing POD deficiencies is fine. But the fundamental thrust of the RFC
is still "replace POD with XML". That's why I even noted the alternative
names and corresponding emphasis in my previous email, as a way to make
it more productive.

I suspect the fate of this RFC with be a "veto", and it will get just as
ignored as if it had never existed. So the analyses it contains of POD
will be skipped over, and repeated verbatim in future discussions.
That's too bad.
 The RFCs are not the end-all of Perl development.  As you stated, they are
 "Requests For Comments", and not every frozen RFC will get accepted by the

Well, this might point out an additional flaw in the process, or at
least misunderstanding. I always thought these were ultimately
suggestions for Larry, for Larry to sort out, *after* the community
(those on p6*) had consolidated input. That is, the finished RFC's would
be delivered with the confidence that at least a good proportion of the
populace felt that way.

I have not seen that with this RFC. I counted 2-3 people who supported
migrating to XML. Everyone else pointed out problems with POD, which
would have been a great "fix POD" RFC on its own. But basically everyone
on the list was against XML replacing POD, which is what the RFC says.
And that's why, in its current form, it should be retracted.

 Not every RFC -can- be accepted by the community; I think there
 are some pairs that are mutually exclusive, and intentionally so.

This is true, but should (hopefully) only occur when people back both,
and it comes down to Larry having to decide. Witness RFC 152 vs. RFC
223, which have opposing ways of implementing self(), both of which had
strong proponents. But then, witness RFC 171 vs. RFC 218, which address
what "my Dog $spot" is supposed to do. The former was retracted because
people liked RFC 218 better. This is a great example of the process

 Do you expect that your 7 retracted RFCs to be looked at by future
 developers?  Even if they had good, but unpopular, points to make?  Or do
 you expect that once retracted, they will be ignored?

No, I hope they are ignored, until somebody says, "Look, we already
talked about the 'list' keyword - go see RFC 175 for why it doesn't

Eventually, RFC's are going to move into a third state, per Larry's
decision on them. At that point, if this RFC is rejected, it will be
ignored just as much as one that was retracted in the first place.

This is *exactly* why I suggested that the RFC be renamed and try to
work within the constraints of keeping POD. In doing so, it could add
really useful input. Otherwise, it will likely be ignored just like it
was retracted now. And I'd bet that the title as-is already causes many
to skip over it as "not gonna happen", causing its points about POD to
be missed completely.


Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

2000-10-02 Thread Nathan Wiger

 There's two ways I've proposed in different RFC's. The first one
 utilizes a more general framework; the second one depends on Ctie
 being used. A UNIVERSAL:: method wouldn't work because you've got to get
 attributes from arrays and hashes as well.
 Maybe I'm just being dense, but why shouldn't arrays and hashes inherit
 attributes from UNIVERSAL?  tie()ing an array is really just like being
 able to call object methods on it distinct from its members, no?  So arrays
 and hashes could be objects too.  Hmm, am I saying that I should be able to
 write @array-method()?

I think under tie this is *exactly* what we should be aiming for. I
think this is awesome.

However, making it a UNIVERSAL method also dictates that this:

   my SomeType @a :someattr;

*must* be either:

   1. a builtin type
   2. tied

To get its attributes back out. I'm not sure this is going to always be
true. In particular, what if SomeType was like "int", and you were just
trying to assert that each individual element was going to be SomeType?

If these problems were resolved, then I must admit to having a perverse
softspot for being able to say:

   my packed @bits :long;
   %attrs = @bits-attributes;

I dunno...I like the way that looks for some reason... ;-)


Re: 0, true or false? (was: PERL6STORM #0052)

2000-10-02 Thread Nathan Wiger

"David L. Nicol" wrote:
 Bart Lateur wrote:
  Bitwise and, or and xor do distinguish strings from numbers, and return
  entirely different kinds of results. Why can't anything else?
 Absolutely.  There is such a thing as Too Much Convenience.  I think
 BOOL as a context or an accessor method should be separate from STRING and
 NUMBER so that if you know, you can suggest which behavior you want out
 of a particular scalar variable, or stick with the misguidable default.

See RFC 159 - BOOLEAN, STRING, and NUMBER are the three main methods.


Re: RFC 324 (v2) Extend AUTOLOAD functionality to AUTOGLOB

2000-10-01 Thread Nathan Wiger

 =head1 CHANGES
 Comments received have been that it would be better to use AUTOSCALAR,
 AUTOHASH etc instead of AUTOGLOB in the interests of encapsulation.
 The argument being that if you only want to implement AUTO scalars in
 your program, then doing:
 Cif($type_of_thing eq 'scalar') {
 # do some stuff
 } else {
 # use our parent's AUTOGLOB
 breaks encapsulation.  However, these sort of shenanigans are common in
 other OO languages such as Java and C++, and in any case, we still need
 to 'break encapsulation' like this if RFC 8 is implemented.  If
 programmers really want to use AUTOHASH, AUTOSCALAR etc then they can
 put their own suitably constructed AUTOGLOB subroutine in the UNIVERSAL
 class which will do all the appropriate magic.

I think you missed my point a little. :-) I wasn't just saying that
AUTO* are prettier to look at, but for polymorphic method delegation
they're a necessity. Any method that internally reinvokes others must
explicitly decide on a method to reinvoke to - this is the part that
breaks encapsulation. Having one sub means you can't delegate to
multiple packages.

Check out these RFC's:

   RFC 193: Objects: Core support for method delegation
   RFC 190: Objects: NEXT pseudoclass for method redispatch
In multiple inheritance this gets really entangled - having Perl
dispatch to the correct type is actually a considerable simplification
and benefit. Otherwise you can't delegate globbing of specific data
types to other classes, which is something you'd conceivably want to do.

Also, all I was trying to say about "controlling what's globbable" is
that we're going to have to do this somehow. :-) Perl will have to do
one or the other of these:

1. Found a %hash that's unavailable
2. Pass to AUTOGLOB('HASH', \%hash)

1. Found a %hash that's unavailable
2. Pass to AUTOHASH(\%hash)

Anyways, I'm not going to keep harping on these points. You've mentioned
them in the RFC; if you change your mind after reading the above RFC's
that's cool, otherwise leaving the RFC as-is is fine with me. But note
that my suggestions also change your proposed migration section from:

  Changes from the semantics of AUTOLOAD mean that existing AUTOLOADs
  will almost certainly break badly if simply renamed.  Therefore it
  would be wise to keep the existing AUTOLOAD (although deprecated)...


  =head1 MIGRATION

  None. New functionality.


Re: Variable attributes - Object-oriented

2000-10-01 Thread Nathan Wiger

 I believe that mentioning an attribute of a variable is
 really a method call on the variable's underlying object --
 which, in perl6, can have user-definable behavior.
 Where some language use dot or arrow syntax, perl uses colon.
 Very isomorphic.
 Please tell me I'm right!  :-)

Pretty much; in fact I just submitted a frozen version of RFC 337 that
tries to extend and firm up this idea. I'm with you, man! ;-)

Since it's deadline time, the implementation didn't get too
super-specific. But the idea's there. Reply to the thread when it comes
out if there's any major holes that need to be plugged.


Re: RFC 355 (v1) Leave $[ alone.

2000-10-01 Thread Nathan Wiger

Bart Lateur wrote:
 My idea is that if anybody sets $[ to 1 in a script, all accesses to
 array in that script would use 1 as the index of the very first item:
 $ary[1]. But if you pass this array (for example, a reference to it) to
 a function in a module that doesn't set $[, it would access the same
 first item through index 0: $ary[0] or $ref-[0].
 And vice versa (swap "module" and "script").

This seems to make sense. But I'm pretty sure this is how it works

   package Bob;
   sub do_print {
  my @a = @_;
  print $a[0];

   package main;
   $[ = 1;
   $array[1] = "Hello\n";

   Bob::do_print(@array);   # prints "Hello\n"

And Camel says:

   Assignment to $[ is now treated as a compiler directive, and cannot
   influence the behavior of any other file. Its use is discouraged.

I'm really surprised by this RFC, to be honest, considering that the
overall reaction to $[ is Don't Do That. I've always thought axing $[
was a no-brainer.

One interesting thing to contemplate is how this might change
higher-order function notation. If you set $[ = 1, you'd surely want ^0
to be changed to ^1 then? And if you set $[ = 2, would you want $1 to
become $2 ?

The :base(1) attribute seems interesting, but not viable. In particular,
then you'd have to check each individual array to see what its base was
set to to know how to handle it.


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

2000-10-01 Thread Nathan Wiger

 Two of POD's deficiencies are list handling and table handling.  POD
 doesn't handle tables right now, but calling this easy to write
 or easy to read is ludicrous:

[horrendous XHTML and DocBook notations deleted]
 I think POD's list handling is full of warts, but what follows
 is much better than HTML/DocBook itemized lists:

[wonderously beautiful POD deleted]
 One of the benefits of POD is that it separates block markup from
 inline markup.  This is the clearest way of distinguising semantic
 structure from presentation.  =head1 is not equivalent to h1
 but rather DocBook's sectiontitle.../title start block.
 section tags aren't as easily abused as H1 tags for REEELY BIG LETTERS.

I'll just throw my $.02 in and support Ziggy, David, John, and all the
other silent majority members completely. The simple proof that POD is
far superior is that you can read the RFC's on this list in POD without
too much trouble. Try reading the source code of the HTML versions of
the RFC's. Bleech.

I'd much rather write:

   =head1 ABSTRACT

   This RFC proposes ...


   This RFC proposes ...

Any day of the week.

SGML and its descendants are a whole nasty can of worms with a steep
learning curve. Making documentation any harder is just going to result
in less documentation with more mistakes, especially for CPAN modules.

 True, C and E are pretty warty, but they clearly identify
 something more presentational in nature.

Yes, this is true. I think it's pretty apparent that the  syntax is
broken - there's too much stuff (like - and ) that uses duplicate
characters. This could be solved if escapes worked:


But that's still nasty. Maybe plain ol' braces would work better:

   C{ foo- bar }

Since not many people seem to use braces inline anyways, and if you do,
there's got to be an opening one first:

   C{ if ($stuff) { ... } }

So they can easily and reliably nest. Sure makes these more readable:

   C{print while ();}
   C{die if $x  5;}
   C{my $foo = bar-baz;}

I might RFC this later in the process towards the documentation end of


Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

2000-10-01 Thread Nathan Wiger

 I haven't got around to RFCing the more generic version (that all attributes
 are inherited inside nested data types), but that would certainly be a nice

RFC 337...the new version I just sent in says:

   This would allow those who want to to warp Perl OO into Java
   or Python or C++ without these features having to be either
   widely used or embedded in core. A base class could simply define
   attribute handlers which other classes could then inherit from.
   Attributes would be inherited just like subs.

Although I didn't mention the implicit autoviv inheritance idea - that's
cool, though. It's something that probably should have gone into RFC
279, actually.

Sigh. Too many RFC's.

-Nate (who will shortly, per the suggestion of Jeremy, be checking
 himself into the Betty Ford RFC Recovery Program)

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

2000-09-30 Thread Nathan Wiger

Alan Gutierrez wrote:
 This just in from RFC 2068 HTTP/1.1 - 4.2 Message Headers:
 The field value may be preceded by any amount of LWS, though a single SP
 is preferred. Header fields can be extended over multiple lines by
 preceding each extra line with at least one SP or HT.

Yes, similar requirements are in RFC 822, which talks about SMTP
headers. The header and unheader function would be able to support them.

Let's take up further concerns by addressing the Text::Header module
itself; I'll check out your other emails and see what can be integrated.
Feel free to email me offline as well.


Re: RFC 350 (v1) Advanced I/O (AIO)

2000-09-29 Thread Nathan Wiger

 you would do:
 $sock = AIO::Open( Host = '',
Port = 80 ) ;

 Similarly for LWP you would just do:
 $sock = AIO::Open( Url = '' ) ;

 $event = AIO::Open( Host = '',
 Port = 80
 Callback = $obj  ) ;
 $event = AIO::Open( Url = '',
 Callback = $obj  ) ;

I like this overall. Very nice.

One of the goals in RFC 14, and the reason why I chose to go the
"handler" route, is to make it look like open() had just been beefed up:

   $file = open "/etc/motd";
   $dir  = open dir "/usr/local";
   $http = open "";

However, the under-the-hood implementation of dir-open and http-open
is not explored; I was trying to create a consistent user-level
interface that does not require the complex syntax shown above. And from
this angle, I think RFC 14 has a lot to offer.

But, one thing that I think is worth exploring is how we could merge
this ideas, since I think the AIO system could well be a very viable
implementation. One thing I could see is ditching the handler idea and
instead just having people use URL's:

   $file = open "/etc/motd";
   $dir  = open "dir:/usr/local";
   $dir  = opendir "/usr/local";   # legacy shortcut
   $http = open "";

The CORE::open would be smart enough to then dispatch to the underlying
AIO-open (or whatever) and do something akin what you've listed above.

I like the AIO idea; if we could stick it under the hood (but still
accessible, like IO::, if you really want to use it directly), I could
see it implementing Perl 6 IO.

One last thing: I could see a class hierarchy as being potentially most
effective for something like this; perhaps you could have AIO::HTTP,
AIO::File, AIO::Dir, and so on, with the main AIO class serving as the
base/dispatch class.


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

2000-09-29 Thread Nathan Wiger

 Hm. This makes it difficult to construct a header incrementally -- for
 example, @HEADERS=(); push @HEADERS, header(content_type='a',
 author='b'); # 75 lines later; push @HEADERS, header(last_modified='c',
 Since in this case, there would be two "blank" head lines instead of just

Yeah, Ziggy already mentioned that offlist.
  The Cheader function would simply:
 1. uc the first letter of each tag token and lc the rest
 Du you want to use the word "ucfirst" here?

Probably; that's what the Text::Header module I wrote as a prototype
does. ;-)
  Should result in C@out being exactly equivalent to C@in.
 It cannot, of course, since the order of hash keys obtained by flattening
 the hash is not necessarily the same as when you built the hash.

Actually, it does. Remember, a hash is just a list. unheader just
returns an ordered list of the headers. So this:

   @out = header unheader @in;

Will always result in identity because it's actually the same as:

   @temp = unheader @in;
   @out = header @temp;

It's only once you assign to a hash explicitly that everything gets out
of whack.


Re: RFC 337 (v1) Common attribute system to allow user-defined, extensible attributes

2000-09-29 Thread Nathan Wiger

  =head1 TITLE
  Common attribute system to allow user-defined, extensible attributes
 Err... have you read perldoc attributes? There's already a mechanism
 for doing this (see my japh), though it is a complete PITA to use and
 I'd like to see it tidied up (and possibly have
 reimplemented, I've got a few ideas, bear with me I may have code
 later that does what you want...)

 sub MODIFY_CODE_ATTRIBUTES {print "@_[2..$#_].\n";()}
 sub MODIFY_CODE_ATTRIBUTES : Just another Perl hacker

Yeah, I've gotta start clarifying my RFC's. I wrote that as a
brainstorm; with 40 to keep track of my head is spinning.

I have seen 'use attributes'. The syntax I used in the RFC was
intentionally not following 'use attributes' because I was dealing with
implementation, not declaration. And by implementation, I mean messing
with internals.

I mentioned it in an email, but neglected to say so here, but the idea
was through XS or Inline or whatever is used to extend Perl 6, there
should be some way of declaring inheritable attributes that can actually
mess with Perl's internals and twist them into obscene "we wish we were
Java" semantics.

Beyond that, I don't have much concrete. Code that could do this would
obviously be cool. ;-)


Why - cannot autoquote the LHS (was Re: RFC 244 (v1) Method calls should not suffer...)

2000-09-29 Thread Nathan Wiger

 =head1 TITLE
 Method calls should not suffer from the action on a distance

 can be parsed either as C'foo'-bar($baz), or as Cfoo()-bar($baz)
 depending on how the symbol Cfoo was used on other places.  The proposal
 is to always choose the first meaning: make C -  autoquote the bareword
 on the left.

Before I forget to mention this again, here is why - *cannot* autoquote
the LHS:

   package Foo;

   use overload q("") = STRING;

   sub new { bless {@_}, shift; }

   sub STRING {
   return "Hello World!";

   sub getdata {
   # do stuff

   package main;

   my $foo = new Foo;
   @data = $foo-getdata;  # !!!   

Unless we want that last line to fail - essentially rendering use
overload and polymorphic objects useless - then the - operator must not
autoquote the LHS.

(And if the RFC is proposing autoquoting only barewords, then I think
that's _really_ inconsistent and should not be done.)


Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

2000-09-29 Thread Nathan Wiger

 =head1 ABSTRACT
 Remove all interpolation within single quotes and the Cq() operator, to
 make single quotes 100% shell-like. C\ rather than C\\ gives a single
 backslash; use double quotes or Cq() if you need a single quote in your

Yes. If people really need single quotes inside single quotes, why not
just put them in q() ??

   $need_singles = q(Why don't y'all just put 'em in here?);

The difference between '' and q() is that the second is a more flexible
alternative. If you really need to put single quotes inside single
quotes, use it.

But '' and q() should become true strict single quotes. Having them do \
interpolation is not good, it defeats the notion. It was needed in the
past, but now there's q(), so it's not needed anymore.

Migration with this is fairly easy, run something like this:


in the translator script. This doesn't catch all the cases, but writing
a more comprehensive one shouldn't be too hard.


Re: RFC 339 (v1) caller-eval BLOCK

2000-09-29 Thread Nathan Wiger

caller-eval EXPRESSION;
 That's mad, bad, scary and dangerous. Let's do it.

Yes, this is cool. In fact, I'm writing Regexp::Func right now as a
prototype for RFC 164 and discovering I could really use this - in fact,
need it.

A couple things:

   1. Implement this eval as UNIVERSAL::eval. Then...

   2. Change the above syntax to self-eval(EXPR)

No reason to have to change caller(). If we had a self() that can be
called anywhere  and returned a reference to the corresponding
package/parent namespace (like RFC 152's), then this works dandy. Then
UNIVERSAL::eval is simply invoked via simple inheritance. Presto:

 package Regexp::Func;

 sub replace (;$@) {
# By default, strip leading/trailing whitespace
my $pat = shift || '/(?:^\s+|\s+$)//g';
my @in = @_ ? @_ : $_;

# Just a simple eval is all we need
for (my $i=0; $i  @in; $i++) {
self-eval("\$in[$i] =~ s$pat;");  # Yes!!
do { chomp $@; croak $@, " in replace" } if $@;

# Always return the first string in scalar
wantarray ? return @in : return $in[0];

Yeah, I could really use this. ;-)


Re: RFC 351 (v1) Beyond the amnesic eval

2000-09-29 Thread Nathan Wiger

 =head1 ABSTRACT
 An unscoped eval is needed. It is part of the necessary steps to
 make Perl palatable as an interactive shell.

I agree with Michael that the syntax is not suitable. If it's a separate
function, then it needs to be a \w+ name.

You should check out RFC 339 - it talks about a very similar extension
to eval. The two might be able to be integrated.


Re: RFC 303 (v1) Keep Cuse less, but make it work.

2000-09-29 Thread Nathan Wiger

Alan Gutierrez wrote:
 C use less 'recursion'  sounds just find to me.
 The negation of C use less 'rolled_loops' ,
 C use more 'unrolled_loops' , does not sound very weird at all.
 Weren't we planning on haveing a use more as an opposite of use less? If
 so, let cuteness prevail!

Yeah, but let's say you can specify storage exactly, as I proposed in
RFC 319:

   # ideas for RFC 303
   use optimize storage = 16,   # how much space
growable = 1,   # can we grow?
growsize = 8,   # how much to grow by
integer = 1,# support ints
string = undef, # but not strings
float = undef,  # or floats
promote = 'bigint';  # promote to class
  # when outgrow

If you're specifying an exact number or definition, neither Cuse less
nor Cuse more makes sense.


The One True Deadline is approaching

2000-09-28 Thread Nathan Wiger

We've only got 4 days left until the One True Deadline on this whole
thing. Please, go check this out:

And get your RFC's finished up. Remember: Oct 1st is a true deadline,
coming from the powers above, meaning if your RFC is not frozen by then,
it will be auto-retracted and not considered.

My original comments on this process can be read here for those

If you need help or guidance, feel free to email me. Otherwise, good


Re: RFC 332 (v1) Regex: Make /$/ equivalent to /\z/ under the '/s' modifier

2000-09-28 Thread Nathan Wiger

 Is $$ the only alternative, or did I miss more? I don't think I've even
 seen this $$ mentioned before?

$$ is not a suitable alternative. It already means the current process
ID. It really cannot be messed with. And ${$} is identical to $$ by

 I still like the idea of $$, as I described it in the original thread.
 I've seen no comments for or against at this time.

See above.

 I can't see how yet another alternative, /$$/, is any better than what
 we have now: /\z/.

I agree. If it's more alternatives we're after, just have the person
write a custom regex. The idea is to make Perl do the right thing,
whatever that may be.

The big problem with changing $, as you note, is for people that need to
catch multiple instances in a string:

   $string = "Hello\nGoodbye\nHello\nHello\n";
   $string =~ s/Hello$/Goodbye/gm;

Without $, you can workaround this like so:

   $string =~ s/Hello\n/Goodbye\n/gm;

My suggestion would be:

   1. Make $ exactly always match just before the last \n, as the
  RFC suggests.

   2. Introduce some new \X switch that does what $ does
  currently if it's deemed necessary.

We're back to new alternatives again, but the one thing this buys you is
a $ that works consistently. I don't think many people need $'s current
functionality, and those that do can have an new \X.


Re: RFC 331 (v1) Consolidate the $1 and C\1 notations

2000-09-28 Thread Nathan Wiger

 =item *
 C\1 goes away as a special form
 =item *
 $1 means what C\1 currently means (first match in this regex)
 =item *
 ${1} is the same as $1 (first match in this regex)
 =item *
 ${P1} means what $1 currently means (first match in last regex)

Here's the big problem with this, and I think others have said it
similarly: If we need the functionality of both \1 and $1, then there is
no reason redoing the syntax. Period.

If \1 is unneeded, then let's ditch it and just use $1 everywhere.
However, this is not the case, as Randal, Bart, and others have shown.

If we need \1, then we should leave as-is. There's no reason to force
literally millions of people to relearn this. Renaming something just to
rename it does not add value.


Re: Murdering @ISA considered cruel and unusual

2000-09-28 Thread Nathan Wiger

Piers Cawley wrote:
  I strongly agree with the opinion that we should try and get away from
  special variables and switches in favor of functions and pragmas.
  Witness 'use base' instead of '@ISA', 'use warnings', and so on.
  Huh?  Why???  Perl's use of @ISA is beautiful.  It's an example
  of code reuse, because we don't need no stinking syntax!
 Indeed. Clear, simple, works. And if you're that way inclined lets you
 do all sorts of weird shit. I say keep it.

I *do* agree with keeping @ISA, actually. :-) My message was spawned by
a message of Ilya's proposing that we slash and burn everything except a
very few variables. I actually said that this was a fragile approach.
But I do agree new variables should be avoided where possible. 

Shit, 90% of my modules would break, including Class::Handler, which I
particularly like (and there's no way around @ISA with 'use base', since
it works at runtime).


Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

2000-09-28 Thread Nathan Wiger

Tom Christiansen wrote:
 So what's left?
 print STDERR "Foo";
 We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
 It is?  I certainly hope not.  It makes as much sense to
 do that as to force a dollar sign on subroutines.

Your point is assuming that STDERR retains its weirdness, and does not
become a simple scalar object so that these two:

   print $STDERR @data;

Are 100% the same. Making STDERR into $STDERR is all hinged on fast
vtable stuff in core, which looks quite likely based on things Dan says,
but not set in stone.

 If use strict 'subs' is in effect you're guaranteed these are subroutine
 calls, or compile-time errors.  If it isn't you get a nice little warning.
 Perhaps the stringification should be removed entirely, and the syntax
 always be a subroutine call.
 Eek, that's what I want to kill.  I want you to HAVE to
 write that as
 $time = time();
 with the parens.  The lack of parens is the root of MANY
 an evil in perl.

Check out  use strict 'words'  in RFC 278.


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

2000-09-28 Thread Nathan Wiger

 A future protocol could well require things in order. Hence you're
 having the output headers in order. Therefore you should have the input
 ones available in order as well.

I don't see a reason why an @HTTP ordered and %HTTP unordered couldn't
both be supported.
 I'm thinking a $headers_in and a $headers_out type thing is needed where
 things are a Headers object that can either return a given header
 Flexible. Transparent. You could even tie things if you want, so things
 are slightly more transparent. Combine operator overloading with some of
 Damian's 'want' and Quantum::Superpositions stuff and things become
 rather interesting.
 Having a %HTTP and a @HEADERS is rather simplistic and not really that
 accommodating for potential modifications to the protocols for HTTP and

I'm not sure I agree. The goal is to make this stuff easy for the
majority of cases. We're certainly not going to get everybody's needs
with this simple pragma.

The idea is to make it so "use cgi" lets you write a simple CGI script.
One that can fluidly parse every header and is fully extensible per the
newest HTTP/6.73 spec? Nope, then it's module time.

Stuff that's in the core should be building blocks off of which other
stuff can be based. Providing @HTTP and %CGI is great, because then
modules can just "use cgi" and parse those thing up, without having to
read from STDIN and do all the GET/POST special stuff.


Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)

2000-09-28 Thread Nathan Wiger

Simon Cozens wrote:
 On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote:
  On Wed, 27 Sep 2000, Nathan Wiger wrote:
   Y'know, I couldn't have said this better myself. :-) I've always felt
   that "use English" was a waste of time and effort, a bandaid trying to
   act as a tourniquet.
  I think it's a nice little bit of optional sugar and I don't see any reason
  to throw it away.
 The key point is that it's optional. If you think it's a waste of time and
 effort, don't use it. If other people use it, well... does Perl stop people
 programming in ways you don't like?

I agree with you. That's why I'd never RFC that we should lose it.* I
was just voicing my opinion that I personally think it's a waste. But
that doesn't mean others don't like it. ;-)


* assuming it doesn't harm the language, which it doesn't currently

Re: RFC 333 (v1) Add Cheader and Cunheader funtions to core distribution

2000-09-28 Thread Nathan Wiger

Jonathan Scott Duff wrote:
 My first thought was "this should definitely be in a module" and your
 comments just fire those synapses even more strongly.

Yes, this will likely end up in a core module. The main thing is that it
always has to be available so that pragmas like "use cgi" can import it.


Re: RFC 333 (v1) Add Cheader and Cunheader funtions to core distribution

2000-09-28 Thread Nathan Wiger

 PS un is such a lame prefix and very un perl like... unjoin? unpush?
 okay so unshift, but still... hey wait I want undelete!

Heh. :-) This is not really true, in fact within Perl it is the One True
Prefix, ala undef, unlink, unpack, unshift, untie...


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

2000-09-28 Thread Nathan Wiger

Alan Gutierrez wrote:
 This header functionality is application specific and does not belong in
 the core any more than the socket stuff which seems to be on its way
 out. I don't see why this has be implemented in the core in C.
 Once again, if core means core modules, and as a part of or or some such I am not concerned. And a switch for tainting
 and inclusion of this module sounds peachy. No core.

Yes, I believe that is the idea, at least currently. is also massive because it also includes a whole bunch of h2()
and like methods that we wouldn't need here. The idea is just to cover
basic stuff that modules like could potentially build on.


Re: Attribute access

2000-09-28 Thread Nathan Wiger

James Mastros wrote:

 As far as setting|getting, I'd like to make a simple proposal.  Consider it
 an idea for whoever writes the RFC (I'm looking at you, Nate) 

Oh, jeez, as if I didn't have enough already! ;-)
 The idea is this: every variable should have a psudohash of attributes.

Idea is good, implementation I think should be different. Especially
since Schwern has professed "pseudohashes must die!".
 To access the attribhash, you'd use somthing like this:
 my %arraysattribs = %@array:;
 my $subsline = $sub:{line};
 print "\%hash has the following attributes:\n";
 foreach (keys %%hash:) {
 print "\$\%hash:{$_} = ", $%hash:{$_}, "\n";
 $subsattribsref = \%sub:;

Here's what I'm thinking: a new builtin, attr(). This might also be
implementable as UNIVERSAL::attr.

Syntax would be such:

   @attrs = $object-attr;
   @attrs = attr %hash;
   $is_fluffy = attr %hash, 'fluffy';   # query a specific attribute

Another keyword could be 'is', which is cuter:

   $can_puff = is %hash, 'fluffy';

but it's way too close to 'isa' for my tastes. If attributes were the
proper tense then 'has' would work:

   $nice_coat = has $spot, 'fluffiness';

which I kinda like.

The attr keyword could be overloaded to also do sub/struct-like
definitions, as specified in RFC 337.

However, overall I think this should be hidden. The internal magic of
attributes will likely not map 1:1 to hash keys, so requiring what is
essentially an accessor function for these is probably a good thing.
That way, attributes can be applied to objects, packages, subs, and
other things that don't have variable representations:

   package BigInt : autotie;

   package main;
   if ( has BigInt 'autotie' ) {
  # class is automatically tied...

The declaration of attrs is proposed vaguely in RFC 337. I'll add access
before the freeze.


Re: RFC 204 (v2) Arrays: Use list reference for multidimensional array access

2000-09-27 Thread Nathan Wiger

Bart Lateur wrote:
 The problem is that
$name = "myarray";
@$name = (1,2,3);
print @$name[0,1];  # 1,2
 Is very consistent currently. Change one and you have to change the
 precedence and parsing of all symbolic refs.
 You are suggesting to keep a weird precedence rule, just to ease
 symbolic dereferencing!?! That's... obscene.

Where did I say that?! I even said:

   I'm not necessarily against it, but it's a deep issue not just
   constrained to arrays in this one specific context.

My point was if this idea is RFC'ed, the RFC better not be titled "Fix
arrays" but better be called "Redo the precedence rules of all symbolic


Re: RFC 324 (v1) Extend AUTOLOAD functionality to AUTOGLOB

2000-09-27 Thread Nathan Wiger

 The AUTOGLOB subroutine should expect to take two parameters, the invocant,
 and a second parameter specifying what type of item is being AUTOGLOBbed,
 followed by - in the case of a sub - the sub's arguments.  We suggest that
 the second parameter should be a scalar value - 'scalar' for an AUTOGLOBbed
 scalar, 'array' for an AUTOGLOBbed array, and so on.  

This is an interesting idea, but I don't think that a single AUTOGLOB,
that has to internally decide what to do based on a string match of one
of its arguments, is the best way to go for this. I think TIE has it


This actually has an advantage - in inheritance, you can polymorphically
inherit some or all of the AUTO* routines without having to rewrite the
whole sub.

 The $AUTOLOAD variable should be renamed to $AUTOGLOB
 (with $AUTOLOAD as a deprecated synonym as above).

As RFC 8 hints at, $AUTOLOAD should die completely. Make the name of the
variable or sub an argument. This has another benefit in that the name
of the variable is going to be passed into TIE* as well in Perl 6. Very
nice symmetry.


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

2000-09-27 Thread Nathan Wiger

David Grove wrote:
 On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen wrote:

  This is screaming mad.  I will become perl6's greatest detractor and
  anti-campaigner if this nullcrap happens.  And I will never shut up
  about it,
  either.  Mark my words.
 Quote from Larry: "I have a particular distaste for the sort of argument that
 goes, 'If I can't have it my way, I'm going to take all my marbles and go
 home.' That's not an argument--that's nuclear blackmail. I'm the only one who's
 allowed to make that sort argument, and you'll never hear me making it."

Yes, and this RFC was already retracted, so flames are particularly
silly. So could we all please let it die and comment on the 'use
tristate' alternative proposed in RFC 275?


Re: RFC 290 (v2) Better english names for -X

2000-09-27 Thread Nathan Wiger

Adam Turoff wrote:
PRL -r  freadable()
PRL -w  fwriteable()
PRL -x  fexecable()
PRL -o  fowned()
PRL -R  Freadable()
PRL -W  Fwriteable()
PRL -X  Fexecable()
PRL -O  Fowned()
  this looks decent to me.
 I reserve the right to switch to readable/writeable iff the socket/exists
 issue has a resolution.  Thoughts anyone?

I actually like the above because of the common prefix. It makes it
quite clear these are file tests.
  maybe make the prefix f_ to make it a little
  more readable (overriding that word again! :)?
 I can't think of any builtins that use _

Indeed, no builtins include _. In fact, the warning

   Unquoted string "stuff" may clash with future reserved word

is only raised if:

  You used a bareword that might someday be claimed as a
  reserved word. It's best to put such a word in quotes,
  or capitalize it somehow, or insert an underbar into it.
  also f/Fexecable() looks very odd.
 Patches welcome for f/F.

Yeah, mixed case gives me the willies! Bigtime. Plus, see above. Here's


I was going to list other alternatives, but I think those work just
fine, personally. Long is not necessarily bad; this is "use english"
after all.


Re: RFC 19 (v2) Rename the Clocal operator

2000-09-27 Thread Nathan Wiger

 Rename the Clocal operator

 A list of other proposed replacement names includes (but is not
 limited to, since I certainly have forgotten some):


Unfortunately, I wish this RFC would have taken a stand on at least a
first choice. :-( I always thought that "now" was by far the most
descriptive, because these changes really are scoped in time, and not
location (since they reach throughout code). Plus, it's short. Short

I also thought there was considerable consensus on this one, at least
more than any of the others:

Plus you didn't even mention my "here" suggestion (which is fine,
actually, because I like "now" better anyways). :-)


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

2000-09-27 Thread Nathan Wiger

Philip Newton wrote:
  Is order important for @HEADERS? Would it be better to have %HEADERS
  instead that does such auto-formatting?
 In my opinion, no, for the reasons given before. Hashes are unordered, and
 if you want to order the keys, you need to know the possibly keys and in
 which order they come. Then, if HTTP/4.2 comes out with the Toast:
 light|medium|dark header, which has to come after the new Breakfast:

Wait, you're both right! ;-)

Personally, I'd like to see a simple version of CGI::header be embedded
in core. HTTP-type headers are widely used in many applications. So you
could have:

   @HEADERS = header(content-type = 'text/html',
 toast = 'medium',   # not too crispy
 breakfast = 'yes');

Under normal life, @HEADERS would just be some variable. But the "use
cgi" pragma could simply flush @HEADERS out ahead of time before your
output stream. If @HEADERS is empty, the "use cgi" pragma just prints
out "Content-type: text/html\n\n";

Note that HTTP-style headers are used lots of other places:

   @mail_header = header(from = '[EMAIL PROTECTED]',
   print $MAILPIPE @mail_header, @mail_message;

So, the formatting of and the auto-printing of cgi headers are really
two separate things. 

Ziggy, are you interested in this idea enough (at all?) to stick a note
about the 'header' function into the RFC? Or should I RFC it separately?


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

2000-09-27 Thread Nathan Wiger

Sounds good. I'll start on my 39th :-{ RFC right now... ;-)


Adam Turoff wrote:
 On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
  Ziggy, are you interested in this idea enough (at all?) to stick a note
  about the 'header' function into the RFC? Or should I RFC it separately?
 Adding headers() to the core language (or a similar pragma that is
 automagically invoked by cgi) would make more sense to me.  I'd be in
 favor of a new RFC.  Adding it into cgi sounds like we're on the
 road to spontaneously reinventing
 It has uses in HTTP, CGI and SMTP contexts, probably others.  Would
 be nice if there were some sort of interaction with 'open http $url' as
 well.   Perhaps that would be what supplies %HTTP (or %HEADERS) for
 incoming headers and does trickery with print and @HEADERS...

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

2000-09-27 Thread Nathan Wiger

Dan Sugalski wrote:
 Because taint mode needs to be turned on REEELY early, like before
 pragmas are compiled.
 'no taint' does make sense, though 'use taint' might not except to locally
 undo 'no taint'. 

Actually, from my talks with Larry both on and off-list about this, he
convinced me pretty strongly that the only thing that really makes sense
is untainting data sources. And this should be done via $fh-untaint,
which already exists.

The original email was here:

Follow the thread a little for details. A "no taint 'checking'" seems
like an interesting idea, but I'm not sure providing lots of ways around
tainting is what we want...


Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)

2000-09-27 Thread Nathan Wiger

Russ Allbery wrote:

 I've found the use of use English in code I had to maintain to be annoying
 and unhelpful, and to actually degrade the maintainability of the code
 I've yet to understand why I'd *want* to use English regularly; so far as
 I can tell, it has essentially no benefit in the long term. 
 I know it's not the only stance to take, but I prefer to try to make my
 Perl code very readable by people who know Perl, and encourage people who
 don't know Perl who are trying to read my code to learn Perl first, or at
 the same time. 
 use English doesn't really address the syntactical points of Perl that
 make it hard to read for someone who doesn't know Perl; it strikes me, and
 always has struck me, as a bad partial solution to a problem that may not
 need to be solved and that only makes things more complicated in the long

Y'know, I couldn't have said this better myself. :-) I've always felt
that "use English" was a waste of time and effort, a bandaid trying to
act as a tourniquet. Using Randal's code:

   /foo/  print while ;

Note that "use English" here does nothing to improve the horribly
unreadable - yet beautifully succinct and flexible - syntax that is

My personal feeling is that I'd love "use English" to be expunged from
the language altogether - it's unnecessary bloat that only increases the
number of mistakes that people can make. But I'm not sure if I have the
guts to write that RFC just yet. ;-)


Re: Expunge use English from Perl?

2000-09-27 Thread Nathan Wiger

  My personal feeling is that I'd love "use English" to be expunged from
  the language altogether - it's unnecessary bloat that only increases the
  number of mistakes that people can make. But I'm not sure if I have the
  guts to write that RFC just yet. ;-)
 Are you talking about the overlong variable names?
 Aliasing -X is being proposed through a 'use english;' mechanism.

Yes, but perhaps a little bit of both. Truthfully, I've always seen long
alternatives as useless bloat, not used widely over the long term. Once
people learn the shortcuts, they use them.

Expunging "use English" may will improve Perl syntax, since it's one
less way to do things with already dubious value. Yes, the overlong
variable names are a waste of time, IMO, because I've never seen them
used in "real code". It's almost a rite of passage to take off the
training wheels and use the "real names" of the variables. Who wants to
write $INPUT_RECORD_SEPARATOR when you can write $/ ? 

I'm not vehemently opposed to "use English", or even the long
alternatives to -r and -w that RFC 290 proposes. But I do think,

   1. They don't solve the real syntactic problems

   2. Very few people will ever use them long-term

So if they bloat the language, we should consider expunging them. They
certainly bloat Camel with duplicate definitions. And I consider the
mneumonic of $! much stronger than $ERRNO (or was that $OS_ERROR or
$SYS_ERROR or ??)

Personally, my stance is that we should all come to accept that we use
and love a language with a syntax that drives many people mad. Not
everyone's gonna like Perl, so I think we should just accept it and move


Re: Expunge use English from Perl?

2000-09-27 Thread Nathan Wiger

Adam Turoff wrote:
 It has nothing to do with improving the syntax though, because everything
 in use English is a variable that serves as a reference to some other

Yes, and that's why I really think it's a waste of time. ;-)
  I'm not vehemently opposed to "use English"... But I do think,
 1. They don't solve the real syntactic problems
 No, because the syntactic problems are -s(FH)/2, and that is
 solved by fsize(FH)/2 iff -s is replaced with fsize (or a better
 spelling thereof).

This is one thing that I'm scared most of, and that is having two
alternatives which work only in certain contexts. I'm sure p5p has
already extensively looked at -s(FH)/2 being "wickedly broken" (as I
believe Tom put it), but the solution should theoretically be to make
-s(FH)/2 work.

The consensus has already pretty much said that they want -s et all to
stick around. So if RFC 290's idea is still to replace -X, then I'm very
much against it. But I was under the impression that they're just "use
english" alternatives.

If, however, these alternatives fix bugs that -X can't handle, then
that's not good.

I'll dig through the p5p archives and toke.c to see if any wisdom is
magically imparted on me. ;-)
 2. Very few people will ever use them long-term
 I dunno.  I remember looking at some code that used '-x _' that
 had half a department befuddled.  -rwx FH is better, and gets rid
 of the special case bare _ syntax.

Yeah, I've never liked the _ syntax, I've always thought it was weird
(to say the least). I think grouping file tests would be much cleaner. 


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

2000-09-27 Thread Nathan Wiger

Dan Sugalski wrote:
 It might be nice if the result of a calculation was never tainted when the
 calculation was in a 'no taint' block.
 Yerk. No, that's bad. The data is still tainted--the fact that it flowed
 through a "no taint" block doesn't make it any more trustworthy. Tainting
 really can't be dealt with like that.

Phew! I was hoping you'd say that, Dan! ;-)

If we're just turning on and off taint *checking*, it might be worth
noting that in whatever pragma name we choose:

   #!perl -T

   no taintchecks;


Just want to plant the seed early. I can see "no taint" or "no tainting"
being *really* confusing (unless it was "no taint 'checks'" or


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

2000-09-27 Thread Nathan Wiger

Robert Mathews wrote:
  Parse the CGI GET/POST request, returning CGI variables into %CGI
  (regardless of the source) in an un-HTTP escaped fashion
 How are you going to handle multiple values for the same parameter?
 With, you can say
   @values = $q-param("foo");
 Are you going to make the values of %CGI listrefs?  That should have
 been spelled out before you froze the RFC.  Also, it seems a bit
 inconvenient if you always have to say C$CGI{bar}[0] when you just
 want one value.

Two choices as I see it:

1. make a listref only for multiple values:

   @name = @{$CGI{name}} if ( ref $CGI{name} eq 'ARRAY' );

2. make it a comma-delimited string:

   $name = $CGI{name};
   @name = split ',', $name;

The problem arises if your data has commas in it. Then you're hosed. So
door #1 might be the only solution.

But I don't think listrefs are needed in all contexts, since you should
know which elements will likely have multiple values (checkboxes, etc).
But having a direct data access method like %CGI does create this
problem. Shit.

Maybe %CGI is tied. Fast embedded tie, like in Perl 6. :-)


Re: RFC 319 (v1) Transparently integrate Ctie

2000-09-26 Thread Nathan Wiger

 I'm kind of curious to know what you think would happen with the
 following. I've commented where I'm confident...
 interface Number;
 sub STORE;
 sub FETCH;
 package integer implements Number; # I really like this notation

Tangentially, yes, it is nice to read, but it prevents multiple
interface specifications. "use interface" is more consistent.

 sub TIESCALAR {...};
 sub STORE {...};
 sub FETCH {...};
 my Number $i;   # Number is an interface, so just an assertion
 my integer $n;  # integer-TIESCALAR($n);
 my non_tied $object;# Just an assertion
 defined($n);# Should be false

Yes. The only potential gotcha is if the user decides to do something
Really Evil and stores a value as part of their TIESCALAR method. Then
$n-FETCH will return that value and defined($n) will be true.

However, this is not the purpose of tie, and I think an appropriate
response is: Don't Do That. I agree with both you and Damian that TIE*
should be called on declaration for consistency. If a person doesn't
know how to use tie, well, that's not our problem. ;-)

 $n = 5;
 $i = $n;
 $n = 10;
 print $i;
 $i = $object;   # Assertion fails

Assuming you've set up your Cuse optimize restrictions appropriately,
then yes. The key is really what 'non_tied' is setup as. If this is a
builtin type that optimizes itself to be a string object, then yes it
will fail. However, if 'non_tied' is just a synonym for 'float' (for
some odd reason) then the last line will be ok.

 my int @b :64bit;   # again, just an assertion
 Asserting what? That's not valid syntax at the moment.

But it will be. :-) See RFC 279.
 @c = @b;# empty list passed still
 @b = (1,2); # int-TIEARRAY(@a, '64bit'); @b-CLEAR(...);
 Hmm... I think this is somewhat ugly. Assuming that you want
 Cmy int @b to imply CUNIVERSAL::isa(all(@a), 'int') then tying the
 entire array seems a bit weird.

Not necessarily. The key is: *how* would you implement the assertion

If you use tie, then your int class STORE method can do something like

   package int;
   use base 'var';
   # take defaults from var class
   STORE {
  if ( self-isa($_[1]) ) {
 SUPER-STORE($_[0], $_[1]);   # internally store
  } else {
 die "Bad data $_[1]" if ( $under_strict_types );

Now, there's a difference between _could_ do this and _must_ do this.
The idea here is that you could do this, and users wouldn't see any
difference between your custom types and builtin types.

 Er... You seem to be implying here that *all* classes should have TIE
 methods. Which is not good.

No, I wasn't trying to imply that, I'll clarify this point. TIE methods
are still completely optional. 

 Err... Specifying which classes implement an interface in the
 interface specification is Wrong Wrong Wrong.

Yes, you're right, and it's way outside of this scope of this RFC,
actually. Your idea:

 my Pet $spot : isa(any(qw/Dog Cat/)) = new Camel; # oops!

is much better for this application.
 Can I just point out that nobody has yet proposed that you can attach
 attributes to a package?

Didn't Damian propose Cpackage Foo : interface already? ;-)

 I'm not entirely sure what you're driving at here. I thought you were
 arguing that *all* packages that created objects would use tie magic,
 in which case the new attribute becomes unnecessary. And if you're not
 proposing that then :tie is too general in the cases where the module
 can only tie to specific variable types. I think you get better
 granularity with interfaces, which are way more general than a special
 new attribute.

No, let me back up a little. The idea is to make it so that tied
interfaces - which are really different beasts from OO interfaces
altogether because of their purpose - should be more closely integrated
into Perl 6. This would allow you to create custom, optimized,
strongly-typed variables that would function just like builtins:

   my Matrix @a = ([1,2,3], [4,5,6]);
   my NISMap %map :passwd = read_passwd_file();
   my Apache::Session %session :transaction;

However, this is not to overshadow OO interfaces, which are needed for
functional methods, as you note.

The :tie attribute is a poorly chosen name. The original name was
:implicit, and was going to be attached to the TIE subs:

   package Demo;
   sub TIESCALAR : implicit { ... }
   sub TIEHASH : implicit { ... }
   sub TIEARRAY { ... }

So in this example, a user can say:

   my Demo $x;
   my Demo %x;
   my Demo @x;   # TIEARRAY not called

However, after thinking about this, I decided this was not a worthwhile
distinction. How often would you want this behavior? So I decided to
attach the attribute to the package:

   package Demo : implicit;

But that really didn't connote what was going on. So I changed it to:

   package Demo : autotie;

But then decided the 'auto' was redundant. However, the more 

Re: RFC 170 (v2) Generalize =~ to a special apply-to assignment operator

2000-09-26 Thread Nathan Wiger

Simon Cozens wrote:
 Looks great on scalars, but...
 @foo =~ shift;   # @foo = $foo[0]  ?
 @foo =~ unshift; # @foo = $foo[-1] ?

Yes, if you wanted to do something that twisted. :-) It probably makes
more sense to do something like these:

   @array =~ reverse;
   @vals =~ sort { $a = $b };
   @file =~ grep /!^#/;
 Although I have to admit I like:
 @foo =~ grep !/\S/;

 But I'm not very keen on the idea of
 %foo =~ keys;

Again, that depends on whether or not you're Really Evil. ;-)


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

2000-09-26 Thread Nathan Wiger

 The http_header() is a straw man intended to demonstrate that there
 are issues with shoving all of the outgoing HTTP headers into a simple
 variable.  Not insoluable problems, but problems.

 I do like the idea of stacking HTTP headers and queueing them up
 before the first print statement, where that print is a little
 more magical than every subsequent print.  I'd imagine that if the
 HTTP headers were blank, it would Do The Right Thing (tm) and emit
 a "Content-type: text/html\n\n", before replacing itself with the
 standard print builtin.

Don't get me wrong, I like this idea too.
 And if HTTP headers are segregated from document content, it's
 easier to determine when the headers are finished and when the
 content starts.  That aids in determining when '\n\n' is appropriate.

 Robust input parsing: yes.
 General purpose output formatting: no, nyet, nein, non, "over my dead body".

I'm guessing you mean "nyet" to "general purpose formatting *only*". :-)

After sending that last email, I was sitting here drinking a beer, and
it occured to me that tons of headers all the use same format

   Tag-With-Hyphens: unspecified value of some type

This is true for HTTP, Mail, and lots of other applications.

Maybe what we need is a general "headers()" function, which could
produce a stack of these headers, something like:

   @http_headers = headers(content-type = 'text/html',
   last-modified = $date);

   @mail_headers = headers(from = '[EMAIL PROTECTED]',
   to = '[EMAIL PROTECTED]');

This function could always be present in Perl. I could see *lots* of
uses for such a function. Then, perhaps the "use cgi" pragma could
simply alter the semantics of this builtin to stack the headers given to
it by the headers() function and auto-output them on print.

That way, we're changing the semantics of headers(), not importing it.
Just like 'use tristate' changes the semantics of undef() without
importing a new function. And 'headers()' makes just as much sense as
having 'quotemeta()' in core - there's many potential uses for it.

How's something like that sound?


  1   2   3   4   >