www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd support for IDEs and the D tool chain

reply Jacob Carlborg <doob me.com> writes:
Here is my thoughts and what I think is needed to build a really good 
IDE and maybe get some attention from the enterprise. It's really not 
enough for the compiler to output some json for an IDE to use, the whole 
tool chain needs to be revised.

Compiler:
  * Written in D
  * Supports all major platform
  * 32 and 64bit support
  * Doesn't have annoying bugs like forward reference errors and problem
    with the linker
  * Built with and IDE in mind
  * Can be built as a (dynamic)library
  * Can build dynamic libraries
  * Supports incremental builds
  * Has clearly separate components, especially the front- and back-end.
  * Has a license that allows it to be built into an IDE and/or shipped
    with an IDE
  * Basically something like LLVM + Clang

Compiler or separate tool:
  * Automatically tracks all dependencies and builds the
    application/library (like DSSS)

GUI library:
  * Written in D
  * Supports all major platforms (mac, linux, win)
  * Uses native controls (as much as possible) to draw its controls
  * Supports (de)serializing controls (Glade, nib)

IDE:
  * Written in D
  * Be able to show syntax and semantic errors as you type
  * Autocompletion
  * Refactoring
  * Building
  * Supports incremental builds
  * Basically something like Eclipse JDT

GUI builder:
  * Supports (de)serializing controls (Glade, nib)
  * Basically something like Interface Builder, Glade


All of the above would be the most optimal. For example, everything 
don't have to be built in D but for building an IDE in D I think that it 
would be easier.

What we have now and what I think is the closest match:

Compiler: LDC
  * Missing most of the mentioned things
  * Needs better platform support
  * At least the back-end is built like this

We have DSSS and xfbuilder (or what it's called)

GUI library: DWT
  * There are some bugs in the mac version
  * Doesn't support (de)serializing controls
  * Not built in a D-way
  * Maybe too heavy

IDE: Descent
  * Missing some features like refactoring
  * Only supports building using an external tool
  * Needs to improve the syntax and semantic errors
  * Needs to improve the performance if possible

GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses
  * To my knowledge none of the above supports a GUI library like the
    one mentioned


Any comments, thoughts?

/Jacob Carlborg
Oct 16 2009
next sibling parent reply digited <digited yandex.ru> writes:
Jacob Carlborg Wrote:
 
 IDE: Descent

Poseidon + xfBuild may do the job (but Poseidon needs work to run on linux and mac). Eclipse itself is too heavy and too java's.
Oct 16 2009
parent reply Jacob Carlborg <doob me.com> writes:
On 10/16/09 13:03, digited wrote:
 Jacob Carlborg Wrote:

 IDE: Descent

Poseidon + xfBuild may do the job (but Poseidon needs work to run on linux and mac). Eclipse itself is too heavy and too java's.

I totally forgot about Poseidon. It has already been ported to the new DWT library, I don't know if it's complete and if it's running.
Oct 16 2009
parent Frank Benoit <keinfarbton googlemail.com> writes:
Jacob Carlborg schrieb:
 On 10/16/09 13:03, digited wrote:
 Jacob Carlborg Wrote:

 IDE: Descent

Poseidon + xfBuild may do the job (but Poseidon needs work to run on linux and mac). Eclipse itself is too heavy and too java's.

I totally forgot about Poseidon. It has already been ported to the new DWT library, I don't know if it's complete and if it's running.

Needs debugging, but can run. I wanted to port it to the jface.text editor component, but lost motivation :)
Oct 16 2009
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Fri, Oct 16, 2009 at 12:06 PM, Jacob Carlborg <doob me.com> wrote:
 Here is my thoughts and what I think is needed to build a really good IDE
 and maybe get some attention from the enterprise. It's really not enough =

 the compiler to output some json for an IDE to use, the whole tool chain
 needs to be revised.

 Compiler:
 =C2=A0* Written in D
 =C2=A0* Supports all major platform
 =C2=A0* 32 and 64bit support
 =C2=A0* Doesn't have annoying bugs like forward reference errors and prob=

 =C2=A0 with the linker
 =C2=A0* Built with and IDE in mind
 =C2=A0* Can be built as a (dynamic)library
 =C2=A0* Can build dynamic libraries
 =C2=A0* Supports incremental builds
 =C2=A0* Has clearly separate components, especially the front- and back-e=

 =C2=A0* Has a license that allows it to be built into an IDE and/or shipp=

 =C2=A0 with an IDE
 =C2=A0* Basically something like LLVM + Clang

 Compiler or separate tool:
 =C2=A0* Automatically tracks all dependencies and builds the
 =C2=A0 application/library (like DSSS)

 GUI library:
 =C2=A0* Written in D
 =C2=A0* Supports all major platforms (mac, linux, win)
 =C2=A0* Uses native controls (as much as possible) to draw its controls
 =C2=A0* Supports (de)serializing controls (Glade, nib)

 IDE:
 =C2=A0* Written in D
 =C2=A0* Be able to show syntax and semantic errors as you type
 =C2=A0* Autocompletion
 =C2=A0* Refactoring
 =C2=A0* Building
 =C2=A0* Supports incremental builds
 =C2=A0* Basically something like Eclipse JDT

 GUI builder:
 =C2=A0* Supports (de)serializing controls (Glade, nib)
 =C2=A0* Basically something like Interface Builder, Glade


 All of the above would be the most optimal. For example, everything don't
 have to be built in D but for building an IDE in D I think that it would =

 easier.

 What we have now and what I think is the closest match:

 Compiler: LDC
 =C2=A0* Missing most of the mentioned things
 =C2=A0* Needs better platform support
 =C2=A0* At least the back-end is built like this

 We have DSSS and xfbuilder (or what it's called)

 GUI library: DWT
 =C2=A0* There are some bugs in the mac version
 =C2=A0* Doesn't support (de)serializing controls
 =C2=A0* Not built in a D-way
 =C2=A0* Maybe too heavy

 IDE: Descent
 =C2=A0* Missing some features like refactoring
 =C2=A0* Only supports building using an external tool
 =C2=A0* Needs to improve the syntax and semantic errors
 =C2=A0* Needs to improve the performance if possible

 GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses
 =C2=A0* To my knowledge none of the above supports a GUI library like the
 =C2=A0 one mentioned


 Any comments, thoughts?

 /Jacob Carlborg

GtkD supports Glade.
Oct 16 2009
parent reply Jacob Carlborg <doob me.com> writes:
On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 On Fri, Oct 16, 2009 at 12:06 PM, Jacob Carlborg<doob me.com>  wrote:
 Here is my thoughts and what I think is needed to build a really good IDE
 and maybe get some attention from the enterprise. It's really not enough for
 the compiler to output some json for an IDE to use, the whole tool chain
 needs to be revised.

 Compiler:
   * Written in D
   * Supports all major platform
   * 32 and 64bit support
   * Doesn't have annoying bugs like forward reference errors and problem
    with the linker
   * Built with and IDE in mind
   * Can be built as a (dynamic)library
   * Can build dynamic libraries
   * Supports incremental builds
   * Has clearly separate components, especially the front- and back-end.
   * Has a license that allows it to be built into an IDE and/or shipped
    with an IDE
   * Basically something like LLVM + Clang

 Compiler or separate tool:
   * Automatically tracks all dependencies and builds the
    application/library (like DSSS)

 GUI library:
   * Written in D
   * Supports all major platforms (mac, linux, win)
   * Uses native controls (as much as possible) to draw its controls
   * Supports (de)serializing controls (Glade, nib)

 IDE:
   * Written in D
   * Be able to show syntax and semantic errors as you type
   * Autocompletion
   * Refactoring
   * Building
   * Supports incremental builds
   * Basically something like Eclipse JDT

 GUI builder:
   * Supports (de)serializing controls (Glade, nib)
   * Basically something like Interface Builder, Glade


 All of the above would be the most optimal. For example, everything don't
 have to be built in D but for building an IDE in D I think that it would be
 easier.

 What we have now and what I think is the closest match:

 Compiler: LDC
   * Missing most of the mentioned things
   * Needs better platform support
   * At least the back-end is built like this

 We have DSSS and xfbuilder (or what it's called)

 GUI library: DWT
   * There are some bugs in the mac version
   * Doesn't support (de)serializing controls
   * Not built in a D-way
   * Maybe too heavy

 IDE: Descent
   * Missing some features like refactoring
   * Only supports building using an external tool
   * Needs to improve the syntax and semantic errors
   * Needs to improve the performance if possible

 GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses
   * To my knowledge none of the above supports a GUI library like the
    one mentioned


 Any comments, thoughts?

 /Jacob Carlborg

GtkD supports Glade.

Yes, but GtkD doesn't use native controls.
Oct 16 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Jacob Carlborg wrote:
 On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 GtkD supports Glade.

Yes, but GtkD doesn't use native controls.

A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.
Oct 16 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:hbarno$188s$1 digitalmars.com...
 Jacob Carlborg wrote:
 On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 GtkD supports Glade.

Yes, but GtkD doesn't use native controls.

A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.

Probably not as minor as it might seem. I find eclipse ugly. And although I'd never really thought about it before, I have to admit, I think it *is* one of the many factors as to why it's always felt too "bloated" for my tastes. Besides, I can think of things (lots of things, in fact) that are pure steaming piles of (well, one can guess), but even despite that have still managed to gain widespread acceptance.
Oct 16 2009
parent Jacob Carlborg <doob me.com> writes:
On 10/17/09 07:06, Nick Sabalausky wrote:
 "Christopher Wright"<dhasenan gmail.com>  wrote in message
 news:hbarno$188s$1 digitalmars.com...
 Jacob Carlborg wrote:
 On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 GtkD supports Glade.

Yes, but GtkD doesn't use native controls.

A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.

Probably not as minor as it might seem. I find eclipse ugly. And although I'd never really thought about it before, I have to admit, I think it *is* one of the many factors as to why it's always felt too "bloated" for my tastes.

Yes eclipse looks ugly. It's quite hard to create a GUI that looks good and native on all platforms (if you don't use separate GUIs).
 Besides, I can think of things (lots of things, in fact) that are pure
 steaming piles of (well, one can guess), but even despite that have still
 managed to gain widespread acceptance.

Oct 17 2009
prev sibling next sibling parent reply "Eric Suen" <eric.suen.tech gmail.com> writes:
"Christopher Wright" wrote
 Jacob Carlborg wrote:
 On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 GtkD supports Glade.

Yes, but GtkD doesn't use native controls.

A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.

SWT wrap native controls, and Eclipse is build on SWT, but for an application like Eclipse, use system provide native controls is no enough, you have to write some custom control. Here is the problem, Java developers just unable to write good looking GUI components or applications using any library, neither Swing nor SWT. for examples, Swing is really powerful GUI frameworks, Java2D is quite powerful, and Swing is very flexible, but most Swing applications are really ugly. Eclipse doesn't look very native because they using ugly tab for layout, you can change that by provide your owner theme. more than 99% controls in Eclipse are native controls... There is the link of custom theme for Eclipse: http://www.agpad.com/images/ide_m.png Eric
Oct 17 2009
parent Jacob Carlborg <doob me.com> writes:
On 10/17/09 10:31, Eric Suen wrote:
 "Christopher Wright" wrote
 Jacob Carlborg wrote:
 On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 GtkD supports Glade.

Yes, but GtkD doesn't use native controls.

A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.

SWT wrap native controls, and Eclipse is build on SWT, but for an application like Eclipse, use system provide native controls is no enough, you have to write some custom control. Here is the problem, Java developers just unable to write good looking GUI components or applications using any library, neither Swing nor SWT. for examples, Swing is really powerful GUI frameworks, Java2D is quite powerful, and Swing is very flexible, but most Swing applications are really ugly.

I think Azureus looks quite native and if they haven't changed anything they're using SWT.
 Eclipse doesn't look very native because they using ugly tab for layout, you
 can change that by provide your owner theme. more than 99% controls in
 Eclipse
 are native controls...

 There is the link of custom theme for Eclipse:

 http://www.agpad.com/images/ide_m.png

 Eric

Oct 17 2009
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 10/17/09 00:23, Christopher Wright wrote:
 Jacob Carlborg wrote:
 On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 GtkD supports Glade.

Yes, but GtkD doesn't use native controls.

A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.

It depends on what you're looking at. The SWT philosophy is something like this: Use controls that are available as native controls on as many platforms as possible. For example, if a control is available as native on 3 out of 4 platforms, use the native on the 3 platforms and emulate it on the fourth. If a control is only native on 1 out of 4 platforms don't include it in SWT. SWT also has some custom (non-native) controls like the tabs used by Eclipse.
Oct 17 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Jacob Carlborg wrote:
 On 10/17/09 00:23, Christopher Wright wrote:
 Jacob Carlborg wrote:
 On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 GtkD supports Glade.

Yes, but GtkD doesn't use native controls.

A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.

It depends on what you're looking at. The SWT philosophy is something like this: Use controls that are available as native controls on as many platforms as possible. For example, if a control is available as native on 3 out of 4 platforms, use the native on the 3 platforms and emulate it on the fourth. If a control is only native on 1 out of 4 platforms don't include it in SWT. SWT also has some custom (non-native) controls like the tabs used by Eclipse.

And the tabs are everywhere, and no attempt was made to make them look native to any platform.
Oct 17 2009
parent "Nick Sabalausky" <a a.a> writes:
"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:hbcg2t$20ih$1 digitalmars.com...
 Jacob Carlborg wrote:
 On 10/17/09 00:23, Christopher Wright wrote:
 Jacob Carlborg wrote:
 On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
 GtkD supports Glade.

Yes, but GtkD doesn't use native controls.

A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.

It depends on what you're looking at. The SWT philosophy is something like this: Use controls that are available as native controls on as many platforms as possible. For example, if a control is available as native on 3 out of 4 platforms, use the native on the 3 platforms and emulate it on the fourth. If a control is only native on 1 out of 4 platforms don't include it in SWT. SWT also has some custom (non-native) controls like the tabs used by Eclipse.

And the tabs are everywhere, and no attempt was made to make them look native to any platform.

And they take up an *enormous* amount of space. I can't actually use them and see their labels at the same time.
Oct 17 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg <doob me.com> wrote:

 Here is my thoughts and what I think is needed to build a really good  
 IDE and maybe get some attention from the enterprise. It's really not  
 enough for the compiler to output some json for an IDE to use, the whole  
 tool chain needs to be revised.

 Compiler:
   * Written in D
   * Supports all major platform
   * 32 and 64bit support
   * Doesn't have annoying bugs like forward reference errors and problem
     with the linker
   * Built with and IDE in mind
   * Can be built as a (dynamic)library
   * Can build dynamic libraries
   * Supports incremental builds
   * Has clearly separate components, especially the front- and back-end.
   * Has a license that allows it to be built into an IDE and/or shipped
     with an IDE
   * Basically something like LLVM + Clang

 Compiler or separate tool:
   * Automatically tracks all dependencies and builds the
     application/library (like DSSS)

 GUI library:
   * Written in D
   * Supports all major platforms (mac, linux, win)
   * Uses native controls (as much as possible) to draw its controls
   * Supports (de)serializing controls (Glade, nib)

 IDE:
   * Written in D
   * Be able to show syntax and semantic errors as you type
   * Autocompletion
   * Refactoring
   * Building
   * Supports incremental builds
   * Basically something like Eclipse JDT

 GUI builder:
   * Supports (de)serializing controls (Glade, nib)
   * Basically something like Interface Builder, Glade


 All of the above would be the most optimal. For example, everything  
 don't have to be built in D but for building an IDE in D I think that it  
 would be easier.

I can't agree more. Everything you wrote is in my TODO list, starting with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource.
Oct 16 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Denis Koroskin wrote:
 On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg <doob me.com> wrote:
 
 Here is my thoughts and what I think is needed to build a really good 
 IDE and maybe get some attention from the enterprise. It's really not 
 enough for the compiler to output some json for an IDE to use, the 
 whole tool chain needs to be revised.

 Compiler:
   * Written in D
   * Supports all major platform
   * 32 and 64bit support
   * Doesn't have annoying bugs like forward reference errors and problem
     with the linker
   * Built with and IDE in mind
   * Can be built as a (dynamic)library
   * Can build dynamic libraries
   * Supports incremental builds
   * Has clearly separate components, especially the front- and back-end.
   * Has a license that allows it to be built into an IDE and/or shipped
     with an IDE
   * Basically something like LLVM + Clang

 Compiler or separate tool:
   * Automatically tracks all dependencies and builds the
     application/library (like DSSS)

 GUI library:
   * Written in D
   * Supports all major platforms (mac, linux, win)
   * Uses native controls (as much as possible) to draw its controls
   * Supports (de)serializing controls (Glade, nib)

 IDE:
   * Written in D
   * Be able to show syntax and semantic errors as you type
   * Autocompletion
   * Refactoring
   * Building
   * Supports incremental builds
   * Basically something like Eclipse JDT

 GUI builder:
   * Supports (de)serializing controls (Glade, nib)
   * Basically something like Interface Builder, Glade


 All of the above would be the most optimal. For example, everything 
 don't have to be built in D but for building an IDE in D I think that 
 it would be easier.

I can't agree more. Everything you wrote is in my TODO list, starting with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource.

Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea.
Oct 16 2009
next sibling parent Jacob Carlborg <doob me.com> writes:
On 10/16/09 14:27, Denis Koroskin wrote:
 On Fri, 16 Oct 2009 16:20:31 +0400, Ary Borenszweig
 <ary esperanto.org.ar> wrote:

 Denis Koroskin wrote:
 On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg <doob me.com> wrote:

 Here is my thoughts and what I think is needed to build a really
 good IDE and maybe get some attention from the enterprise. It's
 really not enough for the compiler to output some json for an IDE to
 use, the whole tool chain needs to be revised.

 Compiler:
 * Written in D
 * Supports all major platform
 * 32 and 64bit support
 * Doesn't have annoying bugs like forward reference errors and problem
 with the linker
 * Built with and IDE in mind
 * Can be built as a (dynamic)library
 * Can build dynamic libraries
 * Supports incremental builds
 * Has clearly separate components, especially the front- and back-end.
 * Has a license that allows it to be built into an IDE and/or shipped
 with an IDE
 * Basically something like LLVM + Clang

 Compiler or separate tool:
 * Automatically tracks all dependencies and builds the
 application/library (like DSSS)

 GUI library:
 * Written in D
 * Supports all major platforms (mac, linux, win)
 * Uses native controls (as much as possible) to draw its controls
 * Supports (de)serializing controls (Glade, nib)

 IDE:
 * Written in D
 * Be able to show syntax and semantic errors as you type
 * Autocompletion
 * Refactoring
 * Building
 * Supports incremental builds
 * Basically something like Eclipse JDT

 GUI builder:
 * Supports (de)serializing controls (Glade, nib)
 * Basically something like Interface Builder, Glade


 All of the above would be the most optimal. For example, everything
 don't have to be built in D but for building an IDE in D I think
 that it would be easier.

with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource.

Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea.

Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow.

Let us know when it's available
Oct 16 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Denis Koroskin" <2korden gmail.com> wrote in message 
news:op.u1v7jdgco7cclz korden-pc...
 Yes, it's a DMD port. Unfortunately, there is no other mature D front-end 
 at present. Other folks are working on D compilers (dil, dang, ...) but 
 the progress is very slow.

FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in).
Oct 16 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Nick Sabalausky wrote:
 "Denis Koroskin" <2korden gmail.com> wrote in message 
 news:op.u1v7jdgco7cclz korden-pc...
 Yes, it's a DMD port. Unfortunately, there is no other mature D front-end 
 at present. Other folks are working on D compilers (dil, dang, ...) but 
 the progress is very slow.

FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in).

I could count the number of places that are ambiguous syntactically or semantically on one hand, and maybe the number of places that require arbitrary lookahead also. Do LALR parsers care about arbitrary lookahead? LL(k) parsers do.
Oct 16 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
news:hbak0n$q5b$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Denis Koroskin" <2korden gmail.com> wrote in message
 news:op.u1v7jdgco7cclz korden-pc...
 Yes, it's a DMD port. Unfortunately, there is no other mature D 
 front-end
 at present. Other folks are working on D compilers (dil, dang, ...) but
 the progress is very slow.

FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in).

All but the hard parts :)

Yea, like I said, "FWIW" ;)
 I could count the number of places that are ambiguous syntactically or
 semantically on one hand, and maybe the number of places that require
 arbitrary lookahead also. Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example?
Oct 16 2009
next sibling parent reply Justin Johansson <no spam.com> writes:
Nick Sabalausky Wrote:

 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
 news:hbak0n$q5b$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Denis Koroskin" <2korden gmail.com> wrote in message
 news:op.u1v7jdgco7cclz korden-pc...
 Yes, it's a DMD port. Unfortunately, there is no other mature D 
 front-end
 at present. Other folks are working on D compilers (dil, dang, ...) but
 the progress is very slow.

FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in).

All but the hard parts :)

Yea, like I said, "FWIW" ;)
 I could count the number of places that are ambiguous syntactically or
 semantically on one hand, and maybe the number of places that require
 arbitrary lookahead also. Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example?

There are a zillion tutorials relating to parsing on the web. Try googling: parsing theory tutorial 2nd hit: An introduction to parsing Cheers Justin Johansson
Oct 16 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:hbamfa$v3b$1 digitalmars.com...
 Nick Sabalausky Wrote:

 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message
 news:hbak0n$q5b$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Denis Koroskin" <2korden gmail.com> wrote in message
 news:op.u1v7jdgco7cclz korden-pc...
 Yes, it's a DMD port. Unfortunately, there is no other mature D
 front-end
 at present. Other folks are working on D compilers (dil, dang, ...) 
 but
 the progress is very slow.

FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in).

All but the hard parts :)

Yea, like I said, "FWIW" ;)
 I could count the number of places that are ambiguous syntactically or
 semantically on one hand, and maybe the number of places that require
 arbitrary lookahead also. Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example?

There are a zillion tutorials relating to parsing on the web. Try googling: parsing theory tutorial 2nd hit: An introduction to parsing

That mentioned, in the section about LL(k), "If both A<B and A<B> are legal expressions, where B can be of arbitrary length, then no finite amount of look-ahead will allow this to be parsed." I did a quick test in gold (LALR), and this handles the above just fine: ------------------------------ "Name" = 'Test' "Author" = 'Test' "Version" = 'Test' "About" = 'Test' "Start Symbol" = <Type1Or2> <Type1Or2> ::= <Type1> | <Type2> <Type1> ::= 'A' '<' <Bs> <Type2> ::= 'A' '<' <Bs> '>' <Bs> ::= 'B' | <Bs> 'B' ------------------------------ However, that one example alone doesn't necessarily prove that it's always doable.
Oct 16 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Nick Sabalausky wrote:
 "Justin Johansson" <no spam.com> wrote in message 
 news:hbamfa$v3b$1 digitalmars.com...
 Nick Sabalausky Wrote:

 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message
 news:hbak0n$q5b$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Denis Koroskin" <2korden gmail.com> wrote in message
 news:op.u1v7jdgco7cclz korden-pc...
 Yes, it's a DMD port. Unfortunately, there is no other mature D
 front-end
 at present. Other folks are working on D compilers (dil, dang, ...) 
 but
 the progress is very slow.

get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in).


 I could count the number of places that are ambiguous syntactically or
 semantically on one hand, and maybe the number of places that require
 arbitrary lookahead also. Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

you give me a simple example?

Try googling: parsing theory tutorial 2nd hit: An introduction to parsing

That mentioned, in the section about LL(k), "If both A<B and A<B> are legal expressions, where B can be of arbitrary length, then no finite amount of look-ahead will allow this to be parsed." I did a quick test in gold (LALR), and this handles the above just fine: ------------------------------ "Name" = 'Test' "Author" = 'Test' "Version" = 'Test' "About" = 'Test' "Start Symbol" = <Type1Or2> <Type1Or2> ::= <Type1> | <Type2> <Type1> ::= 'A' '<' <Bs> <Type2> ::= 'A' '<' <Bs> '>' <Bs> ::= 'B' | <Bs> 'B' ------------------------------ However, that one example alone doesn't necessarily prove that it's always doable.

Bad example. <Bs> is regular. Try making it nested parens or something like that. (It isn't LL(k), but it is pretty trivial anyways. ANTLR3 can handle it without fuss)
Oct 16 2009
parent "Nick Sabalausky" <a a.a> writes:
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
news:hbap0k$141i$1 digitalmars.com...
 Nick Sabalausky wrote:
 That mentioned, in the section about LL(k), "If both A<B and A<B> are 
 legal
 expressions, where B can be of arbitrary length, then no finite amount of
 look-ahead will allow this to be parsed."

 I did a quick test in gold (LALR), and this handles the above just fine:

 ------------------------------
 "Name"    = 'Test'
 "Author"  = 'Test'
 "Version" = 'Test'
 "About"   = 'Test'

 "Start Symbol" = <Type1Or2>

 <Type1Or2> ::= <Type1> | <Type2>
 <Type1> ::= 'A' '<' <Bs>
 <Type2> ::= 'A' '<' <Bs> '>'
 <Bs> ::= 'B' | <Bs> 'B'

 ------------------------------

 However, that one example alone doesn't necessarily prove that it's 
 always
 doable.

Bad example. <Bs> is regular. Try making it nested parens or something like that. (It isn't LL(k), but it is pretty trivial anyways. ANTLR3 can handle it without fuss)

If you mean it's doing it using the dfa/regex lexing engine instead of the parser, it isn't. GOLD has a different syntax for terminals that are to be lexed. Anything with the "<Foo> ::= whatever" syntax is a nonterminal that's handled by LALR parsing. For terminals that are to be handled by the dfa/regex lexer, it's "Foo = whatever". In any case, here's one that can successfully handle nested parens instead of <Bs>: ------------------------------------------------------- "Start Symbol" = <Type1Or2> <Type1Or2> ::= <Type1> | <Type2> <Type1> ::= 'A' '<' <Parens> <Type2> ::= 'A' '<' <Parens> '>' <Parens> ::= '(' ')' | '(' <Parens> ')' ------------------------------------------------------- Or nested sequences of parens: ------------------------------------------------------- "Start Symbol" = <Type1Or2> <Type1Or2> ::= <Type1> | <Type2> <Type1> ::= 'A' '<' <ParensList> <Type2> ::= 'A' '<' <ParensList> '>' <ParensList> ::= <Parens> | <ParensList> <Parens> <Parens> ::= '(' ')' | '(' <ParensList> ')' -------------------------------------------------------
Oct 16 2009
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Nick Sabalausky wrote:
 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
 news:hbak0n$q5b$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Denis Koroskin" <2korden gmail.com> wrote in message
 news:op.u1v7jdgco7cclz korden-pc...
 Yes, it's a DMD port. Unfortunately, there is no other mature D 
 front-end
 at present. Other folks are working on D compilers (dil, dang, ...) but
 the progress is very slow.

chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in).


Yea, like I said, "FWIW" ;)
 I could count the number of places that are ambiguous syntactically or
 semantically on one hand, and maybe the number of places that require
 arbitrary lookahead also. Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example?

PrimExp -> structLiteral PrimExp -> functionLiteral and suppose structLiteral => { /* really, really looooooooooong expression*/ } functionLiteral => { statement } functionLiteral => { /* really, really looooooooooong expression*/ ; } In an LL(k) parser, when you get to PrimExp, you have to know which choice to make based on the first k lookahead characters (probably translates to '{' and one token past that). Obviously, that won't work for this piece, so it isn't LL(k). You have to try parsing the one, and back up and parse the other if the first one fails (dmd should do this, but currently it just looks ahead for the first semicolon. come to think of it, I should try patching that..) ANTLR has pretty good support for backtracking, so writing a D grammar for it wasn't too difficult, but then the resultant performance isn't anything near what I'd like. But what I'm wondering about LALR is will it have to back up if it chooses wrong, or can it sail on through in one parse attempt. I bet it can. And how about actual ambiguity? How well does GOLD handle that?
Oct 16 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
news:hbaom1$138v$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message
 news:hbak0n$q5b$1 digitalmars.com...
 I could count the number of places that are ambiguous syntactically or
 semantically on one hand, and maybe the number of places that require
 arbitrary lookahead also. Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example?

PrimExp -> structLiteral PrimExp -> functionLiteral and suppose structLiteral => { /* really, really looooooooooong expression*/ } functionLiteral => { statement } functionLiteral => { /* really, really looooooooooong expression*/ ; } In an LL(k) parser, when you get to PrimExp, you have to know which choice to make based on the first k lookahead characters (probably translates to '{' and one token past that). Obviously, that won't work for this piece, so it isn't LL(k). You have to try parsing the one, and back up and parse the other if the first one fails (dmd should do this, but currently it just looks ahead for the first semicolon. come to think of it, I should try patching that..) ANTLR has pretty good support for backtracking, so writing a D grammar for it wasn't too difficult, but then the resultant performance isn't anything near what I'd like. But what I'm wondering about LALR is will it have to back up if it chooses wrong, or can it sail on through in one parse attempt. I bet it can.

I'll write up a test in a minute, but for the specific type of lookahead you're talking about, that shouldn't be a problem for LR's in general (including LALR). An LR doesn't start with 'PrimExp', it starts by looking at that first '{'. At this point it doesn't give a rat's tiny hiney what nonterminal the '{' is part of - it'll just consume more tokens until it narrows down the list of "possible matches" to just one (or none, in the case of a syntax error). And once that happens, it already knows all it needs to know, and it moves on. So there's no looking ahead or backtracking needed (except maybe for a one-token lookahead to see if the next token is allowed and what possible matches it might rule out)
 And how about actual ambiguity? How well does GOLD handle that?

When you use GOLD to compile a grammar into a "compiled grammar table" (which will be used by the parsing engine), it'll identify and report any ambiguities, which, in LR parsing, fall in to one of two categories: Reduce-Reduce conflicts: GOLD flags these as errors. Shift-Reduce conflicts: GOLD flags these as warnings and attempts to resolve them by always assuming "shift". Sometimes that works out fine, sometimes it doesn't. But it's best to minimize them in any case. With either type of ambiguity, it'll tell you all about the offending rule(s), and allow you to jump to a view of the related state in the LALR state table. (It handles lex problems similarly.)
Oct 16 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hbblfe$2k4s$1 digitalmars.com...
 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
 news:hbaom1$138v$1 digitalmars.com...
 Well, let's see here...

 PrimExp -> structLiteral
 PrimExp -> functionLiteral

 and suppose

 structLiteral => { /* really, really looooooooooong expression*/ }

 functionLiteral => { statement }
 functionLiteral => { /* really, really looooooooooong expression*/ ; }

 In an LL(k) parser, when you get to PrimExp, you have to know which
 choice to make based on the first k lookahead characters (probably
 translates to '{' and one token past that). Obviously, that won't work
 for this piece, so it isn't LL(k). You have to try parsing the one, and
 back up and parse the other if the first one fails (dmd should do this,
 but currently it just looks ahead for the first semicolon. come to think
 of it, I should try patching that..)

 ANTLR has pretty good support for backtracking, so writing a D grammar
 for it wasn't too difficult, but then the resultant performance isn't
 anything near what I'd like.

 But what I'm wondering about LALR is will it have to back up if it
 chooses wrong, or can it sail on through in one parse attempt. I bet it
 can.

I'll write up a test in a minute,

No sweat :) ----------------------------------------------------------- "Start Symbol" = <Program> ! ------ Terminals Identifier = {Letter}{AlphaNumeric}* Statement = 'foo' ! ------ Rules <Program> ::= <Prim Exp> | <Program> <Prim Exp> <Prim Exp> ::= <StructLit> | <Func Lit> <StructLit> ::= '{' <Expression> '}' <Func Lit> ::= '{' Statement '}' | '{' <Expression> ';' '}' <Expression> ::= <Expression> '+' <Mult Exp> | <Expression> '-' <Mult Exp> | <Mult Exp> <Mult Exp> ::= <Mult Exp> '*' <Negate Exp> | <Mult Exp> '/' <Negate Exp> | <Negate Exp> <Negate Exp> ::= '-' <Value> | <Value> <Value> ::= Identifier | '(' <Expression> ')' -----------------------------------------------------------
Oct 16 2009
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Nick Sabalausky wrote:
 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
 news:hbaom1$138v$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message
 news:hbak0n$q5b$1 digitalmars.com...
 I could count the number of places that are ambiguous syntactically or
 semantically on one hand, and maybe the number of places that require
 arbitrary lookahead also. Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

you give me a simple example?

PrimExp -> structLiteral PrimExp -> functionLiteral and suppose structLiteral => { /* really, really looooooooooong expression*/ } functionLiteral => { statement } functionLiteral => { /* really, really looooooooooong expression*/ ; } In an LL(k) parser, when you get to PrimExp, you have to know which choice to make based on the first k lookahead characters (probably translates to '{' and one token past that). Obviously, that won't work for this piece, so it isn't LL(k). You have to try parsing the one, and back up and parse the other if the first one fails (dmd should do this, but currently it just looks ahead for the first semicolon. come to think of it, I should try patching that..) ANTLR has pretty good support for backtracking, so writing a D grammar for it wasn't too difficult, but then the resultant performance isn't anything near what I'd like. But what I'm wondering about LALR is will it have to back up if it chooses wrong, or can it sail on through in one parse attempt. I bet it can.

I'll write up a test in a minute, but for the specific type of lookahead you're talking about, that shouldn't be a problem for LR's in general (including LALR). An LR doesn't start with 'PrimExp', it starts by looking at that first '{'. At this point it doesn't give a rat's tiny hiney what nonterminal the '{' is part of - it'll just consume more tokens until it narrows down the list of "possible matches" to just one (or none, in the case of a syntax error). And once that happens, it already knows all it needs to know, and it moves on. So there's no looking ahead or backtracking needed (except maybe for a one-token lookahead to see if the next token is allowed and what possible matches it might rule out)
 And how about actual ambiguity? How well does GOLD handle that?

When you use GOLD to compile a grammar into a "compiled grammar table" (which will be used by the parsing engine), it'll identify and report any ambiguities, which, in LR parsing, fall in to one of two categories: Reduce-Reduce conflicts: GOLD flags these as errors. Shift-Reduce conflicts: GOLD flags these as warnings and attempts to resolve them by always assuming "shift". Sometimes that works out fine, sometimes it doesn't. But it's best to minimize them in any case. With either type of ambiguity, it'll tell you all about the offending rule(s), and allow you to jump to a view of the related state in the LALR state table. (It handles lex problems similarly.)

Does GOLD let you manually specify how to resolve the ambiguities? Cuz you're going to have them with D, and murphy says they're going to be reduce-reduce :) All in all, she sounds pretty sweet. Maybe I'll try porting my D grammar to GOLD when I'm past exams. By the way, do you know if there be any way to put conditional productions in GOLD grammars? Like if you wanted to have a grammar that recognizes D1 or D2 dependent on a settable flag? Wait wait wait wait, just looked on wikipedia, GOLD uses DFAs for lexing??!!! Please tell me she can do context sensitive lexers, otherwise how are you going to get perl-style strings let alone nesting comments?
Oct 17 2009
parent "Nick Sabalausky" <a a.a> writes:
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
news:hbcq8b$avf$1 digitalmars.com...
 Does GOLD let you manually specify how to resolve the ambiguities? Cuz
 you're going to have them with D, and murphy says they're going to be
 reduce-reduce :)

No. Reduce-reduce are errors and require adjusting the grammar accordingly, and shift-reduce require either accepting the "resolve by assuming shift" or adjusting the grammar.
 All in all, she sounds pretty sweet. Maybe I'll try porting my D grammar
 to GOLD when I'm past exams.

 By the way, do you know if there be any way to put conditional
 productions in GOLD grammars? Like if you wanted to have a grammar that
 recognizes D1 or D2 dependent on a settable flag?

Not possible at this time, unfortunately.
 Wait wait wait wait, just looked on wikipedia, GOLD uses DFAs for
 lexing??!!! Please tell me she can do context sensitive lexers,
 otherwise how are you going to get perl-style strings let alone nesting
 comments?

For anything that GOLD doesn't normally support (such as nested comments, more than one pair of block-comments, or indentation increase/decrease), it has a kludge called "Virtual Terminals" ( http://www.devincook.com/goldparser/doc/meta-language/virtual-terminals.htm ). These let you declare a terminal, but then leave it up to the lex/parse engine (ex, Goldie) to identify it however it sees fit. I plan to add a number of very useful ones to Goldie (such as nested comments). I also plan to make an alternate implementation of GOLD that will fill in some of the missing features.
Oct 17 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
news:hbaom1$138v$1 digitalmars.com...
 But what I'm wondering about LALR is will it have to back up if it
 chooses wrong, or can it sail on through in one parse attempt. I bet it
 can.

 And how about actual ambiguity? How well does GOLD handle that?

I already answered regarding the parsing stage, but I should point out that the lexing can still backtrack (I don't know if that's obvious or not). For instance, if you have the terminals: FooKeyword = 'foo' StuffKeyword = 'fooAAAB' and input string: fooAAAC Then the lexer will get to the A's, try to match StuffKeyword, then get to the C, realize StuffKeyword doesn't match after all, so it'll then accept the FooKeyword, and continue on again from the first A. That's probably obvious to language and regex experts, but I actually learned that by accident. Someone found a bug in my Goldie GOLD engine when using their grammar, and I tracked it down to that kind of scenario and realized I was supposed to backtrack, if possible, upon a lex error instead of just noting the error and moving on. A better foundation in the theory probably would have helped me with that :) Anyway, I find this stuff neat :)
Oct 17 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Ellery,

 But what I'm wondering about LALR is will it have to back up if it
 chooses wrong,

LALR can't backup
 or can it sail on through in one parse attempt. I bet
 it can.

What it will do is parse the "{", parse an expression and /then/ use what comes next to decide what the stuff it already parsed is part of.
Oct 17 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ellery Newcomer wrote:
 ANTLR has pretty good support for backtracking, so writing a D grammar
 for it wasn't too difficult, but then the resultant performance isn't
 anything near what I'd like.

My recommendation is to forget about parser generators and just build one by hand. They're easy to write, and you won't have speed problems with them. There are other advantages, too, like better error messages and error recovery.
Oct 19 2009
parent Justin Johansson <no spam.com> writes:
Walter Bright Wrote:

 Ellery Newcomer wrote:
 ANTLR has pretty good support for backtracking, so writing a D grammar
 for it wasn't too difficult, but then the resultant performance isn't
 anything near what I'd like.

My recommendation is to forget about parser generators and just build one by hand. They're easy to write, and you won't have speed problems with them. There are other advantages, too, like better error messages and error recovery.

Walter is 110% correct. Over the years I've expended enormous amounts of energy with parser generators esp. with trying to get good error messages and error recovery (exactly as Walter suggests). Nearly every time I went back to a hand-written lexer and recursive descent parser. To see the KISS principle in action, take a look at Walter's DMDScript internals: lexer.d and parser.d. Cheers Justin Johansson
Oct 19 2009
prev sibling parent reply BCS <none anon.com> writes:
Hello Ellery,

 Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.
 

LALR needs to be able to unambiguously determine all the /completed/ productions to the left of each point by looking at nothing beyond the next token to the right. This might not be conservative enough, but I seem to remember that most parser corner cases don't crop up in practice. In general LL needs to known exactly what productions are "in process" where are LR needs to, at each level, have a finite set of options and only needs things to become unambiguous before it finishes a production. (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something)
Oct 17 2009
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
BCS wrote:
 Hello Ellery,
 
 Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

LALR needs to be able to unambiguously determine all the /completed/ productions to the left of each point by looking at nothing beyond the next token to the right. This might not be conservative enough, but I seem to remember that most parser corner cases don't crop up in practice. In general LL needs to known exactly what productions are "in process" where are LR needs to, at each level, have a finite set of options and only needs things to become unambiguous before it finishes a production. (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something)

Small world :) For some reason, my professor seems to be skipping LR parsing.
Oct 17 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Ellery,

 BCS wrote:
 
 Hello Ellery,
 
 Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

productions to the left of each point by looking at nothing beyond the next token to the right. This might not be conservative enough, but I seem to remember that most parser corner cases don't crop up in practice. In general LL needs to known exactly what productions are "in process" where are LR needs to, at each level, have a finite set of options and only needs things to become unambiguous before it finishes a production. (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something)

For some reason, my professor seems to be skipping LR parsing.

If mine did that I'd shoot him (a scorching e-mail :)
Oct 17 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ffb7838cc1d4346badae4 news.digitalmars.com...
 Hello Ellery,

 BCS wrote:

 (BTW I'm taking (but haven't yet finished) a compilers class so I
 might be missing something)

For some reason, my professor seems to be skipping LR parsing.

If mine did that I'd shoot him (a scorching e-mail :)

You should both feel lucky. The best I had was a class where we filled in the bodies of a handful of small functions in a trivial assembler (trivial meaning completely bare-minimum, and no actual lex/parse theory was used) that was written by the *cough* "professor" for a trivially simple fictitious CPU. And that was the *best* of the three colleges I've been to. (Cue Walter reminiscing about how great Caltech was... ;) )
Oct 17 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Nick,

 "BCS" <none anon.com> wrote in message

 If mine did that I'd shoot him (a scorching e-mail :)
 

in the bodies of a handful of small functions in a trivial assembler (trivial meaning completely bare-minimum, and no actual lex/parse theory was used) that was written by the *cough* "professor" for a trivially simple fictitious CPU. And that was the *best* of the three colleges I've been to.

And I'm not even at a well know CS school. I'd have asked for my money back.
Oct 18 2009
parent "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ffb8018cc1e47bb9fc55e news.digitalmars.com...
 Hello Nick,

 "BCS" <none anon.com> wrote in message

 If mine did that I'd shoot him (a scorching e-mail :)

in the bodies of a handful of small functions in a trivial assembler (trivial meaning completely bare-minimum, and no actual lex/parse theory was used) that was written by the *cough* "professor" for a trivially simple fictitious CPU. And that was the *best* of the three colleges I've been to.

And I'm not even at a well know CS school. I'd have asked for my money back.

Oh man, I've fought and lost many battles with schools that were enormously smaller then actually getting any money back. I've known *banks* that were more sensible about money (and hell, I'm even about ready to swear *those* off (I'm not referring to their investment practices)). As far as well-known schools, yea, I've noticed too that quality and level-of-notoriety have basically no correlation. Around Cleveland here (for whatever that's worth, maybe not much I suppose), John Carroll University is widely considered one of the best schools in the area, has one of the highest sets of entrance criteria, and is overall regarded very highly. Any time I've ever mentioned the school's name to anyone around Cleveland, not a single time has the reaction ever been anything less than glowingly positive. Well...they let me in as a transfer (*far* easier to get in pretty much anywhere that way), and while I have a ton of WTF experiences about this place, there's one that always sticks out in my head: One of the CS profs I had there was a PHd (well, they pretty much all were). But with this particular one, he openly pointed out that C was the only language he knew. Which might not normally be so bad (although I'd at least consider it questionable), but...On one of the two or three programming assignments in the class (they were all in C and no more than about a hundred lines max), I had to fill a statically-allocated buffer with some string input from a network connection, echo it to stdout, repeat until the input was exhausted, and exit (yea, not exactly a taxing assignment - and keep in mind, this wasn't an intro or even a lower-division class, this was upper-division). Ok, so I figured, "Obviously, the input length isn't guaranteed to be a multiple of my buffer size, so when I get the final chunk I'd better toss a \0 at the end so my output doesn't include any garbage data from the previous iteration." Turned it in. Few days layer when I got it back, I got a bad grade, and he had marked that \0 I added as "This won't work". (I had tested it, of course.) I just assumed he had simply graded too fast and goofed, so I pointed it out to him and explained the problem. He looked again, studied it, and went "Nope, that won't work." I questioned some more, figuring there must be some *other* bug he was referring to that I just hadn't noticed and that just happened to have worked out by pure luck (it's certainly been known to happen in C). But the more we discussed it, the more I realized: This joker didn't have the slightest clue how null-terminated strings worked! Obviously that would be fine for a Java programmer, or C#, Python, D, etc., but here was this guy who didn't understand one of the most basic concepts in what he himself admits is the only language he knows...and not only does some group of idiots actually give him a PHd in CS, but some other idiots actually hire him to teach it at an allegedly "very good school". Of course, I *am* well aware there's a big distinction between programming and computer science...but this was was just plain ridiculous. You can't call someone a handyman if they've studied a million books on the subject but don't know how to work a screwdriver. And that was just one of many contradictions to John Carroll's alleged quality. Don't get me started on their Sociology dept. And the students...oh, man...I swear I am not exaggerating even the slightest bit when I say that most of them were, without a doubt, among the absolute stupidest people I've ever met in my life (and to top it off, they had the personalities of dry sponges). And yet, this school was known to have fairly strict entrance criteria. The whole place was so pathetic I pretty much just "checked-out" most of my third semester there and then left for a different place (which had a whole other set of...dysfunctions, to put it *very* mildly...). The school I had gone to before that was well-known as a party school (BGSU), and as awful as it was, it was actually *better* than the well-respected JCU in almost every way.
Oct 19 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 (Cue Walter reminiscing about how great Caltech was... ;) ) 

The only software course I took at Caltech was a Fortran one. I can't remember anything about it <g>.
Oct 19 2009
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
BCS wrote:
 Hello Ellery,
 
 BCS wrote:

 Hello Ellery,

 Do LALR parsers care about arbitrary
 lookahead? LL(k) parsers do.

productions to the left of each point by looking at nothing beyond the next token to the right. This might not be conservative enough, but I seem to remember that most parser corner cases don't crop up in practice. In general LL needs to known exactly what productions are "in process" where are LR needs to, at each level, have a finite set of options and only needs things to become unambiguous before it finishes a production. (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something)

For some reason, my professor seems to be skipping LR parsing.

If mine did that I'd shoot him (a scorching e-mail :)

It's probably because he can't make us write a LALR parser by hand.
Oct 17 2009
parent BCS <none anon.com> writes:
Hello Ellery,

 BCS wrote:
 
 Hello Ellery,
 
 For some reason, my professor seems to be skipping LR parsing.
 



For a small language he could. My prof has done several 2-4 production grammars, by hand, on the board, in class!
Oct 18 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
news:hbd6q8$1o55$1 digitalmars.com...
 For some reason, my professor seems to be skipping LR parsing.

Gold's documentation has a lot of good starting point information: http://www.devincook.com/goldparser/articles/lalr.htm http://www.devincook.com/goldparser/doc/meta-language/index.htm http://www.devincook.com/goldparser/doc/engine-pseudo/index.htm LR's are typically considered a little more powerful than LL (although ANTLR has pushed LLs impressively far), and they work in basically the opposite way. If you have: A --> B1 | B2 B1 --> "foo1" | "foo2" B2 --> "foo3" | "foo4" An LL, as you know, starts at the A and works it way down. But an LR starts by matching one of those "foo"s and then works it's way up by reducing to one of the Bs and then to A.
Oct 17 2009
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hbdana$27s9$1 digitalmars.com...
 "Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
 news:hbd6q8$1o55$1 digitalmars.com...
 For some reason, my professor seems to be skipping LR parsing.

Gold's documentation has a lot of good starting point information: http://www.devincook.com/goldparser/articles/lalr.htm http://www.devincook.com/goldparser/doc/meta-language/index.htm http://www.devincook.com/goldparser/doc/engine-pseudo/index.htm LR's are typically considered a little more powerful than LL (although ANTLR has pushed LLs impressively far), and they work in basically the opposite way. If you have: A --> B1 | B2 B1 --> "foo1" | "foo2" B2 --> "foo3" | "foo4" An LL, as you know, starts at the A and works it way down. But an LR starts by matching one of those "foo"s and then works it's way up by reducing to one of the Bs and then to A.

Also, you can use GOLD to actually step through the parsing process, so that's a very good way to get the hang of what's going on in an LR.
Oct 17 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 (BTW I'm taking (but haven't yet finished) a compilers class so I might 
 be missing something)

That's one of my gripes about compiler classes, they expend enormous effort on the simplest part of a compiler - the lexer/parser. In working on the D compiler, I easily spend less than 1% of the effort on the lexer/parser. Plug: you should sign up for my compiler construction seminar! We don't waste much time on the simple stuff, and do the hard bits instead. /Plug
Oct 19 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Walter Bright wrote:
 BCS wrote:
 (BTW I'm taking (but haven't yet finished) a compilers class so I
 might be missing something)

That's one of my gripes about compiler classes, they expend enormous effort on the simplest part of a compiler - the lexer/parser. In working on the D compiler, I easily spend less than 1% of the effort on the lexer/parser. Plug: you should sign up for my compiler construction seminar! We don't waste much time on the simple stuff, and do the hard bits instead. /Plug

Had the last one been in the summer and not during classes while I'm 2500 miles away, I would have.
Oct 19 2009
prev sibling parent BCS <none anon.com> writes:
Hello Walter,

 BCS wrote:
 
 (BTW I'm taking (but haven't yet finished) a compilers class so I
 might be missing something)
 

effort on the simplest part of a compiler - the lexer/parser. In working on the D compiler, I easily spend less than 1% of the effort on the lexer/parser. Plug: you should sign up for my compiler construction seminar! We don't waste much time on the simple stuff, and do the hard bits instead. /Plug

I'd love to, but I'm broke. OTOH I might get lucky and have a job by the next one. When/where/how much/link?
Oct 19 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 16 Oct 2009 16:20:31 +0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Denis Koroskin wrote:
 On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg <doob me.com> wrote:

 Here is my thoughts and what I think is needed to build a really good  
 IDE and maybe get some attention from the enterprise. It's really not  
 enough for the compiler to output some json for an IDE to use, the  
 whole tool chain needs to be revised.

 Compiler:
   * Written in D
   * Supports all major platform
   * 32 and 64bit support
   * Doesn't have annoying bugs like forward reference errors and  
 problem
     with the linker
   * Built with and IDE in mind
   * Can be built as a (dynamic)library
   * Can build dynamic libraries
   * Supports incremental builds
   * Has clearly separate components, especially the front- and  
 back-end.
   * Has a license that allows it to be built into an IDE and/or shipped
     with an IDE
   * Basically something like LLVM + Clang

 Compiler or separate tool:
   * Automatically tracks all dependencies and builds the
     application/library (like DSSS)

 GUI library:
   * Written in D
   * Supports all major platforms (mac, linux, win)
   * Uses native controls (as much as possible) to draw its controls
   * Supports (de)serializing controls (Glade, nib)

 IDE:
   * Written in D
   * Be able to show syntax and semantic errors as you type
   * Autocompletion
   * Refactoring
   * Building
   * Supports incremental builds
   * Basically something like Eclipse JDT

 GUI builder:
   * Supports (de)serializing controls (Glade, nib)
   * Basically something like Interface Builder, Glade


 All of the above would be the most optimal. For example, everything  
 don't have to be built in D but for building an IDE in D I think that  
 it would be easier.

with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource.

Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea.

Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow.
Oct 16 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 16 Oct 2009 20:11:25 +0400, Leandro Lucarella <llucax gmail.com>  
wrote:

 Ary Borenszweig, el 16 de octubre a las 14:20 me escribiste:
I can't agree more. Everything you wrote is in my TODO list,
starting with a compiler, which already compiles most of the
druntime (and hopefully will compile it fully by the end of this
week). I'll release it to public as soon as Brad creates a project
page at dsource.

Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea.

And the back-end is not free! You can't distributed and I don't think it can be ported.

I see no point in porting backend. It's still in C++ and easily accessed from D: extern (C++) { void obj_initfile(const(char)* filename, const(char)* csegname, const(char)* modname); Symbol* symbol_calloc(const(char)* id); type* type_fake(tym_t); dt_t** dtnzeros(dt_t** pdtend, targ_size_t size); void outdata(Symbol* s); dt_t ** dtnbytes(dt_t** pdtend, targ_size_t size, const(char)* ptr); type* type_alloc(tym_t ty); elem* el_ptr(Symbol*); elem* el_bin(uint, tym_t, elem*, elem*); // etc } (These functions could be then moved to a separate backend.dll so that they would be shared between DMD and D-DMD and then only backend.dll would need to be distributed) Besides, Walter gave and explicit permission to Tango devs to distribute dmd (alongside with a backend), so I believe this issue can be sorted out. Walter?
Oct 16 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el 16 de octubre a las 14:20 me escribiste:
I can't agree more. Everything you wrote is in my TODO list,
starting with a compiler, which already compiles most of the
druntime (and hopefully will compile it fully by the end of this
week). I'll release it to public as soon as Brad creates a project
page at dsource.

Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea.

And the back-end is not free! You can't distributed and I don't think it can be ported. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- El techo de mi cuarto lleno de cometas
Oct 16 2009
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Jacob Carlborg wrote:

 Here is my thoughts and what I think is needed to build a really good
 IDE and maybe get some attention from the enterprise. It's really not
 enough for the compiler to output some json for an IDE to use, the whole
 tool chain needs to be revised.

I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments:
 Compiler:
   * Supports all major platform
   * 32 and 64bit support
   * Doesn't have annoying bugs like forward reference errors and problem
     with the linker
   * Can build dynamic libraries
   * Supports incremental builds

Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context.
 Compiler or separate tool:
   * Automatically tracks all dependencies and builds the
     application/library (like DSSS)

We got this, dsss just has to be revived by someone.
 GUI library:
   * Supports all major platforms (mac, linux, win)
   * Uses native controls (as much as possible) to draw its controls
   * Supports (de)serializing controls (Glade, nib)

Not sure it needs to be written in D. Many languages use bindings and wrappers just fine. We already have QtD, DWT, wxWindows, DFL and GtkD. One of those is a port (DWT) and one is native D (DFL). The GUI situation has been so rapidly improved, it's not an impediment anymore imho.
 IDE:
   * Be able to show syntax and semantic errors as you type
   * Autocompletion
   * Refactoring
   * Building
   * Supports incremental builds
   * Basically something like Eclipse JDT

Descent is probably the closest, in some aspects it even destroys C++ IDE's (compile time stuff) already. However one or two more IDE's or very good editors would likely help. This would be my shortlist: - a polished descent which supports D2 - dmd switch to ELF on windows and support for 64-bit there - dsss redux - gdc for embedded, also some more support from phobos for systems programming?
Oct 16 2009
next sibling parent reply "Eric Suen" <eric.suen.tech gmail.com> writes:
"Lutger" wrote
 Jacob Carlborg wrote:

 Here is my thoughts and what I think is needed to build a really good
 IDE and maybe get some attention from the enterprise. It's really not
 enough for the compiler to output some json for an IDE to use, the whole
 tool chain needs to be revised.

I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments:
 Compiler:
   * Supports all major platform
   * 32 and 64bit support
   * Doesn't have annoying bugs like forward reference errors and problem
     with the linker
   * Can build dynamic libraries
   * Supports incremental builds

Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context.

Because of many programming language is not design for speed, there is no point to write a compiler in there native language. Even Java's compiler is writtern in Java, why not D? Compiler bootstrapping is very basic technique, A large proportion of programming languages are bootstrapped. It is nosense to write D compiler in C, that means the D language author does not want to use D language. Does Walter Bright use D for any projects himself? Regards, Eric
Oct 16 2009
next sibling parent Jacob Carlborg <doob me.com> writes:
On 10/17/09 04:22, Eric Suen wrote:
 "Lutger" wrote
 Jacob Carlborg wrote:

 Here is my thoughts and what I think is needed to build a really good
 IDE and maybe get some attention from the enterprise. It's really not
 enough for the compiler to output some json for an IDE to use, the whole
 tool chain needs to be revised.

I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments:
 Compiler:
    * Supports all major platform
    * 32 and 64bit support
    * Doesn't have annoying bugs like forward reference errors and problem
      with the linker
    * Can build dynamic libraries
    * Supports incremental builds

Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context.

Because of many programming language is not design for speed, there is no point to write a compiler in there native language. Even Java's compiler is writtern in Java, why not D? Compiler bootstrapping is very basic technique, A large proportion of programming languages are bootstrapped. It is nosense to write D compiler in C, that means the D language author does not want to use D language. Does Walter Bright use D for any projects himself? Regards, Eric

I think it says somewhere on the digitalmars site that there is not much gain in porting an existing project to D but all new projects will be in D. DMDScript (ECMA 262 also know as JavaScript) is written in D.
Oct 17 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
language_fan wrote:

 Sat, 17 Oct 2009 10:22:55 +0800, Eric Suen thusly wrote:
 
 Does Walter Bright use D for any projects himself?

He makes "nice" html presentations of the language, demonstrating small code snippets. They are sometimes available online :S

DMDscript, the garbage collector, the runtime and phobos are written in D, though DMDScript is a port of C++. I wonder if Walter even has any projects besides D and DMD? I also wonder if it isn't frustrating for Walter spending so many years on D and still writing mostly C++ code.
Oct 17 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Eric Suen wrote:
 Because of many programming language is not design for speed, there is
 no point to write a compiler in there native language. Even Java's compiler
 is writtern in Java, why not D? Compiler bootstrapping is very basic 
 technique,

Doing this would make it more difficult than necessary to move D to new platforms, and would make it more difficult than necessary to adapt it to other back ends which are usually implemented in C or C++.
 Does Walter Bright use D for any projects himself?

dmdscript, Empire, Microemacs, and any new utilities I write, such as the D archives generator.
Oct 18 2009
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 10/16/09 19:18, Lutger wrote:
 Jacob Carlborg wrote:

 Here is my thoughts and what I think is needed to build a really good
 IDE and maybe get some attention from the enterprise. It's really not
 enough for the compiler to output some json for an IDE to use, the whole
 tool chain needs to be revised.

I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments:
 Compiler:
    * Supports all major platform
    * 32 and 64bit support
    * Doesn't have annoying bugs like forward reference errors and problem
      with the linker
    * Can build dynamic libraries
    * Supports incremental builds

Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context.

As I said later in the message, that it would be the optimal and everything doesn't have to be built in D. Like D Clang is quite new and it doesn't need to be built like Clang just to attract the enterprise but I think it would be easier to build an IDE if the compiler was built more like Clang. BTW Clang is shipped with the Developer Tools on Mac.
 Compiler or separate tool:
    * Automatically tracks all dependencies and builds the
      application/library (like DSSS)

We got this, dsss just has to be revived by someone.
 GUI library:
    * Supports all major platforms (mac, linux, win)
    * Uses native controls (as much as possible) to draw its controls
    * Supports (de)serializing controls (Glade, nib)

Not sure it needs to be written in D. Many languages use bindings and wrappers just fine. We already have QtD, DWT, wxWindows, DFL and GtkD. One of those is a port (DWT) and one is native D (DFL). The GUI situation has been so rapidly improved, it's not an impediment anymore imho.

GtkD doesn't use native controls, DFL is only for windows (last I checked).
 IDE:
    * Be able to show syntax and semantic errors as you type
    * Autocompletion
    * Refactoring
    * Building
    * Supports incremental builds
    * Basically something like Eclipse JDT

Descent is probably the closest, in some aspects it even destroys C++ IDE's (compile time stuff) already. However one or two more IDE's or very good editors would likely help. This would be my shortlist: - a polished descent which supports D2 - dmd switch to ELF on windows and support for 64-bit there - dsss redux - gdc for embedded, also some more support from phobos for systems programming?

Oct 17 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Jacob Carlborg wrote:

... 
 GtkD doesn't use native controls, DFL is only for windows (last I
 checked).

Sure. But think of it this way: GtkD *is* the native controls (for Gnome), only they are also usable on other platforms. Same way QT *is* native for the KDE platform. (except QT does use native controls on other platforms nowadays).
Oct 17 2009
prev sibling parent language_fan <foo bar.com.invalid> writes:
Sat, 17 Oct 2009 10:22:55 +0800, Eric Suen thusly wrote:

 Does Walter Bright use D for any projects himself?

He makes "nice" html presentations of the language, demonstrating small code snippets. They are sometimes available online :S
Oct 17 2009
prev sibling parent Justin Johansson <no spam.com> writes:
Jacob Carlborg Wrote:

 Here is my thoughts and what I think is needed to build a really good 
 IDE and maybe get some attention from the enterprise. It's really not 
 enough for the compiler to output some json for an IDE to use, the whole 
 tool chain needs to be revised.
 
 Compiler:
   * Written in D
   * Supports all major platform
   * 32 and 64bit support
   * Doesn't have annoying bugs like forward reference errors and problem
     with the linker
   * Built with and IDE in mind
   * Can be built as a (dynamic)library
   * Can build dynamic libraries
   * Supports incremental builds
   * Has clearly separate components, especially the front- and back-end.
   * Has a license that allows it to be built into an IDE and/or shipped
     with an IDE
   * Basically something like LLVM + Clang
 
 Compiler or separate tool:
   * Automatically tracks all dependencies and builds the
     application/library (like DSSS)
 
 GUI library:
   * Written in D
   * Supports all major platforms (mac, linux, win)
   * Uses native controls (as much as possible) to draw its controls
   * Supports (de)serializing controls (Glade, nib)
 
 IDE:
   * Written in D
   * Be able to show syntax and semantic errors as you type
   * Autocompletion
   * Refactoring
   * Building
   * Supports incremental builds
   * Basically something like Eclipse JDT
 
 GUI builder:
   * Supports (de)serializing controls (Glade, nib)
   * Basically something like Interface Builder, Glade
 
 
 All of the above would be the most optimal. For example, everything 
 don't have to be built in D but for building an IDE in D I think that it 
 would be easier.
 
 What we have now and what I think is the closest match:
 
 Compiler: LDC
   * Missing most of the mentioned things
   * Needs better platform support
   * At least the back-end is built like this
 
 We have DSSS and xfbuilder (or what it's called)
 
 GUI library: DWT
   * There are some bugs in the mac version
   * Doesn't support (de)serializing controls
   * Not built in a D-way
   * Maybe too heavy
 
 IDE: Descent
   * Missing some features like refactoring
   * Only supports building using an external tool
   * Needs to improve the syntax and semantic errors
   * Needs to improve the performance if possible
 
 GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses
   * To my knowledge none of the above supports a GUI library like the
     one mentioned
 
 Any comments, thoughts?
 
 /Jacob Carlborg

Excellent. This is beginning to look like a Manifesto! "It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised." You are right. That (the json) is just a bit of lipstick. Justin Johansson
Oct 16 2009