www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Time to invent a different file format to hold meta data info

reply davidl <davidl 126.com> writes:
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
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
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.
Mar 30 2009
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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.
Mar 30 2009
parent reply Kagamin <spam here.lot> writes:
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
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
prev sibling parent "Simon Gomizelj" <simongmzlj gmail.com> writes:
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:

  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.






-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Apr 03 2009