digitalmars.D - Time to invent a different file format to hold meta data info
- davidl (7/7) Mar 29 2009 I hope it will be integrated to the Compiler. As IDE should not deal wit...
- Unknown W. Brackets (30/40) Mar 29 2009 Actually, I think it would be much more fruitful to have a standard way
- Walter Bright (3/12) Mar 29 2009 That's why Ddoc is part of the compiler, so it can get the syntax
- Unknown W. Brackets (7/20) Mar 30 2009 Does that mean I should be holding my breath for a -DIDE switch to
- Kagamin (3/4) Mar 30 2009 You meant *compilers*? D1, D2, D3 etc.
- Unknown W. Brackets (9/15) Mar 30 2009 Well, I'm not so sure. Every time you invent meta data, someone will
- Kagamin (3/7) Mar 31 2009 We can have this API for metadata. And what if I want full type informat...
- Unknown W. Brackets (13/24) Mar 31 2009 Well, an API allows programatic reduction, handshaking (version
- Simon Gomizelj (7/45) Apr 03 2009 On Mon, 30 Mar 2009 02:09:28 -0400, Unknown W. Brackets
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.
Mar 29 2009
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 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.
Mar 29 2009
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 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.
Mar 29 2009
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 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.
Mar 30 2009
Unknown W. Brackets Wrote:a standard way to integrate a compiler into an IDEYou meant *compilers*? D1, D2, D3 etc. Not only IDE will benefit from extensive metadata. Compiler and runtime reflection will too.
Mar 30 2009
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 IDEYou meant *compilers*? D1, D2, D3 etc. Not only IDE will benefit from extensive metadata. Compiler and runtime reflection will too.
Mar 30 2009
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?
Mar 31 2009
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?
Mar 31 2009
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 generation. It seems like such a silly and obvious waste to me. -[Unknown] davidl wrote:-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/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.
Apr 03 2009