I think the idea is solid, but the specifics are more involved than just making sure that it maps nicely to tokens.
One thing in particular that I've noticed is that many of language features that enable concise code - such as e.g. type inference - are counter-productive for LLMs because they are essentially implicit context, and LLMs much prefer such things to be explicit. I suspect that e.g. forcing the model to spell out the type of every non-trivial expression in full would have an effect similar to explicit chain-of-thought.
Similarly I think that the ability to write deeply recursive expressions is not necessarily a good thing, and an LLM-centric language should deliberately limit that and require explicit variables to bind intermediate results to.
The single biggest factor though seems to be the ability to ground the model through tooling. Static typing helps a lot there, as do explicit purity annotations for code, and so does automated testing, but one area that I would particularly like to explore for LLM use is design-by-contract.
One thing in particular that I've noticed is that many of language features that enable concise code - such as e.g. type inference - are counter-productive for LLMs because they are essentially implicit context, and LLMs much prefer such things to be explicit. I suspect that e.g. forcing the model to spell out the type of every non-trivial expression in full would have an effect similar to explicit chain-of-thought.
Similarly I think that the ability to write deeply recursive expressions is not necessarily a good thing, and an LLM-centric language should deliberately limit that and require explicit variables to bind intermediate results to.
The single biggest factor though seems to be the ability to ground the model through tooling. Static typing helps a lot there, as do explicit purity annotations for code, and so does automated testing, but one area that I would particularly like to explore for LLM use is design-by-contract.