Clojurians
#cljs-dev
<
2015-11-26
>

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

thheller09:11:39

@dnolen I asked this question before but do you have an example of how/why :static-fns is not suited for a REPL environment? I'm trying to break it but can't

mfikes13:11:55

I thought it might have to do with arity, but I’d also be interested in how changing arity breaks it.

dnolen13:11:47

yes compile something with arity 3

dnolen13:11:54

compile another function using it

dnolen13:11:02

re-compile the first thing with arity 2

dnolen13:11:09

call the function that used it

thheller13:11:49

I do not quite understand that example

thheller13:11:38

with static-fns

thheller13:11:22

now contains the output for both

thheller13:11:28

both execute equally

thheller13:11:22

ie. the c parameter is lost

dnolen14:11:07

right but those fns don’t exhibit the fancier optimization

thheller14:11:07

or which optimization do you mean? since it is the REPL there isn't really anything to optimize?

dnolen14:11:28

do your thing again

dnolen14:11:54

fn1) arities 3,4 then redef fn1) arities 4,5

dnolen14:11:02

in the other fn invoke arity 3

thheller14:11:56

Uncaught TypeError: cljs.user.x.cljs$core$IFn$_invoke$arity$3 is not a function

thheller14:11:21

which is what I'd expect?

thheller14:11:54

without static

thheller14:11:57

Uncaught Error: Invalid arity: 3

thheller14:11:19

granted the error message is better

thheller14:11:50

gist has the code

dnolen14:11:26

it’s just wrong, think about dynamic binding a variadic fn instead

dnolen14:11:54

static linking is just never the right behavior at the REPL

thheller14:11:04

well should the compiler not prevent static linking for something marked ^:dynamic in all cases?

dnolen14:11:45

simple fix too, all the optimizations are in the :invoke case of the compiler

thheller14:11:11

uhm so if we'd have that :static-fns would be obsolete?

thheller14:11:39

I'm just trying to understand :static-fns since I have it enabled always and always dismissed it as a REPL thing

thheller14:11:49

but after implementing a REPL myself

thheller14:11:13

I still don't understand static-fns

thheller14:11:57

I'll try something with binding and variadic

dnolen14:11:55

we’re never going to turn on :static-fns by default

thheller14:11:21

don't expect you to, just trying to understand it

dnolen14:11:18

the reason we added it was just that it creates strange behavior for people used to the dynamic aspects of Clojure

dnolen14:11:32

it was Chouser that pointed out the optimizations broke some REPL expectations

dnolen14:11:37

so we put the optimizations behind a flag

thheller14:11:12

can I find that discussion somewhere?

dnolen14:11:29

you’d have to look at the #C03S1KBA2 IRC logs

dnolen14:11:39

probably from late 2011 or early 2012?

thheller14:11:52

static or not both fail in the exact same way

thheller14:11:13

although I'd expect that to work

thheller14:11:18

strange that it doesn't

thheller14:11:08

Uncaught TypeError: (intermediate value)(intermediate value)(...) is not a function is also the weirdest error I have seen :simple_smile:

thheller14:11:39

I'll try to dig up the discussion

thheller14:11:03

hmm ok it works in the cljs repl

thheller14:11:26

great, something I can use to understand this

thheller15:11:35

ok nvm works in my repl too .. just need to include cljs.core before trying to eval it

thheller15:11:39

back to square one

thheller15:11:45

I'll keep digging

thheller15:11:18

binding/variadic works with and without static-fns

mfikes23:11:19

@thheller: “switching a top level definition from a fn to an object (which implements IFn) can cause problems” (from https://groups.google.com/forum/m/#!topic/clojure/c3ho-Y8o6Wg)