On Jun 18, 8:49 am, Rich Hickey <richhic...@gmail.com> wrote:
> Fixing it requires adopting a single
> semantic for +. Choosing auto-promotion precludes the use of + on
> primitives, a huge loss IMO. Choosing throw-on-overflow precludes auto-
> promotion, but preserves polymorphism otherwise, and gives the
> compiler free reign to optimize since it will never be altering the
> semantics by doing so.
>
> I don't see a way around this fundamental dichotomy. The semantics for
> + should be unified, and the operator that makes the other choice
> needs to be called something else, or placed somewhere else.
I'm just a newbie here, but I would prefer the simpler and faster +
(with throw-on-overflow). I don't want to annotate my arguments
(carefully!) to get primitive performance. I want the best
performance in the simple cases. The primitive domain is big enough
for most programs.
I would be willing to use separate function names ("auto-promo-+",
etc.) to get the "safe" auto-promotion semantics. Perhaps they could
be in a separate namespace so that you can make your + symbol refer to
the auto-promoting one if you want to pay the cost. By the way, I
also want to know if a library is using auto-promotion so that I can
avoid it unless I really need it. And, yes, I think I'll know enough
about my domain to make that decision.
Steve Miner
--
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
