Closed radumereuta closed 1 year ago
From Everett:
K
CI
Haskell-backend
LLVM-backend
PYK
K
K repl
comm
attribute (Radu)#trace
hook to K-IO module (Bruce)function, total
(Dwight)CI
ciscript
(Bruce)Nix
haskell/llvm-backend
, k
, evm-semantics
, ksummarize
, avm-semantic
... (Sam, Bruce, Everett)
kup
tool to help with installing K and it's dependencies and keeping everything up to date (Sam)Haskell-backend
kore-rpc-server
, JSON-RPC API for symbolic execution (Jost, Sam, Ana)\\ceil
(Ana)\\not
simplification rules (Jost)hs-backend-booster
(in progress) (Everett, Jost, Ana, Sam)LLVM-backend
amb
, inj
) (Bruce)#trace
hook that prints K terms in surface syntax (Bruce)kore-expand-macros
) (Bruce):
macro
or macro-rec
attribute and only checking the top-level term against thosellvm-kompile
to support friendlier option parsing (Bruce)PYK
runtimeverification/pyk
: fast CI pipeline, lightweight distributionpoetry
, full type checking, integrate code formatters, add linting plugins, move to pytest
, extract runtimeverification/python-project-template
pyk.kore
: KORE AST, parser, kore-rpc
clientpyk.kllvm
: integrate the LLVM backend's Python bindingspyk.ktool
: integrate kast
and krun
, implement kprove
based on kore-rpc
pyk.kbuild
: design and proof of concept implementationpyk.krepl
: design and skeleton implementationpyk.krepl_web
: design and skeleton implementation
A few general directions that we would like to follow in developing K in the year 2022:
Get K into a stable and usable state. Talking with internal users of K that maintain large definitions, I sense a sentiment of frustration because of the poor performance and frequent bugs. It's not fun working on something if your tools are not helping you.
Interoperability between tools. At one point, we need to be able to create spinoff tools for different semantics, depending on the needs of auditors. We need to have some kind of infrastructure in place for them.
More robust scripting api for k. Pyk is a start in this direction which could use some improvements (#2379)
More frequent release schedule. 3-5 per year? We should target versions that feel stable. Large features that may prove problematic should be tested thoroughly.
Keep large definitions up to date.
https://github.com/kframework/k/issues/1655
https://github.com/kframework/k/issues/1657
https://github.com/kframework/k/issues/2386