Re: Pre-Freeze notice for RFC: 199 Short-circuiting built-in function s and user-defined subroutines

[Tom Hughes]

In message <2920001558$[EMAIL PROTECTED]>
  Garrett Goebel <[EMAIL PROTECTED]> wrote:

> I'm particularly interested in commentary for and against:
> - the proposal as a whole

I think there's a big difference between the sort of short
circuiting provided by RFC 199 which I feel is best reserved
for cases where the function wants to terminate in a data
sensitive way, and lazy evaluation which I feel is a better
match for cases where the workload can be reduced in a context
sensitive way.

In other words if we notice that grep is being used in a boolean
context then we can terminate it as soon as we get a match without
any user intervention. Equally if map is assigned to a list of two
variables we can stop it as soon as we have generated those two
values. The only problem is side effects.

If people are worried about the side effect issue (and it is a
big problem) then I feel the lazy keyword suggested elsewhere is
a cleaner solution for those cases than your proposal.

> - the various syntax/semantics changes proposed

I think it requires too much user intervention for the common
cases of terminating a function early on the basis of context.

For data sensitive terminate I don't have a big problem with it.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...Somehow, somewhere along the line, this town lost its pride.

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

[Graham Barr]

On Tue, Sep 19, 2000 at 10:11:23PM -0700, Nathan Wiger wrote:
>undef null
>  
>$a = undef;   $a = null;
>$b = 1;   $b = 1;
>$c = $a + b;  $c = $a + $b;
> 
>$c is 1   $c is null

If you want different semantics for undef then use a pragma, that is
what pragmas are for.

  use tristate;

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

  $c is undef

I did mention this to Larry and his answer was, "you can do anything you
like with pragmas"

However I would suggest that many, including myself, would not like
to see perls values have yet another state of null

Graham.

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

[Graham Barr]

On Wed, Sep 20, 2000 at 12:00:05AM -0700, Russ Allbery wrote:
> Perl already has exactly the data value that you're looking for.  This RFC
> is proposing to fix the wrong problem; the things that need to be changed
> (conditionally) are the logical operators, not the data value.

Absolutley, although I would not limit it to just the logical
operators.

Graham.

Re: RFC 76 (v3) Builtin: reduce

[Graham Barr]

On Wed, Sep 20, 2000 at 05:08:26AM -, Perl6 RFC Librarian wrote:
> =head1 ABSTRACT
> 
> This RFC proposes a built-in C function, modelled after Graham
> Barr's C subroutine from the List::Utils module (a.k.a. The
> Module Formerly Known As builtin.pm).


:-)

> If fewer than N-1 elements would be available for the final reduction
> call, a exception is thrown. Note that this exception could be thrown
> I the reduction begins, by determining the total number of elements
> to be reduced (I) and the number of elements to be processed on each
> reduction step (I) and testing whether the resulting number of steps --
> (I-I)/(I-1) -- is integral.

This would preclude the list from ever being lazy as you will have to expand
it. I would also not that

  @array = (1,2,3);
  %hash = @array;

just gives a warning and the element 3 gets undef. Similar has been suggested
for

  for my($x,$y) ( @array) { ... }

would give a warning on the final iteration and $y would be undef.

I would suggest

I there is 1 element, it is returned. If there are fewer than N elements
for the first reducetion, or N-1 elements for the final reduction, then
a warning is given and undef is passed for the missing elements to the
reduction call.

This does not force exception handling on the user and leaves what to do
upto them.

Graham.

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

[H . Merijn Brand]

On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> =head1 TITLE
> 
> Add null() keyword and fundamental data type
> 
> =head1 MIGRATION
> 
> None. New functionality.

Not true. Apart from the discussion if undef is the same as null, in which I
take no stance, Migration *is* an issue, cause if the null state is available,
DBI/DBD users *will* expect that NULL values from the database are yielded as
null values in perl and not as undef, the way it is implemented now. Same when
inserting data.

-- 
H.Merijn Brand   Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.005.03, 5.6.0, 5.7.1 & 516 on HP-UX 10.20 & 11.00, AIX 4.2 & 4.3,
 DEC OSF/1 4.0 and WinNT 4.0 SP-6a,  often with Tk800.022 and/or DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

Re: RFC 262 (v1) Index Attribute

[Webmaster]

David Nicol Wrote in RFC 262:
>foreach $item (@items){
>#print "$item was at location ",$item:n,"\n";
>print "$item was at location ${item:n}\n";
>};

What would really be nice here is an C function, similar to the
scalar version, that returns the index of the matching entry in a list. For
instance:

my $n=0;
foreach (@items){
 print "Found It at position $n!\n" if /$seek/;
 $n++;
}
Could be replaced by:
if (my $n = arrindex( @items, $seek )) {
 print "Found It at position $n!\n" ;
}
Grant M.
[EMAIL PROTECTED]

Re: RFC 262 (v1) Index Attribute

[Graham Barr]

On Wed, Sep 20, 2000 at 08:05:20AM -0400, Webmaster wrote:
> David Nicol Wrote in RFC 262:
> >foreach $item (@items){
> >#print "$item was at location ",$item:n,"\n";
> >print "$item was at location ${item:n}\n";
> >};
> 
> What would really be nice here is an C function, similar to the
> scalar version, that returns the index of the matching entry in a list. For
> instance:
> 
> my $n=0;
> foreach (@items){
>  print "Found It at position $n!\n" if /$seek/;
>  $n++;
> }
> Could be replaced by:
> if (my $n = arrindex( @items, $seek )) {
>  print "Found It at position $n!\n" ;
> }

Well if there ever is a way to shortcut grep this could be genera;ized
to

  my $index = grep { break if $_ eq $seek; 1 } @items;

assuming `break' causes the shortcut

An therefore allowing more comparisons than just eq

Graham.

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

[Eric Roode]

1. You don't say in your RFC, but I'm guessing, that a null value
evaluates to false in a boolean context. Correct?

2. In your abstract, you say that undef is used to mean that a 
variable's value is undefined, which I presume means uninitialized.
You say that null would provide a useful way to indicate that a
variable's value is known to be unknown or not applicable. Then, 
at various places in the RFC, you use a hypothetical 
use initialize 'null';
construct to initialize all new variables to null. Doesn't that 
defeat the purpose, and make null equivalent to undef?

3. Your RFC does not specify how a null value stringizes. What
is the output from:

$a = null;
print "a is '$a'";

I can see two possibilities: "a is ''" and "a is 'null'". 
I personally would greatly prefer the first.
Would the use of a null value in a string generate a warning, as
an undef value does now?

 --
 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 262 (v1) Index Attribute

[Webmaster]

Graham Barr Wrote:
>Well if there ever is a way to shortcut grep this could be genera;ized
>to
>
>  my $index = grep { break if $_ eq $seek; 1 } @items;

Wouldn't this also assume that grep return the number of times the block was
NOT true, rather than it's current implementation of the number of times it
IS true? I think that in the example, grep would simply return either '1' or
'0', unless there was some easy way to say:

my $index = grep { while( $_ ne $seek) } @items;

I might be wrong here, though. It's still early.
Grant M.
[EMAIL PROTECTED]

Re: RFC 262 (v1) Index Attribute

[Graham Barr]

On Wed, Sep 20, 2000 at 09:03:39AM -0400, Webmaster wrote:
> Graham Barr Wrote:
> >Well if there ever is a way to shortcut grep this could be genera;ized
> >to
> >
> >  my $index = grep { break if $_ eq $seek; 1 } @items;
> 
> Wouldn't this also assume that grep return the number of times the block was
> NOT true,

But in that example the block is always true, thats what the 1 is for.

Graham.

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

[Konovalov, Vadim]

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

I'm quite sure that adding "null" into the language will complicate
programming and hardly will give any benefits. One should differentiate
between "null" and "undef", sometimes (or better always!) check variables
with defined(...) *and* isnull(...).
It is not easy to explain to novice difference between
"$var=undef","$var=null" and "undef $var", because difference will be too
hard to feel.
There will be many bugs because of "undef ne null".


&Vadim;

Re: RFC 76 (v2) Builtin: reduce

[John Porter]

Graham Barr wrote:
> 
> But what does it do if the block
> is a curried function of three arguments, but the list only contains two ?

Return a curried function of one argument, of course.

At least, that's what it *should* do...

-- 
John Porter

Re: RFC 76 (v2) Builtin: reduce

[John Porter]

iain truskett wrote:
> 
> Return a specified value (such as 'undef'). It would allow for more
> elegant code, I think. The universe is old enough to cope by itself.

When I first read this, I thought it said:

The universe is old enough to copy itself.

!-)

-- 
John Porter

Re: RFC 76 (v2) Builtin: reduce

[John Porter]

Nathan Wiger wrote:
> 
> Since undef() has established semantics, I don't think these should
> change. I believe taking from RDBMS and adding null() which has the
> correct NULL semantics is the way it should go.

You realize, I hope, that there is no end of different "special non-value"
semantics.  Perl had one, now you're proposing a second.  RDBMS gurus
have as many as 29.  One step down that path is a bad precedent.
undef is sufficient.  Let there be operators for implementing the various
semantics, NOT new special non-value values.

-- 
John Porter

We're building the house of the future together.

Generalized (taint-like) attributes (was Re: RFC 258)

[John Porter]

Tom Christiansen wrote:
> 
> You want to have more properties that work like tainting does: a
> per-SV attribute that is enabled or disabled by particular sorts
> of expressions, sometimes dependent upon the previous presence or
> absence of that property, other times, not so.

While we're at it, let's unify this with the attribute system
we have.  We'd like to be able define new attributes, get and
set their values, and attach behaviors to their access.
We have been assured that this should be easy to do in user code.

-- 
John Porter

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

[John Porter]

Nathan Wiger wrote:
> 
>undef null
>  
>$a = undef;   $a = null;
>$b = 1;   $b = 1;
>$c = $a + b;  $c = $a + $b;
>$c is 1   $c is null

Uh, this is a difference in the implementations of the '+'
operator, not the data value undef/null.
Operators that treat undef the way SQL treats null are
trivial to implement.


> The keyword C means that a value is B. 

Maybe in your head; not in perl (the implementation).


-- 
John Porter

We're building the house of the future together.

Re: RFC 255 (v2) Fix iteration of nested hashes

[Dave Storrs]

On Tue, 19 Sep 2000, Tom Christiansen wrote:
> >This RFC proposes that the internal cursor iterated by the C function 
> >be stored in the pad of the block containing the C, rather than
> >being stored within the hash being iterated.
> 
> Then how do you specify which iterator is to be reset when you wish 
> to do that?  Currently, you do this by specifying the hash.  If the

Suppose we change each to be:
each HASH
each ITERATOR
and create a new keyword,
iterator HASH 
which creates a new iterator for the specified hash.  This iterator can
then be eached, just like the hash, and reset using
reset ITERATOR

Usage would then look like this (stealing Damian's code):

%desc = ( blue  => "moon",
  green => "egg",
  red   => "Baron" );

$i1 = iterator %desc;
$i2 = iterator %desc;
while ( my ($key1,$value1) = each $i1)
{
  while ( my ($key2,$value2) = each $i2 )
  {
 print "$value2 is not $key1\n" unless $key1 eq $key2;
  }
}
print "(finished)\n";


This runs into problems if you currently have an iterator extant and you
modify the hash to which it points.  Immediate suggestions on how to
handle this would be:

1) Do what the docs currently do; tell people "don't do that"
2) Have the iterator auto-reset when the hash is modified
(probably bad)
3) Make the hash unmodifiable while there is an iterator extant
(probably bad)
4) Make powerful magic in some way that isn't coming to mind


Dave

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

[Nathan Wiger]

> If you want different semantics for undef then use a pragma, that is
> what pragmas are for.

> However I would suggest that many, including myself, would not like
> to see perls values have yet another state of null

Here's my concern about changing the meaning of undef. Convince me this
is not a concern and I'll change the RFC appropriately.

undef has a very well-defined (ha!) Perl meaning: that something is
undefined. null has a very well-defined RDBMS meaning: that something is
unknown. Perl allows you to add and concatenate stuff to undef, because
that value can be coerced into 0 and "" without harm. The concept of
null does not allow you to do this, because a null value is unknown: it
may be undef, or 0, or -3.2e14, or "bob", but you *don't know*.

Using the proposed tristate pragma does not strike me as any better -
in fact, worse - than adding null() because you are now changing the
meaning of fundamental Perl operations. You're *still* introducing "yet
another state of null", but to do so you're conflating undef and null,
which are themselves different concepts. For example, assuming this
code:

   $name = undef;
   print "Hello world!" if ($name eq undef);

The same operation would print "Hello world!" in one circumstance, but
nothing under the tristate pragma. This is just as dangerous as having a
pragma like so:

   use 'zeroistrue';
   $num = 0;
   print "Got data" if ( ! $num );

Where the above would print out "Got data" normally, but not under the
pragma.

That's my concern, in a nutshell. Convince me this is invalid (similar
Perl precedent would help) and I'll change the RFC into a "use tristate"
pragma.

-Nate

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

[Graham Barr]

On Wed, Sep 20, 2000 at 08:30:44AM -0700, Nathan Wiger wrote:
> Using the proposed tristate pragma does not strike me as any better -
> in fact, worse - than adding null() because you are now changing the
> meaning of fundamental Perl operations. You're *still* introducing "yet
> another state of null", but to do so you're conflating undef and null,
> which are themselves different concepts. For example, assuming this
> code:
> 
>$name = undef;
>print "Hello world!" if ($name eq undef);
> 
> The same operation would print "Hello world!" in one circumstance, but
> nothing under the tristate pragma.

Right. as opposed to 

print "Hello world!" if ($name eq null);

which would probably do the same.

But the point is that you only use the pragma IF THAT IS WHAT YOU WANT

adding null which is a bit different to undef, then later adding another
with is a litle different again in some way and then 

This is not the way to go.

If you want an operator to act differently on some piece of data then a pragma
is the way to do it.

> This is just as dangerous as having a
> pragma like so:
> 
>use 'zeroistrue';
>$num = 0;
>print "Got data" if ( ! $num );

Whats dangerous about that. It is doing exactly what I asked it to.

Graham.

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

[Jonathan Scott Duff]

On Wed, Sep 20, 2000 at 08:30:44AM -0700, Nathan Wiger wrote:
> This is just as dangerous as having a pragma like so:
> 
>use 'zeroistrue';
>$num = 0;
>print "Got data" if ( ! $num );
> 
> Where the above would print out "Got data" normally, but not under
> the pragma.

Yep, this is bad IMHO.  Your concern is valid I think, but your
"solution" isn't a good one.  Why not just use a module like Damian's
Quantum::Superpositions?  (i.e. create a Null object that propigates
the unknowability of the value through operations)  If it's part of
the standard distribution, then those that want null in perl can have
it and we don't have to live with Yet Another Keyword.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

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

[Damien Neil]

On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> Add null() keyword and fundamental data type

I think that this is better done as a special overloaded object used
by database modules which wish to implement SQL-style tri-state logic.
Given that making overloaded objects fast appears to be a major
design goal of Perl6, there should be no serious performance problems
to this.

The one thing which this requires that Perl5 does not have is the
ability to overload the defined() operation on an object.  Other
than that, the following code produces a usable null object:

  package Null;

  use overload '""' => sub { undef },
   bool => sub { undef },
   '0+' => sub { undef },
   nomethod => sub { bless {} };

  sub null() { bless {}; }

  print "   1 +1 = ", (   1 +1), "\n";  #1 +1 = 22
  print "null +1 = ", (null +1), "\n";  # null +1 =
  print "   1 + null = ", (   1 + null), "\n";  #1 + null =
  print "null + null = ", (null + null), "\n";  # null + null =

  print "defined(null) = ", defined(null), "\n"; # defined(null) = 1  (error)

I don't think that we would be well served by confusing the state of
truth in core Perl any further than it is now, especially when the
desired functionality does not need to be in the core.

Incidentally, I'm surprised that DBI hasn't added an option to use
an overloaded null object, if this feature is in demand.

- Damien

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

[Nathan Wiger]

Graham Barr wrote:
>
> If you want an operator to act differently on some piece of data then a pragma
> is the way to do it.

I was thinking about this on the way to work. As much as I don't like
conflating undef and null, I dislike even more the idea of the 200 pages
in Learning Perl that will have to now be devoted to why these two:

   $name = undef;
   $name = null;

Are not the same thing.

If everyone's in agreement, what I'll do is redraft the RFC to say Perl
6 should include a "use tristate" pragma which obeys blocks:

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


Thoughts?

-Nate

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

[Chaim Frenkel]

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

>> Currently many programs handle error returns by examining the text of
>> the error returned in $@. This makes changes in the text of the error
>> message, an issue for the backwards compatibility police.

TC> eval {  fn() };
TC> if ($@ == EYOURWHATHURTS) {  } 
TC> sub fn { die "blindlesnot" }

I don't understand what you are trying to say.

The RFC was for perl core messages, so I can't see what a user
level error has to do with this.

Issuing a unique error id for non-core modules will be a nightmare.
And I don't think we want to start up a IANA.

The $@->facility, $@->id pair could be considered unique for non-core
errors.


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

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

[Graham Barr]

On Wed, Sep 20, 2000 at 10:00:56AM -0700, Damien Neil wrote:
> On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> > Add null() keyword and fundamental data type
> 
> I think that this is better done as a special overloaded object used

> Incidentally, I'm surprised that DBI hasn't added an option to use
> an overloaded null object, if this feature is in demand.

Probably because of the performance hit it would have.

Graham.

Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines

[Ilya Zakharevich]

On Tue, Sep 19, 2000 at 08:05:50PM -0700, Nathan Wiger wrote:
> > $_ is not ALLCAPS.  @EXPORT_OK should die (see RFC 233).  @ISA is on
> > its way to its grave already, see C.
> 
> Yeah, but you're still just sidestepping my point. Your position seems
> poised on the hope that no more special variables get introduced, or
> that some of the existing ones go away.

Why not?  This is going to be a very good thing too.

> As for the different namespace for subs thing, I don't think that's the
> way to go. You do have to call special subs directly, at the very least
> from other special subs. And what if you wanted to provide an OO and
> tied interface?
> 
>sub STORE {
># store data
>}
>*store = \&STORE;
> 
> If I call $object->store, what will happen if STORE is a special method
> like you propose?

I do not understand what your message is.  If you need to share a
handler and a method, you can always do it like this (as I already explained):

   sub store {
   # store data
   }
   use tie STORE => \&store;

Ilya

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >The warning for the use of an unassigned variable should be "use of
> >uninitialized variable C<$x>".
> 
> The problem with that idea, now as before, is that this check happens
> where Perl is looking at a value, not a variable.  Even were it possible
> to arduously modify Perl to handle explicitly named simple variables,
> there's much more to consider.
> 
> if ( fx() == fy() ) { }
> 
> For one.
> 
> --tom

Yes, we've been through this before. :-) And now, as before, that's not
what the RFC is saying. Your fx() example would produce the warning "use
of undefined value". No variable name. Same for the code C. I am not changing the existing warning at all,
just rewording it from "uninitialized" to "undefined", because that's
what it is. 'Initialized' means you've assigned something to it at least
once; undefined means defined() returns false.

I am merely suggesting that the compiler detect, when it can, that
you're trying to use the value of a variable without ever having
assigned a value to that variable. And in THAT message, you had better
know the name of the variable, since it's the basis of the analysis. And
yes, it only handles simple named variables.

Example:

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)

I'll add this example to the RFC.

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

[John Porter]

Nathan Wiger wrote:
> 
> Here's my concern about changing the meaning of undef. 
> 
> undef has a very well-defined (ha!) Perl meaning: that something is
> undefined. 

Here's something you and Glenn don't seem to understand:
it doesn't *matter* what the human meaning of undef is.
Call it undefined, uninitialized, unknown, etc. etc.
What matters is that in the perl machine, it's a different
kind of value that a scalar can have, besides string, number,
reference, filehandle, etc.

The special behavior of undef is implemented in code.
If you want a special value (undef) to have different
semantics, and thus to be treated differently, you do
it in code.


> The concept of
> null does not allow you to do this, because a null value is unknown: it
> may be undef, or 0, or -3.2e14, or "bob", but you *don't know*.

False.  Null cannot, by definition, be 0, -3.2e14, or "bob", because
those are not "unknown" values.  Put another way,

( "bob" is null )

can NEVER be true.


> ...you are now changing the meaning of fundamental Perl operations.

Yes; that's why it's a lexically scoped pragma.


> You're *still* introducing "yet another state of null", 

No, you're only changing the behavior of the operations.
undef is still just undef.


> This is just as dangerous as having a pragma like so:
> 
>use 'zeroistrue';
>$num = 0;
>print "Got data" if ( ! $num );

Dangerous?  Well, this is perl.   Caveat programmor.


-- 
John Porter

We're building the house of the future together.

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

[John Porter]

Nathan Wiger wrote:
> 
> ...a "use tristate" pragma which obeys blocks

bka "lexically scoped".  If I'm not mistaken, pragmas *are* lexically scoped.

-- 
John Porter

Re: RFC 12 (v2) variable usage warnings

[Tom Christiansen]

And what about $$x?

Dang, are we back to this incredible confusion about what it is to be
defined in Perl.?

undef $a;

That is now UNINITIALIZED.  So is this:

$a = undef;

You have initialized it to undef.  There is no reasonable difference.

Solution:

Remove all references from the language to defined and undef.
People just aren't smart enough to understand them.  Change
defined() to read has_a_valid_initialized_scalar_value().  Change
undef() to "operator_to_uninitialize_a_variable".  Touch luck
on the chumps who can't type well.  They pay for their brothers'
idiocy.

repeat until blue:

  INITIALIZED ==   DEFINED
UNINITIALIZED == UNDEFINED


--tom

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

[Tom Christiansen]

>Here's something you and Glenn don't seem to understand:
>it doesn't *matter* what the human meaning of undef is.
>Call it undefined, uninitialized, unknown, etc. etc.
>What matters is that in the perl machine, it's a different
>kind of value that a scalar can have, besides string, number,
>reference, filehandle, etc.

Unfortunately, people don't seem to be able to read the documentation
about these matters.  Time to remove them from the language.  It's
too hard.

--tom

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

[Tom Christiansen]

>Nathan Wiger wrote:
>> 
>> ...a "use tristate" pragma which obeys blocks

>bka "lexically scoped".  If I'm not mistaken, pragmas *are* lexically scoped.

They *can* be.  They needn't be.

--tom

Re: RFC 12 (v2) variable usage warnings

[Eric Roode]

Steve Fink wrote:
>I am merely suggesting that the compiler detect, when it can, that
>you're trying to use the value of a variable without ever having
>assigned a value to that variable. And in THAT message, you had better
>know the name of the variable, since it's the basis of the analysis. And
>yes, it only handles simple named variables.

Um, "when it can"? Isn't this considered a Hard Problem by the 
computer scientists? 


>Example:
>
>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)

How about:

foo();
$x = 1  unless defined($x);
print $x;

Generate a warning, or not?

Or:
foo();
print $x;

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

 --
 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 263 (v1) Add null() keyword and fundamental data type

[Glenn Linderman]

John Porter wrote:

> Nathan Wiger wrote:
> >
> >undef null
> >  
> >$a = undef;   $a = null;
> >$b = 1;   $b = 1;
> >$c = $a + b;  $c = $a + $b;
> >$c is 1   $c is null
>
> Uh, this is a difference in the implementations of the '+'
> operator, not the data value undef/null.
> Operators that treat undef the way SQL treats null are
> trivial to implement.

With the multitudinous operator approach, please show me how to make
each of the following conditional statements print true, without
cluttering the code with interleaved additional pragmas and scoping
blocks.  Use of pragmas before the code might be acceptable.

 no strict;
 $a = undef;
 $b = null;
 $c = $a + $b;
 $d = $a + 1;
 $e = $b + 1;

 print "true"  if defined $c;
 print "true"  if defined $b;
 print "true"  if isnull $e;
 print "true"  if defined $d;
 print "true"  if $d == 1;
 print "true"  if $e != 1;
 print "true"  if ! ($b == 0);
 print "true"  if $a == 0;

The multitudinous operator approach is not a solution.

--
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 263 (v1) Add null() keyword and fundamental data type

[Glenn Linderman]

Damian Conway wrote:

>> > Should I point out that RFC 225 (Superpositions) actually covers
>> > most of this?
>> >
>> > C is equivalent in semantics to C or C.

> I hope you won't mind my pointing out that the documentation of the
> Quantum::Superpositions module -- to which the RFC also refers -- does
> provide a comprehensive exposition of superpositions.
>
> I take the liberty of reprinting it for you below.

Indeed.  That is very helpful, although rather complex conceptually, I like the
power it brings to a simple syntax.  It does appear that the equivalence stated is
correct, although the full implementation of RFC 225 would be more extensive than
that of the more limited RFC 263.

I can also imagine that a straightforward implementation of RFC 263 (one bit to
indicate distinguished value, overload the "actual value" field (which would be
otherwise unused) to indicate what type of distinguished value (undef, NULL) could
be extended to implement all 29 flavors of NULL that are known to relational
theorists.  It is less clear that superpositions has an obvious extension to
multiple types of NULL.  On the other hand, it is not clear that all 29 flavors of
NULL that are known to relational theorists are necessary, but I'd hate to preclude
them.

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

"Konovalov, Vadim" wrote:

> I'm quite sure that adding "null" into the language will complicate
> programming and hardly will give any benefits. One should differentiate
> between "null" and "undef", sometimes (or better always!) check variables
> with defined(...) *and* isnull(...).

Unlike undef, which gets assigned to uninitialized variables, NULL is only
used by choice.  So you only need deal with NULL when there is the
possibility that it needs to be handled in some special way, and might exist
as a value in the expression being handled.

> It is not easy to explain to novice difference between
> "$var=undef","$var=null" and "undef $var", because difference will be too
> hard to feel.

The novice need not use NULL until he is an expert, or is dealing with
databases.  As an expert, it is not hard to understand the difference, and if
dealing with databases, there is a definite need to understand the
difference.

> There will be many bugs because of "undef ne null".

There will be more bugs if people try to use undef as 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]

"H.Merijn Brand" wrote:

> On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > =head1 TITLE
> >
> > Add null() keyword and fundamental data type
> >
> > =head1 MIGRATION
> >
> > None. New functionality.
>
> Not true. Apart from the discussion if undef is the same as null, in which I
> take no stance, Migration *is* an issue, cause if the null state is available,
> DBI/DBD users *will* expect that NULL values from the database are yielded as
> null values in perl and not as undef, the way it is implemented now.

I agree that migration is an issue for DBI and scripts that use it and do
non-trivial data manipulations; but for non-database-oriented scripts, there would
be no migration issue.  I would expect this is a simple fix for DBI internals, not
sure the impact on DBI users, except that it will be beneficial for writing higher
level DB functions, so probably worth whatever conversion pain there is.

> Same when
> inserting data.

This is also an issue, probably it could be dealt with by converting undef to null
when it is clearly becoming an entry in a database which doesn't support undef.
use strict should probably diagnose that.

>
>
> --
> H.Merijn Brand   Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
> using perl-5.005.03, 5.6.0, 5.7.1 & 516 on HP-UX 10.20 & 11.00, AIX 4.2 & 4.3,
>  DEC OSF/1 4.0 and WinNT 4.0 SP-6a,  often with Tk800.022 and/or DBD-Unify
> ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

--
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 76 (v2) Builtin: reduce

[Glenn Linderman]

John Porter wrote:

> Nathan Wiger wrote:
> >
> > Since undef() has established semantics, I don't think these should
> > change. I believe taking from RDBMS and adding null() which has the
> > correct NULL semantics is the way it should go.
>
> You realize, I hope, that there is no end of different "special non-value"
> semantics.  Perl had one, now you're proposing a second.  RDBMS gurus
> have as many as 29.  One step down that path is a bad precedent.
> undef is sufficient.  Let there be operators for implementing the various
> semantics, NOT new special non-value values.

29 different, but complete, sets of operators would be required, and you would
be restricted to using only one of the "special non-value" values at a time.
RDBMS gurus need at least some of their 29 to coexist.   Not a solution.

--
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 263 (v1) Add null() keyword and fundamental data type

[Glenn Linderman]

Russ Allbery wrote:

> Glenn Linderman <[EMAIL PROTECTED]> writes:
> > Russ Allbery wrote:
>
> >> I agree with Tom; I think it's pretty self-evident that they're the
> >> same thing.  undef means exactly the same thing as null; that's not the
> >> problem.  The problem is that Perl doesn't implement the tri-state
> >> logic semantics that most users of null are used to, which is a
> >> different issue.
>
> > So, to paraphrase your statement a bit:
>
> > It is self-evident that they're the same, the problem is that they work
> > differently.
>
> No, that's not a paraphrase.  That's saying something completely different
> which is wrong.

I still find it a paraphrase... discussion below.

> If undef functioned differently than null, that would be a bug.

False statement.  undef has the following semantics:

1) all otherwise uninitialized variables are set to undef
2) under "use strict", use of undef in expressions is diagnosed with a warning

3) undef is coerced to 0 in numeric expressions, false in boolean expressions,
and the empty string in string expressions.

The semantics for NULL is different, read the SQL standard.  The _definitions_
of undef and NULL are different; if they functioned the same, that would be a
bug.

>  What's
> missing is a way to say "I want tri-state logic" as a pragma.  When that
> pragma is enabled, undef would be the null-like state.

This could be done, but then you could only use either the concept of undef
(as defined by perl and recapped above), or the semantics of NULL, but not
both.

Another person has suggested privately that rather than a pragma, that
different operators could be provided for all operations, which apply the NULL
functional semantics to their arguments.  This could also be done, but would
require the programmer to choose the desired semantics for every operation, by
choosing the appropriate operator.  It would also double the number of
operators in the language.  Not nice.

> Perl already has exactly the data value that you're looking for.  This RFC
> is proposing to fix the wrong problem; the things that need to be changed
> (conditionally) are the logical operators, not the data value.

Nope, the data value Perl has has different operational semantics that the
data value this RFC is suggesting.

> > Nota Bene: IEEE floating point defines two different concepts that are
> > not numbers, but can be mixed with numbers in expressions: Inf and NaN.
> > And actually, there are positive and negative varieties of both Inf and
> > NaN.  So I guess you might say that they are the same; but the problem
> > is that they work differently.
>
> There are positive and negative infinities, but that's a different
> situation entirely; infinity is a degenerate value, not an undefined
> value.  This is the first time I've ever heard of -NaN; are you sure about
> that?  (There are, in fact, different types of NaN, such as signalling vs.
> non-signalling, but that's due to floating point traps and exceptions,
> issues that don't crop up in the situations where you want undef/null.)

Sorry, the intended point was that IEEE float has (1) multiple types of
distinguished, non-numeric values with different semantics and (2) for each
type of distinguished, non-numeric value it has, multiple values of that type
exist.

However, there are legal forms of NaN with the sign bit set, and legal forms
of NaN with the sign bit reset.  They are not called positive and negative,
however, that was an oversimplification.

--
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 263 (v1) Add null() keyword and fundamental data type

[Glenn Linderman]

Sam Tregar wrote:

> On Tue, 19 Sep 2000, Glenn Linderman wrote:
>
> > They are different.  Neither is a mistake.
>
> How do you explain the fact that every SQL book I've ever seen has
> included copious text on problems concerning NULL?

I'm not sure what SQL books you've seen.  The standard treatise on SQL 92, Jim
Melton's "SQL: A Complete Guide", doesn't seem to include copious text on problems
concerning NULL.

> Why do so many RDBMs
> implement NULL differently?

Please give examples of RDBMS's and how they implement NULL differently.  There is
an ANSI/ISO standard for SQL prescribing the behavior of NULL.  If you are speaking
of the interfaces supplied to allow other languages to deal with NULL because they
don't support the concept in the same way as SQL, tha problem results because of
the other languages not supporting NULL.  Perl could get a leg up here by
supporting it.  I cannot comment further until I see more details about your claim
that they are implemented differently.

> If you can't agree that NULL was a mistake
> you must at least realize that it's difficult for most programmers to
> understand.

I will go as far as to admit that a programmer that has never learned the SQL
language is unlikely to be familiar with the ramifications of supporting NULL...
it's semantics affect many different operators.  If they jump to a conclusion that
NULL is "kind of like Perl undef" (or any other concept which has different
semantics altogether), then they will have difficulties each time they discover one
of the semantics of NULL that doesn't fit their assumption that NULL is the "kind
of like" that other concept.  I recommend that programmer's learn a whole concept
before using it.  I have had no particular difficulty grasping the NULL concept,
but I'm a sample of one, which has no statistical significance.

> > > Perhaps you could show an example using DBI where having NULLs mapped to
> > > undef is actually a problem?
> >
> > If one (you wouldn't, I suspect) wanted to write expressions in Perl that had
> > the same semantics as expressions in SQL, which could come in handy for
> > further manipulating data obtained from SQL, then mapping NULLs to undef
> > doesn't make that easier.
>
> That's not an example.

No, it's a general statement of a class of problem which is difficult to solve
without the concept of NULL.

> What you just described is actually a bad idea.

If your data must come from separate databases, and you need to further manipulate
it, it is actually an extremely good idea, that would allow Perl to fill an
extremely useful niche.

> If you want to program in SQL you know where to find it.

Yes, I do.  Inside each database.  But it is more difficult to access one database
from inside another.  The support for such is varied and spotty, and not
standardized.

> Your code will
> be faster if it runs in the SQL server and you'll have the full "power" of
> SQL in your hands, NULLs and all.

The performance may vary, depending on which database, and whether the data is
accessible.  Not all databases implement a procedural language today, although the
latest standard prescribes one, so it is coming.

> Do you want to do pointer arithmetic in Perl with data you get from C
> programs too?

No.  Pointers are only useful inside the program that creates them.  I must say
that's one aspect of Perl's pack/unpack that I don't understand: the "p" an "P"
codes... I would guess that they are only useful for the boundary code to help
convert C data into Perl data, because perl is implemented in C?

> > It is not a problem if all you do with DB data is retrieve and/or store.  It
> > is only a problem if you want to do DB style manipulations of the data.
>
> Perl does not do "DB style" manipulation of data.

No, but modules written in Perl do want to do "DB style" manipulation of data.
This would be much simplified is Perl supported NULL.

> Adding NULL won't change that, you'll still be missing all that relational jazz
> that makes
> SQL actually usefull - various flavors of joins, grouping, limiting,
> indexing, etc.  And no, I'm not suggesting that we add them.

You wouldn't.  But adding modules that do joins, grouping, and other reporting
based on data from multiple databases would mesh nicely with the other reporting
applications Perl can already perform.  I'll be glad to suggest that we add such
modules, although probably not to core, although someone has RFCd the idea of
making the core module set bigger and mentioned DBI as an example, so maybe such
modules would fit with that.

> > The semantics of NULL neither require nor desire warnings.
>
> There's the problem.  It's not just my problem, it's a problem for a large
> portion of the users of SQL.  NULLs just slide on by, masquerading as real
> values but behaving like invaders from another dimension.

That's not a problem.  That's the definition of NULL semantics.  If you wish to
maintain a mental block about the usefulness and validity of NUL

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

[Tom Christiansen]

>The semantics for NULL is different, read the SQL standard.  

Perl has no business contaminating itself with SQL.

--tom

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

[Glenn Linderman]

Bad idea.  See my multitudinous posts on why.  Briefly:

1) can't use null and undef together
2) not extendable to 29 versions of null, when SQL defines them

Nathan Wiger wrote:

> Graham Barr wrote:
> >
> > If you want an operator to act differently on some piece of data then a pragma
> > is the way to do it.
>
> I was thinking about this on the way to work. As much as I don't like
> conflating undef and null, I dislike even more the idea of the 200 pages
> in Learning Perl that will have to now be devoted to why these two:
>
>$name = undef;
>$name = null;
>
> Are not the same thing.

It only takes a few pages, and a few truth tables to explain NULL.  It should only
take a few pages and a few examples, to explain the difference between undef and
null.

> If everyone's in agreement, what I'll do is redraft the RFC to say Perl
> 6 should include a "use tristate" pragma which obeys blocks:
>
>$a = undef;
>$b = 1;
>$c = $a + $b;# 1
>{
>   use tristate;
>   $d = $a + $b; # undef
>}
>$e = $c + $d;# 1
>
> Thoughts?

That is useless.  It is an attempt to pack 2 data values, null, and undef, into the
same 1/2 bit [1 => number, 0 => either undef or null, depending on no/use tristate].

> -Nate

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

[Tom Christiansen]

>Unlike undef, which gets assigned to uninitialized variables, NULL is only
>used by choice.  So you only need deal with NULL when there is the
>possibility that it needs to be handled in some special way, and might exist
>as a value in the expression being handled.

This can be done without being in the language.  Return a ref to a
blessed object whose stringification or numification method raises
an exception.  

>The novice need not use NULL until he is an expert, or is dealing with
>databases.  As an expert, it is not hard to understand the difference, and if
>dealing with databases, there is a definite need to understand the
>difference.

I completely disbelieve.  Changing the fundamental nature of what
a VALUE is in Perl is hardly something you can hide.  The amount
of pain people seem to go through already understanding this stupid
spectre out of database hell is sufficient to run in terror.

--tom

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

[Tom Christiansen]

> no strict;
> $a = undef;
> $b = null;

Perl already has a null string: "".

--tom

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

[Eric Roode]

Glenn Linderman wrote:
>Eric Roode wrote:
>
>> 1. You don't say in your RFC, but I'm guessing, that a null value
>> evaluates to false in a boolean context. Correct?
>
>I would expect it to be considered false.  Logical expressions involving
>NULL are defined to be "undefined", actually, which is not considered true.

Hmmm. So:

$a = null;
$b = ($a == 42);
print defined($b)? "defined" : "not defined";

would print "not defined", maybe?


[snip]
>$NULL = "NULL";
>
>could be the default; and $NULL could be set to anything desired to be the
>stringization for NULL.  Setting $NULL to NULL would be special, and
>equivalent to the $NULL = "NULL".  Setting $NULL to undef could result in
>warnings during stringization of NULL.

And setting $NULL=null could result in infinite loops :-)

 --
 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 263 (v1) Add null() keyword and fundamental data type

[iain truskett]

* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
> > no strict;
> > $a = undef;
> > $b = null;

> Perl already has a null string: "".

Looks more like a string of no length than a null string.

-- 
iain.

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

[Glenn Linderman]

Damien Neil wrote:

> On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> > Add null() keyword and fundamental data type
>
> I think that this is better done as a special overloaded object used
> by database modules which wish to implement SQL-style tri-state logic.

It could be done as an overloaded object.  You'd have to be able to overload all
the operators, both numeric and string.

> Given that making overloaded objects fast appears to be a major
> design goal of Perl6, there should be no serious performance problems
> to this.

And it would, indeed, have to be fast.

> The one thing which this requires that Perl5 does not have is the
> ability to overload the defined() operation on an object.

And what about overloading the ternary ?: operator?  Of course, that one can be
avoided.

> Other
> than that, the following code produces a usable null object:
>
>   package Null;
>
>   use overload '""' => sub { undef },
>bool => sub { undef },
>'0+' => sub { undef },
>nomethod => sub { bless {} };
>
>   sub null() { bless {}; }
>
>   print "   1 +1 = ", (   1 +1), "\n";  #1 +1 = 22
>   print "null +1 = ", (null +1), "\n";  # null +1 =
>   print "   1 + null = ", (   1 + null), "\n";  #1 + null =
>   print "null + null = ", (null + null), "\n";  # null + null =
>
>   print "defined(null) = ", defined(null), "\n"; # defined(null) = 1  (error)

Not usable, I get lots of "Use of uninitialized value in print" warnings, and do
not have use strict.

> I don't think that we would be well served by confusing the state of
> truth in core Perl any further than it is now, especially when the
> desired functionality does not need to be in the core.
>
> Incidentally, I'm surprised that DBI hasn't added an option to use
> an overloaded null object, if this feature is in demand.

Performance.

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

[Tom Christiansen]

Perl has *one* out-of-band value.  It doesn't need more.  That
doesn't mean that perhaps some rare sorts of programming might not
benefit from fancy weirdnesses.  That's what modules are for.
You don't need to complicate the general language to get what
you want.  Don't make others pay for your problems.

>1) all otherwise uninitialized variables are set to undef

Wrong.  You cannot say that an aggregate is undef.  Scalar
variables--not all variables, just scalar variables alone--hold the
uninitialized value, henceforth known as the antiïinitialized value,
if they were last initialized to the antiïinitialized value, or if
they haven't been initialized at all--in which case, I suppose, you
*might* choose to call it _a_n_t_eïinitialized instead of antiïinitialized,
but then you'll get people wanting to split those up again.

>2) under "use strict", use of undef in expressions is diagnosed with a warning

Wrong.  You are thinking, perhaps, of `use warnings', not `use strict'.
In particular, 

use warnings qw'uninitialized';

>3) undef is coerced to 0 in numeric expressions, false in boolean expressions,
>and the empty string in string expressions.

I'm not happy with your use of "coerce".  There's no mutation.  It simply
*is* those things.  It's not quite kosher to claim that undef gets "coerced"
to false in Boolean expresions.  The antiïinitialized value *is* a false
value.  The only false number is 0, and therefore the antiïinitialized 
numeric value is 0.  Yes, we have two false strings--lamentably--but since
we need a canonical one (eg the result of 1 == 2), we choose "".

You also forgot this:

4) The antiïinitialized value is autovivified to a true value when
used that value is (legally) used lvaluably.  

Notice also this:

% perl -le 'use warnings; $a = 1 == 2; print $a->[1] ? "good" : "bad"'
bad

% perl -le 'use strict;   $a = 1 == 2; print $a->[1] ? "good" : "bad"'
Can't use string ("") as an ARRAY ref while "strict refs" in use at -e line 1.
Exit 255

--tom

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

[Tom Christiansen]

>$a = null;
>$b = ($a == 42);
>print defined($b)? "defined" : "not defined";

>would print "not defined", maybe?

In a sane world of real (non-oo-sneaky) perl, the "==" operator returns 
only 1 or "".  Both are defined.

--tom

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

[Tom Christiansen]

>It only takes a few pages, and a few truth tables to explain NULL.
>It should only take a few pages and a few examples, to explain the
>difference between undef and null.

Ah, so the cost of this is twice a few pages of explanation, plus truth 
tables and examples?  Are you mad?

I can think of no better proof that this is the Wrong Thing than 
your very own words.  Thank you.

---tom

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

[Tom Christiansen]

>* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
>> > no strict;
>> > $a = undef;
>> > $b = null;

>> Perl already has a null string: "".

>Looks more like a string of no length than a null string.

Well, it's not.  That's a null string.  You're thinking of "\0", 
a true value in Perl.

Here are the canonical definitions:

NULL STRING:
A string containing no characters, not to be confused with
a string containing a null character, which has a positive
length.

NULL CHARACTER:
A character with the ASCII value of zero.  It's used by C
and some Unix syscalls to terminate strings, but Perl allows
strings to contain a null.

NULL LIST:
A list value with zero elements, represented in Perl by ().

--tom

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

[Tom Christiansen]

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

>>> Currently many programs handle error returns by examining the text of
>>> the error returned in $@. This makes changes in the text of the error
>>> message, an issue for the backwards compatibility police.

>TC> eval {  fn() };
>TC> if ($@ == EYOURWHATHURTS) {  } 
>TC> sub fn { die "blindlesnot" }

>I don't understand what you are trying to say.

I'm saying that you can't know what to check for, because you don't
know who generated the exception.  Can you use your fancy constants?

And what is "core"?  Compiler?  Interpreter?  Utilities?  Pragmata?
Modules?

Citing IBM as a reference is enough to drive a lot of us away screaming.

Try  or   Notice how much nicer this is.  Few
values, but usable in varied places.

--tom

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

[Casey R. Tweten]

Today around 1:03pm, Tom Christiansen hammered out this masterpiece:

: Perl has *one* out-of-band value.  It doesn't need more.  That
: doesn't mean that perhaps some rare sorts of programming might not
: benefit from fancy weirdnesses.  That's what modules are for.
: You don't need to complicate the general language to get what
: you want.  Don't make others pay for your problems.

=begin half-joking

  use verbose ':all';  # imports null(), true(), false() etc

  if ( $var eq null || false $var ) {
print "This variable _really_ isn't true.";
  }

I'm only half joking because I've been thinking about writing this for a
while.  However, I would probably never use it, personally, I can see times when
others have wanted something close.

=end


-- 

print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce 

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

[iain truskett]

* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 06:09]:
> iain wrote:
> > * Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
> > > > no strict;
> > > > $a = undef;
> > > > $b = null;

> > > Perl already has a null string: "".

> > Looks more like a string of no length than a null string.

> Well, it's not.  That's a null string.  You're thinking of "\0", a
> true value in Perl.

Ah. I wasn't thinking of that, but I had gotten something else confused.
This will teach me to write emails at 6am.

> Here are the canonical definitions:

> NULL STRING:
> A string containing no characters, not to be confused with
> a string containing a null character, which has a positive
> length.

> NULL CHARACTER:
> A character with the ASCII value of zero.  It's used by C
> and some Unix syscalls to terminate strings, but Perl allows
> strings to contain a null.

> NULL LIST:
> A list value with zero elements, represented in Perl by ().

And a NULL SCALAR:
  A scalar value of no value, as distinct from a scalar value of
  undefined value.


cheers,
-- 
\def\Koschei{Iain Truskett}% http://eh.org/~koschei/
\def\WhoAmI#1#2#3#4#5#6{\tt#2#3\it#4#5\bf#6\sl!}\def\i{I}\def\f{i}\def\I
{\if\i\f\f\else\i\fi}\def\Am{am}  \WhoAmI?\I\ \Am\ \Koschei\bye!

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

[Glenn Linderman]

Eric Roode wrote:

> Glenn Linderman wrote:
> >Eric Roode wrote:
> >
> >> 1. You don't say in your RFC, but I'm guessing, that a null value
> >> evaluates to false in a boolean context. Correct?
> >
> >I would expect it to be considered false.  Logical expressions involving
> >NULL are defined to be "undefined", actually, which is not considered true.
>
> Hmmm. So:
>
> $a = null;
> $b = ($a == 42);
> print defined($b)? "defined" : "not defined";
>
> would print "not defined", maybe?

It should.

> [snip]
> >$NULL = "NULL";
> >
> >could be the default; and $NULL could be set to anything desired to be the
> >stringization for NULL.  Setting $NULL to NULL would be special, and
> >equivalent to the $NULL = "NULL".  Setting $NULL to undef could result in
> >warnings during stringization of NULL.
>
> And setting $NULL=null could result in infinite loops :-)

I dealt with that above to avoid the loops.  It is equivalent to $NULL = "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]

Tom Christiansen wrote:

> > no strict;
> > $a = undef;
> > $b = null;
>
> Perl already has a null string: "".

That's an empty string.  In any case, if you really want to call it a
null string, that's fine, just a little more likely to be
misinterpreted.  NULL is neither number nor string, it is null.  $b (per
the example above) is null.  It is not the null string, it is not undef,
it is not zero, and you do not get $200 for passing GO.

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

Tom Christiansen wrote:

> Perl has *one* out-of-band value.  It doesn't need more.  That
> doesn't mean that perhaps some rare sorts of programming might not
> benefit from fancy weirdnesses.  That's what modules are for.
> You don't need to complicate the general language to get what
> you want.  Don't make others pay for your problems.

If it can be built with reasonable performance out of other mechanisms, I'm not
against that.  Just tell me how.  I don't claim to know everything about Perl, just
because I use it a lot.

> >1) all otherwise uninitialized variables are set to undef
>
> Wrong.  You cannot say that an aggregate is undef.  Scalar
> variables--not all variables, just scalar variables alone--hold the
> uninitialized value, henceforth known as the antiïinitialized value,
> if they were last initialized to the antiïinitialized value, or if
> they haven't been initialized at all--in which case, I suppose, you
> *might* choose to call it _a_n_t_eïinitialized instead of antiïinitialized,
> but then you'll get people wanting to split those up again.

OK, scalar variables.  But I see code in the XML modules that check defined (@array)
...

> >2) under "use strict", use of undef in expressions is diagnosed with a warning
>
> Wrong.  You are thinking, perhaps, of `use warnings', not `use strict'.
> In particular,
>
> use warnings qw'uninitialized';

Yep, thanks for the correction.

> >3) undef is coerced to 0 in numeric expressions, false in boolean expressions,
> >and the empty string in string expressions.
>
> I'm not happy with your use of "coerce".  There's no mutation.  It simply
> *is* those things.

Fine.  So, in particular, it _isn't_ null.

> 4) The antiïinitialized value is autovivified to a true value when
> used that value is (legally) used lvaluably.

If, by "true value" in the above, you mean a value other than undef which would be
interpreted as boolean false, then I think I understand what you said.  But not well
enough to have said it, which is why I used coerce.

> Notice also this:
>
> % perl -le 'use warnings; $a = 1 == 2; print $a->[1] ? "good" : "bad"'
> bad
>
> % perl -le 'use strict;   $a = 1 == 2; print $a->[1] ? "good" : "bad"'
> Can't use string ("") as an ARRAY ref while "strict refs" in use at -e line 1.
> Exit 255

Interesting.  I learn something every day.  Today, you helped.  Maybe you can help
some more... implement me an SQL null, that can coexist with Perl undef, not replacing
it.

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

That's not much different than the cost of undef, so I fear it proves
nothing, universally.

Tom Christiansen wrote:

> >It only takes a few pages, and a few truth tables to explain NULL.
> >It should only take a few pages and a few examples, to explain the
> >difference between undef and null.
>
> Ah, so the cost of this is twice a few pages of explanation, plus truth
> tables and examples?  Are you mad?
>
> I can think of no better proof that this is the Wrong Thing than
> your very own words.  Thank you.
>
> ---tom

--
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 230 (v2) Replace C built-in with pragmatically-induced C function

[Damian Conway]

   > Some of oriental characters in Japanese and Korean are usually
   > aligned as if they have 2 columns per character.  
   >
   > Japanese has another formatting rule that punctuation characters
   > cannot appear at the beginning of or end of line (depending on
   > their meanings). 

The proposed C has different breaking behaviour, in that
it doesn't break at all unless it absolutely must, or if the user specifies
an explicit breaking subroutine. I could easily envisage the standard
Format module providing additional standard breaking subs to cover the
(important) internationalization issues you raise: break_16bit, break_kanji,
etc.

Since this would be part of the standard module (and therefore presumably
implemented in C and integrated with the C function itself), I 
don't believe speed would be an issue. 

I will mention this prospect in the final version of the RFC.

Damian

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

[Russ Allbery]

Nathan Wiger <[EMAIL PROTECTED]> writes:

> undef has a very well-defined (ha!) Perl meaning: that something is
> undefined. null has a very well-defined RDBMS meaning: that something is
> unknown. Perl allows you to add and concatenate stuff to undef, because
> that value can be coerced into 0 and "" without harm.

This isn't a major loss with a pragma in effect since -w clean code
already can't do this.  I don't see the harm in changing this to null
semantics when you ask for that.

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

> Using the proposed tristate pragma does not strike me as any better - in
> fact, worse - than adding null() because you are now changing the
> meaning of fundamental Perl operations.

But that's exactly what you want to do.

> You're *still* introducing "yet another state of null", but to do so
> you're conflating undef and null, which are themselves different
> concepts.

I strongly disagree.  You're not changing the data types at all; you're
changing what Perl's operatings (logical, addition, concatenation, etc.)
do with undefined values.  Instead of coercing to 0, you coerce to an
undefined value.

I really like this.  I could see lots of cases other than just databases
where this would be a useful thing to do with undef.  It becomes
considerably less useful if you introduce a new keyword, since then it
requires rewriting code.  Those undef semantics could be useful for error
checking in existing code.

> For example, assuming this code:

>$name = undef;
>print "Hello world!" if ($name eq undef);

So don't do that.  Use C if you want to ask that question.
Most code that I've seen already does that; checking equality with undef
is an odd way of writing it.  *If* you want to use the pragma, just always
write that as C.

> The same operation would print "Hello world!" in one circumstance, but
> nothing under the tristate pragma. This is just as dangerous as having a
> pragma like so:

>use 'zeroistrue';
>$num = 0;
>print "Got data" if ( ! $num );

> Where the above would print out "Got data" normally, but not under the
> pragma.

I strongly disagree here too.  0 as false and 1 as true is an assumption
made in multiple other programming languages, something used by the
majority of Perl scripts that I write, and something that's very
intuitive.  undef semantics, on the other hand, are specific to Perl and
the default is chosen to be friendly to quick and dirty scripts.  Changing
those semantics to propagate undef makes perfect sense to me.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

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

[Russ Allbery]

Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

> Yep, this is bad IMHO.  Your concern is valid I think, but your
> "solution" isn't a good one.  Why not just use a module like Damian's
> Quantum::Superpositions?

No offense to Damian, but I tried to read and understand his documentation
and I thought I was back in grad school.  I don't think it's the fault of
the writing either; I think that Quantum::Superpositions is trying to do
something that's rather too complicated to explain clearly to the average
programmer.

It's a neat idea, but I don't expect to see it ever widely used.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

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

[Russ Allbery]

Glenn Linderman <[EMAIL PROTECTED]> writes:

> With the multitudinous operator approach, please show me how to make
> each of the following conditional statements print true, without
> cluttering the code with interleaved additional pragmas and scoping
> blocks.  Use of pragmas before the code might be acceptable.

>  no strict;
>  $a = undef;
>  $b = null;
>  $c = $a + $b;
>  $d = $a + 1;
>  $e = $b + 1;

>  print "true"  if defined $c;
>  print "true"  if defined $b;
>  print "true"  if isnull $e;
>  print "true"  if defined $d;
>  print "true"  if $d == 1;
>  print "true"  if $e != 1;
>  print "true"  if ! ($b == 0);
>  print "true"  if $a == 0;

Why on earth would you want to do this in real code?

I don't believe you actually need both semantics active at the same time;
it might take really minor rewording of the code (initialize to 0 instead
of undef for counters, etc.), but I'm very unconvinced that you need both
concepts active at the same time.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

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

[Russ Allbery]

Glenn Linderman <[EMAIL PROTECTED]> writes:

> undef has the following semantics:

> 1) all otherwise uninitialized variables are set to undef

And as the RFC says, quite a few times, for database code you often want
all your variables to start as the null value.

> 2) under "use strict", use of undef in expressions is diagnosed with a
> warning

And use of null in an expression would be diagnosed by getting null in the
output.  If you keep them as separate concepts, at this point you're
screwed if that was a bug and you don't know where the null crept in.  If
you keep them the same, you just turn off the pragma for that section and
see where you get the warning.

Keeping them the same lets you turn this warning on selectively for
database code, which could be a significant aid in debugging.

> 3) undef is coerced to 0 in numeric expressions, false in boolean
> expressions, and the empty string in string expressions.

> The semantics for NULL is different, read the SQL standard.

The semantics of undef can be chosen by the programmer.  My point is that
if the undefined value called "undef" and the undefined value called
"null" behave differently in Perl, *that* would be a serious bug in my
opinion.  Talk about horribly confusing.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

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

[Russ Allbery]

Tom Christiansen <[EMAIL PROTECTED]> writes:

>>$a = null;
>>$b = ($a == 42);
>>print defined($b)? "defined" : "not defined";

>> would print "not defined", maybe?

> In a sane world of real (non-oo-sneaky) perl, the "==" operator returns 
> only 1 or "".  Both are defined.

But if you say:

  use tristate;

then $a == 42 returns undef if $a is undef.  Most Perl programs may not
want these semantics, but they're often useful, and for more things than
just databases.  Think error propagation.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

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

[Tom Christiansen]

>That's not much different than the cost of undef, so I fear it proves
>nothing, universally.

YOU OVERQUOTEDsen wrote:

YOU OVERQUOTEDkes a few pages, and a few truth tables to explain NULL.
YOU OVERQUOTEDonly take a few pages and a few examples, to explain the
YOU OVERQUOTED between undef and null.
YOU OVERQUOTED
YOU OVERQUOTEDcost of this is twice a few pages of explanation, plus truth
YOU OVERQUOTEDexamples?  Are you mad?
YOU OVERQUOTED
YOU OVERQUOTED of no better proof that this is the Wrong Thing than
YOU OVERQUOTEDwn words.  Thank you.
YOU OVERQUOTED
YOU OVERQUOTED
YOU OVERQUOTED
YOU OVERQUOTED
YOU OVERQUOTED
YOU OVERQUOTED
YOU OVERQUOTEDe on the right track,
YOU OVERQUOTEDn over if you just sit there.
YOU OVERQUOTED  -- Will Rogers
YOU OVERQUOTED
YOU OVERQUOTEDFree Internet Access and Email__
YOU OVERQUOTED.netzero.net/download/index.html

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

Perl is already too hard.

--tom

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

[Tom Christiansen]

>> For example, assuming this code:

>>$name = undef;
>>print "Hello world!" if ($name eq undef);

>So don't do that.  Use C if you want to ask that question.

That's why I want to change the names of these things.  The current
situation invites errors such as seen previously.  

Actually, one almost wants a warning on "=undef", too.  Well, some uses.  

--tom

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

[Tom Christiansen]

>Tom Christiansen wrote:

>> > no strict;
>> > $a = undef;
>> > $b = null;
>>
>> Perl already has a null string: "".

>That's an empty string.  In any case, if you really want to call it a
>null string, that's fine, just a little more likely to be
>misinterpreted.  

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

It's a shame you don't like it, but this is the way we speak.
If you wish to make sense of the documentation, you must learn
its language.

--tom

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

[Tom Christiansen]

>> I'm not happy with your use of "coerce".  There's no mutation.  It simply
>> *is* those things.

>Fine.  So, in particular, it _isn't_ null.

Of course it's null.  That's why it has length zero.  Stop speaking
SQL at me.  I'm speaking Perl.

>> 4) The antiïinitialized value is autovivified to a true value when
>> used that value is (legally) used lvaluably.

>If, by "true value" in the above, you mean a value other than undef whic
>interpreted as boolean false, then I think I understand what you said.  
>enough to have said it, which is why I used coerce.

No, I mean this:

undef $a;
@$a = ();
if ($a) { . } # always true

It's the lvaluable deref that autoinitializes.

--tom

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

[Nathan Wiger]

Tom Christiansen wrote:
> 
> By your "reasoning", we can just add infinitely more things that
> take twice a few pages to explain.
> 
> Perl is already too hard.

Yes, it is.

And that's why I'm against C.

(Had to get that plug in there) ;-)

-Nate

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

[iain truskett]

* Russ Allbery ([EMAIL PROTECTED]) [21 Sep 2000 07:22]:
> Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

> > Yep, this is bad IMHO.  Your concern is valid I think, but your
> > "solution" isn't a good one.  Why not just use a module like
> > Damian's Quantum::Superpositions?

> No offense to Damian, but I tried to read and understand his
> documentation and I thought I was back in grad school.  I don't think
> it's the fault of the writing either; I think that
> Quantum::Superpositions is trying to do something that's rather too
> complicated to explain clearly to the average programmer.

> It's a neat idea, but I don't expect to see it ever widely used.

I had a thorough read of it yesterday morning, after having been using
it at a basic level for a few weeks. I was quite impressed by it. I'm
really quite impressed by it. Mostly, I've been using it for validation
of data (usually where the data already exists in an array and building
a regexp from the array would be too annoying). In fact, I had to
translate some code that used it into code that didn't use it, and it
went from 3 lines to being about 15. In other words, it simplifies some
operations, thus reducing the likelihood of errors.

I'm not great at either maths or physics (in fact, most people will
happily tell you that I suck at both, including myself), but I can see
what the module does. The main trick is getting the average programmer
to actually read the documentation. Hence, it's mostly a case of putting
more 'practical' examples of its use in the manual.

Of course, I would be interested in seeing a version of Q::S that worked
with threads and/or multiprocesses.

I'll be interested to see Damian's paper when it comes out.


cheers,
-- 
iain truskett, aka Koschei.
You know you are addicted to coffee if...
24  You get a speeding ticket even when you're parked.

Re: RFC 12 (v3) variable usage warnings

[Michael Fowler]

On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> "VARIABLE used only once: possible typo" should be replaced with
> warnings on uses of uninitialized variables (including lexicals).

>  $x = 3

I don't understand, who's to say you didn't misspell $x?  If you're only
using it once wouldn't that be likely?  Who writes a program consisting of
only assignments to variables that are never used, and expects not to see
the "VARIABLE used only once: possible typo" warning?

 
> complains, but
> 
>  $x = 3; $x = 3

As it shouldn't; you've mentioned $x twice, which means you probably didn't
misspell it.  That your mentioning twice in this manner is silly is beyond
perl's grasp.

 
> does not, nor does
> 
>  my $x = 3

I would say that this should complain just as $x = 3 would.

 

> Note that if you currently depend on lexical variables having
> undefined values, you would need to change C to
> C. This is a good thing.

Whoa, are you saying that saying 'my $x' no longer means $x has the value
undef?  What value does it have?  How can this be a good thing?


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

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

[Damien Neil]

On Wed, Sep 20, 2000 at 11:58:08AM -0700, Glenn Linderman wrote:
> > I think that this is better done as a special overloaded object used
> > by database modules which wish to implement SQL-style tri-state logic.
> 
> It could be done as an overloaded object.  You'd have to be able to overload all
> the operators, both numeric and string.

This can be done.  "perldoc overload".


> > The one thing which this requires that Perl5 does not have is the
> > ability to overload the defined() operation on an object.
> 
> And what about overloading the ternary ?: operator?  Of course, that one can be
> avoided.

Overload conversion to bool, and you have this trivially.


> Not usable, I get lots of "Use of uninitialized value in print" warnings, and do
> not have use strict.

I suggest that you read up on the difference between "use strrict" and
"use warnings"/-w.

Furthermore, you may wish to take the five seconds necessary to
understand WHY it prints that message when you print a null value
in that code.  I defined null as stringifying to undef, with the
specific intention of producing that warning message.  If you
would prefer that it stringify to "", or to "null", this would be
a trivial change.


> > Incidentally, I'm surprised that DBI hasn't added an option to use
> > an overloaded null object, if this feature is in demand.
> 
> Performance.

For an optional, off-by-default feature?  If a SQL-style null is
so useful, I'm certain there are people who would be happy to
accept the performance hit.

When you consider that this would be used in conjunction with database
code which often must perform transactions via the network, I strongly
suspect that in many cases the performance overhead of overloading
would be nearly invisible.

   - Damien

Re: RFC 76 (v2) Builtin: reduce

[John Porter]

Glenn Linderman wrote:
> Not a solution.

Frankly, you haven't demonstrated that there's a problem.

-- 
John Porter

Re: RFC 255 (v2) Fix iteration of nested hashes

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  Dave Storrs <[EMAIL PROTECTED]> wrote:

> This runs into problems if you currently have an iterator extant and you
> modify the hash to which it points.  Immediate suggestions on how to
> handle this would be:
>
>   1) Do what the docs currently do; tell people "don't do that"
>   2) Have the iterator auto-reset when the hash is modified
> (probably bad)
>   3) Make the hash unmodifiable while there is an iterator extant
> (probably bad)
>   4) Make powerful magic in some way that isn't coming to mind

See the "Freezing state for keys and values efficiently" section
of RFC 136 for some powerful magic that could achieve this...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...Reading is thinking with someone else's head instead of one's own.

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

[Damien Neil]

On Wed, Sep 20, 2000 at 01:21:52PM -0700, Russ Allbery wrote:
> No offense to Damian, but I tried to read and understand his documentation
> and I thought I was back in grad school.  I don't think it's the fault of
> the writing either; I think that Quantum::Superpositions is trying to do
> something that's rather too complicated to explain clearly to the average
> programmer.
> 
> It's a neat idea, but I don't expect to see it ever widely used.

I disagree.  I think that, ignoring the documentation, the operations
performed by Quantum::Superpositions are intuitive and elegant.

  print "$a is between 1 and 10" if ($a == any(1 .. 10));

The above is simple and clear.  The any() and all() operations are,
perhaps, surprising to experienced programmers (we aren't used to
languages that provide them), but will be instantly understood by
most novices.

If I could be assured that the performance penalty was minimal, I'd
be delighted to write

  if ($errno == any(EAGAIN EINTR)) { ... }

over

  if ($errno == EAGAIN || $errno == EINTR) { ... }

The former is less typing and reads more clearly (to me, at least).


I am of two minds about the documentation.  On one hand, it's
highly theoretical bent will be intimidating to many.  On the other
hand, I found that it clearly described what was going on, and
nicely explained the complexities underlying the simple interface.

I do wonder whether there isn't a better name for eigenstate().

  - Damien

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

[Damien Neil]

On Wed, Sep 20, 2000 at 02:47:01PM -0600, Tom Christiansen wrote:
> In Perl, this is the null character: "\0"
...
> It's a shame you don't like it, but this is the way we speak.

Well, it's the way you speak.  Myself, I'd call that the NUL
character.  :>

 - Damien, exercising a pet peeve.

Re: RFC 226 (v1) Selective interpolation in single quotish context.

[Bart Lateur]

On Fri, 15 Sep 2000 10:29:31 +1100 (EST), Damian Conway wrote:

>Why not just give \I..\E a special "turn-on-interpolation" meaning in
>q{} docs?

This has been uppered already in the pre-discussion to this RFC.
Currently, '\I' is nothing special in q{}, and a lot of people don't
want to chage that.

Besides, single quotes has "this string is not interpolated!" in huge
flickering letters on it. Don't waste that.

The idea I liked the most is not messing with q{}, but instead add a
"\D" or such modifier to doouble-quotish strings, which says: DON'T
interpolate. That is precisely the opposite of this RFC.

print F <<"END";
\D$!
$! execute a.com, copy and purge
$!
$ @sys$login:a.com
$ copy $filename sys$login:*.*
$ purge sys$login:\E$filename\D
$!
$ exit
END

-- 
Bart.

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

[John Porter]

> >$a = null;
> >$b = ($a == 42);
> >print defined($b)? "defined" : "not defined";
> 
> >would print "not defined", maybe?

defined() is the wrong operator to be using there. Rather,

 $a = null;
 $b = ($a == 42);
 print is_null($b)? "is null" : "is not null";

In general, what would these result to:

defined(null)

is_null(undef)

-- 
John Porter

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

[Peter Scott]

At 12:38 PM 9/20/00 -0700, Glenn Linderman wrote:
>OK, scalar variables.  But I see code in the XML modules that check 
>defined (@array)

Then they should be fixed.  That doesn't do anything useful right now.

>Interesting.  I learn something every day.  Today, you helped.  Maybe you 
>can help
>some more... implement me an SQL null, that can coexist with Perl undef, 
>not replacing
>it.

Show me one real example of where this would help.  I have never even 
remotely considered such a thing in my DBI programming; I have some 
convenience modules that translate undef to IS NULL when constructing 
queries, and DBI handily turns NULLs into undefs in results for me.  If 
this is not about DBMS interfacing but you want Perl to implement SQL 
expression semantics, why?  What possible benefit is there?

--
Peter Scott
Pacific Systems Design Technologies

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

[Russ Allbery]

Damien Neil <[EMAIL PROTECTED]> writes:

> If I could be assured that the performance penalty was minimal, I'd
> be delighted to write

>   if ($errno == any(EAGAIN EINTR)) { ... }

> over

>   if ($errno == EAGAIN || $errno == EINTR) { ... }

> The former is less typing and reads more clearly (to me, at least).

Hm, yeah, good point.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Eric Roode wrote:
> 
> Steve Fink wrote:
> >I am merely suggesting that the compiler detect, when it can, that
> >you're trying to use the value of a variable without ever having
> >assigned a value to that variable. And in THAT message, you had better
> >know the name of the variable, since it's the basis of the analysis. And
> >yes, it only handles simple named variables.
> 
> Um, "when it can"? Isn't this considered a Hard Problem by the
> computer scientists?

The halting problem is unsolvable. That doesn't mean you can't figure
out whether the complete program

$x = 1

halts.

But that doesn't even matter that much here; I'm saying that if the
compiler can definitely determine that you are using an uninitialized
variable, it should warn. If you're using something that appears like it
might be uninitialized, but can't be proven either way without solving
that pesky halting problem, then it (if you ask it) says "you might have
screwed up." 90% of the time, it's right -- if the right set of freak
occurrences happen, you really do use the value of an uninitialized
variable. As an example, this may produce a spurious warning:

$y = 1 if $x;
$y = 2 if ! $x; 

...because the compiler is unable to be sure that ($x) || (!$x) is
definitely true. (And in fact, it might not be in the presence of tying.
Which is why, when doing this sort of thing, compilers usually
completely ignore the actual conditions being tested, and assume that
they're independent and sometimes true, sometimes false.)

> >Example:
> >
> >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)
> 
> How about:
> 
> foo();
> $x = 1  unless defined($x);
> print $x;
> 
> Generate a warning, or not?

$x is a global. The compiler cannot detect all possible assignments to
or accesses of globals, so it never warns about them.

If you inserted my $x at the top of that code, it would most likely
produce the "possible use" warning. Or not; this is a simple enough case
that it might be able to infer the right answer.

I am certainly not saying that the "possible use" warning should be
enabled by default. But please, argue over that one separately from the
others. It's the most likely to annoy.

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

Same thing. If $x is lexical, it gives a definite warning. If $x is a
global, it says nothing. You're right; I need to point this out in the
RFC.

Re: RFC 12 (v2) variable usage warnings

[Tom Christiansen]

>But that doesn't even matter that much here; I'm saying that if the
>compiler can definitely determine that you are using an uninitialized
>variable, it should warn. 

...

>$x is a global. The compiler cannot detect all possible assignments to
>or accesses of globals, so it never warns about them.

>If you inserted my $x at the top of that code, it would most likely
>produce the "possible use" warning. Or not; this is a simple enough case
>that it might be able to infer the right answer.

>I am certainly not saying that the "possible use" warning should be
>enabled by default. But please, argue over that one separately from the
>others. It's the most likely to annoy.

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

>Same thing. If $x is lexical, it gives a definite warning. If $x is a
>global, it says nothing. You're right; I need to point this out in the
>RFC.

Careful:

sub ouch {
my $x;
my $fn = sub { $x++ };
register($fn);
print $x;
} 

--tom

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Michael Fowler wrote:
> 
> On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> > "VARIABLE used only once: possible typo" should be replaced with
> > warnings on uses of uninitialized variables (including lexicals).
> 
> >  $x = 3
> 
> I don't understand, who's to say you didn't misspell $x?  If you're only
> using it once wouldn't that be likely?  Who writes a program consisting of
> only assignments to variables that are never used, and expects not to see
> the "VARIABLE used only once: possible typo" warning?

My new warnings are more specific than the old warning. Perhaps I should
make the "variable initialized but never used" warning suggest a
possible typo?

> > complains, but
> >
> >  $x = 3; $x = 3
> 
> As it shouldn't; you've mentioned $x twice, which means you probably didn't
> misspell it.  That your mentioning twice in this manner is silly is beyond
> perl's grasp.

Actually, it isn't. I've often written $x = $x = 3 simply to avoid this
warning, because in the current implementation perl can't several of the
different ways of using a variable.

But I think you're missing the point. Why would you assign a value to a
variable, but then never use that variable's value? All typos would be
caught by the "initialized but never used" warning, as well as other
mistakes.

> > does not, nor does
> >
> >  my $x = 3
> 
> I would say that this should complain just as $x = 3 would.

Yes.

> > Note that if you currently depend on lexical variables having
> > undefined values, you would need to change C to
> > C. This is a good thing.
> 
> Whoa, are you saying that saying 'my $x' no longer means $x has the value
> undef?  What value does it have?  How can this be a good thing?

No. No semantics change. This RFC is... what's the opposite of
far-reaching? It changes no semantics. It only adds warnings. 'my $x'
still means $x's value is undefined (but please do not say "the _value_
undef").

This is probably the most controversial part of the RFC. I'm saying that

my $x;
...some code that might set $x to some value...
if (defined ($x)) { ... }

is bad, but

my $x = undef; # or my $x; undef $x;
...some code that might set $x to some value...
if (defined ($x)) { ... }

is ok. That's because I want to distinguish between initialized
variables and variables whose values are undefined, because I think I
can catch a lot of mistakes by doing so. But this distinction is only in
the compiler. This is the same as in gcc; in gcc, the compiler remembers
whether an integer variable has been initialized, and complains when you
use it. But at runtime, that variable has some numeric value (a junk
value, zero more often than not.) Perl's runtime specifically tracks
variables and expressions whose value is undefined, and does it well
enough that most people think of 'undef' as being just another value.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> And what about $$x?
> 
> Dang, are we back to this incredible confusion about what it is to be
> defined in Perl.?
> 
> undef $a;
> 
> That is now UNINITIALIZED.  So is this:
> 
> $a = undef;
> 
> You have initialized it to undef.  There is no reasonable difference.
> 
> Solution:
> 
> Remove all references from the language to defined and undef.
> People just aren't smart enough to understand them.  Change
> defined() to read has_a_valid_initialized_scalar_value().  Change
> undef() to "operator_to_uninitialize_a_variable".  Touch luck
> on the chumps who can't type well.  They pay for their brothers'
> idiocy.
> 
> repeat until blue:
> 
>   INITIALIZED ==   DEFINED
> UNINITIALIZED == UNDEFINED

Thank you, that's a better way of describing part of the intent of this
RFC. I want to distinguish between variables that are uninitialized, and
expressions whose values are undefined.

my $x; # $x is uninitialized. Also, the value of $x is undefined.
undef $x; # $x has now been initialized. The value of $x is still
undefined.

This is *not* adding a new sort of value to perl. It is adding a
different state for the compiler to think of a variable as being in.
Initialization of a variable means you've done something that influenced
the value of that variable -- either by setting it, or blowing it away
and making it undefined.

You aren't interpreting the last part of the DESCRIPTION section ("you
need to do my $x= undef") as meaning that

my $x;
and
my $x = undef;

have a runtime difference, are you? I think this is confusing some
people, and I really shouldn't say "you would need to" do anything
different; I meant "you would need to say my $x = undef if you have this
warning turned on and you don't want to see it."

Re: RFC 12 (v3) variable usage warnings

[Michael Fowler]

On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > complains, but
> > >
> > >  $x = 3; $x = 3
> > 
> > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > misspell it.  That your mentioning twice in this manner is silly is beyond
> > perl's grasp.
> 
> Actually, it isn't. I've often written $x = $x = 3 simply to avoid this
> warning, because in the current implementation perl can't several of the
> different ways of using a variable.

Which is silly, because you shouldn't have to say '$x = $x = 3' when you
mean '$x = 3'.  Just because there's a real reason behind it doesn't make it
any less silly.

 
> But I think you're missing the point. Why would you assign a value to a
> variable, but then never use that variable's value? All typos would be
> caught by the "initialized but never used" warning, as well as other
> mistakes.

So, in the code:

$foobal = 3;
if (@ARGV) {
$foobar = @ARGV;
}

print $foobar;

Only warn me that $foobar is uninitialized?  I always prefer it when the
actual source of my problem is pointed out, rather than its symptoms.


> > Whoa, are you saying that saying 'my $x' no longer means $x has the value
> > undef?  What value does it have?  How can this be a good thing?
> 
> No. No semantics change. This RFC is... what's the opposite of
> far-reaching? It changes no semantics. It only adds warnings. 'my $x'
> still means $x's value is undefined (but please do not say "the _value_
> undef").

I'm saying the value undef now, because that's exactly what it is, now.  I
have learned that 'my $foo' is an implicit 'my $foo = undef', for all
intents and purposes.

 
> my $x;
> ...some code that might set $x to some value...
> if (defined ($x)) { ... }
> 
> is bad, but

This is an idiom I use all the time, and I don't see anything wrong with it. 
The value is undef, and I don't want to see this change at all.


> my $x = undef; # or my $x; undef $x;

I just have to say, ick.  'my $x' is easy, 'my $x = undef' is slightly
annoying.  'my $x; undef $x;' is confusing; declare a variable, and then
immediately undefine it, so I can avoid uninitialized value warnings? 
Blech.  What of a list of declarations, 'my($foo, $bar, $blah)'? do I get
lots of warnings unless I assign undef to, or undef, all of those?

 
> This is the same as in gcc; in gcc, the compiler remembers whether an
> integer variable has been initialized, and complains when you use it. But
> at runtime, that variable has some numeric value (a junk value, zero more
> often than not.)

I never particularly liked this feature of C, that a variable had junk in it
naturally until you assigned something to it.  I much prefer how Perl does
it; give it a sane value, but warn whenever that value is used unless it was
intentional (by using defined or conditionals).


> Perl's runtime specifically tracks variables and expressions whose value
> is undefined, and does it well enough that most people think of 'undef' as
> being just another value.

It is just another value AFAIK, PL_sv_undef.


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

Re: RFC 12 (v3) variable usage warnings

[Tom Christiansen]

>Which is silly, because you shouldn't have to say '$x = $x = 3' when you
>mean '$x = 3'.  Just because there's a real reason behind it doesn't make it
>any less silly.

I'd like to see where this can happen.  Sounds like someone forgot to
declare something:

our $x;
$x = 2;

--tom

Re: RFC 12 (v2) variable usage warnings

[Tom Christiansen]

>Anything else? Any opinion on whether eval "" should do what it does
>now, and be invisible for the purposes of this analysis; or if it should
>be assumed to instead both use and initialize all visible variables? The
>former produces more spurious warnings, the latter misses many errors.

You have to assume eval STRING can do anything.

--tom

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >Same thing. If $x is lexical, it gives a definite warning. If $x is a
> >global, it says nothing. You're right; I need to point this out in the
> >RFC.
> 
> Careful:
> 
> sub ouch {
> my $x;
> my $fn = sub { $x++ };
> register($fn);
> print $x;
> }

Thanks. I forgot about that one. So either I can punt and treat
capturing a lexical in a closure the same way I'd treat taking a
reference (i.e., assuming that it's both initialized and used), or get a
little more clever and say that getting captured in a closure means you
have to throw out all beliefs about control flow, and fall back to
counting the number of uses and initializations.

Anything else? Any opinion on whether eval "" should do what it does
now, and be invisible for the purposes of this analysis; or if it should
be assumed to instead both use and initialize all visible variables? The
former produces more spurious warnings, the latter misses many errors.

Re: RFC 12 (v3) variable usage warnings

[Michael Fowler]

On Wed, Sep 20, 2000 at 05:10:55PM -0600, Tom Christiansen wrote:
> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> >mean '$x = 3'.  Just because there's a real reason behind it doesn't make it
> >any less silly.
> 
> I'd like to see where this can happen.  Sounds like someone forgot to
> declare something:
> 
> our $x;
> $x = 2;


$x = 2;
print ${"x"};

Maybe?  I don't know, he mentioned it being a problem in certain instances
when perl couldn't tell he was actually using the value more than once. 
I've been going under the assumption that this whole thing is without the
benefit of use strict; a one-liner, perhaps.


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

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> >mean '$x = 3'.  Just because there's a real reason behind it doesn't make it
> >any less silly.
> 
> I'd like to see where this can happen.  Sounds like someone forgot to
> declare something:
> 
> our $x;
> $x = 2;

It happens when I don't bother to declare something. My company has
several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
a pain. As is $My::Package::Name::x.

Re: RFC 12 (v3) variable usage warnings

[Tom Christiansen]

>It happens when I don't bother to declare something. My company has
>several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
>a pain. As is $My::Package::Name::x.

Far, far easier to fix behavioral problems than to hack Perl.

--tom

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

[Chaim Frenkel]

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

TC> I'm saying that you can't know what to check for, because you don't
TC> know who generated the exception.  Can you use your fancy constants?

Then please tell me how anyone has ever coded
$@ =~ //

They don't know what to look for? I just want to replace the examination
of the textual error message with a fixed value.

TC> And what is "core"?  Compiler?  Interpreter?  Utilities?  Pragmata?
TC> Modules?

Anything that came in the TARBALL, anything that p6p will be responsible
for.

TC> Citing IBM as a reference is enough to drive a lot of us away screaming.

Why?

TC> Try  or   Notice how much nicer this is.  Few
TC> values, but usable in varied places.

Sometimes it is acceptable to collapse different errors into one. But
then sometimes losing the direct error makes things difficult to decide
what really happened and how to handle it.

Your issue could be handled by supplying a classification, either
mapping to use warnings, or a different set (or all of them. I
really don't care.) 

But the examination of the textual string, locks away any possiblities
of adjusting the text of the message or even making the error string
localizable.

Consider allowing perl to emit error messages in French, Latin, or
Klingon without breaking the code.


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

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

[Tom Christiansen]

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

--tom

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Michael Fowler wrote:
> 
> On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > > complains, but
> > > >
> > > >  $x = 3; $x = 3
> > >
> > > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > > misspell it.  That your mentioning twice in this manner is silly is beyond
> > > perl's grasp.
> >
> > Actually, it isn't. I've often written $x = $x = 3 simply to avoid this
> > warning, because in the current implementation perl can't several of the
> > different ways of using a variable.
> 
> Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> mean '$x = 3'.  Just because there's a real reason behind it doesn't make it
> any less silly.

Ok, I can't argue with that. :-)

> > But I think you're missing the point. Why would you assign a value to a
> > variable, but then never use that variable's value? All typos would be
> > caught by the "initialized but never used" warning, as well as other
> > mistakes.
> 
> So, in the code:
> 
> $foobal = 3;
> if (@ARGV) {
> $foobar = @ARGV;
> }
> 
> print $foobar;
> 
> Only warn me that $foobar is uninitialized?  I always prefer it when the
> actual source of my problem is pointed out, rather than its symptoms.

It's exactly the same behavior as now, if you add in the "maybe it's a
typo?" guess. Which sounds fine to me.

> > > Whoa, are you saying that saying 'my $x' no longer means $x has the value
> > > undef?  What value does it have?  How can this be a good thing?
> >
> > No. No semantics change. This RFC is... what's the opposite of
> > far-reaching? It changes no semantics. It only adds warnings. 'my $x'
> > still means $x's value is undefined (but please do not say "the _value_
> > undef").
> 
> I'm saying the value undef now, because that's exactly what it is, now.  I
> have learned that 'my $foo' is an implicit 'my $foo = undef', for all
> intents and purposes.

And undef is short for the function call undef(), which could be
implemented

sub undef {
my $var;
return $var;
}

(except undef can optionally take parameters, as in undef $x)

Something that isn't defined() means that either nobody bothered to
assign a value to it, or somebody took away its value.

> > my $x;
> > ...some code that might set $x to some value...
> > if (defined ($x)) { ... }
> >
> > is bad, but
> 
> This is an idiom I use all the time, and I don't see anything wrong with it.
> The value is undef, and I don't want to see this change at all.
> 
> > my $x = undef; # or my $x; undef $x;
> 
> I just have to say, ick.  'my $x' is easy, 'my $x = undef' is slightly
> annoying.  'my $x; undef $x;' is confusing; declare a variable, and then
> immediately undefine it, so I can avoid uninitialized value warnings?
> Blech.  What of a list of declarations, 'my($foo, $bar, $blah)'? do I get
> lots of warnings unless I assign undef to, or undef, all of those?

Yes. Note that I wasn't suggesting that anyone "should" use C over C, it's just more clear given that undef is
a function call.

With my style of programming, my($foo,$bar,$blah) would rarely trigger
warnings, because I would do something with those variables before using
them. I rarely use defined() to mean "if the control has happened to
take a route that never affected the values of this variable". In those
cases, I wouldn't mind using an explicit undef.

It sounds like your style of programming is different. So you wouldn't
enable those warnings. And also that you find the existing warning
useful, which means the control over the warnings must be more
fine-grained than all or nothing. Sounds reasonable to me. And you might
want to temporarily turn on full warnings mode, ignore the spurious
messages, fix the bugs uncovered, and turn the warnings back off.

The question is whether there are enough people who use either my style
of programming or want the temporary warnings firehose to warrant
implementing it. I haven't been able to determine yet whether this is
the case. People largely ignored this RFC when it first came out.

> I never particularly liked this feature of C, that a variable had junk in it
> naturally until you assigned something to it.  I much prefer how Perl does
> it; give it a sane value, but warn whenever that value is used unless it was
> intentional (by using defined or conditionals).

No argument there. But do you like the feature of C where it warns you
at compile time when this is going to happen?

> > Perl's runtime specifically tracks variables and expressions whose value
> > is undefined, and does it well enough that most people think of 'undef' as
> > being just another value.
> 
> It is just another value AFAIK, PL_sv_undef.

That's implementation. The semantics are determined by the effects of
various operations on objects whose values are undefined. And those
effects reveal that it isn't just another value; no other value behaves
anything like it.

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

[Paris Sinclair]

All this talk about adding another undef, called null, that is just a
different logical and semantical version of "not defined," or "not
known," or however you want to say it, strikes me as very odd.

I admit I am new enough to Perl that 5 was my first version, but still...
it seems better to make the new things we add consistent with the Perlish
ways, than to make the new behaviors mimic other languages. If you are
saying that it is needed to help give clarity to users of that language,
in their early stages of migrating to Perl, that is one thing. But, there
are lots of changes to basic behavior that would assist the serial drivers
I've written in Perl, but they would be awful things to add into the core.
Better is to make a module around the special cases that I want to
simplify. undef is wonderful; undef is great! All hail the great undef! If
you need additional semantics than provided by undef, why not make a
module? CPAN is the biggest strength of Perl, I don't think it would be
good use to start dumping our special cases into the core. Can't we make a
tool to make tools, instead of just making another SQL?

use MyModule qw( null some_odd_combination_of_behaviors );
my $name = null();
print "Hello world!" if some_odd_combination_of_behaviors();

or,

use MyModule;
my $obj = new MyModule;
print "Hello world!" if $obj->unknown();

I understand the differences between SQL NULL and Perl undef, I just don't
understand what defaco general problem is solved with adding it.

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

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >It happens when I don't bother to declare something. My company has
> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
> >a pain. As is $My::Package::Name::x.
> 
> Far, far easier to fix behavioral problems than to hack Perl.
> 
> --tom

Not sure what you mean, since this RFC _adds_ a warning in this case. In
fact, with the proposed change, my trick to avoid punishment for my
misbehavior would no longer work.

The point is that if

$x = 3;

elicits a warning, then the problem that the warning is pertaining to is
not fixed by

$x = 3;
$x = 3;

so the warning should not go away either. In general: when possible, the
compiler should not change its behavior when your code does not change
in a way relevant to the problem it's complaining about.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >Anything else? Any opinion on whether eval "" should do what it does
> >now, and be invisible for the purposes of this analysis; or if it should
> >be assumed to instead both use and initialize all visible variables? The
> >former produces more spurious warnings, the latter misses many errors.
> 
> You have to assume eval STRING can do anything.
> 
> --tom

"have to"? Perl5 doesn't.

% perl -we '$x = 3; $v = "x"; eval "\$$v++"'
Name "main::x" used only once: possible typo at -e line 1.

I'd rather think of it as a cost-benefit tradeoff.

Re: RFC 12 (v3) variable usage warnings

[Michael Fowler]

On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
> > $foobal = 3;
> > if (@ARGV) {
> > $foobar = @ARGV;
> > }
> > 
> > print $foobar;
> > 
> > Only warn me that $foobar is uninitialized?  I always prefer it when the
> > actual source of my problem is pointed out, rather than its symptoms.
> 
> It's exactly the same behavior as now, if you add in the "maybe it's a
> typo?" guess. Which sounds fine to me.

Except for the line number reported, which is the important part.


> Something that isn't defined() means that either nobody bothered to
> assign a value to it, or somebody took away its value.

I think of undef as a value in and of itself, not simply a state of being. 
A value that has magical properties, and that is recognized in various
places, but a value nonetheless.  Perhaps I've been corrupted by the
implementation (or what I understand of it), but there it is.

 
> With my style of programming, my($foo,$bar,$blah) would rarely trigger
> warnings, because I would do something with those variables before using
> them. I rarely use defined() to mean "if the control has happened to
> take a route that never affected the values of this variable". In those
> cases, I wouldn't mind using an explicit undef.

I would.  I have not done it personally, but I do maintain code that has
something along the lines of:

my($foo, $bar, %baz, @qux, $quux, $blah ... ad nauseum);

This new warning would make life difficult for me.

 
> It sounds like your style of programming is different. So you wouldn't
> enable those warnings. And also that you find the existing warning
> useful, which means the control over the warnings must be more
> fine-grained than all or nothing. Sounds reasonable to me. And you might
> want to temporarily turn on full warnings mode, ignore the spurious
> messages, fix the bugs uncovered, and turn the warnings back off.

If your warning is optional, turned on by an explicit use warnings call, and
not included in its default set, I'm fine with it.


> But do you like the feature of C where it warns you at compile time when
> this is going to happen?

Yes, and Perl currently has the very same thing, except with the additional
warning when I use a variable that has not been declared.  This being Perl,
it's natural; you cannot use a variable in C without declaring it, so the
issue never comes up.

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

Re: RFC 241 (v1) Pseudo-hashes must die!

[Peter Scott]

At 03:37 PM 9/17/00 -0700, I wrote:
> How about an attribute for hashes:
>
> my %foo : fixed;
>
>And now new keys cannot be inserted into the hash just by assigning to 
>their values.  As to how you could put them there... well the ideas that 
>come to mind are [snipped]
>

Spurred on by the peanut gallery, I attempted to write an RFC for this, but 
it is foundering.  Here's why: the most common case of hashes whose keys 
one would want to fix are anonymous, when they're used as column names in a 
database hash.  For instance:

 $employee{$empno}{SAlARY} -= 10_000;   # IPO failure
 $employee{$empno}{FAX} = '888-555-1212';

First one got the wrong key when my finger slipped on the shift key, second 
one got it when I misremembered FAX instead of FACSIMILE.  But in neither 
case does Perl point this out.  (Yes, I could use objects instead, but 
that's hardly the point.)

I have been unable to come up with a lightweight syntax for saying that the 
second-level hash keys should be fixed.  I supplicate the gods of new 
syntax for any succor they may render in my hour of need.

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Michael Fowler wrote:
> 
> On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
> > > $foobal = 3;
> > > if (@ARGV) {
> > > $foobar = @ARGV;
> > > }
> > >
> > > print $foobar;
> > >
> > > Only warn me that $foobar is uninitialized?  I always prefer it when the
> > > actual source of my problem is pointed out, rather than its symptoms.
> >
> > It's exactly the same behavior as now, if you add in the "maybe it's a
> > typo?" guess. Which sounds fine to me.
> 
> 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."

> I would.  I have not done it personally, but I do maintain code that has
> something along the lines of:
> 
> my($foo, $bar, %baz, @qux, $quux, $blah ... ad nauseum);
> 
> This new warning would make life difficult for me.

It's not just having my($long, $list, $of, $variables). It's never
saying $long = f().

Ah well. It would be interesting to have this and see how many things
complain. I know my code is littered with abandoned 'my $var's that are
no longer used, because I'm lazy and used to relying on a C compiler to
tell me when I can delete an obsolete local variable. Perl won't do that
for lexicals.

> > But do you like the feature of C where it warns you at compile time when
> > this is going to happen?
> 
> Yes, and Perl currently has the very same thing, except with the additional
> warning when I use a variable that has not been declared.  This being Perl,
> it's natural; you cannot use a variable in C without declaring it, so the
> issue never comes up.

Where it catches things for me in C is in places like:

int somefunc() {
int status;
while (...) {
status = syscall();
if (status < 0) break;
...
}
return status;
}

Before I started using -Wall all of the time, I was often puzzled when
somefunc() returned -813714631.

Re: RFC 12 (v2) variable usage warnings

[Tom Christiansen]

>Tom Christiansen wrote:
>> 
>> >Anything else? Any opinion on whether eval "" should do what it does
>> >now, and be invisible for the purposes of this analysis; or if it should
>> >be assumed to instead both use and initialize all visible variables? The
>> >former produces more spurious warnings, the latter misses many errors.
>> 
>> You have to assume eval STRING can do anything.
>> 
>> --tom

>"have to"? Perl5 doesn't.

You mean "perl".

>% perl -we '$x = 3; $v = "x"; eval "\$$v++"'
>Name "main::x" used only once: possible typo at -e line 1.

Non sequitur.  And no, I don't have time.