This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-04
Channels
- # announcements (7)
- # beginners (37)
- # boot (6)
- # calva (13)
- # cider (13)
- # cljdoc (52)
- # cljs-dev (9)
- # clojure (117)
- # clojure-europe (3)
- # clojure-italy (12)
- # clojure-nl (21)
- # clojure-russia (8)
- # clojure-spec (77)
- # clojure-uk (20)
- # clojurescript (142)
- # community-development (6)
- # cursive (5)
- # datomic (13)
- # emacs (9)
- # figwheel-main (20)
- # fulcro (33)
- # graphql (11)
- # instaparse (6)
- # klipse (1)
- # off-topic (7)
- # om (8)
- # quil (7)
- # re-frame (11)
- # reagent (39)
- # reitit (10)
- # shadow-cljs (36)
- # spacemacs (3)
- # test-check (3)
- # tools-deps (83)
- # utah-clojurians (31)
- # vim (14)
I think the clojurescript-site PR can be merged already, without doing a new release
I am reading the part about type inference in https://clojurescript.org/news/2019-01-31-release#_type_inference_improvements
I am asking myself, what are the implications in terms of warnings or optimized transpiled code of an expression being inferred as a number?
I understand that when an expression e
is inferred as a string, then (str e)
is simplified into e
. Is there a similar use case for numbers?
@mfikes Is there a function that emits a warning when it receives a number?
I'd recommend taking a look a the ::ana/numeric
meta that is on those macro-functions and tracing how it causes warnings to be emitted.
I think I need the opposite: a function/macro that is not supposed to receive a number
I’d like to illustrate the scenario with f
and g
, that is mentioned here https://clojurescript.org/news/2019-01-31-release#_type_inference_improvements
> In fact, owing to the way the or macro expands, the expression (or (f 1) 17) is now inferred as being simply number.
Is there a piece of code that we can show to demonstrate how the transpilation was optimized due to this inference?