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

Can't you set any dispatch character you like using make-dispatch-macro-character ?

Oh yes, you can set your own dispatch characters, but the # is the dispatch character for the CL standard syntax.

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

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

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

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.

In Visual Basic, False is 0 and True is -1.

-1 == 1 (mod 2) [But yes, this is Yet Another Reason vb can be irritating to the seasoned programmer.]

(I always found VB's definition more obvious, given that -1 == ~0.)

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

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

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.

Huh. I always assumed it was in C. Shows what I know… :p