just thinking of ways to enable good tree shaking. otherwise you have to include all of the transducer logic whenever you use map, even if you never use it as a transducer

hmm, good point!

how much extra is it though

I haven't done it yet. been thinking about how I would want to implement transducers

there's the transducer-js protocol that we could use, which is different than the way that Clojure does it with different function arities

I found the usage of the two-arity for map, filter, etc pretty error-prone. I was happy that I finally added linting to clj-kondo to find problems like this: (first (map identity))

makes sense

I've argued that different functions: mapping, filtering etc would have been better for adding the transducer logic

in JVM Clojure I mean

But a different namespace would have the same effect (+ we don't have to teach clj-kondo about new core vars)

(ns foo (:require [clava.transducers :as t]))
(t/into #{} (t/map identity) [1 2 3])

if we didn't have the 2-arity version take a collection, then you could have it be composition. so you could do something like:

(->> (map inc) (filter even?) (take 5))

yeah that's exactly what I was thinking re: the namespace

I suppose the ->> is only one character less than comp but for some reason it reads better to me

probably not worth the confusion

Is that the same as (t/comp (map inc) (filter even? (take 5))?

yeah exactly

yeah, let's start with the least surprising stuff that is most similar to CLJS

and we can always add that 3-arity later

ok, I'm with you on the extra namespace now

sure, let's try it

btw, I don't think we have filter yet :)

I'm going to create some issues

filter / remove / mapcat / etc. might be good first issues for people to take on

agreed!

shall I make an issue for each one?

sounds good yes

I'm also going to make an issue for transducers with the separate ns context, and start sketching out the internal design for them

this might be a good test for the protocol changes

btw, I've sent you an invitation for the github org, I wonder if you got it

I did get it, it's in my inbox. thanks for reminding me

is the html auto generated somehow?

yes, using npm run build

I suspect that you can put the base url somewhere in a config file, but I don't know which

https://vitejs.dev/guide/build.html#public-base-path

aaah!

yeah, was about to link to https://vitejs.dev/guide/static-deploy.html#github-pages which says to set the base property to the repo

never used Vite before. seems neat

yep, npx vite build --base=/clava/solidjs/ seems to do the trick

Oh wait, transducers.cljs ?

I was thinking about writing transducers in clava to force me to get protocols to work right 🙂

I think what you should do in this case is just check in the compiled file for distribution

gotcha

Btw, I'd be fine writing it all in JS to ensure the best perf and and smallest code output

I'd be fine with it too, but I think it would also be cool to figure out how to have protocols be small and performant

i guess it depends on how itchy we are to have transducers

at the end of the day, the way that clojure does transducers using different arity produces way less code than using prototype dispatch

haven't done any benchmarks yet

I'll open a draft PR for protocols this AM

Thanks, my issue I was using yarn instead of npm and something seemed to have cached

The bb dev task deletes some analysis file which will evict the cache of core functions

@UPH6EL9DH This is not in scope of clava, but you could use clava's stdlib from ClojureScript

oh ok nice to know that may be possible, thanks

or you can use clava's stdlib from cherry even