so on JVM nil is seqable

should I extend it here? I imagine this may have implications

@pat no you don’t need to extend it

you can call seq on nil ClojureScript as well

all the stuff around sequable isn’t important for ClojureScript

we already have it

A data point: if you do it, seqable? returns true, (-seq nil) works, and the unit tests pass. (Not offering opinion—just some data about it.)

yeah we’re not going to do that

extend-type on nil is too slow

if (seqable? nil) is false, just add a conditional in seqable? to check nil

operations on nil used to be very bad

we extend-type’d it everywhere

I ripped that stuff out years ago

Yeah, it would probably slow down a lot of things for no significant value

@dnolen ok. I'm noticing too that the simple/qualified predicates for keywords return nil instead of false. Should i wrap the namespace check with boolean (inside the and)?

@pat we generally need predicates to return true or false so they can be hinted ^boolean so inference can lead to unchecked ifs

@pat looks like you signed the CA, perhaps twice unless your name is very common

@mfikes yes talked to alex about this

Is different than as written in the jvm patch is all

Ooh. How do we handle seqable? on strings. Are there other special cases?

I suppose the answer to this question is all the cases in seq (`array?` etc.)

@pat I can’t get simple-keyword? or qualified-keyword? to return nil. (I’m only getting true or false.

i may have mutilated it, let me check. it's been a long day,

@pat With respect to boolean? there is a patch in http://dev.clojure.org/jira/browse/CLJS-1241 which might be useful

@mfikes clojure and should return nil or false, which is what im getting

(namespace :foo) ;=> nil

(defn simple-keyword?
   "Return true if x is a keyword without a namespace"
   {:added "1.9"}
   [x] (and (keyword? x) (nil? (namespace x))))

That fn ^?

i'm looking at qualified

Ahh, you are right

the predicate table in the jvm patch lacks the new symbol+kw predicates, i just added them and noticed

I added boolean as (or (cljs.core/true? x) (cljs.core/false? x)), should I pull it out?

boolean? that us

is* geez

I think David was OK with a unified patch containing all of the new stuff

Just suggesting that other ticket as an inspiration for an impl

ok I figured

@pat it’s fine to chat about the details with Alex tomorrow

I will snatch out the test at least

though I don’t see why it’s important that the predicate return boolean

I emailed him about it awhile ago, will send him a reminder

it’s fine that it returns nil instead of false

it’s means the ^boolean thing is a lie, but a harmless one

Gotta love ClojureScript’s code generation. This is much more optimal than it looks:

(defn qualified-keyword?
   [x] (and (keyword? x) (not (nil? (namespace x)))))

oh yeah 🙂

&& + !

David, if you hint ^boolean and return nil that’s one example we can be lax on right. It is 0 and ”” which cause the grief...

yes

as long as we know a fn won’t return those values, lying is OK

Cool, I actually hadn’t considered that aspect. Makes sense.

I put the easy stuff in a patch

the predicate table could be richer

I suppose with CLJS-1672, a decision could be taken on whether macro versions of some of the new predicates are useful, or maybe that’s overkill for now.

just playing with demunging javascript indetifiers back to clojurescript names via demunge, it works pretty well except for when user decides to use dollars in cljs names. Dollars are not forbidden and they don’t get any special treatment in CHAR_MAP but do get special treatment on the way out in demunge-str because of internal cljs usage of dollars to encode namespace separators and js-reserved? stuff

I believe user-specified dollars should have their place in CHAR_MAP (easy solution) or cljs should not use dollars for encoding anything (difficult solution)

@darwin I don’t $ is common for anything except compiler stuff

well, I agree that people don’t use $ in their names (I discovered by accident by trying “crazy” names), but still for correctness I think demunge should be inverse function of munge

I think adding $ into CHAR_MAP should not break anything important

we will just generate _DOLLAR_ for user-specified dollars in names

you should try it

it’s not really clear to me that things won’t break

btw. this will be a part of major new feature in cljs-devtools, I will demunge fn names and args when printing to console, and also part of "Beautification of function names” in Dirac, so I quite care about this to work correctly, because I will be on the receiving end of reports when it won’t work as expected 🙂

I will create a JIRA ticked, with patch and some tests

and we will see, I think this could break someone who would rely on dollars kept intact in munged names or copy&pasted CHAR_MAP into their code, which should be easy to fix if someone really did something like this

there usability things to think about here to for people who aren’t using cljs-devtools

all top level fns get munged names

like cljs$core$first

this works consistently across many JS target in provided better stack traces, better profiling dumps etc.

priotizing Chrome is non-starter

I see, but that won’t change, the change will affect only names which will contain dollars in user code

right so as long as that’s the case - then not a problem

@darwin which is to say, patch welcome! 🙂

working on it 🙂

it will take me more time to figure it out, didn’t realize that cljs compiler at some point relies on clojure munge, so touching just cljs implementation is not enough

@dnolen: Here is an example of a serialized Var in older clojurescript analysis cache. Where schema-with-name is a var imported from another namespace https://gist.github.com/JacobNinja/f663ae6dcef3f2e83478880d07bf09fe

no #object tags just maps of :name :file :line :column

also there may be code like this[1], which relies on fact that munge does not touch dollars: https://github.com/clojure/clojurescript/blob/c3899acf797eb6779c53b313f5606c5018360b83/src/main/clojure/cljs/compiler.cljc#L73 I will have to go carefully through all munge usages and make sure internal dollars are applied after munge, still no big deal, can be done

=> (str (string/replace (munge (str ns)) "." "$") "$" (munge scoped-name)))))

@jr did you try master?

if that’s what your cache looks like then there is no issue

sweet - I’ll check it out and let you know

shameless self promotion: i just blogged about performance aspects of using protocols in ClojureScript - http://blog.ducky.io/clojurescript/2016/06/08/more-defprotocol/

comments are welcome

@rohit the conclusion somewhat inaccurate, nothing to do with protocols everything to do with apply

@dnolen: thanks for that.

@dnolen: i thought a contributing fact was that is was copying over arguments into a new array and using a switch the length of that array

but i didn’t benchmark that

that cost isn’t really worth talking about

it’s costs something, but it’s incredibly small

cool. thanks!

@dnolen: i’ve been meaning to ask you: does it make sense to have a micro benchmarking suite for clojurescript so that those benchmarks can be observed over time

obviously modern js engines are really fast

and these micro benchmarks aren’t representative at all

so i had mixed feelings about them

@rohit we have microbenchmarks in the repo already

it’s low hanging fruit to put together some code so it’s easier to see somewhere

@dnolen: agreed. cool. i’ve been meaning to have a crack at that low hanging fruit for some time now.

@dnolen: blog post fixed. thank you!

is the right test for 'nat-long' to check for zero or positive?

@pat looks that way. code says its a long? and not neg?

(not (neg? x)) <=> (or (pos? x) (zero? x))

More on natural numbers: https://en.wikipedia.org/wiki/Natural_number

@pat just write the appropriate ops for goog.math.Long

yes I'm just unfamiliar with whatever a natlong is

i guess it just considers 0

http://google.github.io/closure-library/api/class_goog_math_Long.html

im there

im a biologist excuse my ignorance here 😕

in this case

(not (.isNegative n)) works

yes I have that for neg-long?

@pat is there something you are missing?

.isNegative and .isZero should have you covered

@pat: so natural numbers are counting numbers - 0, 1, 2, 3 etc

ok yes just verifying the difference between positive check and nat check

@dnolen should I change the long fn & the integer? predicate to use goog.math.Long

@pat not in this patch no

ok

probably not ever, since changing those are likely to cause needless breakage

the idea here is that people may communicate longs for various reason and we want to support that

not about adding longs for doing math stuff

just noting that there will be a conflict between using the long fn and the new long? predicate

i.e. you write a schema for an endpoint that will give you a long

@pat it’s not an important one

ok

long is a coercion

for math

but we don’t have long in JavaScript for math

yeah well thats why I ignored this in the first place

anyways whatever we decide, not in scope for this patch

k

unfortunately my affair with munge turned out to be much more complicated, cljs.compiler uses munge quite deliberately at many places and can pass partially munged names, concatenate them with cljs$core$ specials, and then pass them down the pipe where they can get munged again when finally emitted. I don’t see an easy strategy how to implement my changes locally without touching a lot of code assuming dollars are not munged.

I could rename all cljs internal dollars to some special unicode character and turn them into normal dollars at the emit level (where normal dollars were already munged into _DOLLAR_). But that smells like a hack and I doubt it would be accepted.

Just to add to this, https://clojurians.slack.com/archives/cljs-dev/p1465401175000206 $ is used in functions with multiple arities

yes, dollars are used at many places internally, I believe there is no easy way to distinguish dollars coming from user and dollars added in later compilation stages when munge method gets eventually called

after my explorations today I think demunge-str is too aggressive, it replaces all dollars with “/“: https://github.com/clojure/clojurescript/blob/463de005b81d4a00951188e8b8d38a61d684c18e/src/main/cljs/cljs/core.cljs#L10350

Dollars in functions from users is pretty unlikely, I don’t think I’ve ever seen one

yes, I agree

I was just curious if this can be fixed, didn’t expect it to be such PITA

$ in CHARMAP seems like a good solution regardless though

does not work, unfortunately

oh really?

stink

munge which eventually uses CHAR_MAP can be often called on names constructed by cljs compiler containing internal dollars

but munge has no chance to distinguish between them at that point

I decided to go another route, I will implement my own version of demunge with heuristics which dollars are likely coming from cljs internals

I have to do with namespaces now anyways, namespace separator is unfortunatelly dollar again, so I cannot tell which part of munged name is really a namespace

I have to test goog datastructures if given part is existing namespace

and take the longest one

AFAIK there is no way how to tell from name alone, because user dollars and cljs internal dollars can complicate the resolution