having to define the function signature in one place and its implementation in another adds to the cognitive burden of human developers, which is why we don't see it much in modern languages. instead, what if libraries emitted the equivalent of .h files that work better with LLM? is there a currently a spec for this?
.d.ts files are produced by Typescript compiler automatically from .ts files (and can be written manually for .js files). ML signature files are much like .h files and I think for the same reason - to make compiler work easier.
Edit: as this is LLM thread - ML is Meta Language as in OCaml and SML.
I’m not sure what you’re imagining, but in this case I would not imagine you would generate js or write .d.ts files?
An LLM pass with a high level goal would generate a file list, then a series of .d.ts files from it.
Then (after perhaps a review of the type definition files, possibly also LLM assisted) a second pass taking the .d.ts files as input would generate a typescript file for every .d.ts file.
You would then discard the .d.ts files and just have a scaffolded .ts code base?
My point was doing the same trick with say, Java, seems like a harder problem to solve, but you could do the above right now with existing LLMs.
It's all a kludge, really. You shouldn't have to make up-front decisions where to put type signatures; you should be able to query for them and see them where and when you need them. We're still stuck in the local minimum of programming directly in the code serialization/storage format. It's a lot like using SQLite database by only ever viewing and editing it in a hex editor.
