Time to invent a different file format to hold meta data info

[Unknown W. Brackets]

Actually, I think it would be much more fruitful to have a standard way 
to integrate a compiler into an IDE.  An API would be needed with things 
like: (all optional)

1. Lex a file (returning basic token information.)
2. Parse a file (returning some sort of standardized syntax tree.)
3. Compile a file (returning various error structures.)
4. List common keywords in the language.
5. Syntax check a file (no output, just the errors.)

To put it in code, imagine this:

---
compiler_syntax_func_t syntaxcheck = get_compiler_sym("syntaxcheck");
char[] source_data = get_editor_source();
compiler_error_t* compiler_errors;

compiler_errors = syntaxcheck(source_data.ptr, source_data.length);

compiler_error_t[] errors;
for (auto p = compiler_errors; *p; p++)
    errors ~= (*p).dup;

compiler_free_func_t compiler_free = get_compiler_sym("compiler_free");
compiler_free(compiler_errors);
---

Of course, I'm sure a better API could be devised.  This sort of format, 
if properly standardized, could be used to make IDEs much more 
efficient.  It would also allow for much better and more accurate error 
reporting, and the compiler could be loaded as a shared object so that 
initialization cost would be low.

Most language services for Visual Studio are essentially a large part of 
the compiler (often reimplemented in C# or some such) without the code 
generation.  It seems like such a silly and obvious waste to me.

-[Unknown]


davidl wrote:
> 
> I hope it will be integrated to the Compiler. As IDE should not deal 
> with language changes.
> Dealing with parsing sources of D1, D2, D3, D4... is actually 
> cumbersome. The IDE development gets hindered because the autocompletion 
> must be able to parse both D1/D2 and future DMD releases. And endless 
> bug fixes.
> 
> An extendible while relatively more stable metadata file format may 
> greatly ease IDE development.