babashka-sci-dev 2022-03-06

can sci take some code, expand all the macros in it, but not "run" it? As in only the evaluations needed to expand the macros are done, and then you have access to the AST before execution...

or is the macroexpansion not a seperate step, and is tied up with evaluation?

@retrogradeorbit I guess you could do something like this:

user=> (sci/eval-string "(defmacro dude [x] `[~x ~x]) (clojure.walk/macroexpand-all '(dude 1))")
[1 1]

What problem are you trying to solve?

Im hatching a massive hack

not even sure it will work...

Ive been experimenting with different ways to generate wasm

but I don't like them

last time I used wasm I used C++ and C++ is never enjoyable.

@retrogradeorbit What problem are you trying to solve?

(I'll just keep asking the question ;))

Oh I see now, a C generator

Sorry, I didn't read the title so I couldn't tell if this was C or JavaScript

It reminds me of this: https://github.com/dundalek/liz It parses Clojure (using edamame) and generates zig code

👀 1

Last time I was making wasm I was using C++ and then I got to the point where I wanted to implement something like this

a moving 3x3 window over a 2D array, outputing a central value based on the pattern

and this is quite straight forwards with pattern matching

but C++ doesnt have that

and it quickly descended into hell

and my C++ friend when I asked him just said, "nah you're stuffed. write it all out by hand"

my kingdom for a proper macro system

If I can generate C, I can implement a pattern matcher as a macro

I will check out this liz... see how its doing its magic

why not generate the code once using a macro or whatever templating thing and then inline that code

seems like a lower hanging fruit than implementing a Clojure -> C transpiler

yeah so thats an option... but then it gets unwieldy

as you have half C++ files, half generated snippets.. that get mashed together

implementing a Clojure -> C transpiler does sound like madness, yes

this is effectively what liz is, transpiling to C shouldn't be much harder perhaps

would it even be possible for have core.match emit the C code

yeah, the aim is to not implement a lisp in C

just to write C using s-exp

and then, some macros over the top

that is effectively what liz is ;)

Im gonna read some liz source

you know, its not crazy huge

its quite small

you know what, I should try using liz

see what its like to use liz to generate wasm

yeah, let me know how that goes :)

Maybe using Common Lisp for this would also make sense, given that you can get quite close performance to C using it and there may be WASM bindings for it

but generating C would be most optimal I guess

one approach is to build up wasm from the ground up. wasm has a format wast that is s-expr. It's spec is very lispy already. You would deal directly in the wasm types and map clj straight to wasm ast. This is somewhat like helins/wasm.cljc does

the other is to transpile to another supported lang, and then compile that down to wasm

the first is probably more elegant, but the advantage of the second is the existing toolchains (like emscripten) work magic on the C code

you've got your advanced optimiser already done, and whats really great is you can bring across your stdlib malloc/free heap allocator into the wasm code to manage the wasm "linear memory"

ie, you can malloc and free in your wasm code, then access that data from the JS side. Its shared.

and if you decompile the C generated wasm, you can see the entire libc heap allocator expressed inside the wasm

so theres all this work that just kind of comes for free with transpiling first

zig looks good though!

and if liz supports me writing macros... that can solve my problem

liz doesn't support macros I think :/

at one point liz listed SCI as an option to execute macros during transpilation, not sure if Jakub explored that option, but don't see it mentioned anymore