Talk:Boolean data type

Tableau??

Why is Tableau listed as if it were a programming language? It's a (rather expensive) reporting software package, and while it has a typical eval-based syntax for transforming data from outside data sources, it's not notable as a programming language, certainly no moreso than any of its competitors. Is the goal to list every piece of software that internally has a Boolean type of some sort?

Logic and bits

not (FALSE) 00000000 is (TRUE) 11111111 or -1. Some versions of basic and pascal, treat -1 specifically as being TRUE. Just a thought. Duser404 (talk) 08:20, 4 November 2011 (UTC)

Java Boolean class

In Java there is also a Boolean class, to which one can cast.

Church Booleans

This page should mention something about Church Booleans. Wouter Lievens 11:26, 7 May 2005 (UTC)

Revert over Brainfuck

The last edit was changing the "Brainfuck" references to "Brainf**k" which shouldn't be a change. That is the name of the language so it shouldn't be censored. Also, the anon IP didn't even correctly change the links to which "fuck" is a part of. So I changed it back to what it should be. Chris M. 07:34, 10 January 2006 (UTC)

Heres to that, Wikipedia does not censor. Good job--Oxinabox1 08:36, 22 June 2007 (UTC)

???????????????????? (What are you on about?) LOTRrules (talk) 13:49, 17 February 2008 (UTC)

Brainfuck. 58.145.148.89 (talk) 10:49, 16 August 2010 (UTC)

Ruby

I don't get the part about Ruby. First the text says Ruby doesn't have a boolean data type, but then it says it has literals true and false. What (dynamic) type are these, then? Strings? Numbers? If they're objects, what class are they? I bet it's "Boolean"... Wouter Lievens 12:30, 11 February 2006 (UTC)

Ruby's true and false literals are objects coming from 2 different classes. This is what can be seen at the console by asking the objects themselves: >> true.class => TrueClass >> false.class => FalseClass Pepe (talk) 02:10, 20 November 2010 (UTC)

Consistent example

The examples should all to the same thing. Rather than Python going on about SPAM and EGGs, and VB talking about the end of the world or what ever.--Oxinabox1 08:39, 22 June 2007 (UTC)

The languages don't have consistent handling of boolean values. One example for all would be inappropriate. You should allow scope for each language to show some of its usual ways of using booleans. --Paddy 17:11, 22 June 2007 (UTC)

This point should be moot now that the examples have been moved to the respective language Talk pages. --Jorge Stolfi (talk) 00:37, 31 December 2009 (UTC)

Citation tags and OR

I removed all of the citation tags. The adder of these tags states that "assertions about programming languages need references". This is not inline with policy. Policy's test is material that is challenged or likely to be challenged. Thinking that Ada having True and False as "challengable" is very unlikely. The author isn't challenging them to begin with, just that an assert requires a reference (which is not true in terms of policy).

As far as code being considered original research, again, is not inline with policy. Providing simple source code about true/false comparisons is in no way, shape, or form near something like saying vitamin B12 causes AIDS. Code for an established language that demonstrates the syntax and/or semantics of said language, by definition, cannot be original research. Such functionality is inherit to the language. It's like saying that a sample sentence highlighting nouns is original research. Cburnett 01:07, 23 July 2007 (UTC)

This point should be moot now that the examples have been moved to the respective language Talk pages. --Jorge Stolfi (talk) 00:38, 31 December 2009 (UTC)

Too Much Sample Code

Just wondering, but are all the code samples really necessary in the article? I think there are probably far too many programming languages out there to represent every single one of them like this. I think the article might read better if it were divided up along the lines of the different models for handling Boolean values, with a single code example for each. Some divisions that come to mind: "Pascal-style" BOOLEAN values that represent True and False; "SQL-style" truth values that can evaluate to True, False, or Unknown; "C-style" 1/0 numeric representation; "XQuery-style" effective Boolean values; etc. Basically I'm proposing rewriting the article to classify the different Boolean data type systems based on their representation of truth values. Right now the article reads as a big list of partial code samples, which I don't think really serves the purpose of explaining Boolean data types. Code samples should supplement the text of the article, not completely replace it. SqlPac (talk) 14:50, 25 March 2008 (UTC)

You would need enough categories to represent all the current languages andcategories should represent more than one language. You could have an 'others' category with separate entries for all otherwise un-categorised languages, but you would need to keep this small. --Paddy (talk) 18:09, 25 March 2008 (UTC)

There are several ways of representing Boolean values in computer languages, but many languages borrow their implementation strategies from other languages. By reading this article I see no grouping or classification of different Boolean data types in any way. That seems odd considering how closely many of the Boolean data type implementations are to one another. This article could perhaps be more accurately named "Boolean datatype implementation syntax", as that's what it seems to focus on. SqlPac (talk) 19:04, 29 March 2008 (UTC)

Except this article is specifically about the datatype so I think the code that is here is entirely warranted. If this article were about booleans or boolean algebra then I would be more inclined to agree with you.

However, I think a more summarizing section is warranted.

IMO, as a professional programmer, the code speaks more and louder than the accompanying words. Write all the words you want but the actual code speaks the truth about how that language ultimately handles it. Cburnett (talk) 00:10, 26 March 2008 (UTC)

IMHO, as a professional programmer, this is a programming "cookbook" article, not an encyclopedic article. Many of the partial code samples will not run without modification, and not all languages mentioned show actual code samples (inconsistency?) At least one of the code samples specifically states that it will not run(!)

So the question, I think, is who is this article written for? Is it a code list about programming, by programmers, for programmers? Or is the objective to explain what a Boolean data type is to a broader audience of people who are not professional programmers?

This article appears to be nothing more than a quick reference for people with CS degrees who need a non-comprehensive comparative analysis of Boolean data type syntax in a randomly selected subset of 21 computer languages. If that is the purpose of this article then the cookbook format and randomly selected limited content is wonderful (although it could be improved by applying some level of consistency.) However, if the article is supposed to explain what the Boolean data type is to non-programmers, then it should be explained in such a way that non-programmers can understand. Unfortunately that would require possibly replacing a bunch of code snippets with actual text, since the assumption cannot be made that non-programmers necessarily know the syntax and semantics of ALGOL-60 when they visit the page. (I could be wrong - maybe a lot more non-programmers know ALGOL-60 than I am aware of.)

BTW, I notice that the following code snippets are not yet included in the article: 6502/6510 Assembler language, Z-80 Assembler Language, x86 Assembler Language, 68000-series Assembler Language, VB.NET, COBOL, Haskell, CLI, Visual J++, SNOBOL, RealBASIC, QuickBASIC, PL/1, PILOT, Modula, Clipper, Mathematica, F#, Eiffel, dBase, Cold Fusion, C--, Ch, SmallTalk, Visual FoxPro, X10, ... . I'll start adding these to bring the article closer to completion, but someone else will need to address the others here: List of programming languages. I notice that the Wikipedia list of programming languages is not complete either, so we're going to have to get together a list of languages that aren't listed on Wikipedia. SqlPac (talk) 19:04, 29 March 2008 (UTC)

Can the article be improved? Absolutely. Should the code be removed? Absolutely not. My interpretation of your original post is more of the latter: discuss true and false as generally used and that's it. I think every language should be discussed so don't fall into the trap that so many people do that the current state of an article indicates some sort of consensus that it's "done", so while there are 21 languages here it doesn't mean there's some conspiracy to exclude all the others.

There are already dicussions of "true" and "false" on Wikipedia Boolean algebra (logic), so it would be pointless to write another article rehashing it again. I don't believe the "list of code snippets" is done, as there are 100's of languages that have been left out. As I said, this article currently consists of a "programming cookbook" style of inconsistent code snippets that reflect an apparently randomly selected tiny sampling of possible programming languages.

This article is written for "everyone". Like every other article it should be descriptive for the laymen but also informative to the computer scientist because, by definition, this is a technical article. I think a summary section is entirely warranted to discuss the generalities because while true/false is generally the same in the various language they do treat booleans quite differently. For example, C will convert integers to true/false implicitly but C# will refuse to implicitly cast it, and all the while PHP will implicitly convert various strings as true/false.

This article is not written for "everyone". It's written in a form that would be useful to, as was pointed out, "professional programmers" who need a quick comparative analysis of syntax for a completely random, and tiny, selection of languages. How many non-programmers really need that?

BTW, your comparison of C (which does not have a Boolean data type) with C# (which does have a Boolean data type) is a comparison of two different systems of representing Boolean values. The Boolean data type in VB 6, QuickBASIC, GW-BASIC, etc., is closely aligned with the C implementation which uses numbers to represent true/false; while the C# implementation is more closely aligned to C++ and Java implementations in that they support native Boolean data types that hold true/false values. When you compare apples with apples you start seeing the similarities. Why separate code samples for every single language in existence, especially when many languages share similar implementations? Is the sentence "____ does not allow implicit casting of boolean data type to ____" really justification to dedicate a whole section to a specific language?

How about the PL/I type BIT(1) which can have only two values, but they are '1'B and '0'B instead of TRUE and FALSE? Does that count as a boolean data type? Gah4 (talk) 21:24, 27 September 2011 (UTC)

I think the C section covers its boolean datatype fairly well and shows various ways you can achieve a boolean type without actually having one. The section on ML, however, is too much code because it doesn't have much commentary but I see this as a reason to add prose not remove code. I see it as "too little prose" rather than "too much code". Cburnett (talk) 23:52, 29 March 2008 (UTC)

I see it as far too much code. In .NET framework languages, for instance, the Boolean data type works the same across the board. Do you really need separate code samples for C#, VB.NET, C++.NET (CLI), Delphi.NET, and every other CLI language? Do you really need to clog up an article with code samples for every single language in existence, when many languages handle Boolean data types in similar fashion to one another? This is going to be a very, very, very long article by the time you include code snippets for every language in existence; even if the code snippets are partials that won't run anyway, full of "...". It makes more sense to me to describe the common implementations of languages and classify the hundreds of available languages according to their logic system implementations for purposes of this article. Personally I would find that a lot more useful than an article with hundreds of partial code samples that won't run without modification anyway.

I suggest recommending the article for peer review to get others' feedback on it. Let others, particularly non-CS-degree holding people decide if adding code samples for every language in existence is the best way to go with this article. As I said, I will be happy to add a dozen or so code samples myself to help bring the article a small step closer to conclusion, but there are still hundreds of languages that need to be addressed. Is 200+ code samples too much for one article about the Boolean data type? Will it be useful to the person without a CS degree? Is the person visiting this page really coming here for a comparative analysis and survey of syntax of Boolean data type implementations in every programming language in the world? SqlPac (talk) 00:54, 30 March 2008 (UTC)

Yes, there are far too many code samples. Almost all of them are unreferenced, too. It's some sort of original research programming contest! -- Mikeblas (talk) 01:11, 30 March 2008 (UTC)

BTW I'm not at all against code samples, I just don't see the point of superfluous, inconsistent, and non-working code samples. SqlPac (talk) 01:14, 30 March 2008 (UTC)

This section should be moot now that the examples have been moved to the respective language Talk pages. --Jorge Stolfi (talk) 00:38, 31 December 2009 (UTC)

Wordgroup for boolean prefix

Usually they name boolean variables something like "isEnabled", "hasItem", "canHandle", "shouldDelete" etc. What is the wordgroup called for the words "is", "has", "can", "should" etc.? The closest I found was Copula, but I doesn't seem to fit every case. -- 88.117.79.142 (talk) 21:48, 28 July 2008 (UTC)

Who are they? It's a common convention, but it's not universal, and it's probably absent in some cultures. Personally (I have a C++ background) I prefer "enabled" to "isEnabled", "!empty" to "hasItem" and, well, the others do not make sense out of context. JöG (talk) 21:57, 9 June 2009 (UTC)

Enum example - can this work?

typedef enum { FALSE, TRUE } boolean; ... boolean b; The following typical preprocessor macros are also often used. #define FALSE 0 #define TRUE 1

Well, the article says *ALSO* often used. However, the enum example won't work before FALSE and TRUE are #defined. Hence this is not optional, but mandatory! [edit] On gcc, you need: typedef enum { false, true } boolean; Note that CAPITALIZING the "false" and "true" will result in errors! (just checked!) -andy 92.230.16.89 (talk) 21:43, 5 November 2008 (UTC)

The only way that should cause an error is if FALSE and TRUE were #defined or declared before the enum declaration. For example, some #included header might do that. — DAGwyn 158.12.36.83 (talk) 23:26, 20 June 2011 (UTC)

Pascal has almost exactly that. boolean is, eseentially typedef {false, true} bool. Pascal is better in the sense that it is undefined behaviour to try assinging any other value.

19:40, 24 February 2009 (UTC) —Preceding unsigned comment added by SimonTrew (talk • contribs)

What about _Bool in C99?

There is also a built-in (in contrast to the bool in <stdbool.h>) boolean type called _Bool. Anyone who knows more about this? Rndusr (talk) 08:35, 6 February 2009 (UTC)

Actually, the bool in <stdbool.h> is a #define for _Bool. Not much more to say about it really, but I added the info to the C99 chapter. decltype 09:43, 6 February 2009 (UTC)

Bool is a proper first-class datatype now (though implicitly converted to int). I don't have the refs with me, they are at work

SimonTrew (talk) 19:38, 24 February 2009 (UTC)

_Bool (not Bool) is a standard (unsigned) integer type in C99, distinct from other types, specified to have a width of at least 1 bit. It is intended to be used only via bool from <stdbool.h>. Conversion to and from type _Bool involve the value of the lowest bit in the representation of _Bool, e.g. converting from type long produces 1 if the operand was nonzero and 0 if the operand was zero. Relational expressions still have type int. — DAGwyn 158.12.36.83 (talk) 23:34, 20 June 2011 (UTC)

Caps

This is probably an old chestnut but should it be Boolean or boolean? I don't mind either but it is inconsistent through the article.

SimonTrew (talk) 19:37, 24 February 2009 (UTC)

The abstract data type (not specific to any programming language) should be "a Boolean data type" since that is merely the English word. The name of the data type in specific languages may be Boolean, boolean, BOOLEAN, bool, _Bool, LOGICAL, bool_t, ... and case may or may not matter. All the best,--Jorge Stolfi (talk) 00:44, 31 December 2009 (UTC)

fact tag in C regarding FALSE and TRUE

It is true that the boolean operators ==, !=, >=, <= all return either 1 or 0. But the macros (or enum values) TRUE and FALSE are entirely implementation-dependent, and need not be defined at all. Assuming that the rules for language extensions are similar to those of C++, a program such as

int main(void)
{
  return (1 == TRUE);    
}

should not compile without a diagnostic message, because TRUE is undefined, or defined as a compiler extension. Either way, the return value of the resulting program is not mandated by the standard. decltype (talk) 02:18, 19 April 2009 (UTC)

The relevant part in the text seems to talk about user-defined (not implementation-defined) constants "TRUE" and "FALSE", for example, those defined by "enum { FALSE, TRUE }" or a "#define TRUE 1". In both cases, TRUE will be equal to 1 and, e.g., "(a != b) == TRUE" should work as expected; there is nothing implementation-defined here. I can see the point the text is trying to make, but as it stands, I find it misleading. — Miym (talk) 09:39, 19 April 2009 (UTC)

Good point. I have tried to tweak the text a little. I would provide a cite that comparing against TRUE/FALSE is discouraged in C, but I couldn't find one. decltype (talk) 15:32, 19 April 2009 (UTC)

Do you really need a citation for that? When (in a world where TRUE is defined or enum:ed to 1) you write if(foo()==TRUE) you are introducing the idea that all values except 1 (0, 2, 3, ...) are false. And then you are in conflict with the language, and quite likely with the guy who wrote foo(). One good source is the C FAQ [1] section 9.2. JöG (talk) 20:38, 9 June 2009 (UTC)

Boolean types in Algol 68

There used to be an "Algol 68" section with the following contents:

An actual extract from the ALGOL 68 language specification (page 177) where the Boolean operators are defined:

10.2.2. Operations on Boolean Operands

• op ∨ = (bool a, b) bool:( a | true | b );
• op ∧ = (bool a, b) bool: ( a | b | false );
• op ¬ = (bool a) bool: ( a | false | true );
• op = = (bool a, b) bool:( a∧b ) ∨ ( ¬b∧¬a );
• op ≠ = (bool a, b) bool: ¬(a=b);
• op abs = (bool a)int: ( a | 1 | 0 );

Methinks that the above quote from the Algol 68 manual is too cryptic and of little value to the reader; so I have reduced that section to a short mention that Algol 68 had a bool data type pretty much like Algol 60's Boolean. OK? --Jorge Stolfi (talk) 01:13, 21 June 2009 (UTC)

Restructuring proposal: Move examples to the language articles

Would anyone have objections to me changing the article into a Programming Language heading and a Mathematical Theory heading? It seems sort of wrong having lambda calculus sitting next to more practical languages, but on the other hand lambda calculus represents an abstracted PL. --Sam Pointon 18:53, 16 December 2005 (UTC)

Alternatively, instead of listing every single language that has a boolean type, a listing of the general systems of boolean representation in use, eg:

No special boolean datatypes, single false value: C89, Lisp etc.

No special boolean datatypes, multiple false values: Python (multiple categories), Perl, etc.

Boolean datatypes, but which only represent 0 and 1: Python (multiple categories), C99, C++, etc.

Specialised boolean datatypes, unuseable for other purposes: Java, Smalltalk (I think), etc.

--Sam Pointon 19:10, 16 December 2005 (UTC)

Hear,hear! Indeed all the good arguments in the section Too Much Sample Code now seem to be moot. The goal of giving a minimally accurate description of the Boolean data types and operations for every important language is neither viable nor desirable. Those sections should be all removed from this article and merged into the respective language articles, leaving here only a very succint survey (as in Sam Pointon's suggestion above). At most, there may be a table with one language per line, listing only the most notable feature of its Boolean types (ditto). --Jorge Stolfi (talk) 01:33, 21 June 2009 (UTC)

I have added a merge-to tag to the examples section. If no one objects, I will try to moev each example to the corresponding language article. [unsigned comment by Jorge Stolfi

Since there were no objections, I started to move the section as announced above. The subsections have all been copied verbatim to the Talk: pages of the corresponding languages (Talk:C99, Talk:Ruby , Talk:C Sharp, Talk:Lua, etc.) I suppose that the "curators" of those pages will better know what to do with that material. (Some languages have extensive syntax pages, other have wikibooks, etc.)
Sorry for the inconvenience and for removing so much hard-worked material, but that section, although still incomplete and uneven, was already far too big for one article. Besides, almost all of the code exmples were largely lost on readers who did not know the corresponding languages. All the best, --Jorge Stolfi (talk) 00:32, 31 December 2009 (UTC)

Removed LISP example

This example was removed from the History section:

For example,

(cond
  ((eq x y) (func1 ...))
  (x (func2 ...))
  (t (func3 ...)))

could be written in C-like syntax

if (x == y) { func1 ...; }
else if (x != nil) { func2 ...; }
else { func3 ...; }

It is here in case it may be useful somewhere, someday. --Jorge Stolfi (talk) 22:37, 21 June 2009 (UTC)

C section still misleading

The section on C is, again, misleading. It is true that "if" statements and boolean operators such as &&, ||, etc., interpret zero as false and non-zero as true. However, operators such as >, ==, !=, etc., return only values 0 (for false) or 1 (for true). That's how it is both in C90 and in C99. — Miym (talk) 19:41, 28 June 2009 (UTC)

Please check whether the description which remained in the "History" section is nnow accurate. All the best, --Jorge Stolfi (talk) 05:57, 31 December 2009 (UTC)

Thanks for the edits, overall the article looks much better than it used to be! Regarding this detail, I think it's still slightly inaccurate. I'm not sure how to rephrase it better, but the basic idea should be this:

• Comparison operators ('>', '==', etc.) and logical operators ('&&', '||', '!', etc.) return a signed integer (int) result, either 0 (for false) or 1 (for true).
• Logical operators ('&&', '||', '!', etc.) and condition-testing statements ('if', 'while', etc.) interpret a scalar value that is equal to 0 as false and everything else as true.
• In C99, the _Bool type is not a synonym of int. It is a special type that can only store values 0 and 1 (for example, after "int x = 2; _Bool y = x;" the value of y will be 1, not 2). However, what I said above still holds in C99, too: comparison operators return ints (not _Bools) and condition-testing statements accept any scalar values (including ints, floats, _Bools, etc.).

— Miym (talk) 11:27, 31 December 2009 (UTC)

Classification of Lua

I am not sure about how Lua fits in the taxonomy given in the "History" section, so I left it out for now. Here is part of what the article said about it:

Lua as of version 5.0. defines a boolean type which can be either true or false. The special value nil (of type nil) also evaluates to false in logical expressions. The logical operators and and or return one of their arguments as the result instead of the value true or false.

Help will be appreciated. --Jorge Stolfi (talk) 05:56, 31 December 2009 (UTC)

References

Perl and AWK

There are a couple issues with this part:

C++ has a separate Boolean data type ('bool'), but with automatic conversions from scalar and pointer values that are very similar to those of C. This approach was adopted also by many later languages, especially by some scripting ones such as AWK and Perl.

1. The first sentence seems to imply that AWK and Perl have a separate Boolean data type, whereas they do not.
2. While C++ predates Perl, it postdates AWK.

I suggest simply dropping the second sentence. — Preceding unsigned comment added by Nathanweeks (talk • contribs) 02:20, 12 September 2012 (UTC)

Removal of Next Generation Shell

@Mr248: A recent edit removed Next Generation Shell due to lack of sources and proof of notability. Should it have been replaced by a section on PowerShell?

References