Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines

[Michael G Schwern]

CAPS LOCK KEY STUCK  STOP
CANNOT PROGRAM PERL REVERTING TO BASIC  STOP
SEND HELP QUICK  STOP

-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
When faced with desperate circumstances, we must adapt.
- Seven of Nine

Re: RFC 266 (v1) Any scalar can be a hash key

[Michael G Schwern]

On Thu, Sep 21, 2000 at 03:54:27AM -, Perl6 RFC Librarian wrote:
> =head1 IMPLEMENTATION
> 
> Dunno. With my vague understanding of the existing code and hash
> tables in general:

I believe the main reason why hash keys can't be references is because
they're not really scalars.  Internally they're just normal char
strings IIRC, not SVs.  I'm sure at one point there were efficiency
and memory arguments for this, but I don't know if they still hold.

The idea of promoting hash keys to true scalars has been knocked out
before.  I'm sure you can dig up some p5p threads on the subject.


-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
Maybe they hooked you up with one of those ass-making magazines.
-- brian d foy as misheard by Michael G Schwern

Re: RFC 267 (v1) Eliminate dump() function

[Michael G Schwern]

On Thu, Sep 21, 2000 at 03:55:21AM -, Perl6 RFC Librarian wrote:
> Eliminate dump() function

I didn't even know it existed.

-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
Any failure I encounter in life is the fault of android weasels.
-- everything i ever needed to know i learned from goats

Re: RFC 264 (v1) Provide a standard module to simplify the creation of source filters

[Michael G Schwern]

On Wed, Sep 20, 2000 at 04:12:17AM -, Perl6 RFC Librarian wrote:
> Given this level of complexity, it's perhaps not surprising that source
> code filtering is not commonly used.

The both times I've attempted to use Filter::Util::Call, I've wound up
reverting to Filter::Util::Exec and doing something like this:

use Filter::Util::Exec;

sub import {
my($self, $term) = @_;

$term = 'Peterbilt' unless defined $term;

Filter::Util::Exec::filter_add($self, $^X, '-pe', <<"");
warn "Use of '\$1' detected at line \$.\n".
 "Perhaps you meant '$term'?\n" if /(peterbuilt|$term)/i &&
  $term ne \$1;
s/$term/;/g;

}

Filter::Util::Call's way of doing things is just too twisted and
strange.

Anyhow, I guess this is an elaborate "me too".

-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
shitting is a chore
wet glue enters my sphincter
I shall poop no more
-- Schwern

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

[Tom Christiansen]

>No, in that wonderfully consistent Perl documentation, it's "undef" not 
>is only used to refer to (as you pointed out in another post)

>   the null string
>   the null character
>   the null list

>Those use null as an adjective.  This RFC proposes an addition to Perl t

>   the null

>This uses null as a noun, and it has a different meaning than undef.

A null is a null byte, or a null character.  Period.  You are
completely out of your mind if you expect to co-opt an extant term
for this screwed up notion of yours.  I place my faith in Larry 
not to fuck up the language with your insanity.

--tom

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

[Tom Christiansen]

>> In Perl, this is the null string:""
>> In Perl, this is the null character: "\0"
>> In Perl, this is the null list:  ()

>In RFC 263, this is the null:  null

>That's a different word for a different concept.  No conflict, if you
>learn the way the RFC speaks.

Wrong.  Just plain wrong.

>> It's a shame you don't like it, but this is the way we speak.

>What's this we and you business?  I'm a perl user too.

Who can't speak.

>> If you wish to make sense of the documentation, you must learn
>> its language.

>The documentation isn't all that consistent about everything, either.
>Perhaps you, personally, are more so, and if so, perhaps you should help
>rewrite the documentation to make it as perfectly consistent as yourself.

Thank you very much, but I just did that.  It's called Camel-3.

>I allowed that you might want to call it the null string, and I'm allowed
>to read "null string" and think "empty string", and I'm just as right as
>you are.  You must not have a cohesive argument to make, if you resort to
>insults in an attempt to make points.

You haven't heard insults.  Here are insults: you are a stupid idiot.
And I am incredibly glad that within hours, I'm about to spend three solid 
weeks afraid from such a fucked up blathering fool.

--tom

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

[Tom Christiansen]

>> By your "reasoning", we can just add infinitely more things that
>> take twice a few pages to explain.

>You took that to an illogical extreme conclusion.  Clearly you can't add
>everything to the language.  However, it is clear by the set of currently
>submitted RFCs that more people think suggesting additions to Perl is a better
>use of their time than suggesting subtractions.

Bullshit.   

If it takes several pages just to introduce your new, fucked-up
notion of "false", you've done something wrong.  If it then again
takes several pages just to introduce how your new, fucked-up notion
of "false" is different from the existing ones, you've done something
wrong.

Guess what?

You've done something wrong.

>> Perl is already too hard.

>So make it easier.  Where are your RFCs to remove things?

They're right here in my edit buffer.  I will simply explain them
to Larry directly.  You won't even get the chance to waste my time.

Fortunately, I have every reason to believe that Larry will reject
your idiotic notion of false that grew out of a cancerous complexity
in an obscure niche of programming has no business burdening users
with its incredibly lame-ass naming and confusing behavior.

--tom

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

[Glenn Linderman]

Tom Christiansen wrote:

> A null is a null byte, or a null character.  Period.

ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer
to a null byte or null character.  You are not correct, period or otherwise.

> You are
> completely out of your mind if you expect to co-opt an extant term
> for this screwed up notion of yours.

The concept of NULL is not a screwed up notion of mine; it has been used in SQL
since the mid-1970s.  I'm not sure exactly when Perl appeared on the scene, but I
think it is a relative newcomer, compared to SQL.

> I place my faith in Larry
> not to fuck up the language with your insanity.

This problem seems to be in your mind, not mine.  I have logical (albeit
controversial) justification for each statement I have made.  You, in this
discussion, have clearly been motivated by something other than a desire to make
the language more powerful; you have resorted to quarrelsome tautologies instead of
logic, and profanity rather than helpful criticism.  If you have nothing useful to
say, please refrain from saying it.

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



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

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

[Paris Sinclair]

On Thu, 21 Sep 2000, Tom Christiansen wrote:

> A null is a null byte, or a null character.  Period.  You are
> completely out of your mind if you expect to co-opt an extant term
> for this screwed up notion of yours.  I place my faith in Larry 
> not to fuck up the language with your insanity.
> 
> --tom

I've got your null right here...

:0
* ^From: Tom Christiansen
/dev/null

Can't we all just play nice?

Paris Sinclair|4a75737420416e6f74686572
[EMAIL PROTECTED]|205065726c204861636b6572
www.sinclairinternetwork.com

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

[Tom Christiansen]

>Can't we all just play nice?

Apparently not.   Several of us attempted to explain why this didn't
make sense, for many reasons.  GL wouldn't hear any of it, stubbornly
adhering to this notion despite what was said, often completely
ignoring or apparently purposefully misunderstanding the points.
He then started accusing others of insults where none existed.
Screw that.  Since he asked for insults, now he got them.

But it's funny you should mention nulling him out.  He's now in my
killfile.  Blessed be.

--tom

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

[Philip Newton]

On 20 Sep 2000, Russ Allbery wrote:

> About the only piece of code of mine that this would affect are places
> where I use ++ on an undef value, and that's not a bad thing to avoid as a
> matter of style anyway (usually I'm just setting a flag and = 1 would work
> just as well; either that, or it's easy enough to explicitly initialize
> the counter to 0).

Depends. While it is possible to initialise counters in the canonical
"have I seen this before" situation, it's more convenient the way it is at
the moment:

$seen{$word}++;

looks, to me, nicer than

$seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1;

or

if(defined($seen{$word})) { $seen{$word}++ } else { $seen{$word} = 1 }

or similar.

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

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

[Glenn Linderman]

Thanks, Paris, for your intervention, although I fear it was too late.

Well, since Tom claims to have put me in his kill file, he may never see
this.  But for the record...

Tom Christiansen wrote:

> >Can't we all just play nice?
>
> Apparently not.   Several of us attempted to explain why this didn't
> make sense, for many reasons.  GL wouldn't hear any of it, stubbornly
> adhering to this notion despite what was said, often completely
> ignoring or apparently purposefully misunderstanding the points.

It's true that I think that NULL would be an extremely useful concept,
and until there is a cogent argument to the contrary, I will continue to
believe it.  I've been working with databases for 21 years, and with Perl
for 5, and I truly believe NULL would be a useful addition to using Perl
to work with databases.

However, it is not true that I ignored or purposefully misunderstood any
of the points raised.  The record stands for itself in the archive.  I
may not be as brilliant as TC, I may not have understood all the points,
and I may not have as much history with using Perl as TC, but I can
distinguish logical propositions and argumentative posturing.  Here's
Tom's first complete message in the RFC 263 thread for example:


> >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.
>
> No, they aren't.
>
> --tom
>
>
> He then started accusing others of insults where none existed.
> Screw that.  Since he asked for insults, now he got them.

The record is in the archives.  If anyone cares to figure out where the
first insult came from, they can read it.  I'm sure glad Damian called me
on my sniping remark to him before this imbroglio started... so I was
really, really trying to keep my nose clean.  Really, as Damian pointed
out, such bickering is not a profitable use of time.

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



_NetZero Free Internet Access and Email__
   http://www.netzero.net/download/index.html

Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulous builtins

[Bryan C . Warnock]

On Wed, 20 Sep 2000, Damian Conway wrote:
> This RFC proposes the builtin functions that return a large number of
> values in an array context should also detect hashref contexts (see RFC
> 21) and return their data in a kinder, gentler format.

You may want to add a reference to the various existing modules that
provide this type of interface.

 -- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: Beefier prototypes (was Re: Multiple for loop variables)

[Tom Christiansen]

>   > Could the prototype people please report whether Tim Bunce's issues with 
>   > prototypes have been intentionally/adequately addressed?

>I'm not a prototype person (in fact RFC 128 makes it a hanging offence
>to use that confusing word in connection with parameter lists! ;-)
>Could someone please recapitulate Tim's issues?

The long story is here:

http://www.perl.com/pub/language/misc/bunce.html

The short story includes details that involve how to permit

sub fn($$$)

to work with

fn(@foo)

where @foo==3, which won't be known till runtime.

--tom

Re: IDEA: my() extensions and attribute declarations

[Bryan C . Warnock]

On Wed, 20 Sep 2000, Nathan Wiger wrote:
>my int ($x, $y), char $z;   # mix classes
>my int ($x, $y) :64bit, char $z :long;  # and attrs


my (int ($x, $y), char $z); 
my (int ($x, $y) :64bit, char $z :long);


-- 
Bryan C. Warnock
([EMAIL PROTECTED])

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

[Tom Christiansen]

< Russ:

>> About the only piece of code of mine that this would affect are places
>> where I use ++ on an undef value, and that's not a bad thing to avoid as a
>> matter of style anyway (usually I'm just setting a flag and = 1 would work
>> just as well; either that, or it's easy enough to explicitly initialize
>> the counter to 0).

< Philip:

>Depends. While it is possible to initialise counters in the canonical
>"have I seen this before" situation, it's more convenient the way it is at
>the moment:

>$seen{$word}++;

>looks, to me, nicer than

>$seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1;

er, flip that.

>or

>if(defined($seen{$word})) { $seen{$word}++ } else { $seen{$word} = 1 }

>or similar.

In general, if you can get away with a simpler expression, it's better.
For example, 

if ($foo && is_whatnot($foo)) 

is inferior to 

if ($foo) 

just as

if (!$foo && !is_whatnot($foo)) 

is inferior to 

unless ($foo)

"Inferior by what metric?" you ask?  Complexity.  

Larry wrote (in Camel-3) that

...the autoincrement will never warn that you're using undefined values,
because autoincrement is an accepted way to define undefined values.
^^^

So I think you're safe there.

He also wrote:

The C<||> can be used to set defaults despite its origins as a
Boolean operator, since Perl returns the first true value.  Perl
programmers manifest a cavalier attitude with respect to truth,
since the line above would break if, for instance, you tried
to specify a quantity of 0.  But as long as you never want to
set either C<$quality> or C<$quantity> to a false value, the
idiom works great.  There's no point in getting all superstitious
and throwing in calls to C and C all over the
place.  You just have to understand what it's doing.  As long
as it won't accidentally be false, you're fine.

Simple true and simple false are best if your goal is simplicity.
Sometimes you need more than that.  So you write functions.  Or,
if you're into the quirks of using strange magic of occasionally
dubious charm, then through operationally overloaded objects.

--tom

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

[Graham Barr]

On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote:
> Russ Allbery wrote:
> 
> > Why on earth would you want to do this in real code?
> 
> I wouldn't, of course.  This is just a demonstration that I want both
> semantics available concurrently.

If you are not going to use it, why implement it ?

> > I don't believe you actually need both semantics active at the same time;
> 
> I do.  Need might be a slightly stronger word than necessary, but "want" and
> "convenience" sure come strongly to mind... the proposals to switch from one
> set of semantics to another just don't cut it for ease of use.

How can you convince anyoone if you say you would not use it. For any feature
enhancement to perl, unless there is a strong case for how it makes
the labguage easier and better it is just not going to happen.

Graham.

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

[Tom Christiansen]

>How can you convince anyoone if you say you would not use it. For any feature
>enhancement to perl, unless there is a strong case for how it makes
>the labguage easier and better it is just not going to happen.

It's not as though Tim Bunce has been hollering for this, which is a 
bad sign.

--tom

Re: RFC 266 (v1) Any scalar can be a hash key

[Graham Barr]

On Thu, Sep 21, 2000 at 03:38:50AM -0400, Michael G Schwern wrote:
> On Thu, Sep 21, 2000 at 03:54:27AM -, Perl6 RFC Librarian wrote:
> > =head1 IMPLEMENTATION
> > 
> > Dunno. With my vague understanding of the existing code and hash
> > tables in general:
> 
> I believe the main reason why hash keys can't be references is because
> they're not really scalars.  Internally they're just normal char
> strings IIRC, not SVs.

Sure, but that is just implementation detail.

>  I'm sure at one point there were efficiency
> and memory arguments for this, but I don't know if they still hold.

Right. The hash function needs to be fast. If it has to determine
what type of SV it is then maybe call a sub it will be very
much slower.

However, that does not mean that there could not be two different
hash types internally.

No I am not saying that we want to do this, but it should not be impossible.

> The idea of promoting hash keys to true scalars has been knocked out
> before.  I'm sure you can dig up some p5p threads on the subject.

that beacause with the perl5 code base there is only one hash implementation,
so implementing this would have a huge performance hit.

Graham.

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

[Philip Newton]

On Thu, 21 Sep 2000, Tom Christiansen wrote:

> < Philip:
> 
> >$seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1;
> 
> er, flip that.

Er, yes. Thanks.

> Larry wrote (in Camel-3) that
> 
> ...the autoincrement will never warn that you're using undefined values,
> because autoincrement is an accepted way to define undefined values.
> ^^^
> 
> So I think you're safe there.

I'm glad about that -- it's a very convenient feature.

Having $seen{$word}++ turn $seen{$word} to undef is bad, if (undef)++
assumes NULL semantics everywhere, hence "one more than unknown" = "still 
unknown".

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

Re: Beefier prototypes (was Re: Multiple for loop variables)

[Graham Barr]

On Thu, Sep 21, 2000 at 03:38:59AM -0600, Tom Christiansen wrote:
> >   > Could the prototype people please report whether Tim Bunce's issues with 
> >   > prototypes have been intentionally/adequately addressed?
> 
> >I'm not a prototype person (in fact RFC 128 makes it a hanging offence
> >to use that confusing word in connection with parameter lists! ;-)
> >Could someone please recapitulate Tim's issues?
> 
> The long story is here:
> 
> http://www.perl.com/pub/language/misc/bunce.html
> 
> The short story includes details that involve how to permit
> 
> sub fn($$$)
> 
> to work with
> 
> fn(@foo)
> 
> where @foo==3, which won't be known till runtime.

Well there could be some kind of attribute on the sub to allow
runtime instead of compile time checks.

But it would be nice if

  fn(@foo[0..2])

would actually work instead of getting

Not enough arguments for main::abc at - line 2, near "])"

I know why it does not work, but it seems like it should.

Graham.

Re: IDEA: my() extensions and attribute declarations

[Piers Cawley]

Nathan Wiger <[EMAIL PROTECTED]> writes:
> It seems potentially useful to be able to say:
> 
>my Dog, Cat $fluffy;
> 
> As a way to say "$fluffy can be either a Dog or a Cat". Since variables
> are prefixed, anything comma-separated up to the variable is an
> alternate class for that variable:

Eurgh.

sub Pet::type { ref $_[0] }

my Pet $fluffy;
die unless $fluffy->type =~ s/^(?:Dog|Cat)$/;

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/));

   sub Pet::MODIFY_SCALAR_ATTRIBUTES {
  my($package,$target,@attribs) = @_;
  @attribs = $package->SUPER::MODIFY_SCALAR_ATTRIBUTES($target,@attribs);
  my @unhandled;
  for my $attr (@attribs) {
 push(@unhandled, $attr), next unless $attr =~ /^isa\(.*\)/;
 use attributes Assertion => $target,
"invariant(!defined(\^_) || \^_->$attr)";
  }
  return @unhandled;
   }

Note the ad hoc syntax for assertions. If we only had currying already
I'd be looking at turning this into a perl5 module. I might do it
anyway.

Superpositions are rather cool too...

-- 
Piers

Re: RFC 12 (v2) variable usage warnings

[Bart Lateur]

On Wed, 20 Sep 2000 12:30:26 -0600, Tom Christiansen wrote:

>$a = undef;
>
>You have initialized it to undef.

>Solution:
>
>Remove all references from the language to defined and undef.

Quite the reverse.

Simply assume that uninitialized variables in Perl simply don't exist,
that all variables (values) are ininitalized, but some of them to undef.
Therefore the word "initialized", when talking about Perl, is
meaningless.

Replace all occurences of the (sub)word "initialized" with "defined", in
all of the documentation and in all error messages, in particular in
"Use of uninitialized value%s".

Look at what perldiag says about it:

   Use of uninitialized value%s
 (W uninitialized) An undefined value was used as if it were already
 defined. It was interpreted as a "" or a 0, but maybe it was a
 mistake. To suppress this warning assign a defined value to your
 variables.

Look ma. The message talks about "uninitialized". The explanation only
talks about "defined"/"undefined". The message should match the
description.

-- 
Bart.

PERL6STORM - tchrist's brainstorm list for perl6

[Tom Christiansen]

=head1 NAME

perl6storm - tchrist's brainstorm list for perl6

=head1 DESCRIPTION

I'm going away for a long, long time, way past the RFC deadline.
Here is my file of notions I've brainstormed over the last few
weeks.  Some have been covered in other RFCs.  Many haven't.  Most
could use some kicking around for eventual immuration.  When following
up, you should probably start new threads for each numbered perlstorm
notion below.

=over

=item perl6storm #

This:

($a,$b) = ;  

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

my($x) = ;

=item perl6storm #0001

The way that you need to use \z instead of \Z.  Or that 
even with /s, $ doesn't mean that.  Too many programming
errors because of this.

=item perl6storm #0002

This is our only chance to add more defaults to use strict.
What can we can that is sane, safe, and prudent?

=item perl6storm #0003

Make parens "optionally mandatory" on function calls.

use strict 'functions';

This solves once and for all the annoying precedence problems
that have spawned a million bugs since time immemorial, such 
as writing
rand +3
but meaning
rand() + 3

It also obviates the hard-to-read and/or fiaschetti.

Actually, this could go the other way:

no strict 'parenthification';

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

=item perl6storm #0005

Functions with packed data, like gethostbywhatever, should die die die.
They should never take nor return binary.  the netent functions are busted.

=item perl6storm #0006

How can you have

perl --novice

be

perl -MDevel::Novice

yet this propagate to caller's lexical context a use strict and a
use warnings?  Hm...

Should perl have long opts?

=item perl6storm #0007

Warnings on void syscalls.  including implicit ones.

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

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

=item perl6storm #0012

local()izing a my() lexical?  chip wanted this.  annoying
that you can do it on partials:

my @a;
local $a[1];

but not entires:

my @a;
local @a;

=item perl6storm #0013

perldata reads:

   To find out whether a given string is a valid nonzero
   number, it's usually enough to test it against both
   numeric 0 and also lexical "0" (although this will cause
   -w noises).  That's because strings that aren't numbers
   count as 0, just as they do in awk:

   if ($str == 0 && $str ne "0")  {
   warn "That doesn't look like a number";
   }

   That's usually preferable because otherwise you won't
   treat IEEE notations like NaN or Infinity properly.  At
   other times you might prefer to use the POSIX::strtod
   function or a regular expression to check whether data is
   numeric.  See the perlre manpage for details on regular
   expressions.

   warn "has nondigits"if /\D/;
   warn "not a natural number" unless /^\d+$/; # rejects -3
   warn "not an integer"   unless /^-?\d+$/;   # rejects +3
   warn "not an integer"   unless /^[+-]?\d+$/;
   warn "not a decimal number" unless /^-?\d+\.?\d*$/; # rejects .2
   warn "not a decimal number" unless /^-?(?:\d+(?:\.\d*)?|\.\d+)$/;
   warn "not a C float"
   unless /^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/;

shouldn't this be in a module?  people always want this. even
the C core has looks_like_a_number.

use Some_Core_Module
if (has_all_digits(...))
if (is_natural_number(...))
if (is_integer(...))
if (isn't_integer(...)) :-)
if (is_decimal(...))
if (is_float(...))

See Ram:2 for more, where it reads:

If you're on a POSIX system, Perl's supports the C
function.  Its semantics are somewhat cumbersome, so here's a C
wrapper function for more convenient access.  This function takes a string and
returns the number it found, or C for input that isn't a C float.
The C function is a front end to C if you just want
to say, ``Is this a float?''

sub getnum {
use POSIX qw(strtod);
my $str = shift;
$str =~ s/^\s+//;
$str =~ s/\s+$//;
$! = 0;
my($num, $unparsed) = strtod($str);
if (($str eq '') || ($unparsed != 0) || $!) {
return undef;
} else {
return $num;
} 
} 

sub is_numeric { defined &getnum } 


=item perl6storm #0014

make it easy to have an overloaded stringify (q/""/) and comparison
operator (qw/<=> cmp/) without having to say "use overload".

=item perl6storm #0015

merge tie and overloading.  python

Re: PERL6STORM - tchrist's brainstorm list for perl6

[Tom Christiansen]

=item perl6storm #0106

Safe "signals"!  (not syssigs,really)

Re: RFC 168 & 267 regarding builtins...

[Webmaster]

Both RFC 168 & 267 complain about the inability to override builtins. What
if p6 simply require all user defined functions to be called using the &func
syntax, and that builtins require the bareword syntax? This way any builtin
could be overridden and it would be immediately recognizable as an
overridden version. By implementing it this way, one could also assume that
the original could be 'inherited', by simply calling the builtin (i.e.,
C - and call it
using C<&ord($str)>).
Grant M.
[EMAIL PROTECTED]

scalars vis-a-vis non-scalars

[Ed Mills]

These would be perlish, nice, terse, succint, and economical:

  my ($a, $b, $c) = 0;

  @h(@colours)='red';

  ($i, $i, $k) += 2;

   @nums = 10 * @nums;

.
.
.

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: scalars vis-a-vis non-scalars

[Jeremy Howard]

Ed Mills wrote:
> These would be perlish, nice, terse, succint, and economical:
> 
<...>
> 
>   ($i, $i, $k) += 2;
> 
>@nums = 10 * @nums;
> 
These are both covered by RFC 82.

Re: RFC 267 (v1) Eliminate dump() function

[Randal L. Schwartz]

> "Michael" == Michael G Schwern <[EMAIL PROTECTED]> writes:

Michael> On Thu, Sep 21, 2000 at 03:55:21AM -, Perl6 RFC Librarian wrote:
>> Eliminate dump() function

Michael> I didn't even know it existed.

I do, every time I forget to hit the shift key around certain invocations
of Data::Dumper and then wonder why my program is core dumping.

Doh!

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[John Porter]

Glenn Linderman wrote:
> 
> If they are the same, then you can't tell the different between a variable
> that is yet uninitialized, and one that has been read in from the database,
> containing a NULL.  In my mind, that is horribly confusing.

Since this is a theoretical argument -- as evidenced by the fact
that you have never actually had a situation where this lack of
distinction was really a problem -- I believe it's time for you
to stop wasting everyone's time on it.  Thanks.

-- 
John Porter

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

[John Porter]

Glenn Linderman wrote:
> ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer
> to a null byte or null character.  

Now, that's not accurate either.  "NUL" is simply a normalized form of "null",
because all the ASCII special characters have three upper-case letter names.
There is no doubt that the ASCII guys meant "null" by this.

-- 
John Porter

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

[Tom Christiansen]

>Now, that's not accurate either.  "NUL" is simply a normalized form of "null",
>because all the ASCII special characters have three upper-case letter names.
>There is no doubt that the ASCII guys meant "null" by this.

All other matters aside, kindly consider this simple one: If ever
you thought homophones were bad, imagine then how to rely upon
nothing more than mere case distinction, an ancillary artifact of
our system of writing, in two distinct terms whose usages are not
radically different from each other but whose meanings most certainly
are, is an endeavour virtually guaranteed to be frequently misheard
and thus misconstrued when those terms are used in spoken discourse--as
they inevitably shall be.

--tom

RE: PERL6STORM - tchrist's brainstorm list for perl6

[Fisher Mark]

> =item perl6storm #0064
> 
> Do something about microsoft's CRLF abomination.

I think for the case of Microsoft C++ used for the Win32 port, everyone
would be happy if Perl's sysopen, sysread, etc. did not require binmode.
Unfortunately, Microsoft made the decision very early on in its C/C++
development to make open, read, etc. do CRLF/NL conversions.  To do this I
think that you need to substitute the Win32 API calls like OpenFile for the
calls to open, read, etc.  Unfortunately, I'm too backed up right now to
even come close to making this change.

Mark Leighton FisherThomson Consumer Electronics
[EMAIL PROTECTED] Indianapolis, IN, USA
"Display some adaptability."  -- Doug Shaftoe, _Cryptonomicon_

Re: RFC 12 (v2) variable usage warnings

[Dave Storrs]

On Wed, 20 Sep 2000, Steve Fink wrote:

> 1 my ($x, $y, $z);
> 2 $z = 1;
> 3 my $logfile = "/tmp/log";
> 4 $x = 1 if cond();
> 5 print $x+$y;
> 6 undef $z;
> 7 print $z;
> 
> --> use of uninitialized variable $y in line 5 (compile time)
> --> possible use of uninitialized variable $x in line 5 (compile time)
> --> variable $logfile defined in line 3 but never used (compile time)
> --> use of undefined value in line 7 (run time)


Couldn't the error on line 7 be detected at compile time as well?
After all, there is no execution path which will result in $z having a
defined value.

Dave

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

[Buddha Buck]

At 02:39 AM 9/21/00 -0700, Glenn Linderman wrote:
>Thanks, Paris, for your intervention, although I fear it was too late.
>
>Well, since Tom claims to have put me in his kill file, he may never see
>this.  But for the record...
>
>Tom Christiansen wrote:
>
> > >Can't we all just play nice?
> >
> > Apparently not.   Several of us attempted to explain why this didn't
> > make sense, for many reasons.  GL wouldn't hear any of it, stubbornly
> > adhering to this notion despite what was said, often completely
> > ignoring or apparently purposefully misunderstanding the points.
>
>It's true that I think that NULL would be an extremely useful concept,
>and until there is a cogent argument to the contrary, I will continue to
>believe it.  I've been working with databases for 21 years, and with Perl
>for 5, and I truly believe NULL would be a useful addition to using Perl
>to work with databases.

Ok, let's see if I can make some sense of this...

You want a singleton scalar datatype in addition to the exising scalar 
datatypes of strings, numbers, references, filehandles, and undef that 
represents an unknown value, similar in semantics to the SQL notion of "NULL".

I'm going to call this prototypical datatype/value "unknown", in order to 
represent its meaning in a more perlish way, as well as to avoid the 
overloaded semantics of NULL (and it's related near-homonyms: SQL's unknown 
NULL, C's NULL invalid pointer, Lisp's NIL, ASCII's NUL, the null string, 
the null list, etc).  Calling anything NULL these days is likely to be 
confusing, so I'll avoid it.

This doesn't matter as far as database work goes because DBI can convert 
between SQL NULL and perl unknown just as easily as it can convert between 
SQL NULL and perl undef.

I just reread RFC 263, and I do have some unanswered questions.  How 
pervasive is this "unknown" value?  If $a is unknown, what about $a

Given:

$a = unknown;
print "\$a is ", ($a ? "true" : "false"), "\n";

What should print?

I think the example of:

   die "Fatal, \$name is unset!" if ($name == null);

is flawed.  It will never die, because as you said, two unknown values 
won't compare as equal.  Besides, the test would try to convert both $name 
and null to numbers before doing the numerical comparison, so it would 
depend on what the numerical value of unknown is.  You really need a 
"known()" built-in to go with this, such that known($a) is true if $a is 
NOT unknown.

What gets me is that the implementation of this would require virtually 
every operator, function, etc in core perl to be special-cased to deal with 
the unknown value, yet the RFC makes no mention of this.

With undef, it's simply a matter of having the internal representation of 
undef return 0 or "" when asked for a numerical or string value.  This 
makes most things deal with undef nicely -- even booleans.  With unknown, 
since it is specifically designed to propagate, everything would have to 
deal with unknown values, not just integers, or strings,  or booleans.

Importantly, unless you decide something arbitrary like "unknown is false" 
like the way that it was decided that "undef is false", then you throw out 
the law of excluded middle (every expression is either true or false), and 
make things like the ?:, ||, or && operators go all wiggly (not to mention 
if, while, unless, and so forth).  And if you do arbitrarily say "unknown 
is false", how do you deal with the cases where you want to say "I don't 
know if it's true or false"?

SQL gets away with this by saying that boolean contexts require a boolean 
value, which you get by using a relational operator.  People don't go "IF 
variable THEN..." unless they know that variable will be boolean -- and 
can't be NULL.  And they then decided that using a relational operator on 
NULL will always yield FALSE.  That works for them.

But that's not Perl.  Perl programmers like functions that return a useful 
but true value on success, or undef on failure, and are quite comfortable 
going:

$var = f();
if ($var) { g($var) };   # f was a success

That won't work if $var can end up being unknown.  Worse, fixing it by saying

if (defined($var)) { g($var) };

doesn't help, because the RFC says that defined(unknown) is unknown!

Your unknown seems to be very special-case for doing SQL-based DB work.  In 
all my time programming it, I can't remember wanting it.  It doesn't seem 
to integrate with the rest of Perl all that well, requiring massive changes 
under the hood to integrate it and the potential for messing up lots of 
long-standing Perl idioms, for a relatively small benefit.

Damian mentioned that his Q::S package and RFC would/could provide 
something with similar semantics, and his RFC would also likely result in 
massive changes under the hood, but it also provides a large generally 
useful functionality (and in CONSTANT TIME, too ;-).  It is unclear as of 
yet if the benefit of Q::S will outweigh the probably cost of Q::S.  Can 
you make as strong a case 

Re: RFC 12 (v2) variable usage warnings

[Dave Storrs]

On Wed, 20 Sep 2000, Eric Roode wrote:

> foo();
> print $x;
> 
> Generate a warning, or not?  Which one? Remember, foo() may initialize $x.


My suggest (FWIW) would be that, if there is no execution path
which leads to $x being defined in the second line, then a "Use of
uninit'd variable $x" warning should be thrown at compile time.  If there
is at least one path that will result in $x being defined AND at least one
path that will result in it being undefined, the compile-time warning
could be something like "Possible use of undefined variable $x" or "Not
all execution paths leave $x defined".

Dave

Re: RFC 168 & 267 regarding builtins...

[John Porter]

Webmaster wrote:
> Both RFC 168 & 267 complain about the inability to override builtins. What
> if p6 simply require all user defined functions to be called using the &func
> syntax, and that builtins require the bareword syntax? 

Uh, how does that result in overridability? 
Sounds to me more like a barrier to it.


> This way any builtin
> could be overridden and it would be immediately recognizable as an
> overridden version.

Again, that's kinda counter to the idea of transparency, of which
overriding is a form.


> By implementing it this way, one could also assume that
> the original could be 'inherited', by simply calling the builtin (i.e.,
> C - and call it
> using C<&ord($str)>).

That's what namespaces are for, e.g. CORE::.

  sub ord { my $val = shift; lc($val); return CORE::ord( val ); }

-- 
John Porter

We're building the house of the future together.

Re: RFC 12 (v3) variable usage warnings

[Eric Roode]

Steve Fink, via the Perl6 Librarian, wrote:
>=head2 EXAMPLE
>
>1 my ($x, $y, $z, $r);
>2 $z = 1;
>3 f(\$r);
>4 my $logfile = "/tmp/log";
>5 $x = 1 if cond();
>6 print $x+$y;
>7 undef $z;
>8 print $z;
>
[...]
>No warning is issued for C<$r> because any variable whose reference is
>taken may be used and/or assign to through the reference.

Perl is not C.  Perl passes parameters to subroutines by reference.
Example:
sub initialize_to_seven
{
$_ = 7  foreach @_;
}

my ($a, $b, $c);
initialize_to_seven ($a, $b, $c);
print "$a, $b, $c\n";


 --
 Eric J. Roode,  [EMAIL PROTECTED]   print  scalar  reverse  sort
 Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
 Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Eric Roode wrote:
> 
> Steve Fink, via the Perl6 Librarian, wrote:
> >=head2 EXAMPLE
> >
> >1 my ($x, $y, $z, $r);
> >2 $z = 1;
> >3 f(\$r);
> >4 my $logfile = "/tmp/log";
> >5 $x = 1 if cond();
> >6 print $x+$y;
> >7 undef $z;
> >8 print $z;
> >
> [...]
> >No warning is issued for C<$r> because any variable whose reference is
> >taken may be used and/or assign to through the reference.
> 
> Perl is not C.  Perl passes parameters to subroutines by reference.
> Example:
> sub initialize_to_seven
> {
> $_ = 7  foreach @_;
> }
> 
> my ($a, $b, $c);
> initialize_to_seven ($a, $b, $c);
> print "$a, $b, $c\n";

Right. Thank you.

Lines 2 & 3 should be combined to $z = \$r (I just wanted to take a
reference in something besides void context!), and passing a variable to
a function should be treated as both a use and a definition.

Re: RFC 267 (v1) Eliminate dump() function

[Bart Lateur]

On 21 Sep 2000 03:55:21 -, Perl6 RFC Librarian wrote:

>Eliminate dump() function
>Get rid of it completely.

I think that, for the rare occasions people want this functionality, one
of the many O (B) modules should offer it, at least in spirit.

-- 
Bart.

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Michael Fowler wrote:
> 
> Ok, at this point I'm trying to clear up misunderstandings.  I believe you
> know where I stand with relation to your RFC.

Thanks, you caught several of my mistakes.

> 
> On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
> > Michael Fowler wrote:
> 
> > > Except for the line number reported, which is the important part.
> >
> > Oh. Certainly you'll get the line number. My description didn't include
> > it because it didn't seem to aid to the understanding. I have it in the
> > examples that I added to the RFC.
> >
> > I suppose it could even give both line numbers for declared variables:
> > "use at line 7 of uninitialized variable declared at line 3."
> 
> Yes, you could do that, but it wouldn't catch this problem.
> 
> The example code:
> 
> $foobal = 3;# This $foobal is an intentional typo.
> if (@ARGV) { $foobar = @ARGV }
> print $foobar;
> 
> I want perl to tell me that $foobal, declared on line 1, was never used.
> You want perl to tell me that $foobar, used on line 3, and declared on line
> 1 (!), was used uninitialized.  I'm going to assume you didn't mean perl
> should do code analysis to see exactly where I first misspelled the
> variable.  If it could, great!  Somehow I doubt we're going to go there,
> though.

I don't think of an assignment to a global as a declaration. Only C is a declaration. I need to rewrite the RFC to pertain to both
lexicals and globals. I think I may have to leave current behavior
unchanged (it only considers globals), but add the simple flow analysis
for lexicals.

Typos in uses or assignments would then be caught by existing
mechanisms, because they wouldn't be declared lexical. Typos in
declarations would be caught by "use of uninitialized value", as well as
(probably) the existing mechanisms for the uses and assignments of the
correctly spelled variable.

So I guess I finally get what you've been trying to tell me: for typos,
the existing mechanisms are sufficient.

For lexicals, a use without a declaration makes no sense, because
variables default to global (non-lexical). A use without an
initialization is of arguable utility, because your defined() tests may
already be intended to check for that case, so you'd really rather that
not be a warning. Do I have that right? Then perhaps the warning
*should* be on by default, but suppressed if defined() is ever called on
the variable? That would still warn unnecessarily on

my $x;
...
$y = $x;
...
if (defined($y)) ...

Ugh. I'll have to think about that some more.

Declaring a (lexical) variable without using it still seems like a
useful addition; it's nearly the same as the existing "used once"
warning. And I know it would be useful in my code, because it'll let me
find obsolete local variables in my subroutines.

I'm still wondering if it would be useful to heuristically warn if a
global's value is never used, ignoring possible symbolic references,
eval""s, etc. It might be a useful incremental improvement over the
current use strict 'vars' analysis. But the current analysis already
gives me spurious warnings at times, and this would increase their
frequency.

> Yes, I realize that.  But more often than not the variables are used
> undefined to indicate a certain state, and you want me to either insert a
> "no warnings 'whatever'", or initialize all of those variables to undef
> explicitly.  I'm saying I want the code to work the same, because perl
> already tells me about the use of uninitialized values, and my having used a
> variable only once.
> 
> In fact, I don't want it to mention I've used it only once when I use use
> strict and declare my variables; strict catches my misspellings, and at
> compile-time, no less.

Got it. I think.

Re: PERL6STORM - tchrist's brainstorm list for perl6

[Charles Lane]

Tom Christiansen <[EMAIL PROTECTED]>  wrote:

>=item perl6storm #0016
>
>object as scope/namespace?  see python.  it's danged clean
>there in that you can now implement safe trivially.
>don't have to keep inventing crazy overloads.
>

Yes, this would be great!

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

One combination of #16 and #25 that would be useful is a way to turn
on tainting in a Safe partition (i.e, a trusted 'driver' running
suspect code -T in Safe::).
--
 Drexel University   \V--Chuck Lane
==]-->*<---[===
 (215) 895-1545 _/ \  Particle Physics
FAX: (215) 895-5934 /\ /~~~[EMAIL PROTECTED]

Re: RFC 12 (v3) variable usage warnings

[Michael Fowler]

On Thu, Sep 21, 2000 at 10:59:19AM -0700, Steve Fink wrote:
> For lexicals, a use without a declaration makes no sense, because
> variables default to global (non-lexical).  A use without an
> initialization is of arguable utility, because your defined() tests may
> already be intended to check for that case, so you'd really rather that
> not be a warning. Do I have that right?

Yep.


> my $x;
> ...
> $y = $x;
> ...
> if (defined($y)) ...
> 
> Ugh. I'll have to think about that some more.

I'm usually pretty careful myself, saying something like:

$y = defined($x) ? $x : undef;

or something equally useless (but I only notice now how useless it is).  Use
of uninitialized value warnings are so annoying now that giving them more
often is just going to annoy more people.


> Declaring a (lexical) variable without using it still seems like a
> useful addition; it's nearly the same as the existing "used once"
> warning. And I know it would be useful in my code, because it'll let me
> find obsolete local variables in my subroutines.
>
> I'm still wondering if it would be useful to heuristically warn if a
> global's value is never used, ignoring possible symbolic references,
> eval""s, etc. It might be a useful incremental improvement over the
> current use strict 'vars' analysis. But the current analysis already
> gives me spurious warnings at times, and this would increase their
> frequency.

Well, sure, if the check for a use ignores conditionals, it could be very
useful.  Isn't your whole point, though, to warn when the user uses a value,
in any way, that has never been initialized?  That's not quite the same
thing.


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

Re: RFC 208 (v2) crypt() default salt

[Mark-Jason Dominus]

Bart Lateur:
> >If there are no objections, I will freeze this in twenty-four hours.
> 
> Oh, I have a small one: I feel that this pseudo-random salt should NOT
> affect the standard random generator. I'll clarify: by default, if you
> feed the pseudo-random generator with a certain number, you'll get the
> same sequence of output numbers, every single time. There are
> applications for this. I think that any call to crypt() should NEVER
> change this sequence of numbers, in particular, it should not skip a
> number every time crypt() is called with one parameter.
>
> Therefore, crypt() should have it's own pseudo-random generator. A
> simple task, really: same code, but a different seed variable.

I had considered this for the original RFC, but I decided against it.

To implement it, Perl would have to have its own built-in random
number generator, because there is no way to save and restore the old
state of rand() (for example).  It would substantially complicate the
code.

And the problem you describe is not really a problem.  There has never
been any guarantee that a program would produce the same sequence of
random numbers after a change to the Perl binary.  More recent
versions of Perl use random() or drand48() if they are available,
instead of rand().  A program run under an old version of Perl and
then a newer version that used random() instead of rand() would
generate a different sequence of random numbers depending on which
version of Perl was running it, even if the seed was the same.  This
has never been an issue in the past, so I did not consider it
important.

I will add a note aboput this to the RFC.  If there are no other
comments, I will freeze it in 24 hours.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Daniel Chetlin wrote:
> 
> On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> > % perl -le '$x = 3; eval "\$x++"'
> > (no warning issued)
> 
>   [~] $ perl -wle'$x = 3; eval "\$x++"'
>   Name "main::x" used only once: possible typo at -e line 1.

Doh! Thanks.

Re: RFC 267 (v1) Eliminate dump() function

[Uri Guttman]

> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:

  BL> On 21 Sep 2000 03:55:21 -, Perl6 RFC Librarian wrote:
  >> Eliminate dump() function
  >> Get rid of it completely.

  BL> I think that, for the rare occasions people want this functionality, one
  BL> of the many O (B) modules should offer it, at least in spirit.

one use of a dump type of thing (if it could be made to work) is for the
Perl without perl idea that schwern asked about. this would then be a
form of perlcc without paying for it. i agree that it should be a module
that can be loaded to create a preloaded binary image which can be run
directly.

but dump isn't the way to go as it is broken, you need a flaky undump
program (from emacs), it is not portable, etc.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: RFC 208 (v2) crypt() default salt

[Andy Dougherty]

On Thu, 21 Sep 2000, Mark-Jason Dominus wrote:

> And the problem you describe is not really a problem.  There has never
> been any guarantee that a program would produce the same sequence of
> random numbers after a change to the Perl binary.
> random numbers after a change to the Perl binary.  More recent
> versions of Perl use random() or drand48() if they are available,

Well, there effectively was such a guarantee for perl1.000 ..
perl5.005_03.  The drand48() change went in with 5.6.0. This was actually
a very big issue for me.  I put loud warnings into perldelta.pod and
Jarkko and I put hooks into Configure to enable users to preserve the old
pre-5.6.0 behavior if necessary.

Further, we might eventually want to include our own PRNG into perl6
anyway, if only to work around the really lousy one commonly encountered
on Win32.

Still, even for me, I have never encountered a case where I wanted to
maintain the same rand() sequence and also use a one-arg crypt().

> I will add a note aboput this to the RFC.  If there are no other
> comments, I will freeze it in 24 hours.

I agree this is a non-issue for this RFC.[*]

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


[*] I'm assuming we'll leave the salt example in the documentation, and
that anyone sophisticated enough to rely on getting repeatable values from
rand() can also use the example from perlfunc.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Dave Storrs wrote:
> 
> On Wed, 20 Sep 2000, Eric Roode wrote:
> 
> > foo();
> > print $x;
> >
> > Generate a warning, or not?  Which one? Remember, foo() may initialize $x.
> 
> My suggest (FWIW) would be that, if there is no execution path
> which leads to $x being defined in the second line, then a "Use of
> uninit'd variable $x" warning should be thrown at compile time.  If there
> is at least one path that will result in $x being defined AND at least one
> path that will result in it being undefined, the compile-time warning
> could be something like "Possible use of undefined variable $x" or "Not
> all execution paths leave $x defined".

Makes sense. Just have to be careful to describe all this stuff without
mixing together initialization vs definedness, globals vs lexicals, flow
control analysis vs counting occurrences, compile time vs run time, and
definite problems vs possible problems. Makes my head hurt.

Re: RFC 12 (v2) variable usage warnings

[Eric Roode]

Allow me to throw another log on the fire:

my $x;
if (something)
{
$x = 1;
}
my $y = $x;

This would give a compile-time warning under your RFC, warning the
user of a possibly uninitialized $x. Okay. Next:

my $x;
if (something)
{
$x = 1;
}
else
{
$x = 2;
}
my $y = $x;

Would this give the same warning? Would it notice that $x is set
in both branches of the condition?
Worse:

my $x;
if (something)
{
$x = 1;
}
if (!something)
{
$x = 2;
}
my $y = $x;

I presume this would generate a warning under your RFC, right?
Since I would guess the compiler shouldn't be required to notice
that one condition is the inverse of the other?
I'm not sure I like the above construct not behaving identically
to the second case (if...else...) above...

Moving on:

my $x;
if (thing1)
{
$x = 1;
}
elsif (thing2)
{
$x = 2;
}
elsif (thing3)
{
$x = 3;
}
else
{
$x = 4;
}
my $y = $x;

Warnings, or no?

How about:

my ($x, $i);
for ($i=0; $i<10; $i++)
{
$x .= $i;
}
my $y = $x;

Now, I can look at that and see that $x will be '0123456789', but
the compiler can't be expected (imho) to know whether the loop
condition will ever execute, so under your RFC it will generate a
"possibly uninitialized" warning, right?

 --
 Eric J. Roode,  [EMAIL PROTECTED]   print  scalar  reverse  sort
 Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
 Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';

Re: RFC 208 (v2) crypt() default salt

[Bart Lateur]

On Thu, 21 Sep 2000 15:37:36 -0400 (EDT), Andy Dougherty wrote:

>Still, even for me, I have never encountered a case where I wanted to
>maintain the same rand() sequence and also use a one-arg crypt().
>
>> I will add a note aboput this to the RFC.  If there are no other
>> comments, I will freeze it in 24 hours.
>
>I agree this is a non-issue for this RFC.[*]

Me too, actually. I do think that in the case that crypt() in lazy mode
also uses the same rand() generator as the rest of perl, then the
documentation in perlfunc should mention it.

p.s. how hard can coding a dedicated pseudo-random number generator be?
It's not as if the randomness should be that exceptional, since it only
serves to pick a sequence of two letters (usually).

This code snippet is the whole PRNG, the family known as LCG (see
):

$seed = (a * $seed + c) % m;  # a, c, m are constants

$seed, an integer, is also the output of the generator; divide by m to
get a value between 0 (incl) and 1 (excl).

-- 
Bart.

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

[Glenn Linderman]

Philip Newton wrote:

> Having $seen{$word}++ turn $seen{$word} to undef is bad, if (undef)++
> assumes NULL semantics everywhere, hence "one more than unknown" = "still
> unknown".

Right.  Applying NULL semantics to undef would be bad.  The counterproposals to
RFC 263, along the lines of "use tristate", seem to overlook this sort of
situation.  They also overlook the beneficial debugging warnings that would be
lost for inappropriate use of uninitialized variables that would be lost if you
use undef for NULL.

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



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

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

[Glenn Linderman]

Graham Barr wrote:

> On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote:
> > Russ Allbery wrote:
> >
> > > Why on earth would you want to do this in real code?
> >
> > I wouldn't, of course.  This is just a demonstration that I want both
> > semantics available concurrently.
>
> If you are not going to use it, why implement it ?

I would use the feature; not the particular lines and sequence of code above.

> > > I don't believe you actually need both semantics active at the same time;
> >
> > I do.  Need might be a slightly stronger word than necessary, but "want" and
> > "convenience" sure come strongly to mind... the proposals to switch from one
> > set of semantics to another just don't cut it for ease of use.
>
> How can you convince anyoone if you say you would not use it. For any feature
> enhancement to perl, unless there is a strong case for how it makes
> the labguage easier and better it is just not going to happen.

There is certainly lots of room for multiple interpretations of English language
statements.

The purpose of writing the code sequence was to demonstrate that I want both
semantics available concurrently, not to be, in and of itself, a useful code
sequence.  I interpreted Russ' question as one pertaining to the particular code
sequence itself--why would I want to do that code sequence--and I wouldn't.  What
on earth would I do with all those repititious "true"s?  But the code sequence
does illustrate the coexistance of both undef and NULL semantics in the same code
block, which was its intention.  It tried to be somewhat complete about exercising
different aspects of the semantics of both data values, to avoid rebuttals of
partial solutions that are not satisfactory.

Now you are twisting my words to say I meant I wouldn't use the whole concept.  I
wouldn't be spending the time answering all these EMails if I wouldn't use the
whole concept, and I think you know that, so pardon my use of the word "twisting".

Here is a code sequence that is less demonstrative of the complete sets of
semantics for the two concepts, undef, and null, but is more likely to useful in
real code.  It was, indeed, taken from real code, and modified only slightly.  It
uses DBI, which today returns undef in lieu of NULL, but in writing this sample,
I'm assuming that DBI has been ported or wrapped to return the RFC 263 (v1)
concept of NULL for SQL NULL, and that undef semantics are unchanged.

# $sth is a DBI statement handle when we get here.
my $i = 0;
$display->header($sth, \*STDOUT);
while (my $rowref = $sth->fetchrow_arrayref()) {
 $i++;
 push ( @lastres, [ @$rowref ] );
 if ( $opt{'--expandcr'} )
 { foreach ( @{$lastres[$#lastres]} )
   { s/\r/\n/g;   # note this line
 print;
   }
 }
 $display->row($lastres[$#lastres]);
}
$display->trailer($i);

my $rows = $i;
print "[$rows row" . ($rows==1 ? "" : "s") . " affected]\n";

The line with the note currently requires an "if defined $_" conditional, because
possible NULL values come back as undef, and warnings result.  The purpose of the
code is to display data retrieve from a statement and, if the --expandcr option is
specified, preprocess that data before displaying it, changing \r to \n so it
displays correctly on Windoze.

This is a small example, with small ramifications and a one phrase workaround...
just an illustration of the kind of problem solved by using NULL semantics.  But
in using DBI, I find I have to scatter distracting "if defined" and "unless
defined" phrases all over the place to avoid warnings.  With RFC 263, processing
of NULL would happen correctly automatically, without the "if defined" phrases.
And yet, I'd still get nice warnings if I attempted to misuse a variable
containing undef (the initialization default value, as in perl right now).

I hope this small illustration demonstrates the differences in semantics that is
desired, and why they are useful.  When doing more serious data manipulation the
ratio and complexity of "if defined" phrases goes up.

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

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

[Glenn Linderman]

John Porter wrote:

> Glenn Linderman wrote:
> >
> > If they are the same, then you can't tell the different between a variable
> > that is yet uninitialized, and one that has been read in from the database,
> > containing a NULL.  In my mind, that is horribly confusing.
>
> Since this is a theoretical argument -- as evidenced by the fact
> that you have never actually had a situation where this lack of
> distinction was really a problem -- I believe it's time for you
> to stop wasting everyone's time on it.  Thanks.

Not theoretical.  Sample real code posted just earlier, in response to Graham
Barr's comments.

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



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

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

[Glenn Linderman]

Buddha Buck wrote:

> Ok, let's see if I can make some sense of this...

Thanks for trying.  I think you have.

> You want a singleton scalar datatype in addition to the exising scalar
> datatypes of strings, numbers, references, filehandles, and undef that
> represents an unknown value, similar in semantics to the SQL notion of "NULL".
>
> I'm going to call this prototypical datatype/value "unknown", in order to
> represent its meaning in a more perlish way, as well as to avoid the
> overloaded semantics of NULL (and it's related near-homonyms: SQL's unknown
> NULL, C's NULL invalid pointer, Lisp's NIL, ASCII's NUL, the null string,
> the null list, etc).  Calling anything NULL these days is likely to be
> confusing, so I'll avoid it.

Correct description; I don't really care what it's called; the concept is what is
important.

> This doesn't matter as far as database work goes because DBI can convert
> between SQL NULL and perl unknown just as easily as it can convert between
> SQL NULL and perl undef.

Correct.

> I just reread RFC 263, and I do have some unanswered questions.  How
> pervasive is this "unknown" value?  If $a is unknown, what about $a
>
> Given:
>
> $a = unknown;
> print "\$a is ", ($a ? "true" : "false"), "\n";
>
> What should print?

Well, that's an interesting question, and gives me an inspiration.  A "ternary"
operator is nicely useful with a binary logic system.  It would seem that a
"quatenary" operator would be more useful with a ternary logic system.  Yet SQL
suffers along with binary operators and a ternary logic system.  Buddha, I think
you've hit the nail on the head about why so many people find SQL NULL so hard to
deal with.

So first, I'll answer your question as stated, and then I'll exposulate on the
inspiration above.

For your example, "false" should print.  This is because $a is not true, so the
"true" branch should not be taken, so the else brach is taken instead.  However,
the text printed is misleading, because the value isn't false, but unknown.  The
text should be changed to "not true", or "false or unknown", to be useful in a
ternary logic system.

The exposition on the inspiration:  The basic problem that results from ternary
logic is that there are three possible results: true, false, and unknown.
Structured programming based on binary logic has given us operations that consider
only two possible results, true and false, that being all there is in binary
systems.

So the basic if/then/else construct that perl, SQL, and most other programming
languages have, and the ternary operator, really don't allow simple expression of
conditionals when using a ternary logic system.

So one could extend the logic programming construct, say with "otherwise" (I
hesitate to reuse "unknown" for both the data value and the keyword), resulting in

if ( ternary_condition )
# then
{ # true part
}
else
{ # false part
}
otherwise
{ # unknown part
}

Or, a switch-like statement could be similarly used/extended.  Such constructs
would quite possibly make it easier to write programs based on ternary logic.  The
historical problem with using binary constructs with ternary logic is the need to
repeat part of the condition in one leg of the binary structure to further
subdivide it into the remaining two clauses needed, and with complex conditions,
that becomes more complex quickly.  Ternary structured constructs could simplify
this.

> I think the example of:
>
>die "Fatal, \$name is unset!" if ($name == null);
>
> is flawed.  It will never die, because as you said, two unknown values
> won't compare as equal.  Besides, the test would try to convert both $name
> and null to numbers before doing the numerical comparison, so it would
> depend on what the numerical value of unknown is.  You really need a
> "known()" built-in to go with this, such that known($a) is true if $a is
> NOT unknown.

Yes, known(), that's consistent with "unknown", and would substitute for
"isnull()" which was mentioned by others.  I agree that example is flawed.

> What gets me is that the implementation of this would require virtually
> every operator, function, etc in core perl to be special-cased to deal with
> the unknown value, yet the RFC makes no mention of this.

Yes, it is true that virtually every operator would have to change.  This is not a
trivial matter.  The closest the RFC comes to mentioning it is "that have the
proper semantics" in the implementation section.

> With undef, it's simply a matter of having the internal representation of
> undef return 0 or "" when asked for a numerical or string value.  This
> makes most things deal with undef nicely -- even booleans.  With unknown,
> since it is specifically designed to propagate, everything would have to
> deal with unknown values, not just integers, or strings,  or booleans.

Yes.

> Importantly, unless you decide something arbitrary like "unknown is false"
> like the way that it was decided that "undef 

Re: RFC 85 (v2) All perl generated errors should have a unique identifier

[Chaim Frenkel]

> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:

TC> Ok, so you want message catalogues, and not solely on Perl but anything
TC> in the distribution.  You should say that.

No. That is independent of what I'm suggesting. What I'm suggesting is
an enabler.

I've seen code that actually looks at the value of $@
eval { ... }
$@ !~ //;

Why not make it simpler

eval {  }
$@ !~ any(  );  # Damian's Superpositions.
# I keep reading Superstition :-)


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

RE: PERL6STORM - tchrist's brainstorm list for perl6

[Dan Sugalski]

At 10:22 AM 9/21/00 -0500, Fisher Mark wrote:
> > =item perl6storm #0064
> >
> > Do something about microsoft's CRLF abomination.
>
>I think for the case of Microsoft C++ used for the Win32 port, everyone
>would be happy if Perl's sysopen, sysread, etc. did not require binmode.
>Unfortunately, Microsoft made the decision very early on in its C/C++
>development to make open, read, etc. do CRLF/NL conversions.  To do this I
>think that you need to substitute the Win32 API calls like OpenFile for the
>calls to open, read, etc.  Unfortunately, I'm too backed up right now to
>even come close to making this change.

I'd personally like to toss the C stdio functions entirely wherever we can 
manage. They suck really badly in a lot of places, and are at best a rather 
sad lowest common denominator.

I would *really* like perl's I/O system to do async reads and writes to 
disk files whenever possible. That'd let us get another burst of speed in 
some spots, particularly when slurping through files sequentially (which is 
what's done maybe 95% of the time).

Dan

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

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

[Matthew Wickline]

(offlist)

If I had a qoute file for a raondom sig generator, this would surely be
added. :)

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

-matt

async I/O (was Re: PERL6STORM - tchrist's brainstorm list for perl6)

[Uri Guttman]

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

  DS> I would *really* like perl's I/O system to do async reads and
  DS> writes to disk files whenever possible. That'd let us get another
  DS> burst of speed in some spots, particularly when slurping through
  DS> files sequentially (which is what's done maybe 95% of the time).

i proposed some of that in my rfc47 (universal async i/o). at the perl
level you need a delivery interface as with events. internally i see it
being useful too for the speedup of sequential files. but how do you
know a file is sequential? most unix kernels do readahead blocks anyway
but if you seek, you waste that. maybe a file can be designated as
sequential with async readahead by extra arguments to a smarter
open. others have proposed a better OO open and i second that. these
async options can be added easily and not be in the way of newbies.

in any case async i/o is a big win and should be in p6. we need to
clarify it more.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: async I/O (was Re: PERL6STORM - tchrist's brainstorm list for perl6)

[Dan Sugalski]

At 05:35 PM 9/21/00 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>   DS> I would *really* like perl's I/O system to do async reads and
>   DS> writes to disk files whenever possible. That'd let us get another
>   DS> burst of speed in some spots, particularly when slurping through
>   DS> files sequentially (which is what's done maybe 95% of the time).
>
>i proposed some of that in my rfc47 (universal async i/o). at the perl
>level you need a delivery interface as with events.

I'm not really worried about the perl level for this. I'm more concerned 
with the low-level internal implementation.

>internally i see it
>being useful too for the speedup of sequential files. but how do you
>know a file is sequential?

Who cares? If the filehandle's read within a while(), or in list context, 
we can use a big readahead buffer and issue a lot of async I/O requests. 
For filehandles read with a plain scalar fetch off a filehandle we can use 
a smaller readahead buffer.

Async writes are a win in any case.

>most unix kernels do readahead blocks anyway
>but if you seek, you waste that.

So? We lose in that case, but not by much. If we give full control to the 
user programs (and I'd like to) then the user can get fancy and we'll leave 
the decision to the program.


Dan

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

Re: RFC 268 (v1) Keyed arrays

[Michael Maraist]

> my/our @array :hashsyntax;
>
> would hide the definition of %array in the same way that
>
> my/our %array
>
> would  hide a  prior definition  of %array.   And references  to %array
> would thenceforth actually be references to the keyed array @array.

I can see massive confusion from this.  It's bad enough that globbing allows
multiple data-types with the same name, and it's really bad that the casual
observer has to stretch their mind like crazy to interpret @$sym{qw(a b c)},
which non-intuitively changes context every character (scalar to ref to
array ref to hash-slice ref, etc ).  Then came pseudo-hashes, which
thankfully aren't used for too much other than objects (where there true
natures are somewhat hidden).  Now you're suggesting colliding globing
name-spaces.

What I think you're saying is that hashes and arrays would be totally merged
into a singular data-type.  That might work, but we'd be alienating existing
users that don't want to retrain but work along side perl6 developers.  I'm
not saying it's bad, just that I know it'll affect my work environment.

> The syntaxes
>
> $foo['element']
> $foo{element]

Typo.  Which was it $foo{element} or $foo[element]?

> So, starting with
>
>my @foo:key; # empty array
>$foo ['month'] = 10;  #  $#foo == 1, $foo[0] == 10
>$foo ['day'] = 20;   # $#foo == 2, $foo [1] == 20
>$foo ['year'] = 30;   # $#foo = 3, $foo [2] == 30
> We achieve an array with 3 elements.  There is a clear parallel between
> this and
>
>my %foo;
>$foo{'month'} = 10;
>$foo{'day'} = 20;
>$foo{'year'} = 30;
>
> However, the lookups for @foo are done at compile time, the lookups for
> %foo are done at runtime.

Ok, implementation problem.  Are you suggesting that we really implement
pseudo-hashes behind the scene?  You mention name-spaces, but afaik, these
are just normal perl-hashes (with special values).  This sounds more like
using pseudo-hashes behind the scenes.  The difference is that now you're
requiring a new symbolic hash to be generated for each ":key" array,
where-as pseudo-hashes allow you to reuse the same old hash (as used in
perl5.005's OO).

As an alternative, use an attribute that does not interpolate the field
name.  Make it more like a c-struct, where you _have_ to fully specify the
field name.  With this, you could still use the dynamic generation of fields
as in the above (so you don't have to specify them ahead of time), but by
the time the compiler is finished, the references are fixed and converted to
array indexes.  Moreover, you have a special type of fixed array (as opposed
to a resizable one).  You get all the benifits of space / performance of
c-structures, while not totally throwing away the flexibility of hashes.
The only way you could achieve a dynamic field-name lookup would be through
an eval.  This slows it's usage down, but if you really wanted to use
hashes, you'd use some other variable-name attribute.  Actually, thinking
more on that, you couldn't totally fix the array size if you could 'eval'
the structure with additional field-names.  The most you could say would be
that you have a unidirectionally growing array, and it might not be worth
the while of producing a whole new array structure for just this sort of
optimization.

>
> For :key and :initialkey arrays, the syntax
>
> $foo[$bar]
>
> would inspect $bar to determine if it is convertable to numeric.  If it
> is, the value is used as the numeric index of the array.  If it is not,
> it is treated as a key for the array, and is looked up in the namespace
> of the array.

Doesn't this conflict with the general usage of hashes?  I know I've made
use of hashes as a form of sparce matrix / array.  DB ID's, for example
(where you have 3 sequential values starting at 1,234,567,890 ).  Basing
context on whether the number 'happens' to be numeric is bad (at least for
me in DB programming).  I don't like the idea of coersing it to a string as
in $foo[ "$bar" ].

Also, if you ever mixed keys / indexes, you'd have a serious problem with
code maintanance.  Try the following:

sub foo {
my @hash: bla bla;
$hash{sym2} = 5;
$hash[0]++;
$hash{sym1} = 6;
...
}

Then later we add a debug routine (for what-ever reason)
sub db

   my $var = shift;
  print "DEBUG: sym1 = $var->{sym1}, sym2 = $var->{sym2}";
}
sub foo {
  my @hash: bla bla;
  db( \@hash );
  $hash{sym2} = 5;
  $hash[0]++;   #gotcha, idx0 == sym1 now
  $hash{sym1} = 6;
}

This is obviously contrived, but you get the exact same thing in the
Database world:

my @db_results = $dbh->selectcol_array( 'select * from table' );

Here, we're at the mercy of the order that the columns were defined.  If we
later add a new column anywhere other than the end, then we've invalidated
the above code.  You might say that it's not our fault.  But I offer that
during the development phase, the structure and contents change often (as
I've learned on my own).  Instead you need to either explicitly state the
fields

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Eric Roode wrote:
> 
> Allow me to throw another log on the fire:
> 
> my $x;
> if (something)
> {
> $x = 1;
> }
> my $y = $x;
> 
> This would give a compile-time warning under your RFC, warning the
> user of a possibly uninitialized $x. Okay. Next:

Yes.

> my $x;
> if (something)
> {
> $x = 1;
> }
> else
> {
> $x = 2;
> }
> my $y = $x;
> 
> Would this give the same warning? Would it notice that $x is set
> in both branches of the condition?

Yes, it would notice this and not warn. All paths of flow control
leading to the final statement contain an initialization.

> Worse:
> 
> my $x;
> if (something)
> {
> $x = 1;
> }
> if (!something)
> {
> $x = 2;
> }
> my $y = $x;
> 
> I presume this would generate a warning under your RFC, right?

Yes. And not necessarily a spurious one: consider using $dsoifjd++ for
'something'.

> Since I would guess the compiler shouldn't be required to notice
> that one condition is the inverse of the other?

It would also have to prove that the value of 'something' does not
change from one call to the next.

> I'm not sure I like the above construct not behaving identically
> to the second case (if...else...) above...

The "possibly" version would need to be optional (or more optional) than
the others. As soon as it gave me even one spurious warning, I would
immediately turn it off except to periodically turn on all warnings full
blast to get a "lint"-like effect.

> Moving on:
> 
> my $x;
> if (thing1)
> {
> $x = 1;
> }
> elsif (thing2)
> {
> $x = 2;
> }
> elsif (thing3)
> {
> $x = 3;
> }
> else
> {
> $x = 4;
> }
> my $y = $x;
> 
> Warnings, or no?

No warnings.

> How about:
> 
> my ($x, $i);
> for ($i=0; $i<10; $i++)
> {
> $x .= $i;
> }
> my $y = $x;
> 
> Now, I can look at that and see that $x will be '0123456789', but
> the compiler can't be expected (imho) to know whether the loop
> condition will ever execute, so under your RFC it will generate a
> "possibly uninitialized" warning, right?

Right. We could stray from correctness here and assume any for loop is
executed at least once, but I'd rather not -- this is the code pattern
where it is most useful (because often the programmer doesn't notice
that, in fact, that for or while loop might not execute, in some weird
case.)

In this particular case, it might not be unreasonably difficult to ask
the question of "is COND true immediately after INIT in for(INIT; COND;
INCR)?" But the compiler certainly won't be that smart in version 1.

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

[Greg Boug]

Apologies if these comments have already been noted... 

>   my $PI : constant = 3.1415926;
>   my @FIB : constant = (1,1,2,3,5,8,13,21);
>   my %ENG_ERRORS : constant = (E_UNDEF=>'undefined', E_FAILED=>'failed');
>   
> Constants can be lexically or globally scoped (or any other new scoping
> level yet to be defined).

Just curious about how the use of 'my' and 'local' would be brought into
this. Assume for the moment you don't use strict vars in a script (why 
you wouldn't, I don't know, but some people don't...) Would that 
mean that:

$notusingstrict : constant = 1.2345;

would be legal? Personally, I would prefer to enfore the use of 
strict vars for constants, as it is then obvious as to the scope... 

But then again, I'd also prefer use strict to be the default... ;-) 

Also, presumably the following:

my $notconstant = 1.2345;
my $const : constant = $notconstant;

would cause $const == 1.2345 and remain constant at that value... 

Greg

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

[Russ Allbery]

Glenn Linderman <[EMAIL PROTECTED]> writes:
> Philip Newton wrote:

>> Having $seen{$word}++ turn $seen{$word} to undef is bad,

It doesn't "turn it to undef"; if you're using tristate semantics, it
leaves it as undef, because those are the semantics you've selected for
undefined values.

>> if (undef)++ assumes NULL semantics everywhere, hence "one more than
>> unknown" = "still unknown".

No one's proposing that.  People are proposing the ability to turn on NULL
semantics where you need it.

> Right.  Applying NULL semantics to undef would be bad.  The
> counterproposals to RFC 263, along the lines of "use tristate", seem to
> overlook this sort of situation.

I'm not overlooking it; I just don't agree with you.  There *is* a
difference.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

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

[Jeremy Howard]

Greg Boug wrote:
> Apologies if these comments have already been noted...
>
> >   my $PI : constant = 3.1415926;
> >   my @FIB : constant = (1,1,2,3,5,8,13,21);
> >   my %ENG_ERRORS : constant = (E_UNDEF=>'undefined',
E_FAILED=>'failed');
> >
> > Constants can be lexically or globally scoped (or any other new scoping
> > level yet to be defined).
>
> Just curious about how the use of 'my' and 'local' would be brought into
> this. Assume for the moment you don't use strict vars in a script (why
> you wouldn't, I don't know, but some people don't...) Would that
> mean that:
>
> $notusingstrict : constant = 1.2345;
>
> would be legal? Personally, I would prefer to enfore the use of
> strict vars for constants, as it is then obvious as to the scope...
>
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?

> But then again, I'd also prefer use strict to be the default... ;-)
>
> Also, presumably the following:
>
> my $notconstant = 1.2345;
> my $const : constant = $notconstant;
>
> would cause $const == 1.2345 and remain constant at that value...
>
Yes, this doesn't effect $notconstant in any way. It simply creates a new
constant with the value of 1.2345. Constants such as this can't be inlined
at compile time, so instead they would be implemented as scalars with a
constant flag.

Re: async I/O (was Re: PERL6STORM - tchrist's brainstorm list for perl6)

[Uri Guttman]

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

  DS> At 05:35 PM 9/21/00 -0400, Uri Guttman wrote:
  >> i proposed some of that in my rfc47 (universal async i/o). at the perl
  >> level you need a delivery interface as with events.

  DS> I'm not really worried about the perl level for this. I'm more
  DS> concerned with the low-level internal implementation.

but i am concerned about the language level. this is the language list
and not the internals one. we can deal with how to implement it
later. and saying that perl will do async i/o on files for you is still
a language level issue as the coder may not want that (random access
files, etc.). i think the coder has to be able to request this and not
have it happen automagically.

  >> internally i see it being useful too for the speedup of sequential
  >> files. but how do you know a file is sequential?

  DS> Who cares? If the filehandle's read within a while(), or in list
  DS> context, we can use a big readahead buffer and issue a lot of
  DS> async I/O requests.  For filehandles read with a plain scalar
  DS> fetch off a filehandle we can use a smaller readahead buffer.

this again is a language issue. are all filehandles in while loops going
to do this? i think the user need to control it and not let perl guess
how to handle it.

  DS> Async writes are a win in any case.

true.

  >> most unix kernels do readahead blocks anyway
  >> but if you seek, you waste that.

  DS> So? We lose in that case, but not by much. If we give full control
  DS> to the user programs (and I'd like to) then the user can get fancy
  DS> and we'll leave the decision to the program.

that is my point. i don't think we should do any of this withour user
control. it reminds me of the transactions wars we have had. how can
perl figure out the right thing to do in all cases. IMO only the coder
must have the choice.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: RFC 270 (v1) Replace XS with the C module as the standard way to extend Perl.

[Matthew Cline]

On Thu, 21 Sep 2000, you wrote:

> This one-liner is a complete perl extension:
>
> perl -e 'print add(2,2);use Inline C=>"int add(int x,int y){return
> x+y;}"'

I haven't written any XS myself, but I was under the impression that one 
problem with it is that what you write an extension in (XS) isn't the same as 
the language that you're debugging (C).  (If this isn't true, then just 
ignore this message...)  If I were to ever write a Perl extension, I'd like 
the code I write to be the same as the code I'm going to debug.

But if Perl6 is changed so that you can write extensions in plain old C 
(without using something like Inline), it seems certain that there'd be some 
XS compatability tool, so as to not break all the current XS code out there.  
So then we could have three ways of writing an extension: straight C, XS, and 
Inline.  Hmmm  There's More Than One Way To Do It? ;-)

-- 
Matthew Cline| Suppose you were an idiot.  And suppose that
[EMAIL PROTECTED] | you were a member of Congress.  But I repeat
 | myself.  -- Mark Twain

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

[Glenn Linderman]

Russ Allbery wrote:

> I'm not overlooking it; I just don't agree with you.  There *is* a
> difference.

You are certainly welcome to not agree with me.  And if you didn't overlook
it, that is fine.

In my opinion, which you probably will also not agree with, attempting to
toggle between the current undef semantics and tristate semantics is like
trying to stuff three values into one bit.  This comment assumes that the
current undef is implemented by a bit in a variable structure; when the bit is
in one state, it means the value is undef, and when the bit is in the other
state, it means the value is not undef.  The problem is, when you toggle the
pragma, all variables whose value is undef suddenly have the tristate
semantics, and when you toggle it back, all the variables whose value is undef
suddenly have the undef semantics.  This leaves it purely to the programmer to
make sure that the pragma is used in exactly the right places, and, when
tristate semantics are in effect makes unavailable the normal, helpful
warnings that Perl produces when you attempt to misuse undef values.

I guess that since you have no intention of using the tristate semantics, you
don't care whether it is easy to code using them.

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

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

[Russ Allbery]

Glenn Linderman <[EMAIL PROTECTED]> writes:

> In my opinion, which you probably will also not agree with, attempting
> to toggle between the current undef semantics and tristate semantics is
> like trying to stuff three values into one bit.

I do understand the argument.  I just see confusion either way, and I
think that approach would be the least confusing and allow the code to
remain the most Perl-like.  I can see arguments the other way; that's just
my opinion.

> The problem is, when you toggle the pragma, all variables whose value is
> undef suddenly have the tristate semantics, and when you toggle it back,
> all the variables whose value is undef suddenly have the undef
> semantics.  This leaves it purely to the programmer to make sure that
> the pragma is used in exactly the right places, and, when tristate
> semantics are in effect makes unavailable the normal, helpful warnings
> that Perl produces when you attempt to misuse undef values.

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.

To me, toggling the semantics of the variables which are already undef
strikes me as just what I'd want.

> I guess that since you have no intention of using the tristate
> semantics, you don't care whether it is easy to code using them.

Comments like this are what is making it very difficult for me to continue
discussing this with you.  You don't actually know what type of Perl I
write or whether or not I'd use the semantics or not.  As a matter of
fact, I find them very interesting and fully do expect to use those
semantics if they're implemented in Perl, particularly given that I'm
likely to be doing a lot more database and SQL coding in the future than I
am currently.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 268 (v1) Keyed arrays

[Glenn Linderman]

Michael Maraist wrote:

> > my/our @array :hashsyntax;
> >
> > would hide the definition of %array in the same way that
> >
> > my/our %array
> >
> > would  hide a  prior definition  of %array.   And references  to %array
> > would thenceforth actually be references to the keyed array @array.
>
> I can see massive confusion from this.

OK, this sounds like a vote against the :hashsyntax variation.  That variation
was a stretch, meant to help speed up accessor functions without requiring a
syntax change.  Speeding up accessor functions is what inspired the idea (RFC
163, oops, I forgot that one in my References list, just added it).

> It's bad enough that globbing allows
> multiple data-types with the same name,

Could you elucidate here?  Oh, type globs.  Oh you mean $foo vs @foo vs %foo, I
think.  OK, correct me if I'm wrong, but I think I'm with you.

> and it's really bad that the casual
> observer has to stretch their mind like crazy to interpret @$sym{qw(a b c)},
> which non-intuitively changes context every character (scalar to ref to
> array ref to hash-slice ref, etc ).

Yes, that is not an expression for a casual observer.  But it is explicit, once
you know the rules.

> Then came pseudo-hashes, which
> thankfully aren't used for too much other than objects (where there true
> natures are somewhat hidden).

And hopefully pseudo-hashes can be eliminated.

> Now you're suggesting colliding globing name-spaces.

But only for those variables for which the user requests it.

> What I think you're saying is that hashes and arrays would be totally merged
> into a singular data-type.

Not.  Arrays and hashes would still both exist.  Hashes would remain identical
to today, but would be unencumbered by pseudo-hash code (hopefully, RFC 241).
Arrays (as implemented today) would be exactly available via :nokey.  In fact,
until the user actually uses a key with a :key array, it is no different than a
:nokey array.  It is for that reason that I proposed making :key the default: it
would not alter the semantics of any existing program under perl<6.  But after
reading your comments, I've realized that splice must be prohibited on :key
arrays, so I'm changing the default in v2 to :nokey, which will still support
splice.

> That might work, but we'd be alienating existing
> users that don't want to retrain but work along side perl6 developers.  I'm
> not saying it's bad, just that I know it'll affect my work environment.

So I don't think this conclusion is correctly drawn, as both arrays and hashes
would still exist.  I've rephrased by abstract to try to avoid misleading people
regarding the continued existance of hashes.  Does that help?

> > The syntaxes
> >
> > $foo['element']
> > $foo{element]
>
> Typo.  Which was it $foo{element} or $foo[element]?

Thank you.  It was intended to be (and will be in v2) $foo[element].

> > So, starting with
> >
> >my @foo:key; # empty array
> >$foo ['month'] = 10;  #  $#foo == 1, $foo[0] == 10
> >$foo ['day'] = 20;   # $#foo == 2, $foo [1] == 20
> >$foo ['year'] = 30;   # $#foo = 3, $foo [2] == 30
> > We achieve an array with 3 elements.  There is a clear parallel between
> > this and
> >
> >my %foo;
> >$foo{'month'} = 10;
> >$foo{'day'} = 20;
> >$foo{'year'} = 30;
> >
> > However, the lookups for @foo are done at compile time, the lookups for
> > %foo are done at runtime.
>
> Ok, implementation problem.  Are you suggesting that we really implement
> pseudo-hashes behind the scene?  You mention name-spaces, but afaik, these
> are just normal perl-hashes (with special values).  This sounds more like
> using pseudo-hashes behind the scenes.

Not quite pseudo-hashes, but similar in some ways to pseudo hashes.  That's why
Mr. Schwern and I had an extensive discussion in the -object list (eventually
moved off-line, but the discussion started there re: RFC 163) regarding just
exactly what I was proposing here, and culminating in the quote that I placed at
the top of this RFCs discussion section.  It appears that Mr. Schwern is
somewhat violently opposed to pseudo-hashes continued existance.  But after much
discussion, he realized that this proposal is different.  He encouraged me to
work up something using a tied array, but then I saw something about a new-RFC
deadline, so decided to submit the ideas so far, before I did that.  So
certainly it was premature.

Indeed, the name space is defined to be a _normal_ perl hash in the
implementation section.

> The difference is that now you're
> requiring a new symbolic hash to be generated for each ":key" array,
> where-as pseudo-hashes allow you to reuse the same old hash (as used in
> perl5.005's OO).

That's one difference, I guess.  Certainly, when you say

@foo = @bar;

the new namespace hash for foo could be a pointer to the same namespace hash as
is used for bar, if it makes sense to reference count and copy on write, or
something along those lines.  That's an implementation choice, of

RFC 83 (v3) Make constants look like variables

[Perl6 RFC Librarian]

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

=head1 TITLE

Make constants look like variables

=head1 VERSION

  Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
  Date: 10 Aug 2000
  Last Modified: 21 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 83
  Version: 3
  Status: Frozen

=head1 DISCUSSION

The syntax was widely accepted. Some posters preferred to see constants
expanded to work within complex data structures. Others preferred to keep
things simple. This RFC keeps things simple. A counter-RFC has not been
submitted.

=head1 ABSTRACT

This RFC proposes that the current constant.pm module removed, and
replaced with a syntax allowing any variable to be marked as constant.

=head1 CHANGES

=head2 Since v1

=over 4

=item *

Changed notation to be consistent with other value attributes

=item *

Specified behaviour of references, arrays, and lists

=item *

Added definition

=back

=head1 DESCRIPTION

A constant is a value that can not be changed once it is declared.
Once declared, it behaves just as if it was the actual literal value
that it contains.

Currently, constants are created in Perl using the constant.pm module:

  use constant PI => 3.1415926;

which creates an inlined subroutine:

  sub PI () {3.1415926;}

This method of creating constants has three serious drawbacks:
 
=over 8

=item Can not be interpolated in strings

Whereas variables can be interpolated into strings (e.g. "PI is $Pi"),
subroutines can not be. This makes using constants inconvenient, since
string concatenation must be used.

=item Inconsistant syntax

The sudden appearance of barewords can be quite unsettling to new users.
After becoming told that 'arrays are @name, scalars are $name, ...', the
rule suddenly stops working just because the programmer wants the value to
stay constant.

=item Redundant warnings

In persistant Perl environments such as mod_perl, inlined subroutines
often created the redundant warning 'Constant subroutine PI redefined'.
This has been a frequent source of confusion amongst new mod_perl users.

=back

It is proposed that a new syntax for declaring constants be introduced:

  my $PI : constant = 3.1415926;
  my @FIB : constant = (1,1,2,3,5,8,13,21);
  my %ENG_ERRORS : constant = (E_UNDEF=>'undefined', E_FAILED=>'failed');
  
Constants can be lexically or globally scoped (or any other new scoping
level yet to be defined).

If an array or hash is marked constant, it cannot be assigned to, and its
elements can not be assigned to:

  @FIB = (1,2,3);   # Compile time error
  @FIB[0] = 2;  # Compile time error
  %ENG_ERRORS=();   # Compile time error
  %ENG_ERRORS{E_UNDEF=>'No problem'} # Compile time error
  
To create a reference to a constant use the reference operator:

  my $ref_pi = \$PI;
  
To create a constant reference use a reference operator in the
declaration:

  my $a = 'Nothing to declare';
  my $const_ref : constant = \$a;

Note that this does not make the scalar referenced become constant:

  $$const_ref = 'Jewellery';   # No problems
  $const_ref = \4; # Compile time error

=head1 IMPLEMENTATION

Constants should have the same behaviour as the do now. They should be
inlined, and constant expressions should be calculated at compile time.

=head1 EXTENSIONS

It may be desirable to have a way to remove constness from a value. This
will not be covered in this RFC--if it is required a separate RFC should
be written referencing this one.

=head1 REFERENCES

perldoc constant

perldoc perlsub (for constant subroutines)

Re: RFC 271 (v1) Subroutines : Pre- and post- handlers for subroutines

[Uri Guttman]

> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:


  PRL> If a handler changes one of the original arguments through the
  PRL> aliases in its @_ array, those changes a passed on to subsequent
  PRL> handlers and to the primary itself. For example:

  PRL> pre tax_payable_on {
  PRL> $_[0] -= 20.00; # routinely underquote sales price
  PRL> }

  PRL> sub tax_payable_on {# now sees prices $20 less than
  PRL> # specified argument
  PRL> printf("Tax: %.2lf", $_[0] * 0.1);
  PRL> }

  PRL> tax_payable_on(99.95);  # prints 8.00
  PRL> tax_payable_on(29.95);  # prints 0.99
  PRL> tax_payable_on( 9.95);  # prints -1.01  (a profit!)

i assume like normal subs, that changes the original argument in the
caller. what about splicing new values in/out of @_? is that allowed? i
can see passing in things which get deleted/expanded if they are in a
different format than the primary expects.


  PRL> post tax_payable_on {
  PRL> $_[-1] -= 1.00; # routinely underquote tax payable
  PRL> }

the IRS will get you for that!

  PRL> Either a block or subroutine reference implementing the handler,
  PRL> or a hash reference whose value is a sub reference implementing
  PRL> the handler, or a string or bareword specifying the logical name
  PRL> of a handler.  This argument would be optional.

the 'hash ref whose value' makes no sense. do you mean the keys are the
primary sub names and values are the pre/post sub refs for those
primaries?



  PRL> If the first argument ends in "::" and is therefore the name of a
  PRL> package -- rather than a subroutine -- then the handler is
  PRL> installed in a special I, and is shared
  PRL> by every existing (and future) subroutine in the package. For
  PRL> example:

  PRL> pre Cafe::Bar::, sub { print "calling some method of
  PRL> class Cafe::Bar" };

  PRL> installs a prefix handler that will be invoked whenever I
  PRL> subroutine from package Cafe::Bar is called.

can you have a package level pre and also a per sub pre? do they
both get called or does the sub one only get called?

  PRL> If the first argument is a subroutine reference, the handler is installed
  PRL> for the referent. For example:

  PRL> package Foo;

  PRL> pre \&Zan::Zi::bar, sub { print "about to bar()..." };

  PRL> installs a prefix handler for the subroutine C<&Zan::Zi::bar>, whilst:

  PRL> package Foo;

  PRL> my $anon = sub { print "I am the sub with no name\n" };

  PRL> pre $anon, sub { print "about to bar()..." };

  PRL> installs a prefix handler for the anonymous subroutine referred
  PRL> to by $anon.

so the handlers are attached to the primary code ref? how does this work
with package level ones then? all subs must check for pakcage level pre
before they can be called? this sounds like a big slowdown. i am not
sure package level pre is a good idea in this case. 


  PRL> =head2 Installing C Handlers

why the separate docs for post and pre syntax? without double checking,
i assume they have the same syntax other than pre/post. folding these
into one section would make this easier to digest.


  PRL> =head2 Logically Identified Handlers

  PRL> In order to later manipulate or remove prefix and postfix
  PRL> handlers, it is convenient to given them a logical name. To this
  PRL> end, the second argument to C or C may be specified as
  PRL> reference to a one-element hash:

  PRL> pre Lum::bar, { PAIN => sub { print "ouch!..." } };
  PRL> post Lum::bar, { PAIN => sub { print "...ahhh!" } };

this is getting a little ugly and too much IMO.


  PRL> =head3 Accessing named handlers

  PRL> Finally, it is possible to retrieve the entire prefix or postfix
  PRL> handler sequence for a particular subroutine, by passing just its
  PRL> name/reference to C:

  PRL> $pain_handler_array_ref = pre Lum::bar;

  PRL> $tree_handler_array_ref = post \&Coola::bar;

  PRL> $package_handler_array_ref = pre Cafe::Bar::;

  PRL> This returns a reference to the actual handler sequence for the
  PRL> subroutine, in which each element is a reference to a hash whose single
  PRL> key is the logical name of the handler (or "" if it has no logical name)
  PRL> and whose single value is a reference to the handler itself. That is, the
  PRL> structure of the returned value is like this:

  PRL>  [
  PRL>  { 'NAME' => sub {...} },
  PRL>  { 'NAME' => sub {...} },
  PRL>  { '' => sub {...} },
  PRL>  { 'NAME' => sub {...} },
  PRL>  { '' => sub {...} },
  PRL>  ]

why not just use a single list? the short anon hashes are useless
there. in fact, you could use this to eliminate the need for all the
named handlers. just make the pre/post functions take multiple code refs
as handlers. you can retrie

RFC 269 (v1) 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
  Mailing List: [EMAIL PROTECTED]
  Number: 269
  Version: 1
  Status: Developing

=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

RFC 208 (v3) 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: 21 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 208
  Version: 3
  Status: Developing

=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

RFC 268 (v1) Keyed arrays

[Perl6 RFC Librarian]

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

=head1 TITLE

Keyed arrays

=head1 VERSION

  Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
  Date: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 268
  Version: 1
  Status: Developing

=head1 ABSTRACT

The  idea  here is  to  merge  the concepts  of  array  and hash.   The
resultant  data  structure  is   more  costly  than  either,  for  some
operations, may be more efficient  than hashes for some operations, and
may provide a more compatible  solution for some types of problems than
current RFCs.


=head1 DESCRIPTION

These  are not  pseudo-hashes.   Michael Schwern,  author  of RFC  241:
Pseudo-hashes must die! after some lengthy discussion, said:  Ya
know, I'm going to say that $aref->[string] might be made to work where
pseudo-hashes failed. .  However,  that is not intended to mean
that  Mr.   Schwern  endorses this  proposal,  but  I  did take  it  as
encouragement to develop this RFC  to squeak in before the deadline and
hope that it lends just a bit credence to the proposal.  That said...

=head2 Definition syntax

An array could have an optional namespace.  Probably best to call these
keys, because  it really is the  same concept as hash  keys--we look up
values  using  them.   Probably  there  could be  several  flavors,  as
described below.  I'm not yet  certain if all these flavors are useful,
or  if  all these  flavors,  even  if useful,  are  worth  the pain  of
implementation, since  I don't know the cost  of implementation.  There
may  be  flavors  I  haven't  thought  of  yet,  that  would  be  worth
implementing.  All  but the first are generically  called keyed arrays.
Here's my current concept list:

my/our @array :nokey;
my/our @array :key;
my/our @array :initialkey ( key0, key1, ... );
my/our @array :keyonly;
my/our @array :hashsyntax;

With the :nokey attribute, we  would have a familiar perl<6 array.  Use
numeric indexes, and [] indexing syntax.

The proposed  default attribute would  be :key, which would  allow, but
not require,  keys to be added  to point to  particular array elements,
and numeric indexing could still be used for speed.

The :initialkey  variation would  specify in the  definition a  list of
keys which  would correlate  to the  array indexes 0,  1, ...

The :keyonly variation  would be less efficient, and  would require use
of keys for lookup.  Of course, the compiler could translate fixed keys
into numeric indexes under the covers for performance.

The  :hashsyntax  variation is  identical  to  the :keyonly  variation,
except for  the syntax,  which is like  hashes instead of  like arrays.
This  variation  could  unify  the  concepts of  hash  and  array.  The
definition  of a :hashsyntax  array should  probably reserve  a special
pointer in the  symbol table so that the similarly  named hash would be
automatically  defined for  access,  but would  actually  refer to  the
:hashsyntax keyed array.  In other words, the definition of

my/our @array :hashsyntax;

would hide the definition of %array in the same way that

my/our %array

would  hide a  prior definition  of %array.   And references  to %array
would thenceforth actually be references to the keyed array @array.


=head2 Reference syntax

The syntaxes

$foo['element']
$foo{element]

or for :hashsyntax arrays, either the above or

$foo{'element'}
$foo{element}

would be interpreted as a reference to @foo.  If the namespace for @foo
contains 'element', that member of  @foo is the interpretation.  If the
namespace for @foo does not  contain 'element', then 'element' is added
to the namespace for @foo, the size  of @foo is increased by 1, and the
member 'element' refers to the newly added item in @foo.

So, starting with

   my @foo:key; # empty array
   $foo ['month'] = 10;  #  $#foo == 1, $foo[0] == 10
   $foo ['day'] = 20;   # $#foo == 2, $foo [1] == 20
   $foo ['year'] = 30;   # $#foo = 3, $foo [2] == 30

We achieve an array with 3 elements.  There is a clear parallel between
this and

   my %foo;
   $foo{'month'} = 10;
   $foo{'day'} = 20;
   $foo{'year'} = 30;

However, the lookups for @foo are done at compile time, the lookups for
%foo are done at runtime.

For :key and :initialkey arrays, the syntax

$foo[$bar]

would inspect $bar to determine if it is convertable to numeric.  If it
is, the value is used as the numeric index of the array.  If it is not,
it is treated as a key for the array, and is looked up in the namespace
of the array.

For :keyonly and  :hashsyntax arrays, all indexes are  considered to be
string keys just  like hash keys, requiring lookup  in the namespace of
the array.


Perl uses some heuristic to decide  whether a bareword within the {} of
a hash  key reference  is a  function or a  string, the  same heuristic
should be applied within [] for keyed arrays.


Splice, push,  pop, shift, and unshift  are not valid  for :keyonly and
:hashsyntax  arr

RFC 270 (v1) Replace XS with the C module as the standard way to extend Perl.

[Perl6 RFC Librarian]

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

=head1 TITLE

Replace XS with the C module as the standard way to extend Perl.

=head1 VERSION

  Maintainer: Brian Ingerson <[EMAIL PROTECTED]>
  Date: 21 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 270
  Version: 1
  Status: Developing

=head1 REPLACES

RFC 61 - Interfaces for linking C objects into perlsubs

=head1 ABSTRACT

Extending Perl with XS is too hard. First, there is a hefty learning
curve for even simple extensions. Also, the resulting code gets spread
out over several files, making it hard to maintain.

In the spirit of Perl itself, C makes extending Perl easy for
easy things, and possible for harder things. A Perl programmer can write
their first C extension in minutes. They can learn more
difficult maneuvers as needed. All of the extension code can be in the
same file as the Perl script or module.

This one-liner is a complete perl extension:

perl -e 'print add(2,2);use Inline C=>"int add(int x,int y){return x+y;}"'

The first time you run it, you'll notice a pause (compiling). Subsequent
runs are lightning fast, as long as the C component isn't modified.

=head1 DESCRIPTION

C is basically a user friendly abstraction over XS. You feed
it a snippet of (C) source and it performs the following steps:

1) Determine if the code snippet has already be compiled. 
   If so, goto 5.
2) Parse function definitions to determine how code should bind to Perl.
3) Generate XS glue code.
4) Build the extension and install it in some known place.
5) DynaLoader the extension.

If the extension is a user script or one-liner, the extension will get
built and installed in a place that the user has access to. C
chooses a reasonable default. The default can easily be over-ridden.

If the extension is part of a distributed (ie CPAN) module, the code
gets compiled during "make test" and permanently installed in the
"installsitearch" during "make install".

C is intended to replace 80-90% of the current functionality of
XS. Although it does not need to be built over XS, doing so makes
C more robust, helps towards backwards compatability, and
provides an easy "out" if a project grows to exceed C
capabilities.

In perl6, something like XS should still exist, but just as a foundation
for C. Savvy hackers could defeat C and write glue code
themselves, but this would not be the standard.

=head1 IMPLEMENTATION

All of this is currently functional in C v0.25 (on CPAN now).
C seems to work on any machine that has access to the same
environment that was used to build Perl itself. Success has been
achieved on platforms including MSWin32 and most *nixes.

Version 0.25 provides bindings to the following types: C, C,
C, C, C. (For anything else the user must pass the
argument as a C and do their own type conversion.) There is also
support for passing and returning lists.

Version 0.30 (not yet released) has no default types. It gets all of its
types from XS C files. These files are parsed for their types,
which are dumped into the grammar to parse C. Since Perl comes with a
generic C file, this is used as the default. It contains all
the types listed above and more. 

This allows XS programmers to use their old typemaps when switching to
C. It also allows other modules (like Event.pm) which have an XS
API, to publish that API to C seamlessly, using a syntax like
"use Inline with => 'Event';"

Version 0.30 will also support the following syntax:

use Inline;
print add(2, 4);
__END__

=pod

blah blah blah

=cut

__C__
int add(int x, int y) {
  return x + y;
}

If so desired, perl6 might be able to simply recognize the C<__C__>
marker, and not require the C at all. The code would look
like:

print add(2, 4);

__C__
int add(int x, int y) {
  return x + y;
}

__END__

=pod

blah blah blah

=cut

=head1 REFERENCES

RFC 61: Interfaces for linking C objects into perlsubs 

Inline.pm documentation and tutorial:
http://search.cpan.org/doc/INGY/Inline-0.25/lib/Inline.pod
http://search.cpan.org/doc/INGY/Inline-0.25/lib/Inline/Config.pod
http://search.cpan.org/doc/INGY/Inline-0.25/lib/Inline/C/Tutorial.pod

RFC 271 (v1) Subroutines : Pre- and post- handlers for subroutines

[Perl6 RFC Librarian]

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

=head1 TITLE

Subroutines : Pre- and post- handlers for subroutines

=head1 VERSION

  Maintainer: Damian Conway <[EMAIL PROTECTED]>
  Date: 21 September 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 271
  Version: 1
  Status: Developing

=head1 ABSTRACT

In response to the desiderata set out in RFC 194 and in the
Class::Contract module, this RFC proposes a generic "handler" mechanism
that can install behaviours around (before or after) a subroutine invocation.

=head1 DESCRIPTION

=head2 Overall semantics

It is proposed to provide a mechanism which allows two sequences of
"handlers" to be associated with a specific subroutine or built-in
function (hereafter referred to as the I).

One sequence of handlers (the I) would be called
whenever the primary is invoked, but I the body of the primary
is executed. Each handler would itself be a subroutine, and each would
be called with the same argument list as the primary it prefixes, plus
an extra argument (specifically, $_[-1]) representing a slot for the
eventual return value of the primary. This last argument would normally
have the value C.

The second sequence of handlers would be called I the body of the
primary has executed, but I the return value is returned to the
invoking scope. Once again, each handler would itself be a subroutine,
and each would be called with the same argument list as the primary it
postfixes, plus the return value(s) argument ($_[-1]). For a postfix
handlers, this extra argument would hold a reference to an array
containing the value(s) actually returned from its primary.

Normally prefix handlers would be prepended to the appropriate prefix
sequence, whilst postfix handlers would be appended to the appropriate
postfix sequence, thereby preserving the symmetry of pre- and post-fix
handlers. The mechanisms for setting up such sequences are described in
L.


=head2 Prefix Handler Semantics

A prefix handler may do anything that any other subroutine may do. A
typical action might be to trace or log the invocation of the primary
(the C syntax is used to set up a handler, and is explained in
L).

package Foo;

# set up a tracing prefix handler for the subroutine &Foo::bar...

pre bar { 
local $" = ','
my @caller = caller;
print "Called foo with args (@_[0..$#_-1])\n",
  "from @caller[1,2]\n",
  "in contexts: ", join(", ",want);
}

Note that this (correctly) implies that a handler receives the same information
from C and C (RFC ???) as its primary would.

Another common usage would be to acquire resources that the primary will use:

pre read_file {
flock $_[0], LOCK_EX;
}

(For the obvious complement of this usage, see L).

Note that, in all cases, the return value of the handler is ignored.


=head3 Special semantics: changes to arguments

Each handler receives the same argument list: the one that the primary was
called with.

If a handler changes one of the original arguments through the
aliases in its @_ array, those changes a passed on to subsequent
handlers and to the primary itself. For example:

pre tax_payable_on {
$_[0] -= 20.00; # routinely underquote sales price
}


sub tax_payable_on {# now sees prices $20 less than
# specified argument
printf("Tax: %.2lf", $_[0] * 0.1);
}

tax_payable_on(99.95);  # prints 8.00
tax_payable_on(29.95);  # prints 0.99
tax_payable_on( 9.95);  # prints -1.01  (a profit!)


=head3 Special semantics: changes to return value slot

If a handler changes the value of the (normally C) return value slot
(i.e. $_[-1]), then the remaining handlers (prefix and postfix) are still
called, but the primary itself is I called. Instead, the defined
value in $_[-1] is used as the return value for the primary.
This allows techniques such as memoization to be implemented:

my %sin_cache = (
  0   =>  0,
  1.5707963267949 =>  1,
  3.1415926535898 =>  0,
  4.7123889803847 => -1,
  6.2831853071796 =>  0,
);

pre CORE::sin {
$_[-1] = $sin_cache{$_[0]}; # short-circuit if cache
# value defined
}


One might also use this feature to short-circuit upon failure to acquire
resources:

pre read_file {
flock($_[0], LOCK_EX|LOCK_NB)
or $_[-1] = ""; # Can't lock file so...
# "No data for you!"
}


=head3 Special semantics: exceptions

If a handler throws an exception, that exception is imm