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.

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.

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.

That's why Ddoc is part of the compiler, so it can get the syntax
highlighting right.

Does that mean I should be holding my breath for a -DIDE switch to
launch an IDE that gets the syntax highlighting right? Heh.
Seriously, I do agree that was a smart choice. I wish its output were a
bit more semantic, but things like that can be fixed. Having correct
parsing is priceless, and it's a very logical part of the build process.
-[Unknown]
Walter Bright wrote:

Unknown W. Brackets wrote:

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.

That's why Ddoc is part of the compiler, so it can get the syntax
highlighting right.

Well, I'm not so sure. Every time you invent meta data, someone will
invent a language that goes outside that meta data. It's reality.
Programs would benefit from such an API as well; it could provide basic
runtime information (mangling, dynamic compilation, etc.)
That said, as far as reflection, D already embeds TypeInfo and such. A
lot of reflection is already possible - a library just needs to be
written that does it.
-[Unknown]
Kagamin wrote:

Unknown W. Brackets Wrote:

a standard way to integrate a compiler into an IDE

You meant *compilers*? D1, D2, D3 etc.
Not only IDE will benefit from extensive metadata. Compiler and runtime
reflection will too.

Well, an API allows programatic reduction, handshaking (version
upgrades), and the like. A file format can do some of these things as
well, but it starts to get more complicated, and you start wasting space
for bc, etc. etc.
Also, a file format would have to be generated by running the compiler,
e.g. compiling the file; the original post was about using this for an
IDE. How is it useful to have to compile it first before proper
information is available?
Sure, the compiler could be run by the IDE, and the result returned as a
file... but you can call that "meta data file", I'll still call it "an
API that uses a temporary file."
-[Unknown]
Kagamin wrote:

Unknown W. Brackets Wrote:

Well, I'm not so sure. Every time you invent meta data, someone will
invent a language that goes outside that meta data. It's reality.

API will do the same.

Programs would benefit from such an API as well; it could provide basic
runtime information (mangling, dynamic compilation, etc.)

We can have this API for metadata. And what if I want full type information?

On Mon, 30 Mar 2009 02:09:28 -0400, Unknown W. Brackets
<unknown simplemachines.org> wrote:
Check out clang. LLVM frontend for C, C++, and Objective-C which has
similar IDE intergration in mind.
Maybe ldc can take this route?

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.