5 ms·
Cthulhu.jl – show type-inferred Julia code
- zeckalpha 3y agoHoping this doesn't reopen "Julia is dependent typed" debate
- xgdgsc 3y agoLatest release adds integrate with VSCode that shows inferred types inline.
- sdfghswe 3y agoWhat does this show that @code_warntype doesn't?
- borodi 3y agoIt tries to show you the type information on the source itself, instead of on the IR.
- adgjlsfhk1 3y agoA few things. For me the most important is that it lets you easily explore the whole compile time call graph. (i.e if `h(x)=x*x` and `f(x)=h(x)`, Cthulhu will let you easily switch from looking at `f` to looking at `h` (think of it like compile time debugging). Cthulhu also has the equivalent of @code_llvm and @code_native.
- celrod 3y agoThis is extremely helpful when hunting for type instabilities. `@code_warntype` and `Cthulhu.@descend` can both show `SomePackage.foo` was inferred as `Any`. But why? Cthulhu lets you immediately descend, and see that it's because it calls `SomeOtherPackage.bar`, so you descend, and see... Five or ten calls in, you finally see a problem you can fix that can motivate a PR. This is fast to do with with `Cthulhu`. Descending is as easy as pressing `[enter]`, instead of requiring you to construct all the arguments and descend. Exploring the call graph while doing this gives you some overview of what the code is doing, and you can always look for the initial cause of propagating instabilities, instead of wading through a ton of JET output (but JET is also great).
- andyferris 3y agoThis sounds great! Is this built into the existing VSCode extension, or as another extension you need to install?
- xgdgsc 3y agoJust update to latest julia extension and use Cthulhu inside the extension started REPL.
- tmvphil 3y agoThese tools are a great improvement, but honestly I find working with this aspect of Julia to be super frustrating. External tools feels like a poor substitute for a type system where this kind of information was obvious from the code.
- vchuravy 3y agoYeah in the end this the difference between dynamical and static typing. I enjoy https://tratt.net/laurie/research/pubs/html/tratt__dynamically_typed_languages/ https://tratt.net/laurie/research/pubs/html/tratt__dynamical... as a discussion of dynamic typing.
- ssivark 3y agoAre you talking about static typing? If so, that sounds fundamentally incompatible with the basic worldview behind Julia — that you want to delay binding/dispatch till runtime, and leverage multiple dispatch, for high composability & code reuse. I wonder how capable the ahead-of-time compiler would be, if you have not just the library, but can also provide the “inputs” in your “script” (that it can specialize on).
- skybrian 3y agoThe question I have is whether Julia-style multiple dispatch would be practical in a statically typed language?
- deleted 3y ago[deleted]
- cmrdporcupine 3y agoMultiple dispatch is a kind of runtime type resolution. Static/compile-time function overloading based on types is a thing, but is fairly banal... common in C++, but mostly forbidden in Rust, but it doesn't resolve on vtables, so doesn't give you the same kind of polymorphism as what you'd get in Dylan/Julia/CLOS/Cecil, etc. This looks like a good series of blog posts on this topic: https://eli.thegreenplace.net/tag/multiple-dispatch https://eli.thegreenplace.net/tag/multiple-dispatch Myself, I was excited to work in a language with multiple dispatch at first, but once I spent some time working full-time in Julia the sheen wore off. It could be Julia's take on it, but I really don't like the kind of ... semantic overloading ... and duck typing that can happen all over the place. Programs can become very hard to reason about.
- vchuravy 3y agoOne of the authors here, happy to answer questions.
- contravariant 3y agoYou had a perfectly good opportunity to call a function madness and then descend into it, why didn't you?
- philipov 3y agoThis could be a feature request.
- vchuravy 3y agoAh but what defines madness? For me it's innocuous functions that have surprising/wild behavior due to type inference disagreeing with me. Most of the time I am the one wrong.
- sundarurfriend 3y agoChanging the `function foo()` in the "Usage: descend" section to `function madness()` sounds like a pretty good/funny idea. @descend madness() would be a pretty good reference to the original text! Positive: it would also let people know at a glance that things like `rand() > 0.5 ? Int64 : Float64` are indeed madness. Potential negative: some people may not consider it super DEI-friendly? As a neurodivergent person, I'd just find it to be just a lovely reference though.
- drt5b7j 3y ago[flagged]
- Cthulhu_ 3y agoPh'nglui mwgl'nafh Cthulhu R'lyeh wgah'nagl fhtagn?
- ivirshup 3y agoLove this tool. Invaluable for figuring out what code actually got called after complicated dispatch.
- hnwpy 3y agoIt looks handy to help you debug type inference problems by recursively displaying the type inference code until you find the exact location where the inference failed, went wrong, or had an accident. This feature is very useful for my current development, thanks to the author!