Re: Attribute access

[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($scalar,@array,%hash,^placeholder,&sub);
> 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.

-Nate

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

[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 cgi.pm or
> headers.pm 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.

CGI.pm 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 CGI.pm could potentially build on.

-Nate

Cya dudes

[Ed Mills]

I tried to contribute on this list but it seems we've coalesced downto Tom 
and a handful of others. No one else has a voice.

I have nothing but respect for Tom, Nathan, et al, but its no longer my idea 
of a community - more like a faction.  I'm getting more into PHP now and 
less into Perl, only because PHP evolution seems to be acccelerated by 
novelty, and not mired into a few people's ideas. The politics of Perl are:

   A Suggestion...

   Did Tom or Larry or Uri or someone we all know make it?

   Yes? Unfold into myriad threads about the wonder of the idea..

   No? Don't respond to it, its unworthy..

Nothing but respect for all of you here, and particularly those who I met in 
Monterray this year at Open Source. I just want to move into an arena of 
ideas, and not politics. I'll still use Perl but only as my secondary 
scripting now. PHP is my future because the little guy still has a voice. 
Sorry to make that statement as I committed so much time and effort to Perl 
and it's community, but I think, in the end, its only a place where genius 
has a voice. Sometimes good ideas come out of the masses and litle guys like 
me. I was good enough to complete 2 graduate programs at State universities 
in Comp Sci, and I suppose I ought to be good enough to be heard by a 
programming community. PHP listens, Perl talks.

Again, sorry,
-Ed





_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

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

[Alan Gutierrez]

On Wed, 27 Sep 2000, 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 CGI.pm...
^^^

You are probably finding that CGI.pm is huge for a reason. Because
Frist-Class/easy-to-write CGI requires more than form posts and headers.

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 cgi.pm or
headers.pm or some such I am not concerned. And a switch for tainting
and inclusion of this module sounds peachy. No core.

Alan Gutierrez

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

[Alan Gutierrez]

On Wed, 27 Sep 2000, Nathan Wiger wrote:

> Robert Mathews wrote:

> > How are you going to handle multiple values for the same parameter?
> > With CGI.pm, you can say
> >   @values = $q->param("foo");

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

Hosed indeed. One can control whether or not checkboxes, options, and radio
buttons have a comma in their value attribute. Method two fails when the
user enters "Ann Arbor, MI".

HTML::Embperl stuffs form input into a hash just as proposed here. For
multiple values it creates a tab-delimited string. This will not present
the above trouble with commas, since when the user, for some odd reason,
enters "Ann Arbor\tMI", in most browsers the input focus will jump to
the next input on tab, and the tab does not get entered into a field.

I've used HTML::Embperl a lot and I've not difficulty with series data,
and yes I've worked with checkboxes and selects. It will go a long way
for classic CGI. If the source is coming from other than a browser, or
from a scripting language within the browser it is possible to defeat
this scheme, but we are looking to keep it simple for the common case.

RFC 340 (v1) with takes a context

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

with takes a context

=head1 VERSION

  Maintainer: David Nicol <[EMAIL PROTECTED]>
  Date: 28 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 340
  Version: 1
  Status: Developing

=head1 ABSTRACT

"call frames" become useful as objects.  The current one is always C with
no argument and you can get into an arbitrary one by using C in either forward or backward form, like C.


=head1 DESCRIPTION
=item  description by commented example

sub A{
my $A = shift;
return with;
};

$context1 = A(3);
print "$context1";  # something like CONTEXT(0XF0GD0G)
print "$A" with $context1;  # prints 3
with $context1{print "$A"}; # same thing


=item coexistence w/ pascal-like with 

The context-access C takes a scalar argument, the pascal-like with takes
a hash.  If the pascal-like with is considered as describing aliases to defined
variables, the two have deep similarities.

=item CONTEXT objects in other contexts

In an array context, one of these CONTEXT things will expand into key-value
pairs if it can.

=item warning about memory leaks

using C to store contexts may adversely affect memory recycling.


=head1 IMPLEMENTATION

Perl5 has the hooks required to do this: the closure stuff.  This proposed
C keyword makes access into such things more explicit.


=head1 REFERENCES

None.

RFC 339 (v1) caller->eval BLOCK

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

caller->eval BLOCK

=head1 VERSION

  Maintainer: David Nicol <[EMAIL PROTECTED]>
  Date: 28 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 339
  Version: 1
  Status: Developing

=head1 ABSTRACT

C is extended to allow complete access to the "call frame" of
the current subroutine call.

=head1 DESCRIPTION

Some new syntax is introduced, involving the C keyword,
that allows evaluation of expressions from the point of view of the
situation from which the current method was called.  After thinking
about it for a while I think

caller->eval EXPRESSION;

would work well, with the prototype and semantics of this construction being
identical to regular C, except that resolution of names is done as
if the eval was happening where the call happened.


Neat tricks become possible by directly accessing the immediate symbol
table of the calling context.

=item caller->eval and the hastily destructing return

Also, if we adopt
http://www.mail-archive.com/perl6-internals@perl.org/msg01442.html>
a hastily destructing C 
 (or even if we don't, but easier if we do) we might be able to
break out of loops in the calling context, for instance

return caller->eval{return undef} if $WeAreDone;

would, in the case of C<$WeAreDone> being true, make a first pass over
the expression to be returned, incrementing the reference counts therein,
in this case evaluating "caller" for a value, but not running its eval method,
then destroy the subroutine context (except for rescued values, which there
are none of here) and then evaluate the returned expression.

In this case, the returned expression is a flow control directive, which
will be followed,  returning an undefined value from the calling routine.

In this case, prefixing Ceval> with C might be optional.

=head1 IMPLEMENTATION


C is altered to return a tied scalar that stringifies to
the "caller's package name" if defined, to match perl5.  This object
has some other methods though, in particular an "eval" method which
is described above.


we will still need to keep track of the names of lexical variables that
have been lost to packed offset optimizations, in case they get referred
to by name from within a called function.


If Ceval> contains flow control directives which take us out
of the calling context, the current context must be destroyed


=head1 REFERENCES

perldoc -f caller

How To Implement Tail Recursion: 
http://www.mail-archive.com/perl6-internals@perl.org/msg01442.html

Attribute access

[James Mastros]

There are many (good) RFCs that specify new attributes.  To the best of my
knowledge, there is no good RFC discussing how to go about making
attributes, setting them, and getting them.

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) -- I don't
have the time to write or maintain an RFC.

The idea is this: every variable should have a psudohash of attributes.

To access the attribhash, you'd use somthing like this:
my($scalar,@array,%hash,^placeholder,&sub);
my %arraysattribs = %@array:;
my $subsline = $&sub:{line};

print "\%hash has the following attributes:\n";
foreach (keys %%hash:) {
print "\$\%hash:{$_} = ", $%hash:{$_}, "\n";
}

$subsattribsref = \%&sub:;

This is to say, the attribhash for a varable VAR (where VAR includes the
funny-character is the hash VAR:.  (You can use any expression with a valid
result for VAR.)

In 5.6, C has the same effect as C,
and C is a syntax error.

You need to keep the funnychar of the attributed thingy somewhere in the
attribhash syntax, since otherwise $foo's attribues aren't seperable from
@foo's.

The reason you want an attribute hash is fairly obvious, I think.

An operator with rvalue and lvalue semantics is also possible:
%foosattribs = attribs @foo;
%foosattribs{private}++;
However, I can't see how you could set an attribue on a value without making
a temporary.

Variable names containing a : that isn't part of a :: would be reserved.
(That, or the bare colon is an operator returning a hash (not a list).)

You can also set an attribute like this:

my $foo :private;
This is equivlent to:
my $foo;
$$foo:{private} = 1;

my $foo :private(1);
is equivlent to
my $foo;
$$foo:{private} = [1];

my $foo;
means that
exists($$foo:{private}) is false.

You can put an attribute in anything that can be used as a variable:
Whole arrays.
Whole hashes.
Scalars.
Array elements.
Filehandles
[Globs].
Subs.
Hash values.
Hash key-value pairs?  This probably makes sense iff hash keys become full
scalars and not strings that act like scalars sometimes.  It would be
useful, though.

Note the last one especialy.

$$hash{elem}:{raccess}++;
$hash{elem} = 42;
exists $$hash{elem}:{raccess}; #is false.

This is because %$hash{elem}: sets the attribute on the value of
$hash{elem}, not on the spot in the hash.

I don't know what a good syntax for the hash position would be.  And I've
got other work to do now.

-=- James Mastros




Creating attributes:



-- 
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GU>CS d->-- s-:- a20 C++ UL+++@ P+++>+ L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e>++ h! r- y?
--END GEEK CODE BLOCK--

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

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

-Nate

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

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

-Nate

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

[Jerrad Pierce]

Personally I think this is probably a bad idea.
But if such a thing WERE to be implemented, I don't see why you have to have
two words...

header(a>1, b=>2); #options list, returns a string with formatted headers
header($foo);  #scalar option $foo is parsed and a list is returned
   #(for assignment to a hash most likley)
header();  #implied scalar option $_, if this is a hash reference,
   #header acts in the format sense... else parse
header(header(a=>1, b=>2)); #essentially a NOOP


PS> un is such a lame prefix and very un perl like... unjoin? unpush?
okay so unshift, but still... hey wait I want undelete!
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";&{$F[0]};sub t{*t=sub{};
return if rand()<.5;$_="Vg'f abg lbhe ghea lrg, abj tb.";&{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}&v;}{$_++;$_--;$_||=4;
if($_>>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=5?$0>2?3:1:rand>.5?1:3;
$_="V jva";die(&{$F[0]}) if !($0-1>1);}&v __END__ http://pthbb.org/
MOTD on Sweetmorn, the 52nd of Bureaucracy, in the YOLD 3166:

No civilized person ever goes to bed the same day he gets up

Re: RFC 262 (v1) Index Attribute

[David L. Nicol]

John Porter wrote:
> 
> David L. Nicol wrote:
> >
> >
> >   print "Found It at position ${_:n}!\n" if /$seek/ foreach @items
> 
> If we are going to be throwing around attributes like that, why
> don't we switch to using the ubiquitously recognizable dot instead
> of colon?
> 
> for my $iter ( @things ) {
> print "index= ", $iter.indexof, "\n";


I hope that was a rhetorical question, but here is the rhetorical answer:

Because the ubiquitously recognizable dot is already in use as the
string concat operator in this language, and overloading it would
cause far far far too much ambiguity.  This answer also goes for schemes
for optimising 

->

into one character.

Re: RFC 262 (v1) Index Attribute

[John Porter]

David L. Nicol wrote:
> 
> 
>   print "Found It at position ${_:n}!\n" if /$seek/ foreach @items

If we are going to be throwing around attributes like that, why
don't we switch to using the ubiquitously recognizable dot instead
of colon?

for my $iter ( @things ) {
print "index= ", $iter.indexof, "\n";

-- 
John Porter

Jetzt schalten wir das Radio an. Aus dem Lautsprecher klingt es dann...

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

[Jonathan Scott Duff]

On Thu, Sep 28, 2000 at 03:22:08PM -0600, John Barnette wrote:
> Perl6 RFC Librarian (Today):
> > =head1 TITLE
> > Add C and C funtions to core distribution
> 
> While I'm not sure if this belongs in the core or not, I think it's nifty,
> and I'd like to point out an almost inevitable side effect.  Knowing well
> the nature of Perl hackers, this function will almost certainly be used
> for non-header tasks such as config files, as the data format used in most
> plaintext headers is both simple and general.  Add comment detection to
> the parsing, f'rinstance, and this is quite similar to a Java Properties
> file.

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

To me core-worthy things must be primitivish.  The idea of colonizing
and s/_/-/g and ucfirst()ing each word and adding newlines or reversing
all of that seems so unprimitive.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: PERL6STORM - tchrist's brainstorm list for perl6

[Adam Krolnik]

I think the octal number representation should not be accepted...


Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074

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

[John Barnette]

Perl6 RFC Librarian (Today):
> =head1 TITLE
> Add C and C funtions to core distribution
>Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
> 
> =head1 ABSTRACT

> This RFC proposes that Perl include a simple function, C, that
> can be used to interact with these headers more easily. It is a
> general-purpose formatting function that does not do any
> content-specific handling (unlike C's version). It is also
> proposed that an C function be included which converts in the
> opposite direction.

While I'm not sure if this belongs in the core or not, I think it's nifty,
and I'd like to point out an almost inevitable side effect.  Knowing well
the nature of Perl hackers, this function will almost certainly be used
for non-header tasks such as config files, as the data format used in most
plaintext headers is both simple and general.  Add comment detection to
the parsing, f'rinstance, and this is quite similar to a Java Properties
file.

Useless comment, probably, but it sprung to mind.

~ j. // "The National Association of Theater Concessionaires
 // reported that in 1986, 60% of all candy sold in movie
 // theaters was sold to Roger Ebert." -- D. Letterman  

Re: RFC 171 (v3) my Dog $spot should call a constructor implicitly

[Michael Fowler]

On Thu, Sep 28, 2000 at 12:25:32PM +0100, Tom Christiansen wrote:
> You also didn't mention that you would have broken the symmetry between
> 
>my  Dog $spot;  
>our Dog $spot;

No, I didn't mention our Dog $spot should be the same thing, but on an our
variable.

 
> Or that constructors have no (and should have no) set name in Perl.

What of TIEARRAY, TIEHASH, TIEHANDLE, etc.?  What of the alternative for
providing an author-specified implicit constructor name through a pragma?


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--

RFC 333 (v1) Add C and C funtions to core distribution

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

Add C and C funtions to core distribution

=head1 VERSION

   Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
   Date: 27 Sep 2000
   Mailing List: [EMAIL PROTECTED]
   Number: 333
   Version: 1
   Status: Developing

=head1 ABSTRACT

Many services use HTTP-style headers to pass information, including
HTTP, SMTP, and others. These headers, described in internet RFC 822
(see L), are a widely-accepted internet standard.

This RFC proposes that Perl include a simple function, C, that
can be used to interact with these headers more easily. It is a
general-purpose formatting function that does not do any
content-specific handling (unlike C's version). It is also
proposed that an C function be included which converts in the
opposite direction.

=head1 DESCRIPTION

=head2 The functions

The C function would work very similarly to C's:

   @HEADERS = header(content_type => 'text/html',
 author => 'Nathan Wiger',
 last_modified => $date,
 accept => [qw(text/html text/plain)]);

This would produce an array of the following:

   @HEADERS = ("Content-Type: text/html\n",
   "Author: Nathan Wiger\n",
   "Last-Modified: Wed Sep 27 13:31:06 PDT 2000\n",
   "Accept: text/html, text/plain\n",
   "\n");

Notice that the last element is a "\n" by itself, providing the
necessary blank line separating headers and content. The C
function would simply:

   1. uc the first letter of each tag token and lc the
  rest, also converting _'s to -'s automatically

   2. Add a colon separating each tag and its value,
  and exactly one newline after each one

   3. Combine list elements into a comma-delimited
  string 

   4. Append a singular newline as the last element of
  the list

This usage integrates very well with B on improving the
coupling between Perl and CGI apps. Unlike C, however, the
C function would B provide any defaults. If called simply
as:

   @HEADERS = header;

It would a single-element list consisting of "\n". This allows C
to be more general pupose, so it can provide SMTP and other headers as
well:

   @mail_headers = header(from => '[EMAIL PROTECTED]',
  to => '[EMAIL PROTECTED]');
   print $MAIL @mail_headers, @content;

In addition, it is proposed that an C function be added as
well. This function would convert in the opposite direction. Assuming
the C<@HEADERS> array above:

   %myheaders = unheader(@HEADERS);

The hash C<%myvals> would have the following values:

   %myheaders = (
   content_type => 'text/html',
   author => 'Nathan Wiger',
   last_modified => 'Wed Sep 27 13:31:06 PDT 2000'
   accept => [qw(text/html text/plain)]);
   );

That is, the process that C does is exactly reversed, including
stripping of trailing newlines, conversion to lowercase, and so forth.
So, this call:

   @out = header unheader @in;

Should result in C<@out> being exactly equivalent to C<@in>.

=head2 Location

These are such lightweight functions that their impact on core would be
negligible. As such, they could potentially be put directly into it,
since they are just formatting functions compliant with open standards.
Having to modify them is not seen as likely. Also, other RFC's, such as
B, could well use this mechanism to automatically parse
incoming and outgoing headers. This could also be linked to the concept
of C proposed in B. If functions such as C and
C go in, then it would seem logical to put C and
C in as well.

Nonetheless, it may be more appropriate to place these in a module that
is part of the core distribution. 

=head1 IMPLEMENTATION

A complete Perl 5 implementation can be found as Text::Header at:
http://www.perl.com/CPAN/modules/by-authors/id/N/NW/NWIGER/Text-Header-1.02.tar.gz

Provide a simple and more general-purpose version of C and
C. Also provide an C function that converts in
the opposite direction.

=head1 MIGRATION

This introduces new functionality, but its name does conflict with those
using C. Still, those who say C should win, since the
imported function will overlap with the builtin one (assuming core
functions become true functions).

=head1 REFERENCES

RFC 288: First-Class CGI Support

RFC 14: Modify open() to support FileObjects and Extensibility

RFC 90: Arrays: merge() and unmerge()

C by Lincoln Stein

C by Gisle Aas

http://sunsite.auc.dk/RFC/rfc/rfc822.html

RFC 329 (v1) C

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

C

=head1 VERSION

  Maintainer: Simon Cozens <[EMAIL PROTECTED]>
  Date: 28 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 329
  Version: 1
  Status: Developing

=head1 ABSTRACT

A pragma to modify the syntax of Perl 6 at run time. Oh yes.

=head1 DESCRIPTION

So, maybe the Perl 6 crack pipe finally got around to me, but it
seems to me that if we've got a parser that we can modify and add hooks
to in Perl space (see RFC 314) then we can alter Perl's syntax using
pragmata.

Combining this with source filters means that we can arrange for the
line

use syntax "perl5";

to enable legacy Perl programs to run under Perl 6.

I briefly considered

{
use syntax "python";
}

and nearly lost my lunch.

Seriously, though, I think if we have a flexible parser that we can
modify in Perl space, interpreting legacy versions of Perl or inferior
languages could quite definitely become possible.

=head1 IMPLEMENTATION

First, implement 314. Then construct grammars for what we want to parse,
and ensure that the parser is flexible enough to allow them as alternate
grammars.

=head1 REFERENCES

RFC 314

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

[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. ;-)

-Nate

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

RFC 277 (v2) Method calls SHOULD suffer from ambiguity by default

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

Method calls SHOULD suffer from ambiguity by default

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 24 Sep 2000
  Last Modified: 28 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 277
  Version: 2
  Status: Developing

=head1 CHANGES

The first version was too cute, trying to prove a point but failing
miserably. So here it is, in plain English.

=head1 ABSTRACT

RFC 244 proposes special-casing -> to quote the left operand, and
eliminating the bareword indirect object syntax entirely.

These are both Bad Ideas, and will likely cause a large number of
longtime Perl hackers to run away screaming.

Many people, myself included, view the ability to type:

   $q = new CGI;
   $val = shift->{fullname};

And have Perl DWIM is what makes Perl Perl, and fun. Forcing me to
write:

   $q = new {'CGI'};
   $val = shift()->{fullname};

Because this ambiguity upsets a few people is just plain silly. And
B un-fun.

Tightening this syntax by default makes no sense. Rather, this is
something that can easily be added to C. See B for
details on C and C.

=head1 DESCRIPTION

In Perl 5, there are already plenty of ways in which people can
B disambiguate the above:

   $q = new 'CGI';   # main::new('CGI');
   $q = CGI::->new;  # or 'CGI'->new;

   $val = shift::->{fullname};   # or 'shift'->{fullname}
   $val = shift()->{fullname};   # main::shift()->{fullname}

And if people want this to be enforced, then they can easily C as specified in RFC 278.

Perl 6 should be a value add to Perl 5. It should not take away
established, widely-used syntax just because of a little ambiguity. This
is hardly the only syntactic ambiguity in Perl.

=head1 IMPLEMENTATION

Perl 6 should tokenize the above just like Perl 5.

=head1 MIGRATION

None. Why would we want there to be?

=head1 REFERENCES

RFC 28:  Perl should stay Perl.

RFC 278: Additions to 'use strict' to fix syntactic ambiguities

RFC 244: Method calls should not suffer from the action on a distance

Re: Murdering @ISA considered cruel and unusual

[Simon Cozens]

On Thu, Sep 28, 2000 at 02:40:04PM -0400, John Porter wrote:
> Tom Christiansen wrote:
> > Perl's use of @ISA is beautiful.  
> > 
> > use base is, or can be, pretty silly --
> > think pseudohashes, just for one.
> 
> I suppose you diddle @INC directly, Tom,
> instead of use'ing lib?

I call "non sequitur"!

-- 
People in a Position to Know, Inc.

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

[Adam Turoff]

On Thu, Sep 28, 2000 at 08:06:42AM +0200, H . Merijn Brand wrote:
> On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > This and other RFCs are available on the web at
> >   http://dev.perl.org/rfc/
> > 
> > =head1 TITLE
> > 
> > First-Class CGI Support
> 
> Freezing within two days doesn't leave much space for comments and or
> objections does it?

Retractions are still possible with frozen RFCs.  

Minor revisions and clarifications are still acceptable for frozen RFCs.
The intent of this RFC seems clearly stated.

That, and the discussion I saw seemed to have fleshed out the major issues,
and was getting bogged down in trivia (e.g. embperl).

> I'm not against making things easier in general, but I don't want perl to be
> Just Another Web Service. I've started an RFC on that when perl6 just started,
> but I saw discussions take a good direction, so I didn't post it.

Please post it.  Or something along the lines of what you were thinking.

> I think this one belongs in perl6-stdlib, certainly not in the perl6-core!

Probably.  But it has interaction with taint mode, which is also
something of an internals issue.  And there are some minor language
design issues, like making %CGI become the equivalent of %ENV and 
making taint mode manditory (unless it's REEELY not wanted).

One strike against -stdlib, is that the standard library has CGI.pm
already, and this is a plea for a more standard, less feature-bloated
module that could easily be reused for all of the CGI output interfaces.

Z.

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

[Russ Allbery]

Andy Dougherty <[EMAIL PROTECTED]> writes:

> I find that I don't remember many of the less-frequently-used perlvars
> (where less-frequently-used depends on the types of programs I write,
> obviously).  I certainly couldn't tell you off-hand the differences
> among $< $> $( and $).  I'd have to look them up.

I never understood why these were variables.  You don't change UIDs or
GIDs that often, and when you do you tend to want precise control and
because they're variables, they have weird interaction semantics and you
have to assign to them in just the right order to get done what you want
to get done.  See recent threads on comp.lang.perl.moderated.

I'd honestly rather see getuid, geteuid, getgid, getegid, and getgroups,
along with some consistent and complete subset of the setting functions
(with portability magic behind the scenes), in a separate module that only
those programs that need to do UID fiddling need to load.

I guess the exception is getpwuid($<), which is probably done more than
any other operation on UIDs, but maybe just keep that single variable.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: split() ideas

[John Porter]

Jonathan Scott Duff wrote:
> 
> 1. Allow the first argument to split() to be a number such that
>the string is broken into chunks of that many characters.

  @strings = /(.{$n})/g;


> 2. Allow the first argument to split() to be an array of
>numbers, such that split returns a list of strings each as
>long as the corresponding number.

  @strings = do { my $re = join '', map { "(.{$_})" } @lengths; /$re/ };

-- 
John Porter

Re: Murdering @ISA considered cruel and unusual

[John Porter]

Tom Christiansen wrote:
> 
> Perl's use of @ISA is beautiful.  
> 
> use base is, or can be, pretty silly --
> think pseudohashes, just for one.

I suppose you diddle @INC directly, Tom,
instead of use'ing lib?

-- 
John Porter

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

[Robert Mathews]

Nathan Wiger wrote:
> 1. make a listref only for multiple values:
>@name = @{$CGI{name}} if ( ref $CGI{name} eq 'ARRAY' );

Ick.  That piece of code is small enough, but it's going to end up
replicating itself everywhere %CGI is accessed.  This will be a fruitful
new source of bugs when people forget to check C, and a
maintenance nightmare when someone makes a small like adding "multiple"
to a select tag.

> But I don't think listrefs are needed in all contexts, since you should
> know which elements will likely have multiple values (checkboxes, etc).

Maybe (and I stress maybe) the programmer knows, but the code that
parses into %CGI doesn't know whether a parameter is from a checkbox
group with only one value checked, or something else.

> 2. make it a comma-delimited string:
>$name = $CGI{name};
>@name = split ',', $name;
> The problem arises if your data has commas in it.

Double ick.

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

It looks to me like FETCH is always called in scalar context.  Even
saying C<@foo{...}> results in multiple scalar fetches.  That could be
changed, I suppose, but it makes me twitch.  Maybe someone who knows
ties better could comment on this.

-- 
Robert Mathews
Software Engineer
Excite@Home

Re: split() ideas

[Graham Barr]

On Thu, Sep 28, 2000 at 01:02:11PM -0500, Jonathan Scott Duff wrote:
> I thought I had sent this the other day, but it doesn't appear to have
> made it through...
> 
> Here are a couple of ideas that I don't have time to RFC, but some who
> likes them might:
> 
> 1. Allow the first argument to split() to be a number such that
>the string is broken into chunks of that many characters.
> 
> 2. Allow the first argument to split() to be an array of
>numbers, such that split returns a list of strings each as
>long as the corresponding number.
> 
> Yes, I know this can be done with unpack() or substr(), but that's never
> stopped us before.

Ah, but with them you would need a loop.

One other way would be to allow \G to work in split() so you could do

  @ary = split(/\G(<=..)/, $str)

but then we can already do this with

  @ary = $str =~ /\G(..)/sg;

> Note that if #1 is adopted, $foo in "split $foo, $str" will no longer
> really mean "split /$foo/, $str".

Right, and I think that the fact that there are already several ways to
do it, we don't need to add another.

Graham.

split() ideas

[Jonathan Scott Duff]

I thought I had sent this the other day, but it doesn't appear to have
made it through...

Here are a couple of ideas that I don't have time to RFC, but some who
likes them might:

1. Allow the first argument to split() to be a number such that
   the string is broken into chunks of that many characters.

2. Allow the first argument to split() to be an array of
   numbers, such that split returns a list of strings each as
   long as the corresponding number.

Yes, I know this can be done with unpack() or substr(), but that's never
stopped us before.

Note that if #1 is adopted, $foo in "split $foo, $str" will no longer
really mean "split /$foo/, $str".

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: perl6storm #0050

[John Porter]

Buddha Buck wrote:
> 
> While Perl -lets- every function be well prototyped, it doesn't -require- 
> every function to be well prototyped.  Because of this, it might be well 
> nigh impossible to eliminate all ambiguity to the compiler.

Well, right.  Clearly, in those cases, you can expect to need parens
sometimes.

-- 
John Porter

Jetzt schalten wir das Radio an. Aus dem Lautsprecher klingt es dann...

Re: my and local

[Adam]

On Thu, 28 Sep 2000, Steve Fink wrote:
> Tom Christiansen wrote:
> > 
> > As we sneak under the wire here, I'm hoping someone
> > has posted an RFC that alters the meaning of my/local.
> > It's very hard to explain as is.  my is fine, but local
> > should be changed to something like "temporary" (yes, that
> > is supposed to be annoying to type) or "dynamic".
> 
> my's runtime/compile-time schizophrenia is rather bizarre too. I'd like
> 
> my $x if 0;
> 
> to be equivalent to
> 
> my $x;
> 
Why? Do you mean that you want $x to be created/instantiated even if the
boolean clause is false (but could have been true)? In an if/then blcok
the scalar would be scoped locally and so would be irrelevant if the
boolean clause evaluated evaluated to false. As it is, it is kind of
strange that the scope of $x in your statement isn't bound in the if/then
structure.

-Adam

btw: I am guessing that you usually write that 
my $x = $y if 0/1;

Which could be done slighlty safer
my $x = 0/1 ? $y : 0; # or undef

Re: my and local

[Steve Fink]

Tom Christiansen wrote:
> 
> As we sneak under the wire here, I'm hoping someone
> has posted an RFC that alters the meaning of my/local.
> It's very hard to explain as is.  my is fine, but local
> should be changed to something like "temporary" (yes, that
> is supposed to be annoying to type) or "dynamic".

my's runtime/compile-time schizophrenia is rather bizarre too. I'd like

my $x if 0;

to be equivalent to

my $x;

Re: RFC 262 (v1) Index Attribute

[David L. Nicol]

Webmaster wrote:
> 
> (I have attached a prototype of what I had in mind)
> 
> From: "David L. Nicol" <[EMAIL PROTECTED]>
> > Yes, that is exactly what is being suggested, but the "indexof" function
> > is implicit in the attribute.  Your code becomes
> >
> > print "Found It at position ${_:n}!\n" if /$seek/ foreach @items
> 
> I do like the iterator, but I also prefer:
>  "  split( /$delim/, $items[$index] );"
> To
>  " split( /$delim/, $items[${_:n}]);"
> for readability.

yes.  I imagine :n would be used in debugging code, where you don't
really need it for the general meaning of the passage.

$items[$_:n]# curlies only are required for interpolation

I didn't say it so many words, but an example of how to _access_ an
attribute inside interpolation -- that is what I was getting at too;


>  The two might actually be able to work together, if ':n'
> was an element of the actual array, whereby a subsequent call to the array
> index function using 'null' or 'undef' as the starting index would pick up
> where it left off. The other part is that the array index function could
> potentially return a list. (see attached)
> 
> It's only a suggestion, and I have programmed long enough to do it other
> ways (see attached), but if RFC 199 doesn't fly, this would be nice to have
> around.
> Grant M.
> [EMAIL PROTECTED]

it's not a member, but an attribute, thus the colon.  The curlies are
only needed because we're inside double-quotes in my example.

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

[Simon Cozens]

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?

-- 
It is better to wear chains than to believe you are free, and weight
yourself down with invisible chains.

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

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

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.

-Nate

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

[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
> >through.
> 
> 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;
   $STDERR->print(@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.

-Nate

Re: Murdering @ISA considered cruel and unusual

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

-Nate

Re: Expunge "use English" from Perl? (was Re: Perl6Storm: Intent toRFC #0101)

[Andy Dougherty]

On Wed, 27 Sep 2000, Nathan Wiger wrote:

> 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

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

Well, I think it has some limited uses.  Remember that not everyone
programs in perl all day everyday.  Many competent people are only
occasionally perl programmers.

I find that I don't remember many of the less-frequently-used perlvars
(where less-frequently-used depends on the types of programs I write,
obviously).  I certainly couldn't tell you off-hand the differences among
$< $> $( and $).  I'd have to look them up.  I think it's a nice little
bit of optional sugar and I don't see any reason to throw it away.

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

[Tom Christiansen]

Certainly numbers should never be "zero-padded"!

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: RFC 171 (v3) my Dog $spot should call a constructor implicitly

[Tom Christiansen]

You also didn't mention that you would have broken the symmetry between

   my  Dog $spot;  
   our Dog $spot;

Or that constructors have no (and should have no) set name in Perl.

--tom

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: Murdering @ISA considered cruel and unusual

[Piers Cawley]

Tom Christiansen <[EMAIL PROTECTED]> writes:

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


> use base is, or can be, pretty silly -- think pseudohashes, just for
> one.

C has the potential to be very nice indeed. Preferably after
pseudo hashes have been excised from the language. It happens at
compile time. You can enforce various levels of stricture through it,
which can potentially make it easier for the compiler to optimize
stuff. It's vaguely necessary if you're going to have interfaces and
all that (at least, the compile time behaviour is). I say keep it.

Neither of these methods is the One True Way. They are both very
useful in their place. Deciding where those places are is left as an
exercise for the interested programmer.

-- 
piers

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

[iain truskett]

* Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]:
> On 27 Sep 2000, at 23:48, iain truskett wrote:

> > So surely you'd want %HTTP (the input headers) to also be an array
> > rather than a hash, since they'd be required in order as well?

> I don't care, because I don't work with this much.

It's a case of: if you're going to have the output order, then you
should provide for the input to be ordered. *As well as* unordered.

> And I don't know whether I'd need to bear in mind the protocol which
> requires the order; I'd probably want to access them randomly. But
> that I send out has to follow the protocol.

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

I'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
my $type = $headers_in->value('Content-Type');
or process things sequentially
foreach my $header_key ($headers_in->keys)
{
}
and of course add and remove things
while ($headers_in->keys)
{
my $headerline = $headers_in->shift;
my ($key, $value) = ($headerline->key, $headerline->value);
}
$headers_in->add('Breakfast-Food', 'Bagel');
and so on.

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

> In other words, the input has an order (the order in which the user-
> agent sent the headers), but I'm not necessarily interested in it
> (frequent CGI programmers may have different needs);

Precisely. So theoretically, we should provide for both situations.

> the output also has an order, and *someone* has to provide for that
> order, and I believe it is not good for Perl to do so (for the reasons
> given before).

I would agree.


cheers,
-- 
iain truskett, aka Koschei.
You know you are addicted to coffee if...
 2  You sleep with your eyes open.

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

[Philip Newton]

On 27 Sep 2000, at 23:48, iain truskett wrote:

> So surely you'd want %HTTP (the input headers) to also be an array
> rather than a hash, since they'd be required in order as well?

I don't care, because I don't work with this much. And I don't know 
whether I'd need to bear in mind the protocol which requires the 
order; I'd probably want to access them randomly. But that I send 
out has to follow the protocol.

In other words, the input has an order (the order in which the user-
agent sent the headers), but I'm not necessarily interested in it 
(frequent CGI programmers may have different needs); the output 
also has an order, and *someone* has to provide for that order, and 
I believe it is not good for Perl to do so (for the reasons given before).

Cheers,
Philip

Re: my and local

[Dave Hartnoll]

To my mind, things would be a lot clearer if my and local were to change
places - but I can see why that would not be a good thing.
If it's not too late for suggestions for renaming local, what about
'override'.

Dave.

- Original Message -
From: "Michael Fowler" <[EMAIL PROTECTED]>
To: "Tom Christiansen" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 28, 2000 10:36 AM
Subject: Re: my and local


> On Thu, Sep 28, 2000 at 10:18:34AM +0100, Tom Christiansen wrote:
> > As we sneak under the wire here, I'm hoping someone
> > has posted an RFC that alters the meaning of my/local.
> > It's very hard to explain as is.  my is fine, but local
> > should be changed to something like "temporary" (yes, that
> > is supposed to be annoying to type) or "dynamic".
>
> Someone has:
> RFC19 "Rename the C operator"
http://tmtowtdi.perl.org/rfc/19.pod
>
>
> Michael
> --
> Administrator  www.shoebox.net
> Programmer, System Administrator   www.gallanttech.com
> --
>

Re: my and local

[Michael Fowler]

On Thu, Sep 28, 2000 at 10:18:34AM +0100, Tom Christiansen wrote:
> As we sneak under the wire here, I'm hoping someone
> has posted an RFC that alters the meaning of my/local.
> It's very hard to explain as is.  my is fine, but local
> should be changed to something like "temporary" (yes, that
> is supposed to be annoying to type) or "dynamic".

Someone has:
RFC19 "Rename the C operator" http://tmtowtdi.perl.org/rfc/19.pod


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--

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

[Tom Christiansen]

>So what's left?
>
>print STDERR "Foo";
>
>We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
>through.

It is?  I certainly hope not.  It makes as much sense to 
do that as to force a dollar sign on subroutines.

   sub $foo { ... }

or 

   sub 'foo' { ... }

Heck, maybe everyone should be forced to write

   *foo = sub { ... };


>$time = time;
>print;

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

--tom

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Murdering @ISA considered cruel and unusual

[Tom Christiansen]

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

use base is, or can be, pretty silly -- think pseudohashes, 
just for one.

The general sentiment you espouse obviously has a line beyond
which you don't intend to cross.   The question is where
that line lies.

--tom, who knows that it's hard to read his mail, but it's
   even harder to write it

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

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

[Tom Christiansen]

Try thinking of it this way: it's only a bareword if 
it would make use strict whinge at you.  Thus, the
constructs you cited are all non-uses of barewords,
such as in use Foo or require Foo or Foo => 1, or
even $x{Foo}.  And I have proposed (nonRFC) that
Foo->bar() also be not a bareword.  Yes, I know 
strict doesn't carp about it, but that could be Foo().

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

my and local

[Tom Christiansen]

As we sneak under the wire here, I'm hoping someone
has posted an RFC that alters the meaning of my/local.
It's very hard to explain as is.  my is fine, but local
should be changed to something like "temporary" (yes, that
is supposed to be annoying to type) or "dynamic".

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: perl6storm #0050

[Piers Cawley]

John Porter <[EMAIL PROTECTED]> writes:

> Piers Cawley wrote:
> > 
> > You know, I'm trying to see what's annoying about all those
> > parentheses in the lisp function and what do you know, I can't see
> > anything wrong. Okay, so it's not Perl syntax, but it's still clear
> > what's going on.
> 
> Yes, but it's hard to read.

We could argue this back and forth, but I don't think that was hard to
read. Sure you need to know lisp to understand it, but the same could
be said of *any* programming language.

-- 
Piers

Re: RFC 143 (v2) Case ignoring eq and cmp operators

[Tom Christiansen]

This RFC still has silly language that discounts what
has been said before.  

1) It calls
uc($a) eq uc($b)
"ugly", despite their being completely intuitive and legible
to even the uninitiated.

2) It then proposes "eq/i" without the least blush, despite
   how incredibly ugly and non-intuitive and, if I may,
   syntactically perverse such a notion is.

--tom

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

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

[Hildo Biersma]

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

However, there are many different header schemes in existence - how are
we going to teach perl about new header formatting rules?

I am kind of worried that we extend perl with (CGI|HTTP|SMTP)-like
headers, and then the next version of SOAP (or whatever) comes out that
everyone wants to use two years from now, but is not compatible with the
built-in at all.

If headers are that common, write a Headers module and include it in the
various modules that need it.

Hildo