sci

https://github.com/babashka/SCI - also see #babashka and #nbb
borkdude 2020-09-03T09:03:56.001800Z

@jeroenvandijk I think I may have a nice solution for the macro rewriting problem: https://github.com/borkdude/sci/issues/397

2020-09-03T10:30:21.002100Z

yeah I think that would work and be user friendly when using the backtick. The only thing would be that the namespace symbol of the implementation would end up in Sci context somewhere. Not sure if that is a real issue

borkdude 2020-09-03T10:31:13.002300Z

Why would that be an issue?

2020-09-03T10:31:43.002500Z

maybe if you would like to hide the underlying namespace structure to the Sci user

2020-09-03T10:32:10.002700Z

thinking out loud here, not even sure what you could do with that

borkdude 2020-09-03T10:32:19.002900Z

If you would want to do that, then you could just not use this :)

2020-09-03T10:32:25.003100Z

good point

2020-09-03T10:32:45.003300Z

Sounds like a good solution

borkdude 2020-09-03T10:33:36.003500Z

The macros that will work with this are still only those who don't cause side effects at compile time and probably also not use &env

borkdude 2020-09-03T10:33:42.003700Z

But that's most of the macros anyway

borkdude 2020-09-03T10:34:44.003900Z

Another (more costly, but maybe not significant) solution would be to make sci postwalk the macroexpansion and replace the external namespaces with inner ones

borkdude 2020-09-03T10:35:10.004100Z

Then the macro-expansion will also look more pretty

2020-09-03T10:37:04.004400Z

In a repl environment and using macroexpand the last option would be the least surprising as it doesn’t leak implementation details. But the performance concern is also a valid one

borkdude 2020-09-03T10:37:30.004600Z

Maybe it's not that significant though, since this happens only once, not in a loop or anything

2020-09-03T10:38:06.004800Z

would one or the other matter for the output of stacktraces?

borkdude 2020-09-03T10:46:11.005Z

Good point. Maybe, I have to test this. I'll write it down in the issue.

👍 1