I was pondering how we can improve the ^:const description in the “differences” page (https://clojurescript.org/about/differences#_special_forms) for when the next release comes out. It currently has

* `:const` metadata in ClojureScript disallows re-def and supports case. In Clojure `:const` allows re-def but value inlined at use site.

* `:const` metadata:
  - disallows re-def in ClojureScript, while re-def is allowed in Clojure
  - supports inlining of static literal values in ClojureScript, while only primitives are inlined in Clojure
  - allows `case` test constants which are symbols resolving to `^:const` Vars to instead represent their values in ClojurScript, while such tests constants are symbols in Clojure 

Sweet: Test output is now appearing in the CI builds (where it was being swallowed previously): https://travis-ci.org/mfikes/clojurescript/builds/244743749

@mfikes I don’t think that’s quite right

Clojure inlining is not limited to primitives

OK… it can also inline other simple things? (keywords, symbols?)

also the disallowing redef is only about compiling files - not a REPL thing - so not a big deal for users

and potentially really confusing to call it out

@mfikes no you can inline any EDN value you want as far as I can tell

I think the only thing we should mention is the case will inline ^:const vars

OK. So perhaps there will be no essential difference between ClojureScript and Clojure with respect to inlining. (That line could be removed)

the important semantic distinction is that Clojure will eval the const initializer at compile time

no it wont

const init is no different than any other var init

during inlining

the difference is just intrinsic on the different compilation units

i.e inlining in clj happens after def evaluation, in cljs happens before eval

I don’t follow

if you make a const init expression w/ a side effect

at every inline site, the compiler will run that side effect

nope

not in the code

during inlining at compile time

yeah, that is not correct

make an example

this is what somebody tried when we worked on ^:const

user=> (def ^:const a (do (println "foo") [1]))
foo
#'user/a
user=> (defn x [] a)
#'user/x

(def ^:const ..) is not evaluated any differently than (def .. in clojure

now try this under AOT

Here is an example that made me think that arbitrary EDN might not be inlined in Clojure:

user=> (def ^:const x [1])
#'user/x
user=> (identical? x x)
true

@mfikes to me inlining happens if it breaks redef, try it

(defn foo [] x)

change x to a new const value, foo will return old

@dnolen right, under AOT any def is evalauted twice, once during compilation and once during load, again, not specific to const

it's just that clj will evaluate defs on every ns load, and AOT compiling causes load

@bronsa ah, k that make sense - clarifies things - thanks

right so we can’t replicate that

and that’s what should be called out

so yeah, there is an evaluation difference between clj and cljs but saying that clj does it at compile time is incorrect

So, it sounds like the only thing really worth mentioning on the “differences” page is the case behavior.

@mfikes not quite, @bronsa’s point is correct

(def ^:const foo (:bar baz))

in Clojure this will run the initializer and assign it’s value to foo

then that can be used for inlining

difference is essentially: clj will inline evaluated values, cljs will just inline unevaluated literals. both require the inlined value to be a valid EDN literal

so this specific expectation can’t be supported in ClojureScript

Ahh, right. This is alluded to in https://github.com/clojure/clojure/blob/f572a60262852af68cdb561784a517143a5847cf/changes.md#215-const-defs

I mean semantically it is supported 🙂 but inlining won’t occur in this case

(def ^:const foo (:bar baz)) is perfectly valid ClojureScript

we just can’t inline the result at the compile time

should that work tho?

I don’t see why not

clojure explodes if you try to inline values that can't be inlined

e.g.

user=> (def ^:const bar (Object.))
#'user/bar
user=> (defn foo [] (bar))
CompilerException java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined: java.lang.Object@3d71d552, compiling:(NO_SOURCE_PATH:3:1)

yeah I’m not concerned about that at all

ok

too much Clojure internal stuff going on there

@bronsa one problem is that what we just discussed is surprisingly subtle and easy to be confused about

yes

* `:const` metadata:
  - supports inlining of static EDN values in ClojureScript, while evaluated values are inlined in Clojure
  - allows `case` test constants which are symbols resolving to `^:const` Vars to be inlined with their values in ClojureScript, while such tests constants are symbols in Clojure 

and based on what I did for ^:const (an early aggressive and not quite right commit) there’s too much incorrect stuff already in the wild

it's not easy to talk about in simple terms

well, easy to understand terms*

as in people didn’t understand how it was supposed to work and did the wrong thing in existing code

so forcing Clojure semantics now is just going to break everyone

“people didn’t understand how it was supposed to work” including me for the last who knows how many years

@mfikes so now going back I agree

let’s just mention the case thing

OK… don’t open the inlining rat hole 🙂

I think we should say that ^:const will inline compile-time static EDN values and leave it at that

just so people don’t get tripped up at the REPL

This simpler language just focuses on ClojureScript:

* `:const` metadata:
  - will cause inlining of compile-time static EDN values
  - causes `case` test constants which are symbols resolving to `^:const` Vars to be inlined with their values 

sounds good

I’ll take care of submitting that language when the release is done

There's a problem with cljs compiler and transit analysis cache

wondering if anyone noticed it or if its a transit version mismatch?

Best I can tell from the exception, these write handlers should be one-arg functions, not two-arg method impls: https://github.com/clojure/clojurescript/blob/293b7ddb7c26d525e8fe33c0cf1707cee52c6f8b/src/main/clojure/cljs/analyzer.cljc#L87-L94

hah, this is my code

yeah I would have been surprised if that was the case

er I mean if this hasn’t been caught before but maybe

no it's definitely wrong

reader broken too

I'll have a (well-tested) fix in a sec

but I am really surprised no one ran in to this

I guess no one uses transit caching?

I guess you only hit it if a js val or pattern gets into the aot

(pattern meaning regex)

ugh not the aot, the ast

ah right

yeah probably not that common

For https://dev.clojure.org/jira/browse/CLJS-2110, I’ve posed a question for clarification in #test-check

@mfikes thanks

@dnolen Summary is it appears there was unintentional breakage. Perhaps that means for ClojureScript is that either it could move to 0.10.0-alpha2 if one is produced in time, or we could revert my change that moved it to 0.10.0-alpha1 if a ClojureScript release becomes imminent.

@dnolen https://dev.clojure.org/jira/browse/CLJS-2111

@mfikes hrm first thing is we should make a test for it I think 🙂

and then we can decide if we want to cut a fix for this on Friday

if you want to submit a regression patch go for it

@favila, thanks is that :clj only? perhaps that’s why we messed this up - pretty sure sig is different for transit-clj / transit-cljs

transit-write-opts and almost everything related to writing analysis files seems to be #?(:clj ...) only

all the lines changed by that patch are guarded by :clj

ok cool