Clojurians
#cljs-dev
<
2019-02-04
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

borkdude10:02:06

I think the clojurescript-site PR can be merged already, without doing a new release

viebel16:02:40

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?

mfikes17:02:44

I don't recall any optimizations existing around numbers, just type checks.

viebel18:02:35

@mfikes Is there a function that emits a warning when it receives a number?

mfikes18:02:13

@viebel Are you referring to the kind of warning you get if you say do, (inc "a")?

viebel18:02:54

@mfikes yes

mfikes18:02:40

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.

viebel18:02:12

I think I need the opposite: a function/macro that is not supposed to receive a number

viebel18:02:37

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?