Barliman
sail
Barliman | sail | |
---|---|---|
3 | 2 | |
1,040 | 533 | |
- | 3.8% | |
0.0 | 9.5 | |
4 months ago | 4 days ago | |
Scheme | Isabelle | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Barliman
- Candy – a minimalistic functional programming language
- Ask HN: Open-Source GitHub Copilot?
-
Supporting hand health for Common Lisp developers
If you really want to go crazy, do interactive type-driven program synthesis. Although I think the state-of-the-art in this field is a Haskell tool called Wingman, and there are similar tools for Agda, as described in this paper, it is possible in Common Lisp I don't know if it has been done. The methodology for more rigorous typing in Common Lisp is described here. There is a program synthesis system written in Scheme called Barliman, and someone wrote an Emacs version of it called complete.el.
sail
-
How to improve the RISC-V specification
Sail is pretty similar to ASL (both current ASL and ASL 1.0) except that (1) it has a more expressive type system, so that bitvector lengths can all be statically checked, (2) it has proper tagged unions and pattern matching, and (3) there's a wide range of open-source tooling available, for execution, specification coverage, generating emulators, integrating with relaxed concurrency models, generating theorem-prover definitions, etc. We've recently updated the Sail README, which spells some of this out: https://github.com/rems-project/sail .
As Alastair Reid says, one of the main things missing in the current RISC-V specification documents is simply that the associated Sail definitions are not yet interspersed with the prose instruction descriptions. The infrastructure to do that has been available for some time, in the Sail AsciiDoc support by Alasdair Armstrong (https://github.com/Alasdair/asciidoctor-sail/blob/master/doc...) and older LaTeX versions by Prashanth Mundkur and Alasdair (https://github.com/rems-project/riscv-isa-manual/blob/sail/r...).
-
Candy – a minimalistic functional programming language
That's completely feasible and there are languages that do this. It doesn't really eliminate the need to run your program unless the inputs to your program are also completely restricted types like One, Two, Three. In which case yeah, you don't need to run it and the type system can just tell you the answer.
I believe you can do that sort of thing in loads of type systems, e.g. Typescript, but there are languages that intentionally support it. I use a niche DSL that has fancy types like this called Sail. https://github.com/rems-project/sail
In my experience the downsides of these fancy "first class type systems" are
1. More incomprehensible error messages.
2. The type checker moves from a deterministic process that either succeeds or fails in an understandable way, to SMT solvers which can just say "yep it's ok" or "nope, couldn't prove it", semi-randomly, and there's little you can do about it.
Still my experience of Sail is that it's very comfortable to go a little bit further into SMT land, and my experience of Dafny is that it's very unpleasant to go full formal-verification at the moment.
I've done a fair bit of hardware formal verification too and that's a different story - very easy and very powerful. I'm hoping one day that software formal verification is like that.
What are some alternatives?
fauxpilot - FauxPilot - an open-source alternative to GitHub Copilot server
suggest.el - discover elisp functions that do what you want
doom-emacs - An Emacs framework for the stubborn martian hacker [Moved to: https://github.com/doomemacs/doomemacs]