(ns respo.test.html
  (:require-macros [respo.macros :refer [html
                                         head
                                         title
                                         script
                                         style
                                         meta'
                                         div
                                         link
                                         body]])
  (:require [cljs.test :refer-macros [deftest is testing run-tests]]
            [respo.test.comp.todolist :refer [comp-todolist]]
            [respo.render.html :refer [make-string]]))

just noticed in shadow-cljs :refer-macros works...

I thought we have to use :require-macros always 😱

it seems :refer-macros is actually more robust.

you shouldn’t use this syntax at all

I gave you this example before https://github.com/thheller/shadow-cljs-examples/tree/master/macros

ALWAYS do this … it just makes things unnecessary complicated otherwise

I’ve been looking at setting up an auto-generated changelog (from commit messages) for maria, to be performed on release. something like that might be nice for shadow-cljs too

yeah … I’m not the greatest at maintaining that

but not great at writing commit messages either 🙂

yeah mine can be much improved too. but makes it feel more worthwhile when the format can produce a changelog without any extra work

did you end up learning anything about thi.ng.math.macros namespace? i wonder if his libs may actually not be that useful unless they are modified to be supported by the self-host compiler directly. (but unsure if that is related to why that namespace can’t be found, seems like a different thing)

the only problem i can see with thi.ng.geom.core.macros.vector is the :refer :all, that would be an easy PR if not for the org format

hehe yeah

afaict thatst he only issue

is the math.macros error related to that? it seems like a resolution error

maybe the :exclude option is actively excluding the transitive macro deps of the entry instead of just ignoring them? subtle difference..

making a little test case to figure that one out.

seems it may have nothing to do with :exclude

what was the problem again?

uploaded with a test case. if you uncomment this: https://github.com/mhuebert/shadow-bootstrap-example/blob/master/src/shadow_eval/user.cljs#L21

macros namespace a tries to require macros namespace b, should this work?

[:bootstrap] Build failure:
The required namespace "shadow-eval.b" is not available, it was required by "shadow_eval/a$macros.cljc".

right

it must be a .cljc file currently

but that entire process is busted

yeah transitive deps in macros are a problem

renaming the dep to .cljc does work

really? it does compile it as shadow-eval.b$macros?

I assume it will be shadow-eval.b after which is incorrect I think

I really couldn’t figure this out from reading the analyzer

now i have a.clj and b.cljc and it builds

I think that might be incorrect behaviour though, it should find the b.clj when compiling as a macro

but really I couldn’t find any documentation on how this is supposed to be resolved

it would make intuitive sense if the same resolution algo that was used to find a was used to find b

since they are both macros lookups

move a.clj to a.cljc 😉

in my own code, sure 😉

need to check how lumo or planck would handle such a case

or cljs.core for that matter

https://groups.google.com/d/msg/clojurescript/ya0-38K4WVU/175Wy8B8BAAJ

For bootstrapped ClojureScript you could have any of these arrangements:

Runtime Code   Macro Code
foo.cljs              foo.clj
foo.cljs              foo.cljc
foo.cljc              foo.clj

thats not about transitive deps?

hmm

i would guess it searches with [clj, cljc] preference order but not sure

I do that for macros yes

but not for things the macros themselves require

the problem is if you say (:require [thing.b]) in a macro

you might actually mean thing.b as in a normal namespaces that just contains functions and not macros

so if you have a thing/b.cljs that would work

but if you have include it as a macro it ends up as thing.b$macros

i guess that would break compatibility with JVM clojurescript

where things are divided by “compilation stage”

I don’t know .. AFAICT this behaviour is undefined

for the same reason we can’t intermix defmacro into cljs files without breaking compatibility, we also couldn’t use any other .cljs files in macro compilation stage

if you can confirm that (:require [thing.b]) in a macro should cause thing/b.clj to be compiled as thing.b$macro I can add that

but I’m not convinced that that would be correct behaviour?

I never used any self hosted stuff

can you maybe confirm in lumo or so?

the shadow-bootstrap-example with b.clj

sigh

you are right

🙂. a.cljs :require-macros b.cljc requires c.clj, fail

a.cljs requires b.clj requires c.clj, fail

what did you try?

https://github.com/mhuebert/shadow-bootstrap-example/tree/master/macro-require-test

from that dir, planck -i test/a.cljs

and then mixing and matching b and c file extensions

yeah the problem is that we can’t tell what is what

IMO the moment it was decided to read macros written in ClojureScript (not Clojure) from .clj files, programming became a kind of spiritually elevated art form

full of mystery and awe.

hehe it totally makes sense though 🙂

for compatibility reasons

or other reasons?

if I try to explain it I’ll butcher every correct lisp term for this

by splitting it the compiled code does not itself depend on the compiler or the macros

so the compiled code is drastically smaller by sacrificing runtime eval

I think I get that part. but now in addition to using java-based clojure to write clojurescript macros, we also use JS-based clojure to write clojurescript macros with the same file extension… it would make more sense to me if tools like Planck did not support loading macros from .clj files at all, because planck does not support JVM clojure

with planck you can write macros in .clj files that read from js/window or whatever

well, planck doesn’t have js/window.

but you can use js stuff.

I can’t really say anything about self-hosted. I never use it and don’t know the particular details.

but I do think its important to keep compatibility to the JVM compiler

having self-host-only CLJS libs doesn’t help the community overall

well … JVM only CLJS libs isn’t exactly great either

but those could maybe be fixed to also work in self-host

I really don’t know about the state of self-host and how “rushed” it was

maybe it would actually be simple if just a few things were changed

i think compilation passes got intertwined with language choice, and now we have a system where “.clj” and “.cljc” file extensions can no longer be taken at face value

well, .cljc can

i really don’t know how both concerns can be adequately handled

the problem is that you need to split at every point

you can just create .clj with a .cljc file that :require-macros itself

that way there is no ambiguity whether you wanted to include a macro or just code

from that thread > Why can’t bootstrapped load this file with “macros: false” and ignore all defmacro to load only functions and then load it with “macros: true” and take only defmacro into account?

but that is annoying for the CLJ side

good question

I do not know

would that make sense? we would still have the problem that functions could not use macros defined in the same namespace. but that seems like a reasonable limitation

well technically you need the macros before the code

oh, the rabbit hole 🙂. so for this library it looks like he needs to rename that file to .cljc, no real way around it

(defmacro deffoo [& args])

(deffoo thing
  1 2 3)

you cannot compile this

actually that would work in clojure

(defmacro deffoo [& args])

(deffoo thing
  (js/document.getElementById "foo"))

you can’t compile this 🙂

AFAICT the is just not self-host compatible

exactly. but probably not a lot of changes required for it to be.

i didn’t realize how this macro resolution worked

*macro dependency resolution

problem is I really cannot tell how easy the fix would be because of the org-mode

I do not understand that at all 🙂

me neither

also if the macros only exist because of some perf opts

but from looking at the clj* source files (easy to follow with cursive) it doesn’t look complicated

some of the perf opts might be solved a different way

do you have a preference for whether i mention issues here vs. creating github issues?

looks wonderful... is it valid syntax in shadow-cljs, or in ClojureScript itself?

you can use :refer directly yes, valid in all CLJS

when I was reading guide on clojurescript Wiki, I thought I should use :require-macros, didn't even noticed there was a :refer-macros.

you should not use either ever

the only place you should be using :require-macros is in a file of the same name basically requireing itself

(ns app.lib
  (:require-macros [app.lib]))

like this

everything that uses app.lib then only uses :refer

going to migrate many of my projects...