> Any language should be if not developed by the tool developer, at least developed with tooling in mind. I completely agree. A few things I think would help w

> Any language should be if not developed by the tool developer, at least developed with tooling in mind. I completely agree. A few things I think would help with this: 1) Provide a standard "machine readable" concrete syntax for the language, alongside any "human readable" syntax. S-expressions would work well for this; if someone prefers JSON or XML then I won't argue. The implementation (compiler or interpreter) should have a mode which converts the human syntax to the machine syntax. The compiler/interpreter should handle inputs in either format. This avoids tools having to parse human-readable formats (or worse, run arbitrary preprocessors, etc.), and makes it easier to feed auto-generated or modified code into the system (e.g. for type checking, etc.). Machine-readable formats are also be more robust, since everything's delimited in a standard way, so unknown things (e.g. new language constructs) won't mess up the parsing of everything else, making tooling easier (e.g. linting, documentation generators, etc.). Note that Lisps and Schemes have this already, by virtue of using a machine-readable language as their human-readable language. Others can maybe just serialise their parser's output (as long as it's concrete, not abstract). 2) Allow arbitrary metadata to be attached to pieces of the syntax tree (in both formats). This can be used for comments, but also for source location (e.g. if it's been translated from the human-readable format, or maybe even transpiled from something else). The parent's desire for graphics, etc. in comments could be handled by such annotations, since they're data not just ignored bytes, so they could have e.g. entire Scribble documents attached. Tooling can use this for any data they like, e.g. hints for static analysers, dependency information, required language version/features, blame information, optimisation hints, etc. I think Clojure already allows this, but I've not used Clojure. 3) Keep context/configuration close to the code, or at least allow it to be. For example, if the meaning of some code changes depending on language version, it should be possible to specify the language version as part of that code. That way, tooling is able to obtain and use that information. This could use the annotations from (2). The worst case is when crucial information (like language version, or which arbitrary program to run as a preprocessor, etc.) is kept in some external configuration file, in an arbitrary location, in some bespoke file format, such that no other tooling can make sense of the code (I'm looking at you Cabal!). Even if we want separate config files, the tools which handle them should be able to resolve and propagate that information into the code, e.g. we could ask `tool annotate src/foo.lang` to get a copy of `src/foo.lang` which any relevant context/metadata from the config file appended as a file header. IDEs can use this to get more info about the files they're editing, and propagate that info into the snippets they send into the implementation for type-checking, etc.