lean4 VS typeshed

Nice read! Rust has pushed, and will continue to push, the limits of practical, bare metal, memory safe languages. And it's interesting to think about what's next, maybe eventually there will be some form of practical theorem proving "for the masses". Lean 4 looks great and has potential, but it's still mostly a language for mathematicians. There has been some research on AI constructed proofs, which could be the best of both worlds because then the type checker can verify that the AI generated code/proof is indeed correct. Tools like Kani are also a step forward in program correctness.

Yeah, I believe they said intend for it to be used as a general purpose programming language. I used it to complete Advent of Code last year.

There are some really interesting features for general purpose programming in there. For example: you can code updates to arrays in a functional style (change a value, get a new array back), but if the refcount is 1, it updates in place. This works for inductive types and structures, too. So I was able to efficiently use C-style arrays (O(1) update/lookup) while writing functional code. (paper: https://arxiv.org/abs/1908.05647 )

Another interesting feature is that the "do" blocks include mutable variables and for loops (with continue / break / return), that gets compiled down to monad operations. (paper: https://dl.acm.org/doi/10.1145/3547640 )

And I'm impressed that you can add to the syntax of the language, in the same way that the language is implemented, and then use that syntax in the next line of code. (paper: https://lmcs.episciences.org/9362/pdf ). There is an example in the source repository that adds and then uses a JSX-like syntax. (https://github.com/leanprover/lean4/blob/master/tests/playgr... )

My latest inspiration to use code to a) replace my video editor, b) learn the basics of EDM production and c) understand a few topics in higher maths. This might sound very strange given there are specialised tools for these jobs. There's iMovie / Adobe Premier for video, there's GarageBand and FL studio for music and old good pen and pencil for math proofs. But these tools have three big limitations. First they have a lot of idiosyncratic learning, you have to spend quite some time getting used to these tools and my experience is that this time is quite upsetting. In contrast, you only have to learn to code one, maybe spend a few hours getting used to the syntax of another language. I'm not sure if that's true for most people but it was true for me using the tools mentioned above and wanted a place to discuss and see other people ideas and experiments. The second issue is that all these custom-made tools, are not composing easily. I can't search for all math proofs that used a single theorem. I can't create a plugin for iMovie and apply it to all my videos. I can't pick easily pick a rhythm from the internet and build upon for fun. There's also the issue of costs and version control, all tools I'm using today are open source and my work is stored in my repositories. This way I can create branches and test my ideas and I'm also confident that I can work in these projects in years.

Dafny and Whiley are two examples with explicit verification support. Idris and other dependently typed languages should all be rich enough to express the required predicate but might not necessarily be able to accept a reasonable implementation as proof. Isabelle, Lean, Coq, and other theorem provers definitely can express the capability but aren't going to churn out much in the way of executable programs; they're more useful to guide an implementation in a more practical functional language but then the proof is separated from the implementation, and you could also use tools like TLA+.

https://dafny.org/

https://whiley.org/

https://www.idris-lang.org/

https://isabelle.in.tum.de/

https://leanprover.github.io/

https://coq.inria.fr/

http://lamport.azurewebsites.net/tla/tla.html

Lean4 manages to pull off changing the parser on the fly at compile time. You can add new productions, add new syntax node types, and add new tokens. Then define macros or code to process the additional syntax. Here is a sample I found that adds a simple JSX-like syntax starting around line 93 and then uses it at line 169:

https://github.com/leanprover/lean4/blob/master/tests/playgr...

I believe most of the language is defined this way, although it is pre-compiled.

For more details see the lean4 metaprogramming book: https://github.com/arthurpaulino/lean4-metaprogramming-book

"csv.pyi is from VS Code Pylance extension" is misleading. Yes, it's included in the code base of the extension, but it's likely originally from python/typeshed. I diffed csv.pyi in the extension and the repository, and they're exactly the same.

You can check the typeshed library that offers stubs for many packages.

https://github.com/python/typeshed is Python's equivalent of DefinitelyTyped. I'm not 100% sure why it's not more of a popular thing the way DefinitelyTyped is; I think there might, to some extent, be different attitudes around the appropriateness of having third-party typings for packages, when the actual maintainer of the package isn't interested in providing first-party ones.

https://github.com/python/mypy same with typeshed https://github.com/python/typeshed

Here's the tensorflow type stubs on typeshed. https://github.com/python/typeshed/tree/main/stubs/tensorflow

Also, be aware that there is already a central place for stubs files. If you are going to take the time to write one, contributing it there will help everyone if the package owners aren't already including some type hints.

Python's type hints are definitely an improvement and they're getting better all the time, but they're still frustrating to use at anything approaching the edge. I long for something as elegant and functional as TypeScript.

One hurdle I've stumbled over recently is the question "what is a type?", the answer can be surprising. Unions, for example, are types but not `Type`s. A function that takes an argument of type `Type` will not accept a Union. So if you want to write a function that effectively "casts" a parameter to a specified type, you can't. The best you can do is have an overload that accepts `Type` and does an actual cast, and then another that just turns it into `Any`. This is, in fact, how the standard library types its `cast` function [1]. The argument I've seen for the current behavior is that `Type` describes anything that can be passed to isinstance, but that's not a satisfying answer. Even then, `Union` can be passed to isinstance and still does not work with `Type`. Talk currently is to introduce a new kind of type called `TypeForm` or something to address this, which is certainly an improvement over nothing, but still feels like technical debt.

[1]: https://github.com/python/typeshed/blob/main/stdlib/typing.p...

>Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.

No, I really don't.

https://github.com/keepassxreboot/keepassxc/pull/8500 - I was randomly reading keepassxc's manpage and spotted a curious option, spent some time spelunking through the code and history to discover that it was an outdated option, sent a PR.

https://github.com/python/typeshed/pull/8617 - I converted one of the scripts I use in my DE from shell to Python, saw that VSCode has this new fancy typing support for Python, quickly found a basic bug in the type definitions for the os module, tested a fix locally, sent a PR.

https://gitlab.gnome.org/GNOME/gtk/-/issues/5250 - I found an issue with copy-paste on my phone, investigated it all the way through to the GTK stack, found the commits that introduced the issue, created a distro patch for it while discussing it with GTK upstream.

https://gitlab.alpinelinux.org/alpine/aports/-/merge_request... - I noticed that gnome-passwordsafe crashes some times, debugged it to discover that it was missing a dependency, sent a PR to the distro package to update the dependencies.

etc etc. I've made lots of fixes like these. I have no interest in paying for each and every one of them. The projects are all better off for fixes like mine and gatekeeping them on payment would've been nothing but their loss.

The csv module is one of those standard library modules that doesn't provide its own type hints, but instead gets them through the external typeshed project, and (for compatibility/implementation reasons, I surmise) the name of these types sometimes don't quite align with the objects they correspond to. So, for all intents and purposes, _csv._reader is the correct name of the type that csv.reader() returns, as ugly as it is.

You have to do handling like that in other languages like TypeScript anyway.

Painpoint with type annotations:

- not being able to reuse "shapes" of data: TypedDict, NamedTuple, dataclasses.dataclass, and soon kwargs (PEP 692 [1]) all have named, typed fields now. You have to

- Since there's no generic "shape" structure that works across data types, there isn't a way to load up a JSON / YAML / TOML into a dictionary, upcast it via a `TypedGuard`, and pass it into a TypedDict / NamedTuple / Dataclass. dataclasses.asdict() or dataclasses.astuple() return naive / untyped tuples and dicts. Also the factory functions will not work with TypedDict or NamedTuple, respectively, even if you duplicate the fields by hand. See my post here: https://github.com/python/typeshed/issues/8580

- Standard library doesn't have runtime validation (e.g. pydantic / https://github.com/pydantic/pydantic).

- pytest fixtures are hard.

- Django is hard. PEP 681 may not be a saving grace either. [3]

[1] https://peps.python.org/pep-0692/