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

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.

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.

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 :)

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 =

for
 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=

lem
 =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=

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

ed
 =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 =

be
 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.

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.

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.

"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.

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.

"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

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

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.

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.

"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.

"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.

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.

"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.

  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.

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.

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.

 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.

 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

"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). 

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). 
 
 

All but the hard parts :)

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.

"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? 

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

"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.

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.

 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.
 
 
 

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)

"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> ')'
-------------------------------------------------------

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.

 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? 
 
 

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.

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

"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?

 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, 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.)

"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> ')'

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

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.

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

 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, 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?

"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.

"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 :) 

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.

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.

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

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)

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.

BCS <none anon.com> writes:

Hello Ellery,

 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.
 

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

"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)

 Small world :)

 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... ;) ) 

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 :)
 

 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.

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

"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 :)

 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.

 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!


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.

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>.

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.

 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.

 
 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.

BCS <none anon.com> writes:

Hello Ellery,

 BCS wrote:
 
 Hello Ellery,
 
 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.
 

For a small language he could. My prof has done several 2-4 production
grammars, 
by hand, on the board, in class!

"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.

"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.

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

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.

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)
 

 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
 

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?

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

"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?

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?

"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

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.

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

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. 

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.

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?

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).

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