@Gankra likes after reading
…but also: “and therefore I made the input YAML and used serde” NOPE
@Gankra But…that’s what serde…does. It takes a structured plaintext representation and walks it as a tree structure, which is then converted into a proper AST (structs).
I’m not saying you were wrong to use KDL, I just don’t think there’s anything special going on. The following is equivalent, if a bit less suited to the data in question.
---
kind: struct
name: Simple
fields:
- a: i32
---
kind: alias
name: Simple2
is: Simple
---
kind: struct
name: Complex
fields:
- elems: "[Simple;10]"
- val: Simple2
- opaque: ptr
- flag: bool
---
kind: enum
name: ErrorCode
cases:
- Ok: 0
- FileNotFound: 1
- Bad: -3
---
kind: tagged
name: MyResult
cases:
- name: Ok
fields: { "_": "[u32;3]" }
- name: Err
fields: { "_": "ErrorCode" }
---
kind: tagged
name: MyDeepResult
cases:
- name: Ok
fields: { "_": "MyResult" }
- name FileNotFound
fields:
- x: bool
- y: Simple
---
kind: fn
name: func1
inputs:
- a: Complex
- b: Simple
outputs:
- out: i32
---
kind: fn
name: enumtime
inputs:
- a: "&MyResult"
- b: "MyDeepResult"
- c: "[&ErrorCode;4]"
---
kind: pun
name: MetersU32
reprs:
- langs: [rust]
kind: struct
name: Meters32
attrs: "#[repr(transparent)]"
fields:
- a: u32
- langs: [c, cpp]
kind: alias
name: Meters32
is: u32
@jrose i... guess? feels a bit reductionist. or perhaps i'm missing the distinction you want to make.
like, you can do this transform on any programming language with blocks and nesting.
(your transform also removed at least one place where juxtaposition is used -- with attributes)
@Gankra > Wouldn’t it be funny if I made a programming language where every program was a valid KDL document? And thus kdl-script was born!
You made a whole section about how this was “the heart of abi-cafe 2.0”. But it’s not. The heart of abi-cafe 2.0 is that you made your test cases generated from data instead of handwritten. Which is great! Huge improvement! Definitely a non-trivial amount of work to write code generators for all the things you want to support! But you don’t talk about that, you talk about how you sidestepped parsing by picking an existing structured text format. Which, again, was a good choice! And you picked a good format, even! But it’s not the interesting part of the project.
@jrose oh i see the confusion
it's because i decided to only focus on the silly shitpost detail and not the fact that kdl-script exposes actual compiler-y datastructures for the backends to use: https://github.com/Gankra/kdl-script/blob/main/src/types.rs
@jrose for context on why this felt like a big deal: in 1.0 with the no-types-only-values approach, it became the responsibility of each abi backend to essentially detect that two values had the same type, and deduplicate them when it came time to emit type definitions
it... fucking sucked lol. i am living in the absolute future by having an actual nominal/structural type system with precomputed type ids and a topological sort of the definitions
@Gankra gankra do you have thoughts on crabi
also thank you for the article it was a fun and interesting read
@Gankra oh! it's this stuff: https://github.com/rust-lang/rfcs/pull/3470
extending the c abi with types so languages with similar types systems and memory models can talk to each other without losing information. it's struck me as extremely similar to work happening in wasm modules with richwasm etc, though wasm is maybe blessed in not needing to touch c to begin with and having better ways to share references
@totikom the codebase is kinda in a big flux with the 2.0 work happening on a feature branch, but on that branch i've hoisted a lot of the logic sprawling from main into more clear steps/chunks
https://github.com/Gankra/abi-cafe/tree/kdl/src/harness
however depending on what this looks like, it might be a pretty significant refactor to add this "mode"