Hacker News new | comments | show | ask | jobs | submit login
Literals in Programming Languages (gavilan.edu)
38 points by RohitS5 on Feb 28, 2013 | hide | past | web | favorite | 22 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...


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: