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

[Glenn Linderman]

Damien Neil wrote:

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

Thanks, yes, I figured out the "no warnings" issue afterwards.

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

Yes, I'll have to play with this more.  I guess while it does only take a few seconds
to figure out the null, I have more to learn about perl before I understand the
complete object you've provided here and its semantics.

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

Well, I'd rather have it be the on-by-default feature, if performance allows,
somehow.  Your module looks so short, and nice, if it really can be twiddled into a
"real" SQL null, then we could have them today in Perl5?  And if they are slow,
general object improvements in Perl6 might fix that?

This idea of implementing NULL seems to come along without the baggage of
encapsulating scalar values... i.e. implementing an object consisting of

   package numeric_with_null_support;

   sub new {  bless { null_flag => false, value =>  }}

is intriguing if it can be made to work.  RFC 234 makes me wonder if there is a
problem with binary operators in the case where multiple NULL value packages like
yours were implemented with slightly different semantics (to mirror the mulitple NULL
values possible in SQL), when a binary operators would be applied to two different
NULL values.  Of course, it is probable that all the different NULL values would be
from the same package, just with a different value, so maybe this isn't a problem.
I'm not that deep into overloading to understand the complete issue there.

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

Well, if you do a bunch of post-processing in Perl, that could quickly consume more
time than the original fetch of data via the network.  Especially if there were lots
of NULLs, and NULL is a performance hog.

--
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 241 (v1) Pseudo-hashes must die!

[Glenn Linderman]

Peter Scott wrote:

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

I think RFC 188 addresses this (although it is couched in terms of object
inheritance).

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

In general, it would be nice to convince DBI to do this for you, when it
creates the hashes, and populates them.  But you could simply always do the
call to DBI, then do a

private $employee{$empno}{'!@#$"};

which would add one more key (with a funny spelling unlikely to conflict with
column names) which will turn off the autovivifying for the whole hash as a
side effect.

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

Paris Sinclair wrote:

>  If
> you need additional semantics than provided by undef, why not make a
> module?

This might be workable.  There are some thoughts on that.  Personally, I
haven't used that much overloading in Perl to know whether it can be made to
work well enough to completely conform to SQL NULL semantics, which is the
goal of the RFC.  I'm not sure that the RFC requires the functionality to be
added to the core, it just wants the functionality to be added, and get
reasonable performance from the result.

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

Phew!  With all the negative "my perl isn't SQL, it's only sh, awk, tr, sed,
grep, and C and I want to keep it that way" comments that this RFC generated,
I'm glad someone understands the differences in the semantics.

One example problem that could be solved more easily with this RFC is this:
when writing a report (I think that's a typical use of Perl) that accesses
data from multiple databases, some further processing of the data within perl,
even joins of data form separate databases, might be needful.  Having the NULL
concept available within Perl would make it easier to mimic the joins that can
be done within a database (if only all the data were there).

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



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

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

[Glenn Linderman]

John Porter wrote:

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

The tri-state logic deals with "true", "false", and "unknown" (not
NULL).  To quote from Jim Melton's Understanding SQL:

"Remember, that null is a characteristic of an SQL data item.  Unknown,
in contrast, is a characteristic of a predicate.  The differences may
appear to be subtle between the two concepts and the corresponding
syntactical expressions, but they must be used correctly in order to
develop SQL applications."

If we pick up the SQL data value NULL, as suggested by this RFC, we
should pick up its semantics... not from the RFC, not from Melton's
book, but from the (latest) SQL 99 standard.  It would appear from
Melton's book that there needs to be at least two distinguished values
to do so: NULL and UNKNOWN, both of which have different semantics than
undef.  However, I think that although Melton makes this distinction,
and so does the SQL syntax, that the same effect can be achieved by
using the same distinguished value to represent both concepts, because
their usages never overlap.  Having not read the SQL 99 standard
thoroughly regarding this concept, I hesitate to say if that is still
true for SQL 99, which I believe allows multiple flavors of NULL data
values.

> In general, what would these result to:
>
> defined(null)

true.

> is_null(undef)

false.

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

Peter Scott wrote:

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

I tried to fix it according to the suggested fix in the warning message, and
it didn't work.  I tried another logic transformation that I thought might
work, but it didn't.  But the code works as is.  I agree something should be
fixed.

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

So that I can write joins, including expressions involving NULLs retrieved
from the databases, using Perl.  Not in SQL join syntax, but in Perl.  But
Perl doesn't presently support the NULL concept--using undef and its defined
semantics doesn't produce the same results for expression calculation as using
NULL.   As stated in other post, even in DB programming of this sort, I
perceive that having undef mean uninitialized value (distinct from NULL
meaning null value read from DB) would help catch programming errors, just as
it does today without support of NULL.

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

Tom Christiansen wrote:

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

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

   the null string
   the null character
   the null list

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

   the null

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

> undef $a;
> @$a = ();
> if ($a) { . } # always true
>
> It's the lvaluable deref that autoinitializes.

Thanks for the explanation.

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

Russ Allbery wrote:

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

I wouldn't, of course.  This is just a demonstration that I want both
semantics available concurrently.

> I don't believe you actually need both semantics active at the same time;

I do.  Need might be a slightly stronger word than necessary, but "want" and
"convenience" sure come strongly to mind... the proposals to switch from one
set of semantics to another just don't cut it for ease of use.

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

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

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

In RFC 263, this is the null:  null

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

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

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

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

The documentation isn't all that consistent about everything, either.
Perhaps you, personally, are more so, and if so, perhaps you should help
rewrite the documentation to make it as perfectly consistent as yourself.
I allowed that you might want to call it the null string, and I'm allowed
to read "null string" and think "empty string", and I'm just as right as
you are.  You must not have a cohesive argument to make, if you resort to
insults in an attempt to make points.

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

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

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

> Perl is already too hard.

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

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

Russ Allbery wrote:

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

The RFC suggests that, but I never said that.  I'd actually like them to start
as undef, until such time as I get around to copying values from a database
into them.  Then undef can still indicate that the variable is not yet
defined; has not even been set to a value such as null, yet.

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

Nulls don't creep in.  As stated above, uninitialized variables would still be
undef, and that is convenient.

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

print works fine, too.

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

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

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

RFC 267 (v1) Eliminate dump() function

[Perl6 RFC Librarian]

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

=head1 TITLE

Eliminate dump() function

=head1 VERSION

  Maintainer: Dominus <[EMAIL PROTECTED]>
  Date: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 267
  Version: 1
  Status: Developing

=head1 ABSTRACT

Get rid of it completely.

=head1 DESCRIPTION

dump is a common subroutine name.  People often try to define a dump
subroutine and then get puzzled by the dump.  They have to name their
dump functions 'Dump' or 'dumper' and then they get annoying errors
when they call dump instead by mistake.

dump is not very useful anyway; see MIGRATION below.

=head1 IMPLEMENTATION

None needed.

=head1 MIGRATION

The translator should translate calls to dump() to 

kill 6 => $$;

instead.   

If the translator fails on dump LABEL, that is probably all right.
But if not, then it can translate

...
dump LABEL;
...

LABEL: 
...

to 

...
${^Please_Dump} = 1;
goto LABEL;
...

LABEL:
kill 6 => $$ if ${^Please_Dump};
undef ${^Please_Dump};
...


=head1 REFERENCES

perlfunc manpage for discussion of dump()

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

[Perl6 RFC Librarian]

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

=head1 TITLE

Any scalar can be a hash key

=head1 VERSION

  Maintainer: Steve Fink <[EMAIL PROTECTED]>
  Date: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 266
  Version: 1
  Status: Developing

=head1 ABSTRACT

References will be allowed as hash keys. Blessed references can
additionally provide their own hash functions and equality tests.

=head1 NOTE

This RFC is probably premature. It needs a lot of firming up, and I
wonder if it would be better targeted to the perl6-language-internals
group. But I want to respect the new RFC freeze date (today). And it
should still serve to focus discussion, IMO the main purpose of an RFC.

Anyone else want to maintain it?

=head1 DESCRIPTION

For nonreferences, nothing will change. For non-blessed references,
just one thing will change: the keys returned by C and C
will be full scalars instead of just strings. The lookup will behave
as now: if you have two distinct anonymous hash references with
identical contents, they will still be given distinct keys in the
hashtable. However, C<$hash{$ref}> will no longer be equal to
C<$hash{"$ref"}>.

Blessed references (or whatever they become in Perl6) can define a
HASH subroutine that returns an integer. Any two objects whose HASH
functions return different values will never resolve to the same hash
table entry.

Identical HASH functions are not sufficient for resolving to the same
entry. The equality operator C<==> will be used to find matching
values in the table. Thus, in order for two distinct blessed
references to be treated as identical hash keys, they must both define
C to return the same value and overload C<==> to return true
when either is compared to the other.

If the outcome of the equality test changes while an object is in a
hash table, the results are undefined. (This can happen if the
equality subroutine is redefined, or if internal state that it depends
on changes in either the lookup object or the stored object.) Note
that the equality operator defined by the stored key is irrelevant,
because the probe key's equality test is used during lookup.

The HASH value of a stored object is "frozen" at the moment it is
stored in the hashtable. It may change, but it will be looked up in
the hashtable using the HASH value computed for its insertion.

The number of times the equality and HASH subroutines are called
during any hash operation is undefined.

=head2 WARNING

Note that because C<==> is not constrained to be commutative, the hash
keys no longer form a set of equivalence classes. In other words, it
is possible to get this behavior:

 print $A;# "an A object"
 print $B;# "a B object"
 $hash{$A} = $B;
 print $hash{$A}; # "a B object"
 print $hash{$B}; # "a B object"
 $hash{$B} = $A;
 print $hash{$A}; # "an A object"
 print $hash{$B}; # "a B object"

This is because $A==$B but $B!=$A (assuming the search key's equality
operator is called rather than the hash key's). I'm sure some sick,
twisted individual can come up with a practical use for this, but most
of the time it'll be a subtle bug.

=head2 ALTERNATIVES

1. The HASH function could be allowed to return an arbitrary scalar
value. This would slow down operations, because the entire scalar
would need to be hashed once and then compared to every element in the
hash bucket.

2. The HASH value could be allowed to change after an object is
inserted into the hashtable (and the lookup would reflect this new
value.) This would probably be miserable for performance because in
general, every key in the hashtable would need to be recomputed and
compared against on every hashtable operation. This could be improved,
but hardly seems worth it.

3. The equality test could be skipped, and instead lookups would rely
only on the HASH values being identical. This would work, but it seems
difficult in general to boil an object's identity down to a number or
even a string. Still, this seems like the leading contender: it's what
we have now with overloaded stringification, except
C<(keys %h)[0]->foo()> would work.

=head1 IMPLEMENTATION

Dunno. With my vague understanding of the existing code and hash
tables in general:

All hashtables will have a flag bit for each key indicating whether it
is a reference. If not, the memory for the key strings can be shared
(as they are now.) For a key which is a reference, the key will be a
struct with two slots: the HASH value of the key (call it
HASHENT.keyhash) and the actual scalar key (call it HASHENT.key). A
lookup for a probe object will generate a hash of the lookup key and
map it to a bucket in the hashtable. Each of the entries (call an
entry HASHENT) in that bucket will be examined in turn. The lookup
will succeed if HASHENT.keyhash is equal to H and the C<==> operator
of the probe object returns true for HASHENT.key. The first one found
will be returned.

When inserting into a hash bucket, multiple entries

IDEA: my() extensions and attribute declarations

[Nathan Wiger]

I don't have time to RFC this now, as I'm leaving soon for several days.
So here's a brain dump.

Camel-3 shows some interesting hints of what's been proposed for my
declarations:

   my type $var :attribute = $value;

And we all know that you can use my to declare a group of variables:

   my($x, $y, $z);

Here's the issues:

   1. How do the two jive together?
  
   2. Should it be possible to assign attributes to
  individiual elements of hashes/arrays? (yes)

   3. With types, should multiple types be applicable
  as "candidate types" for that value?

Here's a shot at it. Please, rip it apart and put it back together. When
I get back I'll RFC the remains (if there are any). ;-)

1. Getting everything to work together

Excuse me if I trod over well-worn p5p ground, but it appears to me that
you should be able to group things in different ways to avoid needless
redundancy:

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

Seems most logical that:

   A) The type will be the same across variables; this is common
  usage in other languages because it makes sense.

   B) The attributes will be different for different variables.

Nonetheless, it seems we might want the DWIMmishness available by
supporting these:

   my int ($x, $y, $z) :64bit; # all are 64-bit
   my int ($x, $y, $z :unsign) :64bit  # plus $z is unsigned

   my int ($x, $y), char $z;   # mix classes
   my int ($x, $y) :64bit, char $z :long;  # and attrs

And, of course, the ultimate spaghetti:

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

Meaning is left as an exercise for the reader. :-)

2. Assigning attributes to individual elements of hashes/arrays

This is potentially very useful. ":laccess", ":raccess", ":public",
":private", and others spring to mind as potential candidates for this.
Any reason we shouldn't extend this:

   my int @a :64bit;   # makes each element a 64-bit int
   my string %h :long; # each key/val is long string

To declaring attributes on individual elements:

   $a[0] :32bit  =   get_val;# 32-bit
   $r->{name} :private = "Nate"; # privatize single value
   $s->{VAL} :laccess('data') = "";  # lvalue autoaccessor

However, a problem then arises how to assign types to singular elements:

   my int $a[0] :64bit; # just makes that single element
# a lexically-scoped 64-bit int?

   my string $h{name} = ""; # cast $h{name} to string, rescope %h?

Currently, lexical scope has no meaning for individual elements of
hashes and arrays. However, assigning attributes and even types to
individual elements seems useful. There's two ways around this that I
see:

   A) On my'ing of an individual hash/array element, the
  entire hash/array is rescoped to the nearest block.

   B) Just that individual element is rescoped, similar
  to what happens when you do this:

  my $x = 5;
  {
 my $x = 10;
  }

Input? 

3. Assigning multiple "candidate types" for a variable

It seems potentially useful to be able to say:

   my Dog, Cat $fluffy;

As a way to say "$fluffy can be either a Dog or a Cat". Since variables
are prefixed, anything comma-separated up to the variable is an
alternate class for that variable:

   my double, float ($x, $y) :64bit;
   my int, char ($a, $b), float, double $c :big;

However, we might not want this at all. I'm just throwing it out there.

I likely will not reply to this thread for a good while, so please don't
email stuff phrased directly to me; this is intended to spawn a general
discussion on this topic.

-Nate

Re: RFC 12 (v3) variable usage warnings

[Michael Fowler]

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

On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
> Michael Fowler wrote:

> > Except for the line number reported, which is the important part.
> 
> Oh. Certainly you'll get the line number. My description didn't include
> it because it didn't seem to aid to the understanding. I have it in the
> examples that I added to the RFC.
>
> I suppose it could even give both line numbers for declared variables:
> "use at line 7 of uninitialized variable declared at line 3."

Yes, you could do that, but it wouldn't catch this problem.

The example code:

$foobal = 3;# This $foobal is an intentional typo.
if (@ARGV) { $foobar = @ARGV }
print $foobar;

I want perl to tell me that $foobal, declared on line 1, was never used. 
You want perl to tell me that $foobar, used on line 3, and declared on line
1 (!), was used uninitialized.  I'm going to assume you didn't mean perl
should do code analysis to see exactly where I first misspelled the
variable.  If it could, great!  Somehow I doubt we're going to go there,
though.


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

Yes, I realize that.  But more often than not the variables are used
undefined to indicate a certain state, and you want me to either insert a
"no warnings 'whatever'", or initialize all of those variables to undef
explicitly.  I'm saying I want the code to work the same, because perl
already tells me about the use of uninitialized values, and my having used a
variable only once.

In fact, I don't want it to mention I've used it only once when I use use
strict and declare my variables; strict catches my misspellings, and at
compile-time, no less.


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

Re: RFC 12 (v2) variable usage warnings

[Daniel Chetlin]

On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> Tom Christiansen wrote:
> > Steve Fink wrote:
> > >% 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.
>
> It is relevant in that perl's existing behavior has proven to be
> useful even though the implementation is not correct.

I think Tom's point is that the eval has nothing to do with what
you're showing.

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

> The correct implementation would not have issued the above warning,
> because an eval"" was present in the code. However, the correct
> implementation would also fail to warn in many legitimate cases. The
> current heuristic seems to strike a pretty good balance:
>
> % perl -le '$x = 3; eval "\$x++"'
> (no warning issued)

  [~] $ perl -wle'$x = 3; eval "\$x++"'
  Name "main::x" used only once: possible typo at -e line 1.

Re: RFC 12 (v2) variable usage warnings

[Tom Christiansen]

Have a nice day.  And thanks for all the fish.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >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.

It is relevant in that perl's existing behavior has proven to be useful
even though the implementation is not correct. The correct
implementation would not have issued the above warning, because an
eval"" was present in the code. However, the correct implementation
would also fail to warn in many legitimate cases. The current heuristic
seems to strike a pretty good balance:

% perl -le '$x = 3; eval "\$x++"'
(no warning issued)

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >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...
> 
> that you should declare the variable properly, of course.

I want a similar warning for a file containing only

my $x = 3;

And for a file containing only

my $x = 3;
$x = 3;

Do you think this would be useless? Or do you think that it would report
too many spurious warnings? Or do you think it would confuse people? I'm
having trouble figuring out what your position is, other than not
wanting uninitialized values to be any different from undefined values.
In your opinion, is the RFC without merit, or are you objecting only to
parts of it?

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

[Tom Christiansen]

>But I see code in the XML modules that check defined (@array)

They're buggy and wrong. 

--tom

Re: RFC 12 (v3) variable usage warnings

[Tom Christiansen]

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

that you should declare the variable properly, of course.

--tom

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.

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

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

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

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

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

RFC 230 (v3) Replace C built-in with C function

[Perl6 RFC Librarian]

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

=head1 TITLE

Replace C built-in with C function

=head1 VERSION


  Maintainer: Damian Conway <[EMAIL PROTECTED]>
  Date: 15 Sep 2000
  Last Modified: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 230
  Version: 3
  Status: Frozen

=head1 ABSTRACT

This RFC proposes that Perl's existing C mechanism be replaced
with a standard module based on parts of the Text::Autoformat module.


=head1 DESCRIPTION

I can never remember how formats work. The specification syntax is confusing
to me. And I usually don't want the formatted text going straight down some
magical output stream.

It all came to a head when I was building Text::Autoformat. The smart text
recognition was easy -- trying to do the final formatting with C
and $^A was just too painful.

So I created the C subroutine. It uses a template
specification than fits my brain better, it's deeply DWIMical, it's highly
configurable, and it's re-entrant (so you can use a C to format
another C's headers and footers, for example).

I propose that the existing C mechanism be removed from Perl 6
and be replaced with an add-in function from a standard module (based on
the semantics of C) as described in 
the following sections.


=head2 The C function

The function itself would be called C and would be 
imported with a C call.

It takes a format (or "picture" or "template") string followed by one or
more replacement values. It then interpolates those values into each picture
string, and either:

=over 4

=item *

returns the result as a single multi-line string (in a scalar context)

=item *

returns the result as a list of single-line strings (in a list context)

=back

In a void context, format would emit a warning: "Useless use of format
in void context".


A picture string consists of sequences of the following characters:

=over 4

=item 

Left-justified field indicator. A series of two or more sequential <'s
specify a left-justified field to be filled by a subsequent value.

=item 

Right-justified field indicator. A series of two or more sequential >'s
specify a right-justified field to be filled by a subsequent value.

=item 

Centre-justified field indicator. A series of two or more sequential ^'s
specify a centred field to be filled by a subsequent value.

=item >>>.

A numerically formatted field with the specified number of digits to
either side of the decimal place. See L below.


=item 

Left-justified block field indicator.
Just like a < field, except it repeats as required on subsequent
lines. See below.

=item 

Right-justified block field indicator.
Just like a  field, except it repeats as required on subsequent
lines. See below.

=item 

Centre-justified block field indicator.
Just like a  field, except it repeats as required on subsequent
lines. See below.

=item ]]].

A numerically formatted block field with the specified number of digits to
either side of the decimal place.
Just like a >>>. field, except it repeats as required on
subsequent lines. See below. 

=item ~

A single character field. Interpolates a single character from a subsequent
data value. Repeats on subsequent lines as required.

=item \0

A zero-width field separator. A null character in the template field is
ignored (i.e. I included in the formatted text). This allows two
fields to be adjacent. For example: "[[[\0[[[". To put a
literal "\0" in a formatted text, use a '~' field and pass it the
data string "\0".

=item \

Literal escape of next character (e.g. C<\~> is formatted as a literal '~',
not a one character wide field).

=item Any other character

That literal character.

=back

Hence a typical use of C might look like this:

$formatted = format "<>",
   $aphorism,  "page $page_num";

and might produce an output like this:


page 123





Note that, because every field (except a C<~> field) must be at least
two characters wide, the single C> and C> brackets in the
format string are correctly interpreted as literals.


=head3 Multi-line filling 

As the previous example indicates, any line with a block field continues
interpolation of that field on subsequent lines until all block fields
in the format have consumed all their data. Non-block fields on these
lines are replaced by the appropriate number of spaces.

For example:

$title = "On The Evil That Is Spam";
$text1 = "How many times have you longed to smash...";
$text2 = "...the bedevilment that is spam?";

print format "<<<   [[[   [[",
  $title,   $text1,   $text2;

# prints:
#
# On The Evil   How many times...the be- 
#   h

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

[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

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

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

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

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

[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

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

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

>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

[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

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

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]

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]

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

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

[Perl6 RFC Librarian]

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

=head1 TITLE

Builtins : Make use of hashref context for garrulous builtins

=head1 VERSION

  Maintainer: Damian Conway <[EMAIL PROTECTED]>
  Date: 19 Sep 2000
  Last Updated: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 259
  Version: 2
  Status: Developing

=head1 ABSTRACT

This RFC proposes the builtin functions that return a large number of
values in an array context should also detect hashref contexts (see RFC
21) and return their data in a kinder, gentler format.

=head1 DESCRIPTION

It's hard to remember the sequence of values that the following
builtins return:

stat/lstat
caller
localtime/gmtime
get*

and though it's easy to look them up, it's a pain to look them up
Every Single Time.

Moreover, code like this is far from self-documenting:

if ((stat $filename)[7] > 1000) {...}

if ((lstat $filename)[10] > time()-1000) {...}

if ((localtime(time))[3] > 5) {...}

if ($usage > (getpwent)[4]) {...}

@host{qw(name aliases addrtype length addrs)} = gethostbyname $name;

warn "Problem at " . join(":", @{[caller(0)]}[3,1,2]) . "\n";


It is proposed that, when one of these subroutines is called in the new
HASHREF context (RFC 21), it should return a reference to a hash of values,
with standardized keys. For example:

if (stat($filename)->{size} > 1000) {...}

if (lstat($filename)->{ctime} > time()-1000) {...}

if (localtime(time)->{mday} > 5) {...}

if ($usage > getpwent()->{quota}) {...}

%host = %{gethostbyname($name)};

warn "Problem at " . join(":", @{caller(0)}{qw(sub file line)} . "\n";


=head2 Standardized keys

The standardized keys for these functions would be:

=over 4

=item C/C

'dev'   Device number of filesystem
'ino'   Inode number
'mode'  File mode  (type and permissions)
'nlink' Number of (hard) links to the file
'uid'   Numeric user ID of file's owner
'gid'   Numeric group ID of file's owner
'rdev'  The device identifier (special files only)
'size'  Total size of file, in bytes
'atime' Last access time in seconds since the epoch
'mtime' Last modify time in seconds since the epoch
'ctime' Inode change time in seconds since the epoch
'blksize'   Preferred block size for file system I/O
'blocks'Actual number of blocks allocated


=item C/C

'sec'   Second
'min'   Minute
'hour'  Hour
'mon'   Month
'year'  Year
'mday'  Day of the month
'wday'  Day of the week
'yday'  Day of the year
'isdst' Is daylight savings time in effect
(localtime only)

=item C

'package'   Name of the package from which sub was called
'file'  Name of the file from which sub was called
'line'  Line in the file from which sub was called
'sub'   Name by which sub was called
'args'  Was sub called with args?
'want'  Hash of values returned by want()
'eval'  Text of EXPR within eval EXPR
'req'   Was sub called from a C (or C)?
'hints' Pragmatic hints with which sub was compiled
'bitmask'   Bitmask with which sub was compiled

=item C

'name'  Username
'passwd'Crypted password
'uid'   User ID
'gid'   Group ID
'quota' Disk quota
'comment'   Administrative comments
'gcos'  User information
'dir'   Home directory
'shell' Native shell
'expire'Expiry date of account of password

=item C

'name'  Group name
'passwd'Group password
'gid'   Group id
'members'   Group members


=item C

'name'  Official host name
'aliases'   Other host names
'addrtype'  Host address type
'length'Length of address
'addrs' Anonymous array of raw addresses in 'C4' format

=item C

'name'  Official name of netwwork
'aliases'   Other names for network
'addrtype'  Type of net

RFC 168 (v3) Built-in functions should be functions

[Perl6 RFC Librarian]

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

=head1 TITLE

Built-in functions should be functions

=head1 VERSION

  Maintainer: Johan Vromans <[EMAIL PROTECTED]>
  Date: 27 Aug 2000
  Last Modified: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 168
  Version: 3
  Status: Frozen

=head1 NOTE

See CHANGES for warp-up info.

=head1 ABSTRACT

RFC 26 proposes to eliminate the distinction between functions and
operators from a language perspective.

This RFC proposes that all Perl built-in functions should be usable in
all ways normal functions can be used. It is part of a big consipracy
to remove the number of cases with exceptional behaviour in Perl.

=head1 DESCRIPTION

Named operators, like C, can be called like functions in which
case they behave like functions. However, that's where the similarity
ends. You cannot override most builtins, and cannot tack a reference
to them. 

There is no reason why the built-ins should be treated differently. A
famous Perl saying reads "if it looks like a function, it B a
function." So be it.

In particular, it is desired that every built-in

=over 4

=item *

can be overridden by a user defined subroutine;

=item *

can have a reference taken;

=item *

has a useful prototype.

=back

=head2 Overriding

The principle of least surprise dictates that

sub I { return 10 }
print I();

should call I() and print "10" for all I.

Currently, most built-ins are excluded from this. For example:

sub system { return 10 }
print system();

Instead of calling the user defined system(), the built-in is used.

The second line may give a warning, but only if warnings are enabled:

Ambiguous call resolved as CORE::system(), qualify as such or use &

=head2 References

You can call a built-in, but not take a reference.

$a = \&system;
print $a->(-1)

This gives an error:

Undefined subroutine &main::system called

This should return a reference to the built-in instead.

Since C<&>I implicitly refers to the current package, it would be
acceptible to require

$a = \&CORE::system;

Note that this currently (5.7.0 DEVEL6806) results in the error:

Undefined subroutine &CORE::system called

which is surprising, if not misleading.

=head2 Prototypes

Currently, several built-ins do not provide prototype information. 

prototype("CORE::abs")  ==>  ;$
prototype("CORE::shift")  ==>  undef

This must be fixed. One might even call this a bug, although the
current prototype mechanism is not powerful enough to cope with all
built-ins. 

=head1 CHANGES

=head2 Version 3

Added CHANGES.

=head2 Version 3, 20 September

Frozen after some discussions on the mailing list. People seem to like
the idea, but worry about the prototypes. Other RFC will deal with that.

=head2 Version 2, 28 Aug 2000

Add Status indicator.

=head1 REFERENCES

RFC 26: Named operators versus functions

Tom Christiansen in <12231.967154045@chthon> (perl6-internals, Aug 24, 2000).

RFC 121 (v2) linkable output mode

[Perl6 RFC Librarian]

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


=head1 TITLE

linkable output mode

=head1 VERSION

  Maintainer: David Nicol <[EMAIL PROTECTED]>
  Date: 17 Aug 2000
  Last Modified: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 121
  Version: 2
  Status: Frozen

=head1 changes

Addition of sentences concerning "perl without perl"

=head1 ABSTRACT


Perl5 offers a clunky interface for those who
wish to call perl subroutines from within C programs.
Herein is suggested a vastly simplified application
programmer's interface:  a C< -o > command line switch identical
to that used in C compilers to produce a linkable object file.


=head1 DESCRIPTION

Two command line switches, -o and -oh, are added to perl6's invocation syntax.


Perl invoked with the -o switch does not run its program, but rather
pukes out an "object file" same way gcc would if given a file full of
C code.

Perl invoked with the -oh switch does not run its program, but rather
pukes out a "header file" suitable for inclusion into a C program,
containing the correct linkage definitions for the object file created
by the -o switch.

The resulting object file must be linked with the perl library to work.

The point is, the perl internals are effectively hidden from the programmer
who wishes to use a feature available in perl from within a C program.


Also, it becomes easier to generate a "stand-alone" deliverable
which will work without a full Perl intallation, by linking the
output of C< perl -o > into a simple main() and delivering the resulting
linked binary along with a perl shared object library. Or by just
doing something like this:

perl -o deliverme.o deliverme.pl
ld deliverme.o -o deliverme


=head1 IMPLEMENTATION

Given a nonprototyped subroutine, C will
generate suitable wrapper
code for all subroutines in the input file, as described in the L
and L perldoc pages, and then pass this code (via a temporary file)
to the same C compiler that was used to build perl.


Given a perl6 subroutine with a fully described prototype, which amounts
to a C struct structure, that structure (with its names if any) can
be used as the parameter types of the resulting function call. A restricted
return type described in terms of basic C data types can function as a
C function return type.

Perl functions that are already using restricted parameter lists
and restricted return types are effectively doing their own type conversions,
except between SV{STRING} and char*, but allowing C access to the SV{STRING}
data type and functions can't be anything but good.


Furthermore, the porting team will need to get very chummy
with the linking system on the platform.


=head1 REFERENCES

my imagination

perldoc perlembed

perldoc perlcall

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

RFC 76 (v4) Builtin: reduce

[Perl6 RFC Librarian]

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

=head1 TITLE

Builtin: reduce

=head1 VERSION

  Maintainer: Damian Conway <[EMAIL PROTECTED]>
  Date: 10 August 2000
  Last Modified: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 76
  Version: 4
  Status: Frozen
  Frozen since: v2
  Note: Really Really Frozen this time

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

=head1 DESCRIPTION

A new built-in -- C -- is proposed. 

This function would take an block, subroutine reference, or curried function 
(hereafter referred to as I),
and call it repeatedly to reduce the remaining arguments
(hereafter, referred to as C).

If the reduction subroutine has a prototype, that prototype
determines how many items are reduced at a time. If the reduction subroutine
is a block or has no prototype, two items are reduced each time.

The first call to the reduction subroutine will be passed the first N
elements of the list, and subsequent calls will be passed the result of
the previous call and the next N-1 elements in the list, until no more
elements remain in the list. All calls to the reduction subroutine are
made in a scalar context.

If fewer than N-1 elements would be available for the final reduction
call, a exception is thrown, unless the reduction subroutine's parameter
list specifies the missing data as being optional. For example:

sub reducer1 ($sum,$n,$k) { $sum + $n**$k }
sub reducer2 ($sum,$n;$k) { $sum + $n**($k||0) }

@data = (1..9);

$result = reduce \&reducer1, 0, @data;  # die (no $k for last reduction)
$result = reduce \&reducer2, 0, @data;  # okay (final $k is undef)

Note that this exception could be thrown I the reduction begins
(assuming C and the other list ops aren't made lazy in Perl 6),
by determining the total number of elements to be reduced (I), the
maximal number of elements that may be procesed on each reduction step
(I), and the minimal number of elements that may be processed on each
step (I), and then testing whether:

___  ___
   | E+1-2R |
r  >  E - R - (R-1)| -- |
   |   R-1  |

is true (in which case an exception is required as there will be insufficient
elements to pass to the final reduction step).

If the original list has no elements, C immediately throws an
exception. If the original list has a single element, that element is
immediately returned (without ever calling the reduction subroutine).
Otherwise, in a scalar context, the result of the final reduction call
is the result returned by C. In a list context, a list of all
the interim values, plus the final value, would be returned.


=head1 EXAMPLES

Summation:

$sum = reduce {$_[0]+$_[1]} 0, @numbers;
$sum = reduce sub{$_[0]+$_[1]}, 0, @numbers;
$sum = reduce ^_+^_,0, @numbers;

Note that the first element of the list -- zero in this case, 1 in the next
example -- represents the default value if the list is empty.


Production:

$prod = reduce {$_[0]*$_[1]} 1, @numbers;
$prod = reduce sub{$_[0]*$_[1]}, 1, @numbers;
$prod = reduce ^_*^_,1, @numbers;


Minimization:

$min = reduce ^x <= ^y ? ^x : ^y,  @numbers
$min = reduce ^x le ^y ? ^x : ^y,  @strings


Minimization to zero:

$min = reduce any(^x,^y)<0 ? 0 : ^x<^y ? ^x : ^y,  @numbers


Collection:

@triples = @{ reduce sub($;$$$){ [@{shift},[@_]] }, [], @singles };


Separation:

$sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] }
 [[],[]],
 @numbers;

# or, more cleanly:

$sorted = reduce { push @{^0->[ ^1 % 2 ]},^1; ^0 }, [[],[]], @numbers;


Accumulative sequence generation:

@increase = reduce ^value + ^delta, $original, @bonuses;

@growth = reduce ^value * ^rate, $principal, @annual_interest_rates;


=head1 IMPLEMENTATION

Extend Graham's List::Util, I'd imagine.


=head1 REFERENCES

The List::Util module

RFC 23: Higher order functions

RFC 128: Subroutines: Extend subroutine contexts to include
  named parameters and lazy arguments

RFC 199: Short-circuiting built-in functions and user-defined subroutines

RFC 12 (v3) variable usage warnings

[Perl6 RFC Librarian]

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

=head1 TITLE

variable usage warnings

=head1 VERSION

  Maintainer: Steve Fink <[EMAIL PROTECTED]>
  Date: 2 Aug 2000
  Last Modified: 20 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 12
  Version: 3
  Status: Developing

=head1 ABSTRACT

"VARIABLE used only once: possible typo" should be replaced with
warnings on uses of uninitialized variables (including lexicals).

=head1 CHANGES

v2: Separated "definitions without uses" from "uses without
definitions" (def-use and use-def chains).

v3: Added example and attempted to improve the explanation.

=head1 DESCRIPTION

Perl6 should distinguish between uses and assignments to variables,
and warn only when a variable is used without being assigned, or
assigned to without being used. In perl5 the complete program

 $x = 3

complains, but

 $x = 3; $x = 3

does not, nor does

 my $x = 3

nor

 use vars qw($x $y); $x = $z; $y = $z;

It would be more useful to have a complaint for both lexical and
package variables, and only when a variable is used without ever being
assigned to (or having its reference taken), or assigned to without
its value ever being used.

The warning for the use of an unassigned variable should be "use of
uninitialized variable C<$x>". This message is too close to the
existing "use of uninitialized value", but that message is badly
phrased anyway, so it will change to "use of undefined value" to
better reflect its actual meaning. (The two are related; "use of
undefined value" can be thought of as encompassing the runtime
counterpart to the compile-time "use of uninitialized variable"
proposed here.) The assignment of a variable which is never used will
result in "variable C<$x> defined but never used".

If whether a variable is initialized is conditional upon the control
flow and thus unknowable at compile time, the warning is "possible use
of uninitialized variable C<$x>".

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.

=head2 EXAMPLE

1 my ($x, $y, $z, $r);
2 $z = 1;
3 f(\$r);
4 my $logfile = "/tmp/log";
5 $x = 1 if cond();
6 print $x+$y;
7 undef $z;
8 print $z;

--> possible use of uninitialized variable $x in line 6 (compile
time)
--> use of uninitialized variable $y in line 6 (compile time)
--> variable $logfile defined in line 4 but never used (compile
time)
--> use of undefined value in line 8 (run time)

No warning is issued for C<$r> because any variable whose reference is
taken may be used and/or assign to through the reference.

=head1 IMPLEMENTATION

I have no idea how difficult this would be to implement. You just need
to distinguish between lvalue and rvalue uses of a variable, I guess?
But hey, this is a language RFC, not an internals RFC. :-) There's
also the question of whether to properly track uses and definitions so
that C<$::z = $x; $x = 3> is a warning, as well as
C<$x = 3 if f(); print $x>. Though the latter would require renaming
the warning to "possible use of uninitialized variable C<$x>".

=head1 CONTRIBUTORS

Glenn Linderman <[EMAIL PROTECTED]> - definitions without uses

=head1 REFERENCES

None.

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

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]

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

[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

[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 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 85 (v2) All perl generated errors should have a unique identifier

[Brad Hughes]

Perl6 RFC Librarian wrote:
[...]
> =head1 TITLE
> 
> All perl generated errors should have a unique identifier
>
[...]
> An id string could have some structure associated to enable
> better handling. One suggestion was to follow the lead of VMS.
> 
> facility:
> The program (or, in perl's case, the thing that errored)
> status:
> I=information, W=warning, E=error, S=Severe error
> message-code:
> A one word abbreviation for the text message
> 
> text message:
> A human readable string with more detail
> 
> A sample error:
> 
> %APPEND-I-CREATED, MEM.SUM;1 created
> 
> For perl the actual text would be in $@.
>

As an aside here, on VMS message text is kept in sharable images, which
are dynamically linked to executables.  This means that, for example,
the same executable can run on one machine with English messages, and
a different machine with French messages, without needing to recompile
or relink.

[...] 
> =head1 REFERENCES
> 
> IBM Messages and Codes
> 
> VMS (anyone have a reference)

http://www.openvms.compaq.com:8000/72final/6100/6100pro_contents.html#toc_chapter_3

> 
> SCCS

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

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

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

[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

[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

[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

[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

[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

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

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

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

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

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

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]

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

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

[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