perl6storm #0010: kill all defaults

[Philip Newton]

On Thu, 21 Sep 2000, Tom Christiansen wrote:

> =item perl6storm #0010
> 
> Allow a way to kill *all* defaults at compile time.  Or warn about them.
> 
> no defaults;
> use defaults 'none';
> use warnings 'defaults';
> 
> this is for anal python folks.

What are defaults, in this context? Things like abs taking $_ if no
variable is specified? Or localtime taking time()? Or what?

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

perl6storm #0011: interactive perl mode

[Philip Newton]

On Thu, 21 Sep 2000, Tom Christiansen wrote:

> =item perl6storm #0011
> 
> perl w/o args with stdin and out ttys should be perl -de 0.
> saves novices from typing "perl" and getting confuddled.

I think it should print out a banner message, too.

A couple of times I was wondering whether perl was installed on a machine
and typed 'perl' to see -- and "nothing happened". (I suppose either of
`which perl` or `perl -v` would be a better way to find out, but still.)

Having Perl tell me 'this is perl5.7.0\n> ' or similar would have been
nice. But that's just me.

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

Re: PERL6STORM - tchrist's brainstorm list for perl6

[Philip Newton]

On Thu, 21 Sep 2000, Tom Christiansen wrote:

> =item perl6storm #0035
> 
> Make A->B place A in string context, like => does.
> That way no A()->B naughtiness.

While still allowing explicit A()->B?

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

perl6storm #0050

[Philip Newton]

On Thu, 21 Sep 2000, Tom Christiansen wrote:

> =item perl6storm #0050
> 
> Radical notion: consider removing precedence.
> Wrong precedence makes people miserable.

(Some people already suggest that Perl only has two precedence rules: (1)
multiplication and division come before addition and subtraction, and (2)
parenthesize everything else.)

This would make Perl more like Lisp, I suppose. But it would make code
less ambiguous, probaly at the cost of readability. Arguably, some (most?)
of the precedence levels already work the way people expect them to (for
example, == binds more tightly than || or &&), so fewer "cluttering"
parentheses are needed to make things readable while still being correct.

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

perl6storm #0060: formats

[Philip Newton]

On Thu, 21 Sep 2000, Tom Christiansen wrote:

> =item perl6storm #0060
> 
> formats and html doesn't mix nicely (not wysiwig).   Neither do any
> hidden chars, like ESC-blah.  Can we do more for generating simple
> clean transparent xml?

Talking of ESC-blah, I've sometimes wanted to have a way to use formats
that can print embedded printer control sequences -- that is, formats that
know that length("\e*(3B") == 0. However, this is probably impossible to
generalise or get right (specifically because escape sequences are
variable length, and the set of escape sequences cannot be defined
beforehand).

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

perl6storm #0073

[Philip Newton]

On Thu, 21 Sep 2000, Tom Christiansen wrote:

> =item perl6storm #0073
> 
> kill bareword strings entirely.

Including in places such as use? Well, I suppose we can get used to

use 'strict';

. Any other "famous" incidences of barewords? (Maybe
'Foo::Blurf'->meth().)

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

Re: perl6storm #0011: interactive perl mode

[Russ Allbery]

Philip Newton <[EMAIL PROTECTED]> writes:
> On Thu, 21 Sep 2000, Tom Christiansen wrote:

>> =item perl6storm #0011

>> perl w/o args with stdin and out ttys should be perl -de 0.
>> saves novices from typing "perl" and getting confuddled.

> I think it should print out a banner message, too.

> A couple of times I was wondering whether perl was installed on a
> machine and typed 'perl' to see -- and "nothing happened". (I suppose
> either of `which perl` or `perl -v` would be a better way to find out,
> but still.)

> Having Perl tell me 'this is perl5.7.0\n> ' or similar would have been
> nice. But that's just me.

As long as it's possible to get the current "perl" behavior; I actually
use that a lot.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: perl6storm #0050

[raptor]

> On Thu, 21 Sep 2000, Tom Christiansen wrote:
>
> > =item perl6storm #0050
> >
> > Radical notion: consider removing precedence.
> > Wrong precedence makes people miserable.
>
> (Some people already suggest that Perl only has two precedence rules: (1)
> multiplication and division come before addition and subtraction, and (2)
> parenthesize everything else.)
>
> This would make Perl more like Lisp, I suppose. But it would make code
> less ambiguous, probaly at the cost of readability. Arguably, some (most?)
> of the precedence levels already work the way people expect them to (for
> example, == binds more tightly than || or &&), so fewer "cluttering"
> parentheses are needed to make things readable while still being correct.

What if we have these 2 rules or no rules AND we can set manualy the
precedence of all operators... as in PROLOG
(op(precedencePriority,associativity!,operator)).
This way older scripts will still work , and for the new scripts any can
decide ambiguousity or readability is more important!!
=
iVAN
[EMAIL PROTECTED]
=

Re: PERL6STORM - tchrist's brainstorm list for perl6

[Bart Lateur]

On Sat, 23 Sep 2000 04:20:37 -0400 (EDT), Philip Newton wrote:

>On Thu, 21 Sep 2000, Tom Christiansen wrote:
>
>> =item perl6storm #0035
>> 
>> Make A->B place A in string context, like => does.
>> That way no A()->B naughtiness.
>
>While still allowing explicit A()->B?

Of course. You can still have

A() => 'B'

too, can't you? The rules would be the same.

-- 
Bart.

Re: RFC 83 (v3) Make constants look like variables

[Nathan Wiger]

Jeremy Howard wrote:
> 
> Good question. I haven't tackled this in RFC 83, because it is a more
> general question about attribute syntax. We don't really have a good
> attribute syntax RFC yet, although Nate threw up some ideas a couple of days
> ago. Is someone interested in whipping up an RFC that combines Nate's
> suggestions with clarification of issues such as this?

Nate is! ;-)

I'm on it, should be out today...

-Nate

perl6storm ideas that are already covered

[Nathan Wiger]

Just so we don't rehash issues that are already covered in other RFC's,
since many are:

> =item perl6storm #0015
> 
> merge tie and overloading.  python's ease of doing this
> makes this embarrassing.

RFC 200: Objects: Revamp tie to support extensibility (Massive tie
changes)

> =item perl6storm #0021
> 
> make the User::pwent style by-name hash object returns
> the default

RFC 259: Builtins : Make use of hashref context for garrulous builtins
RFC 73: All Perl core functions should return objects

> =item perl6storm #0033
> 
> Should == on strings (wrong type) turn into eq?

RFFC 54: Operators: Polymorphic comparisons
 
> =item perl6storm #0034
> 
> Find an easier way to write the prefix dereffers.  infix
> easier for brain to read for left-to-write stack-based cognitive
> reasons.
> 
> @{ (some_expression_here) }

RFC 134: Alternative array and hash slicing

> =item perl6storm #0035
> 
> Make A->B place A in string context, like => does.
> That way no A()->B naughtiness.

RFC 244: Method calls should not suffer from the action on a distance
 
> =item perl6storm #0036
> 
> Allow
> 
> print $fh[$i] "whatever\n"
> 
> to work. 

RFC 174: Improved parsing and flexibility of indirect object syntax
 
> =item perl6storm #0041
> 
> People don't grok <>.  They think
> 
> while (<>)
> 
> will localize $_, or that <> by itself will assign to it!

RFC 129: Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN
   - covers the "while(<>)" part of the issue

RFC 215: More defaulting to $_
   - covers the "$_ = <>" part of the issue

> =item perl6storm #0046
> 
> make open work on URLs.

RFC 14: Modify open() to support FileObjects and Extensibility
RFC 100: Embed full URI support into Perl

> =item perl6storm #0053
> 
> Make  call readdir() just as  calls readline().

RFC 14: Modify open() to support FileObjects and Extensibility
 
> =item perl6storm #0054
> 
> Add dup() and dup2() style stuff to give legible ways of
> handling &FH and &=FH.

RFC 14: Modify open() to support FileObjects and Extensibility
 
> =item perl6storm #0065
> 
> Make indirect objectable built-ins overloadable/overrideable/inheritable
> by object type.

Working on it already...have an upcoming RFC on embedded objects
 
> =item perl6storm #0067
> 
> Where's ferror()?   Can we raise exceptions on them?
> 
> use io_errors;  # wrong name
> 
> or maybe
> 
> STDOUT->raise_on_error

RFC 14: Modify open() to support FileObjects and Extensibility
   - talks about filehandle methods, of which this could be one

> =item perl6storm #0071
> 
> How do you prototype split?  print?

RFC 174: Improved parsing and flexibility of indirect object syntax
   - covers the print issue

> =item perl6storm #0104
> 
> Look at the deep magic seen in some of the examples in Camel-3's
> OO and tie chapters and in perltootc.  Consider what to canonize
> into a simpler-to-get-at mechanism, just as plum engendered much
> in perl5.

RFC 200: Objects: Revamp tie to support extensibility (Massive tie
changes)
And an upcoming RFC by myself on embedded objects

-Nate

Re: RFC 269 (v1) Perl should not abort when a required file yields a false value

[Nathan Wiger]

> =head1 TITLE
> 
> Perl should not abort when a required file yields a false value

Damian already covered this in RFC 55:  http://dev.perl.org/rfc/55.pod

-Nate

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

[Russ Allbery]

Glenn Linderman <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> Perhaps I don't use those warnings in the same way that you do.  I
>> *very* rarely have undefined value warnings in my programs, and when I
>> do they're usually not actually bugs, just things that require a
>> different way of writing to be -w clean.  So I don't have as high of an
>> opinion of this warning as being particularly important to debugging; I
>> only find it useful in certainly particular circumstances.

> I can't say that I often get the warning, but when I do, I find it
> generally results from a bug.  So something about the way we write code
> is different, I guess.

Most likely.  It caught stuff for me before use strict (generally variable
typos) but with use strict, those warnings tend to be either checking for
keys in aggregate structures when they've not been initialized (which is
mostly just an annoyance) or they're just a symptom of something going
wrong somewhere else entirely and aren't particularly helpful in tracking
down where it's going wrong.

> I find this absolutely amazing.  You've now convinced me you understand
> the arguments I've been making, and the issues I'm concerned
> about... and yet you still hold this opinion.  Certainly we have a
> difference of opinion here.

It's quite possible that I'd have a different opinion if I used it for a
while; I don't know.  I think it's worth trying it with undef first and
writing some code that way and seeing how it works and how hard it is to
debug.

> Russ, I apologize.  I confused you with someone else in this posting.  I
> looked back over your postings, and you, unlike those that seem to just
> hate SQL, have repeatedly expressed interest in using the tristate
> semantics.  I've been trying to keep my nose clean regarding remarks
> like this, but I guess my frustration level finally got the better of
> me...and perhaps partly, I guess I stayed up too late last night and
> probably shouldn't be posting this late tonight either.

No problem; it's easy enough to do.  :)

> Maybe the enlightenment is shed by your earlier remark: you don't find
> the undef warnings to be particularly important to debugging.  So maybe
> that is the reason that you don't see the need to concurrently have both
> sets of semantics available?

That's quite possible.

> Since you don't need the current set of semantics?

The main thing I use undef for is in areas where I'm checking with
defined, which I would assume would continue to work regardless of the
selected semantics of undef.  Having undef propagate would make it useful
in additional areas (or at least I think it would).  From writing language
parsers, I found that it's useful in areas other than SQL to have a
distinguished value that propagates through any arithmetic operation.

> Going back to your first remark about seeing confusion either way, maybe
> explaining the types of confusion that you see with a separate null and
> undef vs the types of confusion that you see with a tristate pragma
> would help me to grasp that logic.

The main thing I'm worried about with undef plus null is that undef is
already very hard to explain and having an additional parallel concept
that behaves slightly differently and that can easily be confused with
undef is worrisome.  The advantage of explaining a tristate pragma is that
with normal undef semantics, most times undef shows up in an arithmetic or
logical operation other than a simple test of true or false, it's
symptomatic of poorly-constructed code; increments are about the only
exception.  So the area that tristate logic changes is not something that
we recommend that people use under normal circumstances.

> And if/when my database needs require the use of multiple different NULL
> values (currently they are not there, multiple NULL values do get talked
> about by relational theorists, and there is some move to put them into
> the SQL standard, but it appears they haven't yet appeared in one) I see
> having multiple "special non-values" (as someone else called them) much
> simpler to extend to the concept of multiple NULL values than the pragma
> approach.

Hm.  Yes, that's a good point.  (At that point, something more like
Quantum::Superpositions may be more what you want.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 83 (v3) Make constants look like variables

[Jeremy Howard]

Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > Good question. I haven't tackled this in RFC 83, because it is a more
> > general question about attribute syntax. We don't really have a good
> > attribute syntax RFC yet, although Nate threw up some ideas a couple of
days
> > ago. Is someone interested in whipping up an RFC that combines Nate's
> > suggestions with clarification of issues such as this?
>
> Nate is! ;-)
>
> I'm on it, should be out today...
>
Excellent! I thought you were in the RFC recovery program--but you couldn't
resist writing  'just one more', could you? ;-)

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

[Glenn Linderman]

Russ Allbery wrote:

use 'strict'  is probably the difference between our code... I tend not to use
it, because I wrote a bunch of code that didn't, initially, before I heard of
it (maybe before it existed?  I started with Perl 4.something), and haven't
gotten it all converted so that it can be used together with strict.  A
project that hasn't yet gotten high enough on my priority list.

> > Going back to your first remark about seeing confusion either way, maybe
> > explaining the types of confusion that you see with a separate null and
> > undef vs the types of confusion that you see with a tristate pragma
> > would help me to grasp that logic.
>
> The main thing I'm worried about with undef plus null is that undef is
> already very hard to explain and having an additional parallel concept
> that behaves slightly differently and that can easily be confused with
> undef is worrisome.

That's an interesting observation.  To me, the concept of undef could be
explained in a paragraph.  But I've been working with SQL & NULL for 15 years
before I heard of Perl and its undef so I had no problem with the concept.

I guess if undef is perceived as hard to understand or explain, then SQL NULL
would be perceived as hard to understand and explain.

To me, SQL NULL is somewhat complex, but understandable, and undef is totally
trivial.

> The advantage of explaining a tristate pragma is that
> with normal undef semantics, most times undef shows up in an arithmetic or
> logical operation other than a simple test of true or false, it's
> symptomatic of poorly-constructed code; increments are about the only
> exception.  So the area that tristate logic changes is not something that
> we recommend that people use under normal circumstances.

I can see that.  Following that logic down the path of my preferred
implementation, though...

It seems to me that if 99% of the perl operators were simply modified such
that SQL NULL in produced SQL NULL out (which is the net effect of most of the
changes to most of the operators, to achieve the desired semantics), that 99%
or more of the time, a programmer that wants to ignore NULL could quite easily
do so... if they aren't introduced in the input, they won't come out the
output, even if the operators are ready, willing, and able to deal with them.
Which is why I can't see why people get so upset about the idea.  undef gets
introduced into their data if they forget to initialize something, and because
some perl operations return it as a failure indication.  But SQL NULL would
only get introduced into their data if they explicitly do so, or use something
like a ported DBI.  And if they use a ported DBI (ported to use NULL rather
than undef, that is), then they probably speak SQL, and SQL NULL would not be
a new concept.

And if we wanted to make it explicitly 100% ignorable, we could have a pragma
to "enable or disable NULL", which would make it impossible to introduce NULL
into the data (make the null keyword a compile error).  But I still think that
when it is turned on, it should be a separate concept.

> > And if/when my database needs require the use of multiple different NULL
> > values (currently they are not there, multiple NULL values do get talked
> > about by relational theorists, and there is some move to put them into
> > the SQL standard, but it appears they haven't yet appeared in one) I see
> > having multiple "special non-values" (as someone else called them) much
> > simpler to extend to the concept of multiple NULL values than the pragma
> > approach.
>
> Hm.  Yes, that's a good point.  (At that point, something more like
> Quantum::Superpositions may be more what you want.)

Is it?  As far as I could read, Quantum::Superpositions defines null as the
empty set.  There was no provision for multiple absence concepts.  Perhaps
that could be added though.

And if Damien Neil is correct, and if Perl overloading is powerful enough, it
may be possible to overload all the operators to deal with a NULL module,
which could have 29 different instantiated sub-object types?  No time until
next week, maybe, to pursue that path further... I've been reluctant to dive
that direction into Perl, until I got my code "strict-ized", but seems like
I'll probably invert that priority.

--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
   -- Will Rogers


___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html

Perl6Storm: Intent to RFC #0000

[Adam Turoff]

I plan to offer a more formal RFC of this idea.

Z.

=item perl6storm #

This:

($a,$b) = ;  

should not drain whole ahndle on known LHS count, to rescue

my($x) = ;

Perl6Storm: Intent to RFC #0022

[Adam Turoff]

I plan to offer a more formal RFC of this idea.

Z.

=item perl6storm #0022

make marshalling easy.  core module?  would this allow for easy
persistence of data structures other than dbm files?
general persistence is hard, right?  can this be an attribute?

Perl6Storm: Intent to RFC #0004

[Adam Turoff]

I plan to offer a more formal RFC of this idea.

Z.

=item perl6storm #0004

Need perl to spit out pod/non-pod, like cc -E.  Pod is too hard to parse.
This would make catpod trivially implemented as a compiler filter.

Perl6Storm: Intent to RFC #0025

[Adam Turoff]

I plan to offer a more formal RFC of this idea.

Z.

=item perl6storm #0025

Make -T the default when operating in a CGI env.  That is, taintmode.
Will this kill us?  Close to it.  Tough.  Insecurity through idiocy
is a problem.  Make them *add* a switch to make it insecure, like
-U, if that's what they mean, to disable tainting instead.

Perl6Storm: Intent to RFC #0026

[Adam Turoff]

I plan to offer a more formal RFC of this idea.

Z.

=item perl6storm #0026

Make CGI programming easier.  Make as first class as
@ARGV and %ENV for CLI progging.

Re: Perl6Storm: Intent to RFC #0000

[Nathan Wiger]

Sounds good. Here's some stuff we had discussed on it:

http://www.mail-archive.com/perl6-language@perl.org/msg03484.html
http://www.mail-archive.com/perl6-language@perl.org/msg03487.html
http://www.mail-archive.com/perl6-language@perl.org/msg03488.html
http://www.mail-archive.com/perl6-language@perl.org/msg03500.html
http://www.mail-archive.com/perl6-language@perl.org/msg03532.html
http://www.mail-archive.com/perl6-language@perl.org/msg03536.html
http://www.mail-archive.com/perl6-language@perl.org/msg03537.html

I believe this ties in with RFC 123 on lazy evaluation as well,
basically just making lazy evaluation the default for functions where it
makes sense to. As one of the emails notes, I was going to RFC something
like this, but never found the time (and still haven't).  :-(

-Nate

Adam Turoff wrote:
> 
> I plan to offer a more formal RFC of this idea.
> 
> Z.
> 
> =item perl6storm #
> 
> This:
> 
> ($a,$b) = ;
> 
> should not drain whole ahndle on known LHS count, to rescue
> 
> my($x) = ;

Perl6Storm: Intent to RFC #0043

[Adam Turoff]

I plan to offer a more formal RFC of this idea.

Z.

=item perl6storm #0043

Write something that spits out module dependencies.  Like makedep.
A tool that sources but doesn't run? a program/module then spits
out %INC might suffice.  Can we autobundle with CPAN tricks?

Perl6Storm: Intent to RFC #0101

[Adam Turoff]

I plan to offer a more formal RFC of this idea.

Z.

=item perl6storm #0101

Just like the "use english" pragma (the modern not-yet-written
version of "use English" module), make something for legible
fileops.

is_readable(file) is really -r(file)

note that these are hard to write now due to -s(FH)/2 style
parsing bugs and prototype issues on handles vs paths.

RFCing perl6storm #0003, #0035, #0050

[Nathan Wiger]

I have an RFC already in the works that addresses these with additions
to C. Hopefully out RSN.

-Nate

=item perl6storm #0003

Make parens "optionally mandatory" on function calls.

use strict 'functions';

=item perl6storm #0035

Make A->B place A in string context, like => does.
That way no A()->B naughtiness.

=item perl6storm #0050

Radical notion: consider removing precedence.
Wrong precedence makes people miserable.

RFC 208 (v4) crypt() default salt

[Perl6 RFC Librarian]

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

=head1 TITLE

crypt() default salt

=head1 VERSION

  Maintainer: Mark Dominus <[EMAIL PROTECTED]>
  Date: 11 Sep 2000
  Last Modified: 23 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 208
  Version: 4
  Status: Frozen

=head1 ABSTRACT

A frequently-asked question is how to generate an appropaite random
salt for password encryption.  I propose that Perl generate the salt
automatically if the salt argument is omitted in the call to crypt().

=head1 DESCRIPTION

At present, crypt() requires two arguments:

 crypt PLAINTEXT,SALT

It then passes these arguments directly to the C library crypt()
function.

When encrypting a new password, the programmer is required to generate
a salt at random:

@letters = ('A' .. 'Z', 'a' .. 'z', '0' .. '9', '/', '.');
$salt = $letters[rand@letters] . $letters[rand@letters];
$passwd = crypt($passwd, $salt);

This is inconvenient and nonportable.  It's also nonobvious: people
frequently ask in the newsgroups how to do it.  I propose that if the
SALT argument is omitted, Perl should generate an appropriate salt
internally and use that.

$passwd = crypt($passwd);# Same as above

On systems where the password format is different, Perl can do the
appropriate thing.

=head1 IMPLEMENTATION

For the standard DES-based crypt, the implementation is
straightforward trivial. Perl already has many functions that take an
optional argument, and the C internals of the random-salt generator
are well-known.

Details will vary for systems using alternative password hashing
schemes.  On some systems, no salt need be generated.  These can be
taken care of with a suitably ifdef'ed section of code if necessary.

If the random number generator has not yet been seeded, Perl should
seed it.  

Michael Schwern has developed a partial demonstration implementation
in pure Perl.  It is available from

 http://www.pobox.com/~schwern/src/RFC-Prototype-0.01.tar.gz

It has been suggested that C should have a private random
number generator, to avoid interfering with the sequence of numbers
produced by rand().  This would significantly complicate the
implementation, and I believe it is probably unnecessary.  See the
REFERENCES for details.

=head1 MIGRATION

C with only one argument is presently a compile-time error,
so there are probably few translation issues.  The meaning of this
program will change:

$" = ', ';
$code = "crypt(@ARGV)";
eval $code;
die $@ if $@;

But I don't think this is anything to worry about---it should fall
into the "other 5%" category.

=head1 REFERENCES

perlfunc manpage for discussion of crypt()

crypt(3)

http://dev.perl.org/archive?35:mss:4500:29:lmemkmdbnocclmnnijmc

Re: IDEA: my() extensions and attribute declarations

[Nathan Wiger]

Piers Cawley wrote:
> 
> By declaring a variable as being one of many types you throw away any
> possible compile time optimizations that may be possible (unless you
> add the restriction that said types have a common interface...)
> 
> Note that a possible syntax for doing what you want could be:
> 
>my Pet $fluffy : isa(any(qw/Dog Cat/));

Something like that works for me.

-Nate

RFC 103 (v3) Fix C<$pkg::$var> precedence issues with parsing of C<::>

[Perl6 RFC Librarian]

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

=head1 TITLE

Fix C<$pkg::$var> precedence issues with parsing of C<::>

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 14 Aug 2000
  Last Modified: 23 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 103
  Version: 3
  Status: Retracted
  Frozen since: v2

=head1 ABSTRACT

Currently, trying to dynamically assign to unnamed classes is very
difficult:

   $pkg::$var = $val; # error
   ${pkg}::$var = $val;   # nope
   ${$pkg::$var} = $val;  # you wish
   ${${pkg}::$var} = $val;# sorry
   ${"${pkg}::$var"} = $val;  # works, but bleeech :-)

The precedence and parsing of the :: operator should be fixed to allow
easy access to anonymous package operations.

=head1 NOTES ON RETRACTION

I don't see any easy way of getting this to work without causing
potentially really hairy problems with precedence. In particular check
out:

http://www.mail-archive.com/perl6-language%40perl.org/msg04058.html

Which is actually a reply to Schwern's post, but that appears to be
gone from the mail archives forever...

=head1 DESCRIPTION

In a perfect world, these should work in Perl 6:

  $var = 'RaiseError';
  $DBI::$var = 1 ;   # $DBI::RaiseError = 1

  $pkg = 'Class';
  $var = 'DEBUG';
  ${${pkg}::$var} = 1;   # $Class::DEBUG = 1

  $subpkg = 'Special';
  $class = $pkg . '::' . $subpkg;
  require $class;# require Class::Special

  $mypkg = 'Some::Package::Name';
  $ret = $mkpkg::do_stuff(@a);   # is &{"${mypkg}::do_stuff"}(@a) now  

Currently, the precedence of :: does not allow these operations. Some of
the above examples may still require additional braces, but they
shouldn't require the types of contortions currently needed.

=head1 IMPLEMENTATION

Unfortunately, I don't have the time to think this part up yet. :-( I
will gladly contribute to the precedence and parsing rules discussions
that will ensue in the future if this RFC is accepted.

=head1 REFERENCES

Programming Perl, 2ed, for the ${"${pkg}::$var"} syntax

RFC 222: Interpolation of method calls

RFC 263 (v2) Add null() keyword and fundamental data type

[Perl6 RFC Librarian]

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

=head1 TITLE

Add null() keyword and fundamental data type

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 19 Sep 2000
  Last Modified: 23 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 263
  Version: 2
  Status: Retracted
  
=head1 ABSTRACT

Currently, Perl has the concept of C, which means that a value is
not defined. One thing it lacks, however, is the concept of C,
which means that a value is known to be unknown or not applicable. These
are two separate concepts.

The absence of a C concept and keyword in Perl makes it more
difficult to interface with relational databases and other medium which
utilize C. Modules such as C must map C to C,
which is an imperfect match.

This RFC proposes a new C keyword and fundamental value for Perl
6. 

=head1 NOTES ON RETRACTION

This was basically universally acknowledged as the Wrong Way to
implement the idea. For more details, see the mail thread starting here:

http://www.mail-archive.com/perl6-language%40perl.org/msg04272.html

The alternative approach of a C pragma was determined to
be much more suitable and Perlish.

=head1 DESCRIPTION

=head2 What is NULL anyways?

The concept of C as opposed to C is sometimes difficult for
people to understand. Here is Glenn Linderman's great explanation,
directly from an email he posted to the list:


There is a difference between "undefined" and "unknown".

SQL NULL, and the resultant tristate operators used in SQL, specifically
is based on NULL representing the "unknown" value.

Perl undefined is a different concept--that of an uninitialized
variable.  This is proven from its earliest versions where the value is
coerced to 0 or '' (specific values) when used (without warnings on).

Some Perl programs & modules (including DBI) attempt to correlate NULL
and undefined, for lack of a better match of concepts (Perl is missing
the concept of NULL, SQL is missing the concept of undefined, but that
doesn't correctly imply that the concepts each language _does_ have are
correlated, or should be).

If you want NULL, RFC it is a new concept.  DBI could then be ported to
Perl 6, and the power of using NULL in its operators (perhaps together
with transactional variables) could make Perl an extremely powerful
database manipulation language and would make the language,
complementary to and augmenting SQL in ways no other language currently
does.

Any OO language with full operator overloading could write
objects/operators that behave like SQL values, and implement tristate
logic for those objects, just like SQL does.  Perhaps you should attempt
that, and RFC the failures.  I would recommend, however, that you not
attempt to use the concept of undefined to implement the concept of
NULL, at least not visibly.


=head2 Why the heck do we care?

As mentioned above, C and  are two different things
altogether. Consider the following two examples:

   undef null
     
   $a = undef;   $a = null;
   $b = 1;   $b = 1;
   $c = $a + b;  $c = $a + $b;

   $c is 1   $c is null

The keyword C means that a value is B. This
means a couple important things, with semantics far different from
C:

   1. Any math or string operation between a null and
  non-null value results in null

   2. No null value is equal to any other null, unlike
  undef

   3. A null value is neither defined nor undefined

To recap: There is no 1:1 mapping between C and . Any
attempt to do so is inaccurate. For more details, please read the
references.

=head2 The new 'null' keyword

The new C keyword can be used anywhere that C can be:

   my $name = null;
   null @array;
   @return = query($amount, $country, null, $time);
   die "Fatal, \$name was unset!" if ( $name == null );

With semantics to represent the RDBMS concept of C. Note that the
last one works because we are simply testing against C. However,
the following code:

   $a = null;
   $b = null;
   print '$a eq $b!' if ($a eq $b);

Would not print anything, since two C values are not equivalent.

=head2 The 'initialize' pragma

The C pragma is introduced to tell Perl what to default your
unitialized values to. By default, it will remain C, same as
currently. However, this code:

   use initialize 'null';   # or "use initialize 'undef'"

   my($a, $b);
   print "Hello world!" if ($a == $b);

Would no longer print out C<"Hello World!">, since the unitialized
values $a and $b would now be set to C, rather than C. This
allows very easy porting of RDBMS-related work. The C
pragma should obey blocks as well:

   use initialize 'null';
   my($a, $b);
   print "Hello world!" if ($a == $b);
   {
   use initialize 'undef';
   my($c, $d);
   print "Hello universe!" if ($c == $d);

   }

The above example would print out "Hello universe!". By obeying blocks,
you can easily embed true S

RFC 275 (v1) Add 'tristate' pragma to allow undef to take on NULL semantics

[Perl6 RFC Librarian]

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

=head1 TITLE

Add 'tristate' pragma to allow undef to take on NULL semantics

=head1 VERSION

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

=head1 ABSTRACT

RFC 263 proposed the introduction of a C keyword for introducting
tristate logic into Perl 6. However, that was abandoned in favor of the
approach specified here, a C pragma.

=head1 DESCRIPTION

The C pragma allows for undef to take on the RDBMS concept of
C, in particular:

   1. Any math or string operation between a NULL and any other
  value results in NULL

   2. No NULL value is equal to any other NULL

   3. A NULL value is neither defined nor undefined

The C pragma is lexically scoped, so that it obeys code
blocks:

   $a = undef;
   $b = 1;
   $c = $a + $b;# 1
   {
  use tristate;
  $d = $a + $b; # undef
   }
   $e = $c + $d;# 1

For more details on theoretical issues, please see the references or RFC
263.

=head1 IMPLEMENTATION

No idea, too burned out.

=head1 MIGRATION

None, unless some dumbass has a custom C module that they
wrote to navigate the tristate area of New York, New Jersey, and
Connecticut. But that should be C anyways.

=head1 REFERENCES

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

http://www.sitelite.nl/mysql/manual_Problems.html#IDX666

http://www.unb.ca/web/transpo/mynet/mtx19.htm#r2

RFC 269 (v2) Perl should not abort when a required file yields a false value

[Perl6 RFC Librarian]

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


=head1 TITLE

Perl should not abort when a required file yields a false value

=head1 VERSION

  Maintainer: Dominus <[EMAIL PROTECTED]>
  Date: 21 Sep 2000
  Last Modified: 23 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 269
  Version: 2
  Status: Withdrawn
  See Also: RFC 55

=head1 STATUS

This proposal is withdrawn because it duplicates RFC 55, "Compilation:
Remove requirement for final true value in require-d and do-ed files"

=head1 ABSTRACT

Modules should not have to end with C<1;>.  It is silly and confusing.

=head1 DESCRIPTION

Modules typically contain subroutine definitions.  A module may
contain initialization code also.  If the initialization code fails,
the module can return a false value to its caller, which aborts the
compilation. 

In Perl 5, a module that contains nothing but subroutine definitions
will return false by default, necessitating a

1;

at the bottom.  If the C<1;> is omitted, Perl emits the error

Foo.pm did not return a true value...

In spite of plenty of documentation, people Frequently Ask what this
error means.  Some languages like to have the compiler emit annoying
messages to announce you forgot to include some pointless code whose
only purpose is to stop the compiler from emitting the annoying
message.  Perl is mostly free of such nonfeatures.  

I propose that this unfeature be dropped entirely.  No useful
functionality is lost.  If a Perl 6 module wants to indicate an
initialization failure by throwing a fatal exception, it can simply
call C.  If the calling module wants to abort when a Cd
file returns a false value, it is free to do that.

The 'module initialization' feature is little-used.  99 the of 102
files in Perl 5.6 lib/*.{pl,pm} end with C<1;>.  AnyDBM_File invokes
'die' explicitly.  The only real exceptions are diagnostics.pm and
timelocal.pl.

=head1 IMPLEMENTATION

'require' should execute code in a file and return the result, as
before, but it should not call Perl_die when the result is false.  

However, see below.

=head1 MIGRATION

In 98% of cases, no translation is necessary.  The first version of
the translator can ignore the issue entirely.  Strategies to cover the
other 2% follow:

Is general, direct source translation of this feature of Perl 5
modules would probably be impossible.

It's tempting to say that the translator should simply translate the
last statement or block in the module from this:

STATEMENT

to this:

unless (do {STATEMENT}) {
  require Carp;
  Carp::croak "... did not return a true value";
}

However, I think that is impractical.  The module might contain code
that looks like this:

if (something()) {
  return $v1;
}

...

$v2;

In this case the 'return $v1' statement would I have to be
translated.  In general, there might be many, many statements that
would need to be translated.  This would look awful.  

I think that if complete coverage is desired, the best choice would be
to introduce a new pragma, which would enable the old behavior.  A
translated module would begin with

package Foo;
use perl5 'require/use semantics'; 

...

When this file was Cd, the pragma would set a flag.  The
C opcode would check the flag after compiling the file,
and would call C as before if the file returned a false
value and if the flag was set.  If Foo Cd any other modules,
the flag would be cleared before loading them, and restored again
afterwards.  (That is, the flag would have file scope.)

=head1 REFERENCES

Perl on-line manuals