joomy

The issue was a fun read, thanks for sharing.

Our 2 page extended abstract was more like a preannouncement. We hope to have a draft of the full paper by the end of the year.

And we're not opposed to choice trees. I personally am not too familiar with them but there's time to catch up on literature. :)

The title alone reads like the "digging for diamonds" meme.

We mean Haskell-style software transactional memory (STM). We call it a primitive because it is not defined in Rocq itself; instead, it is only exposed to the Rocq programmer through an interface.

I'm not entirely sure I fully agree with this definition; it seems somewhat arbitrary to me. Where is this definition from?

My usual intuition is whether the generated code at the end needs a complicated runtime to replicate the source language's semantics. In Crane, we avoid that requirement with smart pointers, for example.

Have you considered combinatorial testing?

Our plan was to do random Rocq program generation and differential testing of Crane extracted code versus other extraction methods and even CertiCoq. But fixing a program and trying different mappings would certainly be a useful tool for any dev who would like to use our tool, and we should put it on our roadmap.

This is another reason we are being careful with the correctness claim. The closest project I know right now that comes close to a formalized model of C++ is the BRiCk project:

https://skylabsai.github.io/BRiCk/index.html

https://github.com/SkyLabsAI/BRiCk

Yes, we were careful not to call it that. I still don't mind calling our programs verified, since they are verified in Rocq and we do our best to preserve the semantics of them. Right now the only measure we have is testing a small set of programs and also carefully picking a subset of C++ that we trust. Our future plan is to generate random Rocq programs, extract them via Crane, and compare the output to the outputs of extraction to OCaml, and even CertiCoq, which is a verified compiler from Rocq to C, (mostly) proven correct with respect to CompCert semantics.

Just like JavaScript folks like calling their compilers "transpiler", proof assistants folks like calling their compilers "extraction". Essentially it's a compiler from a high-level language to a slightly lower-level, but still reasonably high-level language.

We do C++ only because C++ is the primary programming language at Bloomberg, and we aim to generate verified libraries that interact easily with the existing code. More about our design choices can be found here: https://bloomberg.github.io/crane/papers/crane-rocqpl26.pdf

We're based in NYC. The Infrastructure and Security Research team in the CTO Office, in particular.

And we are looking for senior researchers to join us, see https://x.com/jvanegue/status/2004593740472807498

Hi, I'm one of Crane's developers. You can map Rocq `bool`s to C++ `bool`, Rocq strings to C++ `std::string`s, etc. You just have to manually import the mapping module: https://github.com/bloomberg/crane/blob/6a256694460c0f895c27...

The output you posted is from an example that we missed importing. It's also one of the tests that do not yet pass. But then again, in the readme, we are upfront with these issues:

Crane is under active development. While many features are functional, parts of the extraction pipeline are still experimental, and you may encounter incomplete features or unexpected behavior. Please report issues on the GitHub tracker.

I should also note, mapping Rocq types to ideal C++ types is only one part of it. There are still efficiency concerns with recursive functions, smart pointers, etc. This is an active research project, and we have plans to tackle these problems: for recursion: try CPS + defunctionalization + convert to loops, for smart pointers: trying what Lean does (https://dl.acm.org/doi/10.1145/3412932.3412935), etc.

You're right about the records providing flexible order, I overlooked that.

But Kip lets you repeat cases in arguments, so you're not limited to 8 arguments for a function. In cases where a function takes multiple arguments of the same case, the order in which those arguments are applied matters, otherwise it doesn't. So if you say "any number of arguments but only 8 are named, that seems bad", I'd understand, but that is a relatively uncommon problem to run into, especially in a toy language like this that is not meant for any serious work.

(bu tam-sayının) mutlak-değeri, (bunun 0'dan büyüklüğü) doğruysa, bu, değilse, bunun -1'le çarpımıdır.

(5'in mutlak-değerini) yaz.

(-5'in mutlak-değerini) yaz.

You can try it in the playground.

Okay there is an updated web page and playground now: https://kip-dili.github.io/

Cases essentially act like named arguments, except the names are inferred from the case of an argument, which is inferred through morphological analysis. And that analysis can be ambiguous, so the ambiguities are solved by the type checker / elaborator. It's different from record types in the sense that you can provide the arguments in any order to a function, and the system will figure it out because of the cases.

"fark" here takes two arguments, the first (the minuend) is in instrumental case (-le), the second (the subtrahend) is in genitive case (-in). Now, because of the suffixes of the cases, regardless of the order in which you give the arguments, the type system can figure out which one is supposed to be the minuend and which the subtrahend.

If it helps, you can think of it like named arguments where the name is inferred from the case.

Yes, that's one of my inspirations! I'm writing a short paper about Kip and I'm citing Perligata there for sure. The closest modern non-English programming language I know that also uses grammar features is Tampio, for Finnish. https://github.com/fergusq/tampio

That's okay, thanks for sharing!

It would actually be a good fit for event handlers...

That's pretty cool! From what I can tell, it does a morphological guess based on the suffix. If you didn't have the apostrophe, it'd have issues with ambiguity (say "aşı", does it mean vaccine or does it mean "aş" in accusative case?) but the apostrophe solves that problem too.

My solution for this problem in Kip was to go all the way with the morphological analysis using TRmorph (https://github.com/coltekin/TRmorph) for it, and then resolve the ambiguities in type checking / elaboration. (Therefore Kip almost never needs apostrophes.) Whether it was worth it, I don't know, but it was a fun problem to solve. :)

Hi all, Kip's developer here! I was going to wait until we had finished the playground and landing page before posting about the project more, but here's the browser-based playground we have so far (thanks to Alperen Keles) for anyone who wants to play with the language: https://alpaylan.github.io/kip/

(The work on JavaScript transpilation just started today and currently doesn't work, but running the language should mostly work, though it probably has bugs, which I'd love to hear about in the repo's issues!)