Re: RFC 263 (v1) Add null() keyword and fundamental data type
This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote: The concept of Cnull as opposed to Cundef is sometimes difficult for people to understand. "People" in this context being the people who are reading perl6-language and purporting to be able to know what Perl 6 needs. People who ought to really understand Perl and how it works. If this concept is too difficult for them, then it really shouldn't exist. KISS. -- If the code and the comments disagree, then both are probably wrong. -- Norm Schryer
RE: RFC 263 (v1) Add null() keyword and fundamental data type
On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen [SMTP:[EMAIL PROTECTED]] wrote: This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Quote from Larry: "I have a particular distaste for the sort of argument that goes, 'If I can't have it my way, I'm going to take all my marbles and go home.' That's not an argument--that's nuclear blackmail. I'm the only one who's allowed to make that sort argument, and you'll never hear me making it." On the other hand, I have to agree with the core sentiments. All this talk about nulls and strong types and everything-is-an-object is frankly scaring the willies out of me. Maybe perl does need a revamp, but it should still stay perl. I'm a perl programmer, not a Visual PerlBOLthonajaffellispQL++ robot. Perl has always stood on these: There is more than one way to do it. (Public/private OOP?) No arbitrary limits. (Everything is an object? Exceptions getting in the way of open(FILE,"file") or die "$!\n"? Hard typing?) We're very proud of our language that doesn't force us to put an if before or after a statement, and doesn't care whether we indent one tab per block level, and doesn't belch out exceptions at us if we forget the ungodly mess of exception classes, and allows sheep to sleep and die if I feel poetic. Perl is Perl. It isn't Java. It isn't C++. It isn't Python (thank goodness). Maybe there are a few nifties we can borrow from those creations, but twisting the language inside out to make it closely resemble something second or third or fourth best is quite distasteful. We're improving a language here, not creating a new one. Again from Larry: "At the moment, I'm not only trying to follow along here; I'm also reading all the books on computer languaes I can get my hands on--not just to look for ideas to steal, but also to remind myself of the mindset Perl was designed to escape." and nate: "If you want Ada, you know where to find it" There are a lot of good ideas in these RFC's. Lot of wishing it was language X too, which I can't see as a good thing. Map to null, work around the problem. It takes, what, one line of code to do so? This isn't C where it would take 20 or C++ where it would take 200. But having a real switch statement... that's been on the table for years now... and having parseable regex syntax, fine.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
David Grove wrote: On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen wrote: This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Quote from Larry: "I have a particular distaste for the sort of argument that goes, 'If I can't have it my way, I'm going to take all my marbles and go home.' That's not an argument--that's nuclear blackmail. I'm the only one who's allowed to make that sort argument, and you'll never hear me making it." Yes, and this RFC was already retracted, so flames are particularly silly. So could we all please let it die and comment on the 'use tristate' alternative proposed in RFC 275? -Nate
Re: RFC 263 (v1) Add null() keyword and fundamental data type
At 10:26 AM 9/27/00 +0100, Simon Cozens wrote: On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote: The concept of Cnull as opposed to Cundef is sometimes difficult for people to understand. "People" in this context being the people who are reading perl6-language and purporting to be able to know what Perl 6 needs. People who ought to really understand Perl and how it works. If this concept is too difficult for them, then it really shouldn't exist. KISS. SQL's NULL is an interesting and rather useful concept, though it's fairly mind-bending if you've not had much reason to use it. (The same can be said for OO programming, undef, and regular expressions) Whether (and how) it should be in perl is another matter entirely, of course. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Glenn Linderman [EMAIL PROTECTED] writes: Russ Allbery wrote: Perhaps I don't use those warnings in the same way that you do. I *very* rarely have undefined value warnings in my programs, and when I do they're usually not actually bugs, just things that require a different way of writing to be -w clean. So I don't have as high of an opinion of this warning as being particularly important to debugging; I only find it useful in certainly particular circumstances. I can't say that I often get the warning, but when I do, I find it generally results from a bug. So something about the way we write code is different, I guess. Most likely. It caught stuff for me before use strict (generally variable typos) but with use strict, those warnings tend to be either checking for keys in aggregate structures when they've not been initialized (which is mostly just an annoyance) or they're just a symptom of something going wrong somewhere else entirely and aren't particularly helpful in tracking down where it's going wrong. I find this absolutely amazing. You've now convinced me you understand the arguments I've been making, and the issues I'm concerned about... and yet you still hold this opinion. Certainly we have a difference of opinion here. It's quite possible that I'd have a different opinion if I used it for a while; I don't know. I think it's worth trying it with undef first and writing some code that way and seeing how it works and how hard it is to debug. Russ, I apologize. I confused you with someone else in this posting. I looked back over your postings, and you, unlike those that seem to just hate SQL, have repeatedly expressed interest in using the tristate semantics. I've been trying to keep my nose clean regarding remarks like this, but I guess my frustration level finally got the better of me...and perhaps partly, I guess I stayed up too late last night and probably shouldn't be posting this late tonight either. No problem; it's easy enough to do. :) Maybe the enlightenment is shed by your earlier remark: you don't find the undef warnings to be particularly important to debugging. So maybe that is the reason that you don't see the need to concurrently have both sets of semantics available? That's quite possible. Since you don't need the current set of semantics? The main thing I use undef for is in areas where I'm checking with defined, which I would assume would continue to work regardless of the selected semantics of undef. Having undef propagate would make it useful in additional areas (or at least I think it would). From writing language parsers, I found that it's useful in areas other than SQL to have a distinguished value that propagates through any arithmetic operation. Going back to your first remark about seeing confusion either way, maybe explaining the types of confusion that you see with a separate null and undef vs the types of confusion that you see with a tristate pragma would help me to grasp that logic. The main thing I'm worried about with undef plus null is that undef is already very hard to explain and having an additional parallel concept that behaves slightly differently and that can easily be confused with undef is worrisome. The advantage of explaining a tristate pragma is that with normal undef semantics, most times undef shows up in an arithmetic or logical operation other than a simple test of true or false, it's symptomatic of poorly-constructed code; increments are about the only exception. So the area that tristate logic changes is not something that we recommend that people use under normal circumstances. And if/when my database needs require the use of multiple different NULL values (currently they are not there, multiple NULL values do get talked about by relational theorists, and there is some move to put them into the SQL standard, but it appears they haven't yet appeared in one) I see having multiple "special non-values" (as someone else called them) much simpler to extend to the concept of multiple NULL values than the pragma approach. Hm. Yes, that's a good point. (At that point, something more like Quantum::Superpositions may be more what you want.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Russ Allbery wrote: use 'strict' is probably the difference between our code... I tend not to use it, because I wrote a bunch of code that didn't, initially, before I heard of it (maybe before it existed? I started with Perl 4.something), and haven't gotten it all converted so that it can be used together with strict. A project that hasn't yet gotten high enough on my priority list. Going back to your first remark about seeing confusion either way, maybe explaining the types of confusion that you see with a separate null and undef vs the types of confusion that you see with a tristate pragma would help me to grasp that logic. The main thing I'm worried about with undef plus null is that undef is already very hard to explain and having an additional parallel concept that behaves slightly differently and that can easily be confused with undef is worrisome. That's an interesting observation. To me, the concept of undef could be explained in a paragraph. But I've been working with SQL NULL for 15 years before I heard of Perl and its undef so I had no problem with the concept. I guess if undef is perceived as hard to understand or explain, then SQL NULL would be perceived as hard to understand and explain. To me, SQL NULL is somewhat complex, but understandable, and undef is totally trivial. The advantage of explaining a tristate pragma is that with normal undef semantics, most times undef shows up in an arithmetic or logical operation other than a simple test of true or false, it's symptomatic of poorly-constructed code; increments are about the only exception. So the area that tristate logic changes is not something that we recommend that people use under normal circumstances. I can see that. Following that logic down the path of my preferred implementation, though... It seems to me that if 99% of the perl operators were simply modified such that SQL NULL in produced SQL NULL out (which is the net effect of most of the changes to most of the operators, to achieve the desired semantics), that 99% or more of the time, a programmer that wants to ignore NULL could quite easily do so... if they aren't introduced in the input, they won't come out the output, even if the operators are ready, willing, and able to deal with them. Which is why I can't see why people get so upset about the idea. undef gets introduced into their data if they forget to initialize something, and because some perl operations return it as a failure indication. But SQL NULL would only get introduced into their data if they explicitly do so, or use something like a ported DBI. And if they use a ported DBI (ported to use NULL rather than undef, that is), then they probably speak SQL, and SQL NULL would not be a new concept. And if we wanted to make it explicitly 100% ignorable, we could have a pragma to "enable or disable NULL", which would make it impossible to introduce NULL into the data (make the null keyword a compile error). But I still think that when it is turned on, it should be a separate concept. And if/when my database needs require the use of multiple different NULL values (currently they are not there, multiple NULL values do get talked about by relational theorists, and there is some move to put them into the SQL standard, but it appears they haven't yet appeared in one) I see having multiple "special non-values" (as someone else called them) much simpler to extend to the concept of multiple NULL values than the pragma approach. Hm. Yes, that's a good point. (At that point, something more like Quantum::Superpositions may be more what you want.) Is it? As far as I could read, Quantum::Superpositions defines null as the empty set. There was no provision for multiple absence concepts. Perhaps that could be added though. And if Damien Neil is correct, and if Perl overloading is powerful enough, it may be possible to overload all the operators to deal with a NULL module, which could have 29 different instantiated sub-object types? No time until next week, maybe, to pursue that path further... I've been reluctant to dive that direction into Perl, until I got my code "strict-ized", but seems like I'll probably invert that priority. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Fri, 22 Sep 2000, Glenn Linderman wrote: In my opinion, which you probably will also not agree with, attempting to toggle between the current undef semantics and tristate semantics is like trying to stuff three values into one bit. This comment assumes that the current undef is implemented by a bit in a variable structure; when the bit is in one state, it means the value is undef, and when the bit is in the other state, it means the value is not undef. If this is what you're assuming, no wonder there's a disconnect. Explore overloading. I think it's where you're likely to find your solution. (Particularly with vtables behind them.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Glenn Linderman said [in response to Russ]: ...maybe explaining the types of confusion that you see with a separate null and undef vs the types of confusion that you see with a tristate pragma would help me to grasp that logic. I don't see why we need to keep spinning our wheels on this issue. It's really not each other we need to convince. Let's give Larry some credit. He'll make the right decision. -- John Porter We're building the house of the future together.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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 ___
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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
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
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
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
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
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
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 263 (v1) Add null() keyword and fundamental data type
No, in that wonderfully consistent Perl documentation, it's "undef" not SNIP 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 tSNIP the null This uses null as a noun, and it has a different meaning than undef. A null is a null byte, or a null character. Period. You are completely out of your mind if you expect to co-opt an extant term for this screwed up notion of yours. I place my faith in Larry not to fuck up the language with your insanity. --tom
Re: RFC 263 (v1) Add null() keyword and fundamental data type
In Perl, this is the null string:"" In Perl, this is the null character: "\0" In Perl, this is the null list: () In RFC 263, this is the null: null That's a different word for a different concept. No conflict, if you learn the way the RFC speaks. Wrong. Just plain wrong. It's a shame you don't like it, but this is the way we speak. What's this we and you business? I'm a perl user too. Who can't speak. If you wish to make sense of the documentation, you must learn its language. The documentation isn't all that consistent about everything, either. Perhaps you, personally, are more so, and if so, perhaps you should help rewrite the documentation to make it as perfectly consistent as yourself. Thank you very much, but I just did that. It's called Camel-3. I allowed that you might want to call it the null string, and I'm allowed to read "null string" and think "empty string", and I'm just as right as you are. You must not have a cohesive argument to make, if you resort to insults in an attempt to make points. You haven't heard insults. Here are insults: you are a stupid idiot. And I am incredibly glad that within hours, I'm about to spend three solid weeks afraid from such a fucked up blathering fool. --tom
Re: RFC 263 (v1) Add null() keyword and fundamental data type
By your "reasoning", we can just add infinitely more things that take twice a few pages to explain. You took that to an illogical extreme conclusion. Clearly you can't add everything to the language. However, it is clear by the set of currently submitted RFCs that more people think suggesting additions to Perl is a better use of their time than suggesting subtractions. Bullshit. If it takes several pages just to introduce your new, fucked-up notion of "false", you've done something wrong. If it then again takes several pages just to introduce how your new, fucked-up notion of "false" is different from the existing ones, you've done something wrong. Guess what? You've done something wrong. Perl is already too hard. So make it easier. Where are your RFCs to remove things? They're right here in my edit buffer. I will simply explain them to Larry directly. You won't even get the chance to waste my time. Fortunately, I have every reason to believe that Larry will reject your idiotic notion of false that grew out of a cancerous complexity in an obscure niche of programming has no business burdening users with its incredibly lame-ass naming and confusing behavior. --tom
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Tom Christiansen wrote: A null is a null byte, or a null character. Period. ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer to a null byte or null character. You are not correct, period or otherwise. You are completely out of your mind if you expect to co-opt an extant term for this screwed up notion of yours. The concept of NULL is not a screwed up notion of mine; it has been used in SQL since the mid-1970s. I'm not sure exactly when Perl appeared on the scene, but I think it is a relative newcomer, compared to SQL. I place my faith in Larry not to fuck up the language with your insanity. This problem seems to be in your mind, not mine. I have logical (albeit controversial) justification for each statement I have made. You, in this discussion, have clearly been motivated by something other than a desire to make the language more powerful; you have resorted to quarrelsome tautologies instead of logic, and profanity rather than helpful criticism. If you have nothing useful to say, please refrain from saying it. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Thu, 21 Sep 2000, Tom Christiansen wrote: A null is a null byte, or a null character. Period. You are completely out of your mind if you expect to co-opt an extant term for this screwed up notion of yours. I place my faith in Larry not to fuck up the language with your insanity. --tom I've got your null right here... :0 * ^From: Tom Christiansen /dev/null Can't we all just play nice? Paris Sinclair|4a75737420416e6f74686572 [EMAIL PROTECTED]|205065726c204861636b6572 www.sinclairinternetwork.com
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On 20 Sep 2000, Russ Allbery wrote:
About the only piece of code of mine that this would affect are places
where I use ++ on an undef value, and that's not a bad thing to avoid as a
matter of style anyway (usually I'm just setting a flag and = 1 would work
just as well; either that, or it's easy enough to explicitly initialize
the counter to 0).
Depends. While it is possible to initialise counters in the canonical
"have I seen this before" situation, it's more convenient the way it is at
the moment:
$seen{$word}++;
looks, to me, nicer than
$seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1;
or
if(defined($seen{$word})) { $seen{$word}++ } else { $seen{$word} = 1 }
or similar.
Cheers,
Philip
--
Philip Newton [EMAIL PROTECTED]
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Thanks, Paris, for your intervention, although I fear it was too late. Well, since Tom claims to have put me in his kill file, he may never see this. But for the record... Tom Christiansen wrote: Can't we all just play nice? Apparently not. Several of us attempted to explain why this didn't make sense, for many reasons. GL wouldn't hear any of it, stubbornly adhering to this notion despite what was said, often completely ignoring or apparently purposefully misunderstanding the points. It's true that I think that NULL would be an extremely useful concept, and until there is a cogent argument to the contrary, I will continue to believe it. I've been working with databases for 21 years, and with Perl for 5, and I truly believe NULL would be a useful addition to using Perl to work with databases. However, it is not true that I ignored or purposefully misunderstood any of the points raised. The record stands for itself in the archive. I may not be as brilliant as TC, I may not have understood all the points, and I may not have as much history with using Perl as TC, but I can distinguish logical propositions and argumentative posturing. Here's Tom's first complete message in the RFC 263 thread for example: Currently, Perl has the concept of Cundef, which means that a value is not defined. One thing it lacks, however, is the concept of Cnull, which means that a value is known to be unknown or not applicable. These are two separate concepts. No, they aren't. --tom He then started accusing others of insults where none existed. Screw that. Since he asked for insults, now he got them. The record is in the archives. If anyone cares to figure out where the first insult came from, they can read it. I'm sure glad Damian called me on my sniping remark to him before this imbroglio started... so I was really, really trying to keep my nose clean. Really, as Damian pointed out, such bickering is not a profitable use of time. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Russ:
About the only piece of code of mine that this would affect are places
where I use ++ on an undef value, and that's not a bad thing to avoid as a
matter of style anyway (usually I'm just setting a flag and = 1 would work
just as well; either that, or it's easy enough to explicitly initialize
the counter to 0).
Philip:
Depends. While it is possible to initialise counters in the canonical
"have I seen this before" situation, it's more convenient the way it is at
the moment:
$seen{$word}++;
looks, to me, nicer than
$seen{$word} = (exists $seen{$word}) ? 1 : $seen{$word} + 1;
er, flip that.
or
if(defined($seen{$word})) { $seen{$word}++ } else { $seen{$word} = 1 }
or similar.
In general, if you can get away with a simpler expression, it's better.
For example,
if ($foo is_whatnot($foo))
is inferior to
if ($foo)
just as
if (!$foo !is_whatnot($foo))
is inferior to
unless ($foo)
"Inferior by what metric?" you ask? Complexity.
Larry wrote (in Camel-3) that
...the autoincrement will never warn that you're using undefined values,
because autoincrement is an accepted way to define undefined values.
^^^
So I think you're safe there.
He also wrote:
The C|| can be used to set defaults despite its origins as a
Boolean operator, since Perl returns the first true value. Perl
programmers manifest a cavalier attitude with respect to truth,
since the line above would break if, for instance, you tried
to specify a quantity of 0. But as long as you never want to
set either C$quality or C$quantity to a false value, the
idiom works great. There's no point in getting all superstitious
and throwing in calls to Cdefined and Cexists all over the
place. You just have to understand what it's doing. As long
as it won't accidentally be false, you're fine.
Simple true and simple false are best if your goal is simplicity.
Sometimes you need more than that. So you write functions. Or,
if you're into the quirks of using strange magic of occasionally
dubious charm, then through operationally overloaded objects.
--tom
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote: Russ Allbery wrote: Why on earth would you want to do this in real code? I wouldn't, of course. This is just a demonstration that I want both semantics available concurrently. If you are not going to use it, why implement it ? I don't believe you actually need both semantics active at the same time; I do. Need might be a slightly stronger word than necessary, but "want" and "convenience" sure come strongly to mind... the proposals to switch from one set of semantics to another just don't cut it for ease of use. How can you convince anyoone if you say you would not use it. For any feature enhancement to perl, unless there is a strong case for how it makes the labguage easier and better it is just not going to happen. Graham.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
How can you convince anyoone if you say you would not use it. For any feature enhancement to perl, unless there is a strong case for how it makes the labguage easier and better it is just not going to happen. It's not as though Tim Bunce has been hollering for this, which is a bad sign. --tom
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Glenn Linderman wrote: If they are the same, then you can't tell the different between a variable that is yet uninitialized, and one that has been read in from the database, containing a NULL. In my mind, that is horribly confusing. Since this is a theoretical argument -- as evidenced by the fact that you have never actually had a situation where this lack of distinction was really a problem -- I believe it's time for you to stop wasting everyone's time on it. Thanks. -- John Porter
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Glenn Linderman wrote: ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer to a null byte or null character. Now, that's not accurate either. "NUL" is simply a normalized form of "null", because all the ASCII special characters have three upper-case letter names. There is no doubt that the ASCII guys meant "null" by this. -- John Porter
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Now, that's not accurate either. "NUL" is simply a normalized form of "null", because all the ASCII special characters have three upper-case letter names. There is no doubt that the ASCII guys meant "null" by this. All other matters aside, kindly consider this simple one: If ever you thought homophones were bad, imagine then how to rely upon nothing more than mere case distinction, an ancillary artifact of our system of writing, in two distinct terms whose usages are not radically different from each other but whose meanings most certainly are, is an endeavour virtually guaranteed to be frequently misheard and thus misconstrued when those terms are used in spoken discourse--as they inevitably shall be. --tom
Re: RFC 263 (v1) Add null() keyword and fundamental data type
At 02:39 AM 9/21/00 -0700, Glenn Linderman wrote:
Thanks, Paris, for your intervention, although I fear it was too late.
Well, since Tom claims to have put me in his kill file, he may never see
this. But for the record...
Tom Christiansen wrote:
Can't we all just play nice?
Apparently not. Several of us attempted to explain why this didn't
make sense, for many reasons. GL wouldn't hear any of it, stubbornly
adhering to this notion despite what was said, often completely
ignoring or apparently purposefully misunderstanding the points.
It's true that I think that NULL would be an extremely useful concept,
and until there is a cogent argument to the contrary, I will continue to
believe it. I've been working with databases for 21 years, and with Perl
for 5, and I truly believe NULL would be a useful addition to using Perl
to work with databases.
Ok, let's see if I can make some sense of this...
You want a singleton scalar datatype in addition to the exising scalar
datatypes of strings, numbers, references, filehandles, and undef that
represents an unknown value, similar in semantics to the SQL notion of "NULL".
I'm going to call this prototypical datatype/value "unknown", in order to
represent its meaning in a more perlish way, as well as to avoid the
overloaded semantics of NULL (and it's related near-homonyms: SQL's unknown
NULL, C's NULL invalid pointer, Lisp's NIL, ASCII's NUL, the null string,
the null list, etc). Calling anything NULL these days is likely to be
confusing, so I'll avoid it.
This doesn't matter as far as database work goes because DBI can convert
between SQL NULL and perl unknown just as easily as it can convert between
SQL NULL and perl undef.
I just reread RFC 263, and I do have some unanswered questions. How
pervasive is this "unknown" value? If $a is unknown, what about $a
Given:
$a = unknown;
print "\$a is ", ($a ? "true" : "false"), "\n";
What should print?
I think the example of:
die "Fatal, \$name is unset!" if ($name == null);
is flawed. It will never die, because as you said, two unknown values
won't compare as equal. Besides, the test would try to convert both $name
and null to numbers before doing the numerical comparison, so it would
depend on what the numerical value of unknown is. You really need a
"known()" built-in to go with this, such that known($a) is true if $a is
NOT unknown.
What gets me is that the implementation of this would require virtually
every operator, function, etc in core perl to be special-cased to deal with
the unknown value, yet the RFC makes no mention of this.
With undef, it's simply a matter of having the internal representation of
undef return 0 or "" when asked for a numerical or string value. This
makes most things deal with undef nicely -- even booleans. With unknown,
since it is specifically designed to propagate, everything would have to
deal with unknown values, not just integers, or strings, or booleans.
Importantly, unless you decide something arbitrary like "unknown is false"
like the way that it was decided that "undef is false", then you throw out
the law of excluded middle (every expression is either true or false), and
make things like the ?:, ||, or operators go all wiggly (not to mention
if, while, unless, and so forth). And if you do arbitrarily say "unknown
is false", how do you deal with the cases where you want to say "I don't
know if it's true or false"?
SQL gets away with this by saying that boolean contexts require a boolean
value, which you get by using a relational operator. People don't go "IF
variable THEN..." unless they know that variable will be boolean -- and
can't be NULL. And they then decided that using a relational operator on
NULL will always yield FALSE. That works for them.
But that's not Perl. Perl programmers like functions that return a useful
but true value on success, or undef on failure, and are quite comfortable
going:
$var = f();
if ($var) { g($var) }; # f was a success
That won't work if $var can end up being unknown. Worse, fixing it by saying
if (defined($var)) { g($var) };
doesn't help, because the RFC says that defined(unknown) is unknown!
Your unknown seems to be very special-case for doing SQL-based DB work. In
all my time programming it, I can't remember wanting it. It doesn't seem
to integrate with the rest of Perl all that well, requiring massive changes
under the hood to integrate it and the potential for messing up lots of
long-standing Perl idioms, for a relatively small benefit.
Damian mentioned that his Q::S package and RFC would/could provide
something with similar semantics, and his RFC would also likely result in
massive changes under the hood, but it also provides a large generally
useful functionality (and in CONSTANT TIME, too ;-). It is unclear as of
yet if the benefit of Q::S will outweigh the probably cost of Q::S. Can
you make as strong a case for unknown?
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Philip Newton wrote:
Having $seen{$word}++ turn $seen{$word} to undef is bad, if (undef)++
assumes NULL semantics everywhere, hence "one more than unknown" = "still
unknown".
Right. Applying NULL semantics to undef would be bad. The counterproposals to
RFC 263, along the lines of "use tristate", seem to overlook this sort of
situation. They also overlook the beneficial debugging warnings that would be
lost for inappropriate use of uninitialized variables that would be lost if you
use undef for NULL.
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Graham Barr wrote:
On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote:
Russ Allbery wrote:
Why on earth would you want to do this in real code?
I wouldn't, of course. This is just a demonstration that I want both
semantics available concurrently.
If you are not going to use it, why implement it ?
I would use the feature; not the particular lines and sequence of code above.
I don't believe you actually need both semantics active at the same time;
I do. Need might be a slightly stronger word than necessary, but "want" and
"convenience" sure come strongly to mind... the proposals to switch from one
set of semantics to another just don't cut it for ease of use.
How can you convince anyoone if you say you would not use it. For any feature
enhancement to perl, unless there is a strong case for how it makes
the labguage easier and better it is just not going to happen.
There is certainly lots of room for multiple interpretations of English language
statements.
The purpose of writing the code sequence was to demonstrate that I want both
semantics available concurrently, not to be, in and of itself, a useful code
sequence. I interpreted Russ' question as one pertaining to the particular code
sequence itself--why would I want to do that code sequence--and I wouldn't. What
on earth would I do with all those repititious "true"s? But the code sequence
does illustrate the coexistance of both undef and NULL semantics in the same code
block, which was its intention. It tried to be somewhat complete about exercising
different aspects of the semantics of both data values, to avoid rebuttals of
partial solutions that are not satisfactory.
Now you are twisting my words to say I meant I wouldn't use the whole concept. I
wouldn't be spending the time answering all these EMails if I wouldn't use the
whole concept, and I think you know that, so pardon my use of the word "twisting".
Here is a code sequence that is less demonstrative of the complete sets of
semantics for the two concepts, undef, and null, but is more likely to useful in
real code. It was, indeed, taken from real code, and modified only slightly. It
uses DBI, which today returns undef in lieu of NULL, but in writing this sample,
I'm assuming that DBI has been ported or wrapped to return the RFC 263 (v1)
concept of NULL for SQL NULL, and that undef semantics are unchanged.
# $sth is a DBI statement handle when we get here.
my $i = 0;
$display-header($sth, \*STDOUT);
while (my $rowref = $sth-fetchrow_arrayref()) {
$i++;
push ( @lastres, [ @$rowref ] );
if ( $opt{'--expandcr'} )
{ foreach ( @{$lastres[$#lastres]} )
{ s/\r/\n/g; # note this line
print;
}
}
$display-row($lastres[$#lastres]);
}
$display-trailer($i);
my $rows = $i;
print "[$rows row" . ($rows==1 ? "" : "s") . " affected]\n";
The line with the note currently requires an "if defined $_" conditional, because
possible NULL values come back as undef, and warnings result. The purpose of the
code is to display data retrieve from a statement and, if the --expandcr option is
specified, preprocess that data before displaying it, changing \r to \n so it
displays correctly on Windoze.
This is a small example, with small ramifications and a one phrase workaround...
just an illustration of the kind of problem solved by using NULL semantics. But
in using DBI, I find I have to scatter distracting "if defined" and "unless
defined" phrases all over the place to avoid warnings. With RFC 263, processing
of NULL would happen correctly automatically, without the "if defined" phrases.
And yet, I'd still get nice warnings if I attempted to misuse a variable
containing undef (the initialization default value, as in perl right now).
I hope this small illustration demonstrates the differences in semantics that is
desired, and why they are useful. When doing more serious data manipulation the
ratio and complexity of "if defined" phrases goes up.
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
Re: RFC 263 (v1) Add null() keyword and fundamental data type
John Porter wrote: Glenn Linderman wrote: If they are the same, then you can't tell the different between a variable that is yet uninitialized, and one that has been read in from the database, containing a NULL. In my mind, that is horribly confusing. Since this is a theoretical argument -- as evidenced by the fact that you have never actually had a situation where this lack of distinction was really a problem -- I believe it's time for you to stop wasting everyone's time on it. Thanks. Not theoretical. Sample real code posted just earlier, in response to Graham Barr's comments. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Buddha Buck wrote:
Ok, let's see if I can make some sense of this...
Thanks for trying. I think you have.
You want a singleton scalar datatype in addition to the exising scalar
datatypes of strings, numbers, references, filehandles, and undef that
represents an unknown value, similar in semantics to the SQL notion of "NULL".
I'm going to call this prototypical datatype/value "unknown", in order to
represent its meaning in a more perlish way, as well as to avoid the
overloaded semantics of NULL (and it's related near-homonyms: SQL's unknown
NULL, C's NULL invalid pointer, Lisp's NIL, ASCII's NUL, the null string,
the null list, etc). Calling anything NULL these days is likely to be
confusing, so I'll avoid it.
Correct description; I don't really care what it's called; the concept is what is
important.
This doesn't matter as far as database work goes because DBI can convert
between SQL NULL and perl unknown just as easily as it can convert between
SQL NULL and perl undef.
Correct.
I just reread RFC 263, and I do have some unanswered questions. How
pervasive is this "unknown" value? If $a is unknown, what about $a
Given:
$a = unknown;
print "\$a is ", ($a ? "true" : "false"), "\n";
What should print?
Well, that's an interesting question, and gives me an inspiration. A "ternary"
operator is nicely useful with a binary logic system. It would seem that a
"quatenary" operator would be more useful with a ternary logic system. Yet SQL
suffers along with binary operators and a ternary logic system. Buddha, I think
you've hit the nail on the head about why so many people find SQL NULL so hard to
deal with.
So first, I'll answer your question as stated, and then I'll exposulate on the
inspiration above.
For your example, "false" should print. This is because $a is not true, so the
"true" branch should not be taken, so the else brach is taken instead. However,
the text printed is misleading, because the value isn't false, but unknown. The
text should be changed to "not true", or "false or unknown", to be useful in a
ternary logic system.
The exposition on the inspiration: The basic problem that results from ternary
logic is that there are three possible results: true, false, and unknown.
Structured programming based on binary logic has given us operations that consider
only two possible results, true and false, that being all there is in binary
systems.
So the basic if/then/else construct that perl, SQL, and most other programming
languages have, and the ternary operator, really don't allow simple expression of
conditionals when using a ternary logic system.
So one could extend the logic programming construct, say with "otherwise" (I
hesitate to reuse "unknown" for both the data value and the keyword), resulting in
if ( ternary_condition )
# then
{ # true part
}
else
{ # false part
}
otherwise
{ # unknown part
}
Or, a switch-like statement could be similarly used/extended. Such constructs
would quite possibly make it easier to write programs based on ternary logic. The
historical problem with using binary constructs with ternary logic is the need to
repeat part of the condition in one leg of the binary structure to further
subdivide it into the remaining two clauses needed, and with complex conditions,
that becomes more complex quickly. Ternary structured constructs could simplify
this.
I think the example of:
die "Fatal, \$name is unset!" if ($name == null);
is flawed. It will never die, because as you said, two unknown values
won't compare as equal. Besides, the test would try to convert both $name
and null to numbers before doing the numerical comparison, so it would
depend on what the numerical value of unknown is. You really need a
"known()" built-in to go with this, such that known($a) is true if $a is
NOT unknown.
Yes, known(), that's consistent with "unknown", and would substitute for
"isnull()" which was mentioned by others. I agree that example is flawed.
What gets me is that the implementation of this would require virtually
every operator, function, etc in core perl to be special-cased to deal with
the unknown value, yet the RFC makes no mention of this.
Yes, it is true that virtually every operator would have to change. This is not a
trivial matter. The closest the RFC comes to mentioning it is "that have the
proper semantics" in the implementation section.
With undef, it's simply a matter of having the internal representation of
undef return 0 or "" when asked for a numerical or string value. This
makes most things deal with undef nicely -- even booleans. With unknown,
since it is specifically designed to propagate, everything would have to
deal with unknown values, not just integers, or strings, or booleans.
Yes.
Importantly, unless you decide something arbitrary like "unknown is false"
like the way that it was decided that "undef is false", then you throw out
the law of
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Glenn Linderman [EMAIL PROTECTED] writes:
Philip Newton wrote:
Having $seen{$word}++ turn $seen{$word} to undef is bad,
It doesn't "turn it to undef"; if you're using tristate semantics, it
leaves it as undef, because those are the semantics you've selected for
undefined values.
if (undef)++ assumes NULL semantics everywhere, hence "one more than
unknown" = "still unknown".
No one's proposing that. People are proposing the ability to turn on NULL
semantics where you need it.
Right. Applying NULL semantics to undef would be bad. The
counterproposals to RFC 263, along the lines of "use tristate", seem to
overlook this sort of situation.
I'm not overlooking it; I just don't agree with you. There *is* a
difference.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Russ Allbery wrote: I'm not overlooking it; I just don't agree with you. There *is* a difference. You are certainly welcome to not agree with me. And if you didn't overlook it, that is fine. In my opinion, which you probably will also not agree with, attempting to toggle between the current undef semantics and tristate semantics is like trying to stuff three values into one bit. This comment assumes that the current undef is implemented by a bit in a variable structure; when the bit is in one state, it means the value is undef, and when the bit is in the other state, it means the value is not undef. The problem is, when you toggle the pragma, all variables whose value is undef suddenly have the tristate semantics, and when you toggle it back, all the variables whose value is undef suddenly have the undef semantics. This leaves it purely to the programmer to make sure that the pragma is used in exactly the right places, and, when tristate semantics are in effect makes unavailable the normal, helpful warnings that Perl produces when you attempt to misuse undef values. I guess that since you have no intention of using the tristate semantics, you don't care whether it is easy to code using them. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Glenn Linderman [EMAIL PROTECTED] writes: In my opinion, which you probably will also not agree with, attempting to toggle between the current undef semantics and tristate semantics is like trying to stuff three values into one bit. I do understand the argument. I just see confusion either way, and I think that approach would be the least confusing and allow the code to remain the most Perl-like. I can see arguments the other way; that's just my opinion. The problem is, when you toggle the pragma, all variables whose value is undef suddenly have the tristate semantics, and when you toggle it back, all the variables whose value is undef suddenly have the undef semantics. This leaves it purely to the programmer to make sure that the pragma is used in exactly the right places, and, when tristate semantics are in effect makes unavailable the normal, helpful warnings that Perl produces when you attempt to misuse undef values. Perhaps I don't use those warnings in the same way that you do. I *very* rarely have undefined value warnings in my programs, and when I do they're usually not actually bugs, just things that require a different way of writing to be -w clean. So I don't have as high of an opinion of this warning as being particularly important to debugging; I only find it useful in certainly particular circumstances. To me, toggling the semantics of the variables which are already undef strikes me as just what I'd want. I guess that since you have no intention of using the tristate semantics, you don't care whether it is easy to code using them. Comments like this are what is making it very difficult for me to continue discussing this with you. You don't actually know what type of Perl I write or whether or not I'd use the semantics or not. As a matter of fact, I find them very interesting and fully do expect to use those semantics if they're implemented in Perl, particularly given that I'm likely to be doing a lot more database and SQL coding in the future than I am currently. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Damian Conway wrote: Should I point out that RFC 225 (Superpositions) actually covers most of this? Cnull is equivalent in semantics to Cany() or Call(). I'd love to read your not yet available paper to which the RFC refers. However, until it is available, and I have time to read it, I'll spend my time reading proposals and discussions that are available. -- 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
On Tue, 19 Sep 2000, Glenn Linderman wrote: I agree that undef and NULL have different semantics. However, this is clearly SQL's fault and not Perl's. We shouldn't repeat their mistake just because we occasionally have to interface with their system. 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? Why do so many RDBMs implement NULL 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. 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. What you just described is actually a bad idea. If you want to program in SQL you know where to find it. 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. Do you want to do pointer arithmetic in Perl with data you get from C programs too? 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. 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. 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. If you want warnings, use strict and undef. Under your plan DBI would be modified to return NULLs, right? How would I "use strict and undef" then? -sam
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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. If undef functioned differently than null, 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. 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. 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.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Should I point out that RFC 225 (Superpositions) actually covers
most of this?
Cnull is equivalent in semantics to Cany() or Call().
I'd love to read your not yet available paper to which the RFC
refers. However, until it is available, and I have time to read it,
I'll spend my time reading proposals and discussions that are
available.
I know we're all under a great deal of pressure as the deadlines draw
near, but let's *try* and preserve the positive tone that has pervaded
this discussions until now. Sniping -- even politely -- is only
counterproductive.
Meanwhile, please accept my apologies that other commitments have not
allowed me the time to finish the full paper on the topic.
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.
Damian
---cut---cut---cut---cut---cut--
NAME
Quantum::Superpositions - QM-like superpositions in Perl
SYNOPSIS
use Quantum::Superpositions;
if ($x == any($a, $b, $c)) { ... }
while ($nextval all(@thresholds)) { ... }
$max = any(@value) all(@values);
use Quantum::Superpositions BINARY = [ CORE::index ];
print index( any("opts","tops","spot"), "o" );
print index( "stop", any("p","s") );
BACKGROUND
Under the standard interpretation of quantum mechanics, until they are
observed, particles exist only as a discontinuous probability function.
Under the Cophenhagen Interpretation, this situation is often visualized
by imagining the state of an unobserved particle to be a ghostly overlay
of all its possible observable states simultaneously. For example, a
particle that might be observed in state A, B, or C may be considered to
be in a pseudo-state where it is simultaneously in states A, B, and C.
Such a particle is said to be in a superposition of states.
Research into applying particle superposition in construction of
computer hardware is already well advanced. The aim of such research is
to develop reliable quantum memories, in which an individual bit is
stored as some measurable property of a quantised particle (a qubit).
Because the particle can be physically coerced into a superposition of
states, it can store bits that are simultaneously 1 and 0.
Specific processes based on the interactions of one or more qubits (such
as interference, entanglement, or additional superposition) are then be
used to construct quantum logic gates. Such gates can in turn be
employed to perform logical operations on qubits, allowing logical and
mathematical operations to be executed in parallel.
Unfortunately, the math required to design and use quantum algorithms on
quantum computers is painfully hard. The Quantum::Superpositions module
offers another approach, based on the superposition of entire scalar
values (rather than individual qubits).
DESCRIPTION
The Quantum::Superpositions module adds two new operators to Perl: `any'
and `all'.
Each of these operators takes a list of values (states) and superimposes
them into a single scalar value (a superposition), which can then be
stored in a standard scalar variable.
The `any' and `all' operators produce two distinct kinds of
superposition. The `any' operator produces a disjunctive superposition,
which may (notionally) be in any one of its states at any time,
according to the needs of the algorithm that uses it.
In contrast, the `all' operator creates a conjunctive superposition,
which is always in every one of its states simultaneously.
Superpositions are scalar values and hence can participate in arithmetic
and logical operations just like any other type of scalar. However, when
an operation is applied to a superposition, it is applied (notionally)
in parallel to each of the states in that superposition.
For example, if a superposition of states 1, 2, and 3 is multiplied by
2:
$result = any(1,2,3) * 2;
the result is a superposition of states 2, 4, and 6. If that result is
then compared with the value 4:
if ($result == 4) { print "fore!" }
then the comparison also returns a superposition: one that is both true
and false (since the equality is true for one of the states of `$result'
and false for the other two).
Of course, a value that is both true and false is of no use in an `if'
statement, so some mechanism is needed to decide which superimposed
boolean state should take precedence.
This mechanism is provided by the two types of superposition available.
A disjunctive superposition is true if any of its states is true,
whereas a
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Tue, Sep 19, 2000 at 10:11:23PM -0700, Nathan Wiger wrote: undef null $a = undef; $a = null; $b = 1; $b = 1; $c = $a + b; $c = $a + $b; $c is 1 $c is null If you want different semantics for undef then use a pragma, that is what pragmas are for. use tristate; $a = undef; $b = 1; $c = $a + b; $c is undef I did mention this to Larry and his answer was, "you can do anything you like with pragmas" However I would suggest that many, including myself, would not like to see perls values have yet another state of null Graham.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 12:00:05AM -0700, Russ Allbery wrote: Perl already has exactly the data value that you're looking for. This RFC is proposing to fix the wrong problem; the things that need to be changed (conditionally) are the logical operators, not the data value. Absolutley, although I would not limit it to just the logical operators. Graham.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote: =head1 TITLE Add null() keyword and fundamental data type =head1 MIGRATION None. New functionality. Not true. Apart from the discussion if undef is the same as null, in which I take no stance, Migration *is* an issue, cause if the null state is available, DBI/DBD users *will* expect that NULL values from the database are yielded as null values in perl and not as undef, the way it is implemented now. Same when inserting data. -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.005.03, 5.6.0, 5.7.1 516 on HP-UX 10.20 11.00, AIX 4.2 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: RFC 263 (v1) Add null() keyword and fundamental data type
1. You don't say in your RFC, but I'm guessing, that a null value evaluates to false in a boolean context. Correct? 2. In your abstract, you say that undef is used to mean that a variable's value is undefined, which I presume means uninitialized. You say that null would provide a useful way to indicate that a variable's value is known to be unknown or not applicable. Then, at various places in the RFC, you use a hypothetical use initialize 'null'; construct to initialize all new variables to null. Doesn't that defeat the purpose, and make null equivalent to undef? 3. Your RFC does not specify how a null value stringizes. What is the output from: $a = null; print "a is '$a'"; I can see two possibilities: "a is ''" and "a is 'null'". I personally would greatly prefer the first. Would the use of a null value in a string generate a warning, as an undef value does now? -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Nathan Wiger wrote: undef null $a = undef; $a = null; $b = 1; $b = 1; $c = $a + b; $c = $a + $b; $c is 1 $c is null Uh, this is a difference in the implementations of the '+' operator, not the data value undef/null. Operators that treat undef the way SQL treats null are trivial to implement. The keyword Cnull means that a value is Bknown to be unknown. Maybe in your head; not in perl (the implementation). -- John Porter We're building the house of the future together.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
Add null() keyword and fundamental data type
I think that this is better done as a special overloaded object used
by database modules which wish to implement SQL-style tri-state logic.
Given that making overloaded objects fast appears to be a major
design goal of Perl6, there should be no serious performance problems
to this.
The one thing which this requires that Perl5 does not have is the
ability to overload the defined() operation on an object. Other
than that, the following code produces a usable null object:
package Null;
use overload '""' = sub { undef },
bool = sub { undef },
'0+' = sub { undef },
nomethod = sub { bless {} };
sub null() { bless {}; }
print " 1 +1 = ", ( 1 +1), "\n"; #1 +1 = 22
print "null +1 = ", (null +1), "\n"; # null +1 =
print " 1 + null = ", ( 1 + null), "\n"; #1 + null =
print "null + null = ", (null + null), "\n"; # null + null =
print "defined(null) = ", defined(null), "\n"; # defined(null) = 1 (error)
I don't think that we would be well served by confusing the state of
truth in core Perl any further than it is now, especially when the
desired functionality does not need to be in the core.
Incidentally, I'm surprised that DBI hasn't added an option to use
an overloaded null object, if this feature is in demand.
- Damien
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Graham Barr wrote:
If you want an operator to act differently on some piece of data then a pragma
is the way to do it.
I was thinking about this on the way to work. As much as I don't like
conflating undef and null, I dislike even more the idea of the 200 pages
in Learning Perl that will have to now be devoted to why these two:
$name = undef;
$name = null;
Are not the same thing.
If everyone's in agreement, what I'll do is redraft the RFC to say Perl
6 should include a "use tristate" pragma which obeys blocks:
$a = undef;
$b = 1;
$c = $a + $b;# 1
{
use tristate;
$d = $a + $b; # undef
}
$e = $c + $d;# 1
Thoughts?
-Nate
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 10:00:56AM -0700, Damien Neil wrote: On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote: Add null() keyword and fundamental data type I think that this is better done as a special overloaded object used Incidentally, I'm surprised that DBI hasn't added an option to use an overloaded null object, if this feature is in demand. Probably because of the performance hit it would have. Graham.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Nathan Wiger wrote: Here's my concern about changing the meaning of undef. undef has a very well-defined (ha!) Perl meaning: that something is undefined. Here's something you and Glenn don't seem to understand: it doesn't *matter* what the human meaning of undef is. Call it undefined, uninitialized, unknown, etc. etc. What matters is that in the perl machine, it's a different kind of value that a scalar can have, besides string, number, reference, filehandle, etc. The special behavior of undef is implemented in code. If you want a special value (undef) to have different semantics, and thus to be treated differently, you do it in code. The concept of null does not allow you to do this, because a null value is unknown: it may be undef, or 0, or -3.2e14, or "bob", but you *don't know*. False. Null cannot, by definition, be 0, -3.2e14, or "bob", because those are not "unknown" values. Put another way, ( "bob" is null ) can NEVER be true. ...you are now changing the meaning of fundamental Perl operations. Yes; that's why it's a lexically scoped pragma. You're *still* introducing "yet another state of null", No, you're only changing the behavior of the operations. undef is still just undef. This is just as dangerous as having a pragma like so: use 'zeroistrue'; $num = 0; print "Got data" if ( ! $num ); Dangerous? Well, this is perl. Caveat programmor. -- John Porter We're building the house of the future together.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Nathan Wiger wrote: ...a "use tristate" pragma which obeys blocks bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped. -- John Porter
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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
John Porter wrote: Nathan Wiger wrote: undef null $a = undef; $a = null; $b = 1; $b = 1; $c = $a + b; $c = $a + $b; $c is 1 $c is null Uh, this is a difference in the implementations of the '+' operator, not the data value undef/null. Operators that treat undef the way SQL treats null are trivial to implement. With the multitudinous operator approach, please show me how to make each of the following conditional statements print true, without cluttering the code with interleaved additional pragmas and scoping blocks. Use of pragmas before the code might be acceptable. no strict; $a = undef; $b = null; $c = $a + $b; $d = $a + 1; $e = $b + 1; print "true" if defined $c; print "true" if defined $b; print "true" if isnull $e; print "true" if defined $d; print "true" if $d == 1; print "true" if $e != 1; print "true" if ! ($b == 0); print "true" if $a == 0; The multitudinous operator approach is not a solution. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Damian Conway wrote: Should I point out that RFC 225 (Superpositions) actually covers most of this? Cnull is equivalent in semantics to Cany() or Call(). 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
"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
"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
Russ Allbery wrote: Glenn Linderman [EMAIL PROTECTED] writes: Russ Allbery wrote: I agree with Tom; I think it's pretty self-evident that they're the same thing. undef means exactly the same thing as null; that's not the problem. The problem is that Perl doesn't implement the tri-state logic semantics that most users of null are used to, which is a different issue. So, to paraphrase your statement a bit: It is self-evident that they're the same, the problem is that they work differently. No, that's not a paraphrase. That's saying something completely different which is wrong. I still find it a paraphrase... discussion below. If undef functioned differently than null, that would be a bug. False statement. undef has the following semantics: 1) all otherwise uninitialized variables are set to undef 2) under "use strict", use of undef in expressions is diagnosed with a warning 3) undef is coerced to 0 in numeric expressions, false in boolean expressions, and the empty string in string expressions. The semantics for NULL is different, read the SQL standard. The _definitions_ of undef and NULL are different; if they functioned the same, that would be a bug. What's missing is a way to say "I want tri-state logic" as a pragma. When that pragma is enabled, undef would be the null-like state. This could be done, but then you could only use either the concept of undef (as defined by perl and recapped above), or the semantics of NULL, but not both. Another person has suggested privately that rather than a pragma, that different operators could be provided for all operations, which apply the NULL functional semantics to their arguments. This could also be done, but would require the programmer to choose the desired semantics for every operation, by choosing the appropriate operator. It would also double the number of operators in the language. Not nice. Perl already has exactly the data value that you're looking for. This RFC is proposing to fix the wrong problem; the things that need to be changed (conditionally) are the logical operators, not the data value. Nope, the data value Perl has has different operational semantics that the data value this RFC is suggesting. Nota Bene: IEEE floating point defines two different concepts that are not numbers, but can be mixed with numbers in expressions: Inf and NaN. And actually, there are positive and negative varieties of both Inf and NaN. So I guess you might say that they are the same; but the problem is that they work differently. There are positive and negative infinities, but that's a different situation entirely; infinity is a degenerate value, not an undefined value. This is the first time I've ever heard of -NaN; are you sure about that? (There are, in fact, different types of NaN, such as signalling vs. non-signalling, but that's due to floating point traps and exceptions, issues that don't crop up in the situations where you want undef/null.) Sorry, the intended point was that IEEE float has (1) multiple types of distinguished, non-numeric values with different semantics and (2) for each type of distinguished, non-numeric value it has, multiple values of that type exist. However, there are legal forms of NaN with the sign bit set, and legal forms of NaN with the sign bit reset. They are not called positive and negative, however, that was an oversimplification. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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 NULL semantics, feel free. But there's no need for you
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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
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
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
no strict; $a = undef; $b = null; Perl already has a null string: "". --tom
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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 ([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
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
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
$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
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 ([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
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 belg4mit at MIT dot EDU
Re: RFC 263 (v1) Add null() keyword and fundamental data type
* 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
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
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
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
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
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 Cdefined $name 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 Cdefined $name. 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]) http://www.eyrie.org/~eagle/
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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]) http://www.eyrie.org/~eagle/
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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
For example, assuming this code: $name = undef; print "Hello world!" if ($name eq undef); So don't do that. Use Cdefined $name 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 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
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 whicSNIP
interpreted as boolean false, then I think I understand what you said. SNIP
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 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 Cuse invocant. (Had to get that plug in there) ;-) -Nate
Re: RFC 263 (v1) Add null() keyword and fundamental data type
* 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.http://eh.org/~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
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 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 01:21:52PM -0700, Russ Allbery wrote:
No offense to Damian, but I tried to read and understand his documentation
and I thought I was back in grad school. I don't think it's the fault of
the writing either; I think that Quantum::Superpositions is trying to do
something that's rather too complicated to explain clearly to the average
programmer.
It's a neat idea, but I don't expect to see it ever widely used.
I disagree. I think that, ignoring the documentation, the operations
performed by Quantum::Superpositions are intuitive and elegant.
print "$a is between 1 and 10" if ($a == any(1 .. 10));
The above is simple and clear. The any() and all() operations are,
perhaps, surprising to experienced programmers (we aren't used to
languages that provide them), but will be instantly understood by
most novices.
If I could be assured that the performance penalty was minimal, I'd
be delighted to write
if ($errno == any(EAGAIN EINTR)) { ... }
over
if ($errno == EAGAIN || $errno == EINTR) { ... }
The former is less typing and reads more clearly (to me, at least).
I am of two minds about the documentation. On one hand, it's
highly theoretical bent will be intimidating to many. On the other
hand, I found that it clearly described what was going on, and
nicely explained the complexities underlying the simple interface.
I do wonder whether there isn't a better name for eigenstate().
- Damien
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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
$a = null; $b = ($a == 42); print defined($b)? "defined" : "not defined"; would print "not defined", maybe? defined() is the wrong operator to be using there. Rather, $a = null; $b = ($a == 42); print is_null($b)? "is null" : "is not null"; In general, what would these result to: defined(null) is_null(undef) -- John Porter
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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
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]) http://www.eyrie.org/~eagle/
Re: RFC 263 (v1) Add null() keyword and fundamental data type
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 263 (v1) Add null() keyword and fundamental data type
But I see code in the XML modules that check defined (@array) They're buggy and wrong. --tom
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Should I point out that RFC 225 (Superpositions) actually covers most of this? Cnull is equivalent in semantics to Cany() or Call(). Except, of course, the superpositional versions work...In Constant Time! ;-) Damian
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Tom Christiansen wrote:
Currently, Perl has the concept of Cundef, which means that a value is
not defined. One thing it lacks, however, is the concept of Cnull,
which means that a value is known to be unknown or not applicable. These
are two separate concepts.
No, they aren't.
Uhhh, yes, they are...
undef null
$a = undef; $a = null;
$b = 1; $b = 1;
$c = $a + b; $c = $a + $b;
$c is 1 $c is null
The keyword Cnull means that a value is Bknown to be unknown. This
means a couple important things, with semantics far different from
Cundef:
1. Any math or string operation between a null and
non-null value results in null
2. No null value is equal to any other null, unlike
undef
3. A null value is neither defined nor undefined
To recap: There is no 1:1 mapping between Cundef and null. Any
attempt to do so is inaccurate. For more details, please read the
references.
...
=head1 REFERENCES
http://www.sitelite.nl/mysql/manual_Problems.html#IDX666
http://www.unb.ca/web/transpo/mynet/mtx19.htm#r2
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On 20 Sep 2000, Perl6 RFC Librarian wrote: The absence of a Cnull concept and keyword in Perl makes it more difficult to interface with relational databases and other medium which utilize Cnull. Modules such as CDBI must map Cnull to Cundef, which is an imperfect match. Does it really make it more difficult? I would argue that having NULLs mapped to undefs is actually better than having real NULLs in Perl. An undef is a rather concrete and easily dealt with value - simply test with defined(). Plus, if you're careless enough to try to use it you'll get warnings in strict mode. That, to me, is basically exactly what I want from a NULL. What I don't want is what SQL provides - a total oddball of a value. It doesn't even equal itself. It spreads like a plague through operations with *no warnings*. It's hands-down the hardest thing about SQL to learn to use correctly both because of its inherent nonsensicality and the fact that different RDBMs handle it differently. You want to add this misfeature to Perl? No thanks. I agree that undef and NULL have different semantics. However, this is clearly SQL's fault and not Perl's. We shouldn't repeat their mistake just because we occasionally have to interface with their system. Perhaps you could show an example using DBI where having NULLs mapped to undef is actually a problem? Do you ever want to just blithely use a NULL in an expression and not get a warning out of it? Is this really about skipping error checking code on the results of SELECTs? -sam
Re: RFC 263 (v1) Add null() keyword and fundamental data type
At 10:11 PM 9/19/00 -0700, Nathan Wiger wrote: Tom Christiansen wrote: Currently, Perl has the concept of Cundef, which means that a value is not defined. One thing it lacks, however, is the concept of Cnull, which means that a value is known to be unknown or not applicable. These are two separate concepts. No, they aren't. Uhhh, yes, they are... [snip] The keyword Cnull means that a value is Bknown to be unknown. This means a couple important things, with semantics far different from Cundef: 1. Any math or string operation between a null and non-null value results in null 2. No null value is equal to any other null, unlike undef 3. A null value is neither defined nor undefined I repeat, why do you want to do this in Perl? It makes perfect sense for these rules to apply in SQL, but that is a far different language from Perl. SQL is an implementation of the relational calculus, Perl is an imperative language. The propagation of NULLs in query expressions is necessary to give meaningful query semantics; what does this have to do with how expressions are used in Perl? To recap: There is no 1:1 mapping between Cundef and null. Any attempt to do so is inaccurate. For more details, please read the references. =head1 REFERENCES http://www.sitelite.nl/mysql/manual_Problems.html#IDX666 http://www.unb.ca/web/transpo/mynet/mtx19.htm#r2 These references talk only about the meaning of NULL in a relational database. I cannot see how they support your position at all. They say nothing about why such an entity would be of any use in any other language. SQL weirdness of the week: I just had a program that formed a "WHERE foo IN (LIST)" clause fail because the LIST was empty. You'd think that it would do the sensible thing and return a null set (there's that wretched word again), but no, it's an error. Even more bizarre, I cured it by setting the clause to "WHERE foo IN (NULL)". You'd think that would be the same as "WHERE foo IS NULL", but n, we're talking about SQL here. (At least the Oracle brand of it.) Let's not venture one inch down that path. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Currently, Perl has the concept of Cundef, which means that a value is not defined. One thing it lacks, however, is the concept of Cnull, which means that a value is known to be unknown or not applicable. These are two separate concepts. No, they aren't. --tom
