That's what I thought, but it appears truth values are typically defined with a partial ordering a <= b iff a && b == a, which gives false <= false < true <= true.
You could choose to ignore that partial ordering at your own peril.
This article is only about primitive literals, not compound ones. I think the list and dict literals in Python are the #1 reason I like it better than C. I think the regexp literals in Perl were one of the main reasons people liked Perl better than C.
That line blurs when you have homoiconic syntax, specially one with a programmable reader. Common Lisp uses the # for dispatch macro character, you can define your own literals, in whatever environment you want.
Isn't it strange to compare Python/Perl to C and say that one is better than the other? It's apples to oranges. You wouldn't use Python or Perl to build an OS, and you wouldn't use C to prototype a web app.
Sure, but I said "like", not "better". When I learned Python, I had that feeling described as weightlessness by xkcd [http://xkcd.com/353/], because I didn't have to write several lines and a loop to make a list. It made me happy. Fair comparisons don't really come into it.
Even in C it's not a literal. The consequence is that in a 32-bit implementation, you can't write INT_MIN as -2147483648 (-2^31), because 2147483648 would overflow a signed int. Instead a workaround such as -2147483647-1 must be used.
Making the minus part of the literal can lead to parsing ambiguity. For example, "x-3" would parse as 2 tokens "x" and "-3" (instead of 3 tokens "x", "-" and "3") which would be a syntax error in C. The only workaround I can think of is making any expression followed by a negative number parse as a subtraction.
> Making the minus part of the literal can lead to parsing ambiguity.
Not really. It's done in java. Usually, minus ("-") is parsed as a token and then unary minus on integer literals are transformed to a negative integer literal.
So, -2147483648 is read as MINUS INT_LITERAL and thus transformed into "-2147483648" as an INT_LITERAL, but -(2147483648) should be read as MINUS L_PAREN INT_LITERAL R_PAREN and should thus not be transformed.
22 comments
[ 0.15 ms ] story [ 58.9 ms ] threadI was surprised to find this is true,
http://plato.stanford.edu/entries/truth-values/#3
You could choose to ignore that partial ordering at your own peril.
http://www.franz.com/support/documentation/6.2/ansicl/subsec...
Isn't it strange to compare Python/Perl to C and say that one is better than the other? It's apples to oranges. You wouldn't use Python or Perl to build an OS, and you wouldn't use C to prototype a web app.
It mentions array literals: http://www.gavilan.edu/csis/languages/literals.html#_Toc7587...
(In Haskell, it's just sugar for negate 14, while in Standard ML it's spelt ~14. And I assume there are other exceptions too.)
Not really. It's done in java. Usually, minus ("-") is parsed as a token and then unary minus on integer literals are transformed to a negative integer literal.
So, -2147483648 is read as MINUS INT_LITERAL and thus transformed into "-2147483648" as an INT_LITERAL, but -(2147483648) should be read as MINUS L_PAREN INT_LITERAL R_PAREN and should thus not be transformed.
(they might as well have been added by a user library).