ClojureScript: smaller Clojure libraries that conform to ClojureScript compiled directly into JavaScript

71 views
Skip to first unread message

Alen Ribic

unread,
Sep 1, 2011, 4:32:10 AM9/1/11
to Clojure Dev
Are there any currently thoughts around how perhaps smaller Clojure
libraries that conform to ClojureScript could be compiled directly
into JavaScript?
At the moment, on unix-based systems, one could create symbolic links
from .clj to .cljs files.

The closure/cljs-dependencies that is invoked during the `build`
process hardcodes the .cljs extension.
Could one perhaps fallback on .clj extension if a specific .cljs
dependency file is not found? I haven't thought through all the
implications but one of those could well be that a .clj file would be
located with the same name that was actually not meant to be the
intendent dependency.

-Alen

Chouser

unread,
Sep 1, 2011, 9:31:20 AM9/1/11
to cloju...@googlegroups.com

I think these are interesting questions, particularly for the case of
some library maintainer specifically choosing to support both
languages. Conditional compilation syntax will help, but there are
still issues to resolve around filenames (as you point out) and
perhaps classpaths. None of the solutions I've heard or thought of
are particularly appealing to me.

What about using a common filename extension for both languages (.clj)
and then have some sort of header inside the file indicate what set of
languages this file supports?

(ns clojure.data.finger-tree
(:languages #{:clj :cljs}))

--Chouser

Laurent PETIT

unread,
Sep 1, 2011, 11:08:30 AM9/1/11
to cloju...@googlegroups.com


2011/9/1 Chouser <cho...@gmail.com>

Hello,

What about havin the same file extension, and let the "classpath" (extended notion, not just java, but also what serves as "classpath" for compiling cljs files) resolve the right files.

So a lib which can work both for clojure & clojurescript just has to be placed on the classpath or on the clojurescript compiler deps ...
 

--Chouser

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.


Alen Ribic

unread,
Sep 6, 2011, 6:48:52 AM9/6/11
to Clojure Dev

On Sep 1, 3:31 pm, Chouser <chou...@gmail.com> wrote:
Firstly, I'd like to thank you for the suggestion and provide some
comment.
Besides the obvious benefits of the :languages option approach, here
are some noteworthy disadvantages:

* Developer cannot, at a glance, identify what compiler the file is
targeted for as it has the common file extension.
* When giving the compiler a source directory instead of a source
file, the compiler will have to filter, potentially a large set of,
source files that support the target language.
* And finally, Clojure core `ns` macro would most probably have to be
changed in order to interpret the addition of the :langauges option

I have spent some time contemplating other possible solutions and I
believe that I have one that might be worth perusing.

Action:
* Keep extensions as is (Clojure: clj, ClojureScript: cljs).
* At compile time, create temporary .cljs files for each dependency,
in a temp directory, for whom a .cljs source file is not found but
a .clj source file exists. (This is a compile time operation, let the
compiler delegate this sort of work as it already does when
renaming .cljs files to .js)

Benefits with this approach are as follows:
* Least impact on the existing ClojureScript codebase
* No impact on Clojure codebase
* Developer can identify, at a glance, what compiler the file is
targeted for by the extension.
* We already generate `target directory` (out/) that contains files
that are potentially temporary at least in case of advanced
optimization. So we don't really deter form this pattern.

Disadvantages:
* No real way of communicating the target languages supported by
source file. (Perhaps metadata entry would be sufficient: (ns
^{:doc ... :author ... :languages #{:clj :cljs}})
* Still faced with the problem that a .clj source file maybe picked as
a dependency when it was not meant to be one. (Maybe the metadata
entry suggestion above for `:languages` above could server as a *hint*
to the compiler?)


-Alen


>
> --Chouser

Alen Ribic

unread,
Sep 6, 2011, 8:29:40 AM9/6/11
to Clojure Dev
To elaborate with an example:

my/lib.clj
----------------

(ns
^{:author alen
:languages #{:clj :cljs}
:doc "simple library"}
my.lib)

(defn sqaure [n]
(* n n))

my/core.cljs
----------------

(ns my.core
(:require [my.lib :as l]))

(.log js/console (l/square 3))


ClojureScript compiler will analyse/emit my/core.cljs and it would
look for the cljs dependencies.
It wont find my/iib.cljs so it will look for my/lib.clj and it can
check for metadata of `ns` for :languages entry to see if there is a
hint for :cljs language support. If so, it will create a temp file for
lib.clj with a .cljs extension and then perform the analyse/emit as
done on my/core.cljs.
As cleanup step, the compile could instruct a cleanup process of the
lib.cljs file.

Something along these lines. Any comments or suggestions welcome.

-Alen
Reply all
Reply to author
Forward
0 new messages