On Jun 18, 2010, at 10:09 AM, Christophe Grand wrote:
On Fri, Jun 18, 2010 at 2:49 PM, Rich Hickey <richhic...@gmail.com>
wrote:
This L suffix idea is a non-starter. Here's why:
We're in a reader based language. The reader reads objects. When
the reader
reads 42, it must return an object. It cannot return an int or a long
primitive. Right now, it returns an Integer. I've also conducted
experiments
where it returned a Long. Certainly 42000000000 will be a Long. What
different thing would the reader return given 42L, or 42000000000L?
Given an
int 42 what should the printer print? And long 42, Long 42? Would
(= 42L
(read-string (pr-str 42L)))?
But what if the reader reads 42 as a BigInteger (or an alternative
implementation) and 42L as a Long?
then you should be able to tell them apart.
And keeps them that way? Hrm. Then most programs, that currently have
no bigints, will now be full of them. And the boxed math will be
slower still, as it will be the (possibly improved, but still more
complex) logic of bigints. And the interop will be trickier. The
current boxing matches the boxing you will get from things from the
outside world. This wouldn't. And if this is just a 'way to
communicate with the compiler' thing, then read/print round-tripping
will break.
I agree with the goals of the num branch, I'm just unconvinced by the
reader defaulting to Long for integer literals.
It's important not to get focused on the literals. There are
primitives coming from other places as well. The semantic dichotomy is
the driver. The choice of the semantics of + can't be based upon the
boxed-ness of the argument, as it is now.
Rich
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
