<< Back to previous view

[CLJS-721] support :include-macros true modifier in :require Created: 09/Dec/13  Updated: 10/Dec/13  Resolved: 10/Dec/13

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


This modifier will additionally trigger a load of a Clojure file containing macros that matches the namespace. This would allow libraries to adopt cljs.core's inlining macro style without needing both a :require-macros and :require.

The following should be supported:

(ns foo.bar
  (:require [baz.woz :as woz :include-macros true))
(ns foo.bar
  (:require [baz.woz :as woz :refer [one] :refer-macros [two]))

I think the following is probably a bridge too far:

(ns foo.bar
  (:use [baz.woz :only [one] :include-macros [two]))

Comment by Jozef Wagner [ 10/Dec/13 4:15 AM ]

Same goal as CLJS-563

Comment by David Nolen [ 10/Dec/13 9:20 AM ]

Thanks I've closed CLJS-563. The required explicit modifier here avoids unpleasant surprises.

Comment by Jozef Wagner [ 10/Dec/13 11:32 AM ]

What will be the semantics if only the .clj file is present on classpath?

Comment by David Nolen [ 10/Dec/13 11:36 AM ]

An error.

Comment by Thomas Heller [ 10/Dec/13 12:35 PM ]

I assume you plan something like this (if not ignore me):

(ns wants-to-use-macros
(:require [has-macros :as m :include-macros true])

Could we instead do something like

(ns has-macros


(ns ^:include-macros has-macros)

Seems to me it would be more helpful to write the include-macros once instead of every time the ns is used?

Comment by David Nolen [ 10/Dec/13 1:08 PM ]

Further complicating ns form parsing via metadata and custom forms is not on the table. I'm not particularly interested in convenience beyond removing two requires for two files that are logically related.

Comment by Thomas Heller [ 10/Dec/13 3:38 PM ]

Sorry to be blunt but I don't see where its more complicated to parse one extra form in the ns vs. parsing a far more complicated argument list in (:require) as you put in your example. Also trading one inconvenience (:require-macros) for another (:refer-macros, :include-macros) is only a small improvement.

IMHO its totally inconvenient that I a) have to remember which namespaces provide macros b) which defs were actually macros (assuming :refer). Assuming someone writes a library which provides some macros, shouldn't the library author worry about including the correct macros and let me just use it, just as in Clojure?

But I assume my proposal is more complex since you can't analyze a namespace on its own anymore (since any referred var may be a macro), which is a totally valid argument not to do it.

Comment by David Nolen [ 10/Dec/13 4:01 PM ]

Yes your suggestion has other implications. What I'm suggesting will desugar into existing supported functionality.

Comment by David Nolen [ 10/Dec/13 5:30 PM ]

fixed, http://github.com/clojure/clojurescript/commit/de6ee41b3b0e26020e01b409f97e513bce87456d

Generated at Tue Jan 24 05:30:03 CST 2017 using JIRA 4.4#649-r158309.