4 ms·
Can anyone help me understand the usage of these literals (2.1.1, 2.1.2)? Why and for what are they useful?
by darklajid 15y ago
Can anyone help me understand the usage of these literals (2.1.1, 2.1.2)? Why and for what are they useful?
- spacemanaki 15y agoI'm not sure if you're asking about the use of those specific literals or about the extensible reader, but there was a short interview with Rich Hickey about the new extensible reader and there was valuable discussion on HN about it: http://news.ycombinator.com/item?id=3831803 http://news.ycombinator.com/item?id=3831803
- darklajid 15y agoThanks, but no. I was explicitly referring to the instant literals and uuid literals. I honestly never missed something like that. They seemed esoteric, kind of. So I'm hoping for someone more knowledgeable than me chiming in and explaining possible drivers/motivations for these literals. When do you write a literal uuid?
- zephjc 15y agoI think it was a case of a couple useful examples of the new literals as a pattern for developers.
- djpowell 15y agoThey are likely to be more useful when using Clojure as a serialisation syntax for data (much like how JSON is used with JavaScript), rather than when used directly in source code. I assume that these extensible literals will be ported to the JavaScript and .NET implementations of Clojure, making it easier to work with rich data types without having to pepper your code with calls to date parsing functions, etc. Having an intuitive, idiomatic concept of 'data' at the heart of your code is an important aspect of Clojure. In comparison, I find it hard to the answer the question, "How is data represented in Java?" Which is why I find doing things like data transformation to be far easier in Clojure than in Java.
- technomancy 15y agoInstant literals returning java.util.Date instances are a great way to sneak bugs into a codebase that uses immutable values everywhere else.
- tensor 15y agoThe mutable methods of the Date class all look to be deprecated. No?
- technomancy 15y agoThat doesn't stop them from being called. As soon as you introduce an object like this, you throw a bunch of important guarantees about your code out the window.
- moomin 15y agoTrue. At least in Clojure you can change the default behaviour.
- deleted 15y ago[deleted]
- moomin 15y agoI think you'll find they're extremely useful for implementing Datomic.
- matthavener 15y agoThey're just adding more default literals to the language. Clojure already has strings "like this", characters \l \i \k \e \t \h \i \s, numbers 1234, regex #".*". Now you can have dates, times, or presumably some other literal that's applicable to your domain.
- swannodette 15y agoThink JSON.Next. So you get a lightweight interchange format but you regain the extensibility of XML.
- chc 15y agoWhat I want to know is, what's the benefit of representing your domain-specific datatypes with a literal like #htmlelement [:div {:id "foo"}] rather than just (htmlelement [:div {:id "foo"}])? It seems like all you save is one character. Is there some other benefit I'm missing?
- weavejester 15y agoSecurity. You can parse a reader literal without evaluating the resulting data structure. If you're just reading and evaluating, you might find someone injecting some malicious code in there. By using reader literals, you can include custom types like dates or UUIDs or whatever, without needing to trust the entity sending you the data.
- chc 15y agoOh, I think I get it now: The difference is that the data part of a reader literal has a fixed form, while the argument to a function could be arbitrary code. Is that right?
- Tuna-Fish 15y agoCorrect.
- nickik 15y agoYes and another thing is that when you want to use Clojure Data together with other languages. You cant calls (mydate "15.11.2000") to a python runtime, to understand it you would need a clojure runtime. When you send #mydate "15.11.2000" you only need a clojure reader. What to do with the date literals can be handled in a python function. The reader is a rather simple peace of code.