ClojureScript

Details

Type:
Enhancement

Status:
Closed

Priority:
Major

Resolution:
Completed

Affects Version/s:
None

Fix Version/s:
None

Component/s:
None

Labels:

None

Description

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.

Thomas Heller
added a comment - 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
(include-macros))
or
(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?

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.

David Nolen
added a comment - 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.

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.

Thomas Heller
added a comment - 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.