Literals in Programming Languages(gavilan.edu)
gavilan.edu
Literals in Programming Languages
http://www.gavilan.edu/csis/languages/literals.html
4 comments
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.
http://www.franz.com/support/documentation/6.2/ansicl/subsec...
http://www.franz.com/support/documentation/6.2/ansicl/subsec...
C99 has array and struct literals:
(int []) { 1, 2, 3 }
(struct Point) { 3, 5 }
(struct Point) { .x = 3, .y = 5 }> This article is only about primitive literals, not compound ones.
It mentions array literals: http://www.gavilan.edu/csis/languages/literals.html#_Toc7587...
It mentions array literals: http://www.gavilan.edu/csis/languages/literals.html#_Toc7587...
> I like [Python] better than C
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.
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.
> Booleans are ordinal values and usually false is less than true.
I was surprised to find this is true,
http://plato.stanford.edu/entries/truth-values/#3
I was surprised to find this is true,
http://plato.stanford.edu/entries/truth-values/#3
So in fact you believed it was false before true then ;-)
well i believed that they are not ordered. (which they are not in some languages)
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.
You could choose to ignore that partial ordering at your own peril.
In Python, bool is a subclass of int. The constants True and False have the values 1 and 0 respectively, and it's legal to do arithmetic with them :)
Factor has them for many data-structures: http://docs.factorcode.org/content/article-syntax-literals.h..., but they are simple to add in a concatenative language
(they might as well have been added by a user library).
(they might as well have been added by a user library).
To nitpick, -14 isn't a literal in all languages. :)
(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.)
(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.)
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.
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.
Huh. I always assumed it was in C. Shows what I know… :p