The defect existed prior to CLJS-116. The problem is that we're using the Clojure reader and g is not a valid flag for a Java RegexPattern.

The following patches include an implementation of Common Lisp's #+
and #- reader macros to allow conditional compilation/reading for
Clojure and ClojureScript.

The patches add a dynamic variable called features to the
clojure.core and cljs.core namespaces, that should contain the
supported features of the platform in question as keywords.

Unlike in Common Lisp, the variable is a Clojure set and not a list.
In Clojure the set contains at the moment the :clojure keyword, and in
ClojureScript the :clojurescript keyword.

I would like to get feedback on the names that are added to this
variable. Are those ok? Is :jvm for Clojure and :js for ClojureScript
better? Should ClojureScript add something like :rhino, :v8 or
:browser as well?

To run the ClojureScript tests, drop a JAR named "clojure.jar" that
has the Clojure patch applied into ClojureScript's lib directory.

This is an enhancement so it probably requires a design page and extended discussion before it will go anywhere. Until that happens I'm marking this is as low priority.

Ok. If someone could give me write access to the Clojure Dev Wiki I would be happy to start such a design page.

If you've sent in your CA request permissions on the clojure-dev mailing list.

I started a design page for this ticket in the Clojure Dev wiki:
http://dev.clojure.org/display/design/Feature+Expressions

Posting my comments over on the design page...

Benefits:
Better support for mobile (Android, iOS, iPad) development in ClojureScript.

Problem:
Please add support for passing "--define" option to compiler.jar.
With this we can optimize code performance where only mobile browsers are our target.

Resources:
goog.userAgent global props: http://closure-library.googlecode.com/svn/docs/closure_goog_useragent_useragent.js.html
goog.userAgent.product global props: http://closure-library.googlecode.com/svn/docs/closure_goog_useragent_product.js.html
"java -jar compiler.jar --help" for all available options
Google Closure Definitive Guide at Google Books: http://books.google.pl/books?id=p7uyWPcVGZsC

clojurescript/src/clj/cljs/closure.clj: functions "make-options" and "set-options"

"TODO: Add any other options that we would like to support."
(defn set-options
"TODO: Add any other options that we would like to support."
[opts ^CompilerOptions compiler-options]
(when (contains? opts :pretty-print)
(set! (.prettyPrint compiler-options) (:pretty-print opts)))
(when (contains? opts :print-input-delimiter)
(set! (.printInputDelimiter compiler-options)
(:print-input-delimiter opts))))
(defn make-options
"Create a CompilerOptions object and set options from opts map."
[opts]
(let [level (case (:optimizations opts)
:advanced CompilationLevel/ADVANCED_OPTIMIZATIONS
:whitespace CompilationLevel/WHITESPACE_ONLY
:simple CompilationLevel/SIMPLE_OPTIMIZATIONS)
compiler-options (doto (CompilerOptions.)
(.setCodingConvention (ClosureCodingConvention.)))]
(do (.setOptionsForCompilationLevel level compiler-options)
(set-options opts compiler-options)
compiler-options)))

One more usecase, I've stumbled upon, while wrapping goog.i18n, here's a line from goog/base.js:59:

/**
 * @define {string} LOCALE defines the locale being used for compilation. It is
 * used to select locale specific data to be compiled in js binary. BUILD rule
 * can specify this value by "--define goog.LOCALE=<locale_name>" as JSCompiler
 * option.

So, without --define it's simply impossible to create i18n apps with ClojureScript and Closure Library.

Attached patch doesn't work with the latest master.

OSX 10.7

I had a similar problem when my namespace contained a word class, e.g. in namespace:

(ns foo.bar.class)

Advanced closure compiler produced an error treating class as a JS keyword.

Will this change cause strings like "{\"foo\" :true}" to have ambiguous parses? And if we want CLJS to be a superset of JSON do we need to parse "null" as well?

See CLJS-247 for comments relevant to this patch.

Not seeing much of a perf benefit from this, though Michal reports differently. More investigation is needed.

patch no longer applies. I wonder if I see bad behavior because I was testing with node or it was prior to the fixes around avoiding deoptimization.

I'll bring it up to date with the recent changes, thanks for the prod!

flag might be:

:inline-protocol-fns true

No switch in this version – will add one if it seems it's worth it.

With this applied, core-advanced-test.js grows in size to 360301 bytes from 357528 bytes on current master.

This does seem to be a perf win on both :simple and :advanced, by the way.

Reattaching the patch to CLJS-246. Will get back to this.

After some discussion with Rich this is definitely a direction we should pursue. It's very similar to what Clojure currently does.

I went ahead and tried this, http://github.com/clojure/clojurescript/compare/master...cljs-247-protocol-fn-call-sites.

Code size is not very different 364k vs 373k for compiling all of the tests.

This is not going to be faster given our use of satisfies? I noticed that if we removed the satisfies? calls this is a performance win.

Problem: If a symbol passes a satisfies? it would be nice if we could tag it as satisfying the protocol and just emit the protocol dispatch directly. However this would not work for JavaScript primitives.

Looks like I spoke a bit too soon There was a typo in the branch. The performance improvement between this and master is small for V8, but measurable for SpiderMonkey and JavaScriptCore.

Also, we could do the satisfies? optimization such that it works for JS natives with a simple gensymed mutable local around the callsite.

K for handling natives simply tagging the symbol is not enough. We need to set a runtime gensymed flag that denotes whether it's a fast path protocol call. We can then avoid any redundants tests in the true branch of satisfies? and emit code like the following:

fast-path-flag ? foo.cljs$lang$Protocol$bar$arity0$(x) : cljs.core.Protocol.bar[goog.typeOf(x)](x);

Here's a patch which eliminates recursion in all the fns mentioned in the ticket name.

I haven't done much in the way of measuring the impact on perf; a naive benchmark of (assoc huge-vector 123 :foo) seems to indicate a modest perf gain (a few percent shaved off the runtime).

Note that whether pop-tail as implemented in this patch is an improvement over the previous version is not that clear, since it needs to precalculate the level at which the main loop should terminate. Careful measurements will be necessary. (I wouldn't be surprised if the difference turned out to be unmeasurable, in which case I guess we needn't bother with the change.)

push-tail and do-assoc have no such problems – all the work being done needs to be done (and is now done in a non-recursive fashion).

Hm... Actually that probably means this patch should be split in two (pop-tail & rest). I'll get around to that soon.

More importantly, some benchmarks for large data structures should be added (assoc / conj of 32 items (at any rate, a large enough number of items for the tail to be pushed in) / repeated pops (again, enough to pop the tail)). ("Large" here means "large enough for the shift of the vector to grow at least to 10", meaning size > 1024 + 32; shift 15 would be better, requiring size > 32768 + 32.)

Awesome! Lets split the patch in two.

Ok. Here's a new patch which eliminates recursion in push-tail and do-assoc. I guess the large data structure benchmarks should probably get in first – see CLJS-357 (some benchmarks already attached – could use some scrutiny in case they're not exercising what they should be; initial runs indicate a very modest speedup).

I'll give pop-tail a little more thought and write a new patch for it sometime soon too. (Perhaps worth pointing out is that the zlvl precalculation in the current version of the pop-tail patch doesn't need to traverse any nodes – it's all bit twiddling – so it should be pretty cheap... I guess we'll see what the benchmarks say – I haven't actually ran them on this code yet.)

So how did the benchmarks turn out for these?

I applied and ran these benchmarks using the lasted V8. These don't seem to make any difference. Perhaps V8 no longer has issues with the recursive cases? I didn't test beyond running the benchmark script. Might be worth getting something up on JSPerf.

Thanks! Did you verify that browser REPL continues to function properly?

I've never used this before, so just assume everything in bold has earmuffs around it.

This seems like a lot of separate issues rolled into one. Can we break this ticket apart into simpler actionable tickets?

Now that we have default-data-reader-fn, its possible to have a clean fix. Just set default-data-reader-fn to the function described above.

Should I generate a patch?

What function defined above?

the function is
(fn [tag data] `((cljs.core/get (cljs.core/deref cljs.reader/tag-table) ~tag) ~data))

The proposal is to bind default-data-reader-fn to the above, in compiler.clj for the compile-file* function. And get rid of the binding for data-readers in that function as well.

It should be possible to get rid of the tagged_literals.clj file as well, since those definitions are no longer needed after this change.

Was this ticket supposed to be filed against Clojure, not ClojureScript?

No. This ticket refers to the HackerSchool work to provide a reflection hook for ClojureScript to make the REPL interactions more friendly. Look at clojure.reflect in the ClojureScript repo.

As we've changed the topic of this issue a little bit..., I'd like to add the additional requirement that the reflection facility should be pluggable, meaning that if I have additional help/reflection functions that I want to make available to the cljs-repl users, then I should not have to wait for acceptance in a new clojurescript version.

Maybe some form of registration API thru which I can add new cljs-functions that communicate with their clj-counterparts thru some naming convention . Not sure about the details here...

That's really a separate issue that probably warrants it's own discussion.

Well... you started to add the (seemingly unrelated) CrossPageChannel requirement to the asynchronous one

But seriously, the pluggability requirement is probably important to keep in mind when any implementation for asynchronous clojure/reflect is designed and implemented - I'll open-up another issue for pluggability to keep it clean.

The protocol should probably just be called IAtom. A note, changing atoms to go through protocols has performance implications - generally protocol fns are about twice as slow as regular fns.

I'll take a closer look.

Auto-generation from the build script of version_autogen.clj and version_autogen.cljs files
that both define the cljs.version-autogen/clojurescript-version
with the current version info for both the clj and cljs environments

Why a separate namespace for this?

Good point - probably better to add the clojurescript-version var to the cljs.core namespace.

New patch change the build script to auto-generates the clojurescript-version assignment statements in both cljs/core.clj and cljs/core.cljs to reflect the correct version info.

In that way it resembles more the clojure.core use of clojure-version.

Note that the two separate assignments for clj and cljs are needed to detect out-of-sync of repl-compiler version with the compiler used to generate the js-code that was downloaded thru the webpage.

Difficult to write a test-script, but it seems to work in my repl:

—
user=> (require 'cljs.core)
nil
user=> cljs.core/*clojurescript-version*
{:minor 0, :revision 1515, :major 0}
user=> (run-repl-listen)
"Type: " :cljs/quit " to quit"
ClojureScript:cljs.user> *clojurescript-version*
{:revision 1515, :major 0, :minor 0}
ClojureScript:cljs.user>
—

CLJS-402: build script auto-generates the clojurescript-version assignment statements in both cljs/core.clj and cljs/core.cljs to reflect the correct version info

When I tried to implement a "clojurescript-version" function like the "clojure-version" one, I (re)discovered that cljs/core.clj is not your average cli-file but some funky file used by the clojurescript compiler to bootstrap - in other words it's not a good file to require and run normal functions from your clj-environment.

So I moved the *clojurescript-version* var to cljs/compiler.clj as it seemed to make sense to associate the version with the compiler.

On the cljs site, I left the *clojurescript-version* in cljs/core.cljs, although I was tempted to create a cljs.compiler namespace to store that var on the cljs side to make it symmetric .

Also added a (clojurescript-version) function to both the clj and cljs sides, with an added special-fn in the cljs/repl.clj such that you can ask for the compiler version of the repl-server from the cljs-repl.

Updated 3rd patch file replaces the previous one.

Just wanted to record an example of a mismatch in compilers:

user=> (run-repl-listen)
"Type: " :cljs/quit " to quit"
ClojureScript:cljs.user> (clojurescript-version)
"0.0.1515"
ClojureScript:cljs.user> (clj-clojurescript-version)
"0.0.1516"
ClojureScript:cljs.user>

This happens when you generate the javascript from your cljs with a "lein cljsbuild once" command with compiler version "0.0.1515",
then upgrade the compiler to "0.0.1516" and then run the cljs-repl without regenerating the javascript for the webpage-download.
Very obscure things can happen after that...

build script auto-generates the clojurescript-version assignment statements in both cljs/compiler.clj and cljs/core.cljs to reflect the correct version info
Function "clojurescript-version" is added to both compiler.clj and core.cljs to mimic equivalent "clojure-version"
Special-fn "clj-clojurescript-version was added to repl.clj to obtain the compiler's clojurescript-compiler version from the cljs-repl

The patch uses sed, I'm not sure this is such a great idea since whatever the patch does should probably work with whatever build setup we have on Hudson.

Would it make sense to call this 'clojure-version' as well, instead of clojurescript-version? It's a map, and so various flags could be added to differentiate jvm, js, python, c, etc. runtimes. What does ClojureCLR do?

sed was already used in the build script... a few lines down, the pom file is transformed with:

sed -e s/CLOJURESCRIPT_VERSION/0.0-$REVISION/ < "$POM_TEMPLATE" > "$POM_FILE"

A quick scan of the src-code showed that ClojureCRL uses clojure-version and *clojure-version*.

However, there is less chance for confusion as you are supposedly running on the CLR already.

With ClojureScript you can have these three intertwined "clojure" environments that are all live at the same time: the clojure version, the repl clojurescript version, and the clojurescript version used to compile the initially loaded js. Not sure if overloading the clojure-version fn-name and relying on namespaces to differentiate will be helpful... but it's not that big of a deal and I'm easily persuaded otherwise - somebody should make the call and I'll change it.

Sorry just now coming back to this ticket. I think it's probably preferable that the map of properties be called the same thing everywhere. I would apply the patch with this change. I note it no longer applies to master.

First patch implements specify, second switches extend-type to use it.

This is a big patch so it's going to take time to review. First question, if we're going to follow the footsteps of extend what's the purpose of changing the syntax like having to specify a map of arities?

The reason is that I wanted specify* to do as little as possible. It's basically just an abstraction over the name mangling for protocol methods, which was completely hidden till now. One of the purported use cases is:

(def methA-1 [this] ...)
(def methA-2 [this x] ...)
(def methB-1 [this] ...)

(defn specify-to-P [o]
  (specify* o
    P {methA {1 methA-1
              2 methA-2}
       methB {1 methB-1}}))

Here the method bodies are not allocated every time specify-to-P is called, as opposed to what the more high-level specify would do. If we didn't know which arities are to be generated, there would be simply no way to infer it:

• there is no simple way to know at compile time which arities an fn has
• if there was we wouldn't be able to get the fn at compile time in all cases
• defprotocol doesn't expose it's methods or their arities

EDIT:

As for using symbols instead of keywords: I could do this, since specify* is a macro, not a function.
Making specify* a function may have its own merits, which I frankly hadn't thought about. Actually, that might be sweet, I'll look into that possibility.

As for specify* being a function: It uses a map in its syntax and at the same time is used to define PersistentHashMap, so that wouldn't work.
EDIT: the real reason is name mangling, see comment below

What could conceivably be done is to have a core function (specify-method [proto method arity impl]).
EDIT: can't be done without reflection, same reason

That way we could support consumers that want to determine the set of implemented protocols at runtime, similar to extend. This can be a separate ticket where we work out whether it's :method 'method or "method".

As for specify* using symbols: My gut feeling tells me that since it will always be a compiler macro (or builtin) and takes the arities, there is no merit in making it superficially more similar to extend.

OTOH, it occurs to me that given specify-method, we could leave out specify* completely. I think I'll try that when I get home from work. Thoughts on that approach?

Actually, I had a rationale for using symbols in specify*, which I just now rediscovered while trying to implement aforementioned specify-method.
It uses symbols to highlight the fact, that the method names are subject to the same (gclosure) minification as every other name.

This is also the real reason specify* (or specify-method) can't be a function: It would need a reflective layer to go from [proto method arity] to the gclosure minified version of $proto$method$arity$a. We don't have that in clojurescript, since it would considerably add to the output size.

Considering that all, I think specify* in the current form is appropriate after all.

Nevertheless I found an unrelated issue in the patch where 'Object would be resolved (with an unused result), triggering a warning. I added the 0001_1 patch, which supersedes 0001 and is functionally equivalent modulo the warning issue. 0002 still applies.

Attached patch set 01** supersedes patch set 00**

The differences are

• Make ^:skip-protocol-flag work
• Added tests

Set up a design page http://dev.clojure.org/display/design/specify+i.e.+reify+for+instances

Attached patch 0104, applies on top of other 01* patches.
It adds capability to specify* IFn and allows specify* to take an expression too.

rebased to current master
see also https://groups.google.com/d/topic/clojure-dev/1UegnkLSwhE/discussion

The issue is actually a bit subtle for example:

(defn foo "name")

is valid Clojure - however this doesn't work in ClojureScript. In this case ClojureScript generates the following:

function () {
    switch (arguments.length) {
    }
    throw (new Error("Invalid arity: " + arguments.length));
}

After talking to Rich the above really should not compile.

Here's a patch with the fn* validations I could think of. It seems to cause the compilation time to increase by a measurable amount, which I find quite surprising (even though it's to be expected that there will be quite of few fn* forms in CLJS sources). I'd love to know if it's just on my box (let's hope so). If validations really have that sort of effect, I'm thinking about refactoring the analyser so that they can be turned on (which should also be the default) and off (for particularly fast compilations).

Ah, wait, there's a minor typo in the commit message, I'll fix it in a second...

...um, no there isn't. Sorry for the confusion.

Isn't the stack trace recoverable from the original exception?

I hadn't considered that. If a cause is provided, that seems reasonable. The only trouble is that you still have to know where the ExceptionInfo is being thrown, so that you can catch it and throw the cause. Chrome's debugger would make it easy to at least find where the ExceptionInfo is thrown, but it's still more trouble than having the appropriate stack trace directly on the ExceptionInfo.

If no cause is provided, of course that won't work. But I suppose one could write (ex-info msg data (js/Error.)) instead of (ex-info msg data)? Personally, I don't expect to pass a cause very often — I expect the binary arity to be much more common in my cljs libraries.

If we rely on the cause for the stack trace, maybe we could have the cause default to a new Error if not supplied? It seems sort of conceivable that we could also wire up the ExceptionInfo to proxy .stack to that Error so that the stacktrace will come through, without needing to override the ExceptionInfo constructor.

N/A

Is this behavior supported in Clojure?

It seems it is

@David,

Yep, it is supported. Enhancing Jozef's response:

user=> (use 'clojure.instant)
nil
user=> (read-instant-date "2012-12-30T23:20:05.066980000-00:00")
#inst "2012-12-30T23:20:05.066-00:00"

/Anatoly

Ok, do you all have a good idea about what a patch would look like?

Since JavaScript has no support for nanoseconds in Date, I'd vote for dropping the nanoseconds. Currently the reader just blows up when reading a String with java.sql.Timestamp printed in CLJ, since that is printed in nanosecond precision.

While probably not the best solution, I attached a patch for cljs.reader/parse-and-validate-timestamp fn that just drops the nanoseconds from the millisecond portion. Would be easier to just strip the ms string to 3 digits but that would cause "2012-12-30T23:20:05.066980000012312312123121-00:00" to validate.

Well, Math. Just realized that this is not really correct, since 1000 is closer to 999 than it is to 100.

Sorry, for that brainfart.

Or we could return a custom ClojureScript Date type that provides the same api as js/Date but adds support for nanoseconds.

One could extend the js/Date prototype with a setNanos/getNanos method and call them accordingly. I'd offer to implement that but the cljs.reader/parse-and-validate-timestamp function scares me, any objections to rewriting that?

As for the js/Date extension, thats easy enough:

(set! (.. js/Date -prototype -setNanos) (fn [ns] (this-as self (set! (.-nanos self) ns))))
(set! (.. js/Date -prototype -getNanos) (fn [] (this-as self (or (.-nanos self) 0))))

Not sure if its a good idea though, messing with otherwise native code might not be "stable".

Not convinced that keeping the nanos around is "required" since javascript cannot construct Dates with nanos, but its probably better not to lose the nanos in case of round tripping from clj -> cljs -> clj.

We definitely don't want to mutate Date's prototype without namespacing. I'm not sure we want to mutate Date's prototype at all. That's why I suggested a ClojureScript type with the same interface as Date just as Google has done in Closure.

clojurescript r1552

What do you think of this approach based on
based on http://www.50ply.com/blog/2012/07/08/extending-closure-from-clojurescript/

While it may not preserve enough of gen-class's semantics. This would be enough for us to start gradually porting our large GClosure code base to Clojurescript. The code size reduction would be enormous.

(ns com.example
  (:require [goog.ui.tree.TreeControl :as TreeControl]))
(gen-class
  :name DemoTree
  :extends goog/ui.tree.TreeControl
  :constructor ([name config]
                 (goog/base (js* "this") name config))
  :methods [[handleKeyEvent [e]
              (goog/base (js* "this") "handleKeyEvent" e)
              ;; my special code to handle the key event
    ]])

here is a untested mock implementation modified from http://www.50ply.com/blog/2012/07/08/extending-closure-from-clojurescript/

I changed constructors to constructor because there can be only one in js

This unfortunately has different semantics from gen-class because the original did not include the definition of the methods and constructor inline. It tried to read the Clojure gen-class source,but I still do not yet understand how the :prefix grabbing of functions from the current namespace works from within a macro.

For Google Closure interop each class should have its own provide

(defmacro gen-class [{new-type :name base-type :extends ctor :constructor methods :methods}]
  `(do
     ;(goog/provide ~@(str *ns* "." new-type)) 
     (defn ~new-type ~@ctor)

     (goog/inherits ~type ~base-type)

     ~@(map
        (fn [method]
          `(set! (.. ~type -prototype ~(to-property (first method)))
                 (fn ~@(rest method))))
        methods)))

ClojureScript 0.0-1586 build #22, Chrome, OSX

type just returns the constructor property of an Object. For some reason this is returning undefined instead of value. It's likely that this has nothing to do with ClojureScript and more to do with Google Closure. Have you investigated whether the OAuth token constructor has changed in Closure itself?

I don't think the token object or the apis have any significant relationship with closure, they are loaded dynamically from google (gapi.client.load):
https://code.google.com/p/google-api-javascript-client/wiki/ReferenceDocs#OAuth_2.0_Token_Object
https://code.google.com/p/google-api-javascript-client/wiki/GettingStarted

Did type return something for you instead of undefined in 1450?

Sorry I can't answer that; js->clj just worked so I didn't probe too deeply but looking at the code in js->clj It looks like it must have. I tried the original implementation of js->clj before the recent changes but confirmed this still suffers from the same problem (type x) js/Object):

(defn js->clj
"Recursively transforms JavaScript arrays into ClojureScript
vectors, and JavaScript objects into ClojureScript maps. With
option ':keywordize-keys true' will convert object fields from
strings to keywords."
[x & options]
(let [{:keys [keywordize-keys]} options
keyfn (if keywordize-keys keyword str)
f (fn thisfn [x]
(cond
(seq? x) (doall (map thisfn x))
(coll? x) (into (empty x) (map thisfn x))
(goog.isArray x) (vec (map thisfn x))
(identical? (type x) js/Object) (into {} (for [k (js-keys x)]
[(keyfn k)
(thisfn (aget x k))]))
:else x))]
(f x)))

Note that there are two other places where the Clojure reader is used in ClojureScript — one in the analyzer, one in the compiler — where a similar fix may be required. Perhaps cljs.compiler/forms-seq should be the sole place where the Clojure reader is used with *ns* properly tracked therein...

Is this fixed in master?

Attached patch 0001 binds data-readers in cljs.compiler/parse-ns.

This allows the compiler to run, even if files with reader tags are already compiled.

This in turn allows multiple test compilations to be brought back, which I'll submit as part of a patch for an additional debugging flag, if nobody beats me to it.

I think this won't fix load-file , but after the hotfix we should probably look for the proper place in the compiler to bind data-readers.

Patch 0002 is my overhaul for the test script.
Since it's a test case for patch 0001, I think it's justifiable on this ticket.

Note: On my machine, with SpiderMonkey 185, the test case (not (integer? 1e+308)) fails. It probably doesn't have to do anything with the removed -n flag (there is no js -n omm), I just wanted to mention it.

When I try to run the jsprefs I get "ReferenceError: cljs_perf is not defined."

Chromium browser on kde mint

Works for me on master. Which version of ClojureScript are you using?

Patch 0001 depends on patches 0001 and 0002 from CLJS-480 because of changes to the test script.

There's a patch for Clojure, here CLJ-960

Related, https://github.com/brandonbloom/clojurescript/compare/clojure:master...brandonbloom:track-pos

wip here http://github.com/clojure/clojurescript/tree/source-map

Related ticket (tracking line & col during emission) that was resolved - http://dev.clojure.org/jira/browse/CLJS-176

Later

Do we need something more sophisticated then this: http://github.com/clojure/clojurescript/wiki/Running-the-tests

My plan is a macro `as-js` that takes a single expression. If it's a literal vector or map, it will expand to a js* form that will emit the appropriate array or object literal. In the case of a map, all the keys must be constants (string, keyword, or symbol) in order to for this to work since literal object keys in javascript aren't evaluated. Keyword and symbol keys would be converted to strings.

If the argument to the `as-js` macro isn't a literal (or is a map with non-constant keys), the macro will expand to a call to an `-as-js` protocol fn. When called on a vector, the vector will return its internal array. When called on an ObjMap whose keys are all s convtrings, its internal strobj will be returned. If any of the ObjMap's keys are not strings, then no appropriate js obj exists and a new one will be created, converting keys to strings just like the macro above. HashMaps never contain an appropriate js object, so a new one would be created, again converting keys to strings.

So in the common case of maps whose keys are known at compile time, such as (as-js {:foo "bar" :baz (str "qu" "ux")}), this would at compile time become the js obj literal {"foo": "bar", "baz" cljs.core.str("qu", "ux")}. When the map or vector is not a literal, the least possible copying is done to produce the correct obj or array at runtime.

...why do I have this annoying feeling that I may have done something too compound here?

Some work towards a solution: https://github.com/clojure/clojurescript/compare/37-support-for-js-literals

The macro-based solution I outlined above is unacceptable.

The key issue is that Rich wants the reader to actually create the target type (js array or object) at read time, so special reader syntax is required. I think the syntax was to be #js[1 2 3] for arrays and #js{k v k v} for objects. Then of course there needs to be support in the compiler to generate code that evaluates the array elements and the object values (but not their keys, since the js literal produced can't have expressions for keys).

Does a special reader syntax ask for something readable across other platforms? i.e. #native[]/#native{}

It seems that this would enhance the ability of ClojureScript libraries to be reusable across other platforms. It's easier to get around macro/function differences between platforms, however reader syntax differences would cut off the options for sharing source files between Clojure platforms.

Any update on this issue?

Waiting on whether Clojure becomes a JSON superset.

clojure 1.3.0-alpha-8
clojurescript commit 22a64ff17b343b6c61039fcb66fd9acf34d98522
windows vista
node.js version v0.4.11

I think your shell (bash?) may be treating the [...] portion of that expression as a character class and substituting matches from the file system. I'm not aware of any method for avoiding this other than changing shells to one that won't try to expand the [...].

http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_04_03.html

Perhaps we should change the documentation examples so that they always quote the opts map. Maybe that would help avoid confusion.

NodeJS 0.6.1
MacOSX Lion

I'm not sure how to fix this since the implementation of goog.provide has no meaning in Node.js. As a compromise perhaps we should complain if you try to target node with :whitespace optimizations?

Sure, that would probably be sufficient to point the user to what the problem really is.

Perhaps it's obvious to everyone else that :whitespace doesn't make sense for Node, but it wasn't to me. But I can now deduce that :simple maybe resolves all provide/require into a single file, whereas :whitespace is an intermediate format that is not applicable for Node.

I don't think it's obvious at all and many people have encountered this issue.

Something that seems to work is

#!/usr/bin/nodejs
var _cljsGlobal_ = {};
with (_cljsGlobal_) {
var COMPILED = false;
_cljsGlobal_.goog = {};
goog.global = _cljsGlobal_;
// ... rest of source
}

Does this cause any problems other than forcing e.g. ;module.exports = _cljsGlobal_.mori; in whitespace mode?

Using with is probably not an acceptable solution.

nclosure actually sounds kind of promising! Do we need to do anything more then recommend that people install nclosure if they want to work :whitespace or :none for the optimization level? If the nclosure approach is simple enough we could perhaps duplicate the strategy?

Haha I deleted the comment after I started digging into the code. I'll try to capture my adventure here.

CLJS's node compat layer is built in the opposite direction as nclojure - that is, we provide an externs file for node, and assume interop will happen that way.
nclosure's approach is to hijack the base interactions with goog, and decide to dispatch accordingly to Node or to the Closure lib, but it expects you're writing node-based code. Everything is pushed into shared object off of the node `globals`.

My hypothesis was: I can use the nclosure stuff, but allow ALL dispatching to go to closure (since we have externs file), which very well may call node stuff in the end. The small shim would allow for skirting around the issues described here.

I hacked together the js files and copied the result in to my CLJS-compiled-JS file. All looked good except - the nclosure JS code needs to be inserted into the file before compilation happens. The nclosure stuff redefines core goog interactions, which is why it works. Technically, we could do a preamble hook when we're gathering all the the files together (much like how main-cli-fn is at the tail of all files).

That said, when inserted into the right spot, it prevents the errors.

Have you looked lein cljs-build. Does the extern feature there address the issue?

ClojureScript version used:

commit aa51a01141131736871e791918df63f185155421
Author: David Nolen <dnolen@Davids-MacBook-Pro.local>
Date: Wed Mar 14 20:21:07 2012 -0400

I like the idea, but I normally start the cljs-repl from a clj-repl with

user=> (run-repl-listen 9000 ".lein-cljsbuild-repl")

and then the proposed solution seems to exit both the cljs-repl and the clj-repl as well with a single ctrl-D, which increases the irritation with a small amount...

Sorry, I'm not well versed enough in the IO intricacies to provide an alternative.

In my environment, the deps.js script tag is appended to the page automatically as a side-effect of loading base.js.

base.js (line 613 in my release)

// Allow projects to manage the deps files themselves.
  if (!goog.global.CLOSURE_NO_DEPS) {
    goog.importScript_(goog.basePath + 'deps.js');
  }

It's not my impression that clojure.browser.dom is meant to be a library for general consumption (though I could be wrong). I think it's there to support browser REPL and the samples.

You might be right. It's still a very useful piece of code and makes DOM manipulation much more "clojure-y". I think it should be kept and improved.

As I can see clojure.browser.dom isn't used in clojure.browser.repl. Is it there only for samples?

I found two issues with this patch:

1) I never used the IVar that I declared :-P

2) (apply #'+ (range 100)) throws "Invalid arity: 101" – this is related to http://dev.clojure.org/jira/browse/CLJS-211

I'll look into fixing both. However, we should discuss supporting variable arity protocol methods...

any support for reified vars is a low priority for the foreseeable future.

Reified vars (and binding frames!) are a requirement for a CPS transform to be correct with respect to dynamic bindings.

+1 towards bound-fn and friends. I had an explanation written here but now I see "async Javascript (ie. nearly all Javascript) makes the binding macro effectively useless without bound-fn". Indeed.

bound-fn could also be implemented by setting / resetting bound vars before / after the wrapped fn, similar to binding. We would just need to add tracking of the currently rebound dynamic vars.
That should also be CPS - friendly, no?

I've considered that and would love to see it happen.

But what about:

(def ^:dynamic *foo* 3)
(set! *foo* 4)
(def f (bound-fn [] *foo*))
(set! *foo* 5)
(f)

It looks like removing apply manually eliminates apply-to as expected. Another dead code elimination issue - the global-hierarchy atom. No need to emit this if the user never uses multimethods.

Global hierarchy atom issue has been addressed in master.

To be honest this mostly affects people doing performance work who run the tests against all three JS engines. The tests execute fairly quickly under V8, but they take a long time under JavaScriptCore and SpiderMonkey. I understand that the full tests are desireable - would be nice if there was a way to run :all or :core benchmarks, or something like that.

Thanks for the report. ArrayChunk is an implementation detail - do these conditions actually arise?

I observe that in my JS console, "undefined + 1 => NaN" but "null + 1 => 1". I assume this has something to do with this issue.

Do you have any suggestions on how to make this work without slowing arithmetic down? If not I'm inclined to close this as Won't Fix.

I do not. I haven't had a chance to put a lot of thought into it, though.

I consider this kind of problem to be rather insidious. Null is not a number, and treating it as zero will lead to nasty bugs creeping into people's code.

A historical anecdote: the C function "int atoi(char* s)" takes a string and returns the number it represents. However, if the string can't be converted, it returns zero (which could also be a valid result for e.g. the string "0"). Technically, it's possible to distinguish "0 meaning error" and "0 meaning 0" by taking additional steps after the function call, but in practice people forget to do this. Thus, atoi is universally a disaster. I have literally seen the lights go off in a warehouse due to atoi's poor design (I used to work in building control).

Treating null as zero will result in similar problems. Someone forgets to check the result of a computation, it's null, and the program silently continues as if nothing is wrong. Hello, data corruption.

So I seriously urge you to not close this as Won't Fix, even if a performant solution is not yet obvious. IMHO it's worth more thought.

Closing as Won't Fix doesn't mean we don't care, but this issue is simply a symptom of something much larger - punting on numerics. A ticket is the wrong place for this discussion as it has many nuances. It should be a part of a larger design for ClojureScript numerics. Without that larger discussion this ticket is likely to get stuck in limbo.

Fair enough! I thought Won't Fix had stronger implications than that. Do you know if there's already a design doc that addresses numerics? Or should I start one?

One place that this has burned me, that may warrant a separate card is

(update-in some-map [:foo :bar] inc)

@Fogus: Huh, that is the exact same use-case that burned me – I was using update-in/inc on a nested map. The default value for my [:foo :bar] was, in fact, supposed to be zero, so it silently worked for me. But when I moved that code from the client in my webapp (ClojureScript) to the server (Clojure), I found out that my original implementation was wonky.

It doesn't seem to me that you could do that safely without fnil + 0. I too hate JS's silent failures around numerics. Been hoping someone would tackle this challenge with gusto.

@David Nolen: Yeah, fnil would do the job. In my case, I was calling update-in on what I thought was an initialized map, but it was actually nil. update-in initialized each level of nesting with an empty map, and then inc was called on nil. My fix was simply to initialize the nested maps like I meant to.

David,
That was ultimately the solution, so I suppose we need to start advocating this pattern so that others might avoid the same fate.

Can you identify precisely where a LazySeq is getting emitted here? A LazySeq is not literal so this seems like a bug in the macro to me. I could be wrong. Thanks!

The lazy seq seems to be introduced on line 7, the '~syms form

`(let [mappings# (into {} (map-indexed #(identity [%2 %1]) '~syms))

Clojure allows lazy-seqs to be embedded: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L4538

As an aside: The relevant protocol is not literality, but the print-dup multimethod. Do / Should we have print-dup in CLJS?

Attached patch 0001 doesn't add a case for LazySeq, but folds two cases for PersistentList and Cons into one for ISeq.

All test pass

Not sure I like the names oget/set. How about obj-get obj-set?

fine by me, added a new patch !

The patches are identical.

Why is this needed?

It's a bit ugly, not to mention asking for clashes to implement apply instead of cljs$lang$applyTo.

So the expectation here is having

(apply js/String [1])

result in "1"?

Since js/String is a built-in function object (defmethod emit :fn ...) will not produce cljs$lang$applyTo magic.

So is this sg for the compiler to do in a bootstrap step or rather a (set! String.prototype.cljs$lang$applyTo ...) hack?

Lowering the priority on this ticket. If have we have real Keywords & Symbols we don't need to bother with this.

Patch hooks up the tests into the test suite.

If you want to see the provide error, delete out before compiling.

If you want to see the failing assertion from the original test, compile a second time.

In order to better understand tickets it best not to complect different issues If there's a problem not addressed by the patch please mention that in another ticket (and feel to reference that one here).

I assume the patch fixes one thing, but reveals an unresolved issue, am I correct?

You're right, the ordering problem could be a different ticket. Sorry for that.

To clarify, there are three issues at play:

1) Part of the testsuite not executed (fixed by the patch)
2) The part that is now executed fails, didn't have time this morning to find out the original intention of Michał, can probably do tomorrow, if he doesn't pick it up.
3) The compilate is different depending on whether the .js file is cached in out/. This might require some deeper investigation.

The reason I decided to roll it into one ticket is that only addressing one of 2) and 3) leaves the test suite failing. I almost wanted to reopen CLJS-312, but decided against it, since it's water under the bridge.

I fixed some dependency ordering issue in another patch, would be nice to know if the ordering issues are addressed. What part of this ticket is still relevant? This is why tickets that only address one thing at a time are nice

Seems like the underlying issue is referring to a var while it is being defined. This form exhibits the same issue:

(def f [x] (aget f "prototype"))

The more I study this, the more I'm convinced that cljs-warn-on-undeclared is broken badly. Recursive functions (not using recur) generate this warning. As do certain parameters, locals, or other variable references that are actually defined. The issue seems to stem from a conflation between symbol definition and resolution. resolve-var, resolve-existing-var, and (parse 'def ...) are all tangled in a crazy mutually recursive way. A lot of that stems from a recursive analyze call to yield init-expr and ultimately fn-var? inside of the def parse code.

Your first comment isn't valid code so I'm not sure what you mean. When I enter it correctly into the REPL I get no warnings. I also get no warnings when defining at a protocol at the REPL. Do you have a specific minimal CLJS project that exhibits the issue?

This is a known issue which will have to wait for if and when Keywords and Symbols become proper types in ClojureScript.

Extending js/Object is not recommended, if you actually need to add functionality to the base JS native types the convention is different from Clojure: default instead of Object, string instead of js/String. Please refer to core.cljs if you want more examples.

Thanks for the pointer about default and string, I didn't know about that.

I reported the issue at the demand of bbloom. It does seem to be difficult to address without taking a (major) performance hit unfortunately.

Linux, lein-cljsbuild

I didn't realize JIRA treats asterisks as markup, so just for clarification: the characters that produce the defect are slash asterisk, ie JavaScript's block comment closing syntax.

Do you have a suggested fix for this?

Mac OS X (10.7), java version "1.6.0_37", leiningen 2 preview 10, cljsbuild 0.2.9.
clojure/clojurescript master 01 December 2012 - 5ac1503

code tags

This one is a bit annoying. We should probably use namespaced keywords internally.

^not-native support is already in master and does deliver performance benefits in the cases where native types need not be considered.