@U04V70XH6 @U0ETXRFEW spam?

Hey @U04V15CAJ let me know if the group is for something else. I an delete it 😊

well, at least you're not a bot, that counts for something :)

Oh no. I am a final year undergrad student from India. LinkedIn: https://www.linkedin.com/in/arunima-chaudhuri/ Twitter: https://twitter.com/arunimastwt GitHub: https://github.com/tinniaru3005

Cool. If you want to do some post like this, giving some personal introduction may help people (like me) understanding why you are posting this, instead of just being a bot posting spam. Thanks :)

Okay sure

I mean in the original message (so everyone can read it)

those seem like kind of a brainstorming list, and then once you look at the cases in detail, the requirements to make it work are very expensive, or a lot of common ways that programs are used makes them less useful, or there are adhoc solutions that are good enough

like, it depends, but often the reason expensive functions are expensive is because their inputs are large, so you are going to keep around large inputs, and spend the time to compare them, to determine if you should be caching results somewhere for re-use

https://github.com/jpmonettas/flow-storm-debugger does some similar things

adhoc wise, I've used something like https://gist.github.com/hiredman/a2630ea6153d06840a2723d5b2c9698c to open a repl over tap in places where I wanted to inspect and poke at things in the middle of a running program

I once had a similar idea to track the input size of arguments to a function operating on sequences to try and calculate the empirically observed computational complexity of the function. I agree that it would be a lot of work to implement, but doing so may help provide tools to make theoretical CS concepts more tangible to people by surfacing them in the context of a running program.

I'm working with that kind of stuff in #C03KZ3XT0CF. Currently working on deriving fn types (args and return) from execution. So I'm basically instrumenting an entire codebase, then running the tests or whatever, and collecting types information for generating documentation that can be browsed.

here you can see an unreleased experiment of this

there I instrumented the entire ClojureScript compiler codebase, then run a compilation of a simple program to exercise the codebase, and generated fn documentation. You can see the documentation shows types, and also examples calls

here you can see that cljs.util/file? can accept multiple things as input

there was a talk I saw a video of recently at some haskell event, where the speaker was comparing haskell tooling with racket tooling, and observing that the racket tooling all worked together better because it started from a place of all being resident in memory together and being functions that you call at the repl, so there is a lot of shared context, where the haskell tooling was all kind of batch mode and sharing stuff between the tools is harder

https://www.youtube.com/watch?v=H0ATppFmt2o

That's kind of another axis, static/dynamic then batch compilation/image like

I think the original article up there kind of conflates the two axis

Which a lot of tooling work does as well

Static analysis tools really also want batch/whole program compilation

You see some of that same pressure towards static analysis in clojure tooling, relying on loading files from disk rather than interacting with a running clojure process

I'm hoping that the "Clojure codebase in a Datalog DB" approach that #C03FF6W62A3 is trying to develop can become that kind of common substrate for different tools that are aware of both runtime information and information derived from the source code.

Interesting he doesn't mention Common Lisp, where there's a lot of prior art: • condition system/restarts • CLOS (and various things built in it e.g. AspectL, ContextL) this is the stuff I miss most from CL in Clojure and I agree that an image-based compilation model is a key part of this

#C8145Q6VD