digitalmars.D - dmd support for IDEs and the D tool chain
- Jacob Carlborg (61/61) Oct 16 2009 Here is my thoughts and what I think is needed to build a really good
- digited (3/4) Oct 16 2009 Poseidon + xfBuild may do the job (but Poseidon needs work to run on lin...
- Jacob Carlborg (3/6) Oct 16 2009 I totally forgot about Poseidon. It has already been ported to the new
- Frank Benoit (4/14) Oct 16 2009 Needs debugging, but can run.
- Tomas Lindquist Olsen (7/68) Oct 16 2009 lem
- Jacob Carlborg (2/83) Oct 16 2009 Yes, but GtkD doesn't use native controls.
- Christopher Wright (3/7) Oct 16 2009 A minor point, I think. Eclipse doesn't look very native and has
- Nick Sabalausky (9/16) Oct 16 2009 Probably not as minor as it might seem. I find eclipse ugly. And althoug...
- Jacob Carlborg (3/20) Oct 17 2009 Yes eclipse looks ugly. It's quite hard to create a GUI that looks good
- Eric Suen (18/25) Oct 17 2009 SWT wrap native controls, and Eclipse is build on SWT, but for an
- Jacob Carlborg (3/29) Oct 17 2009 I think Azureus looks quite native and if they haven't changed anything
- Jacob Carlborg (8/15) Oct 17 2009 It depends on what you're looking at. The SWT philosophy is something
- Christopher Wright (3/20) Oct 17 2009 And the tabs are everywhere, and no attempt was made to make them look
- Nick Sabalausky (4/24) Oct 17 2009 And they take up an *enormous* amount of space. I can't actually use the...
- Denis Koroskin (5/45) Oct 16 2009 I can't agree more. Everything you wrote is in my TODO list, starting wi...
- Ary Borenszweig (4/59) Oct 16 2009 Is it a port of DMD? Because I think the main problem with above is that...
- Denis Koroskin (5/65) Oct 16 2009 Yes, it's a DMD port. Unfortunately, there is no other mature D front-en...
- Jacob Carlborg (2/66) Oct 16 2009 Let us know when it's available
- Nick Sabalausky (7/10) Oct 16 2009 FWIW, I've been meaning to try to write a D grammar for GOLD when I get ...
- Ellery Newcomer (6/19) Oct 16 2009 All but the hard parts :)
- Nick Sabalausky (5/26) Oct 16 2009 Yea, like I said, "FWIW" ;)
- Justin Johansson (7/38) Oct 16 2009 There are a zillion tutorials relating to parsing on the web.
- Nick Sabalausky (19/61) Oct 16 2009 That mentioned, in the section about LL(k), "If both A are le...
-
Ellery Newcomer
(4/75)
Oct 16 2009
Bad example.
is regular. Try making it nested parens or something - Nick Sabalausky (25/56) Oct 16 2009 If you mean it's doing it using the dfa/regex lexing engine instead of t...
- Ellery Newcomer (22/52) Oct 16 2009 Well, let's see here...
- Nick Sabalausky (22/55) Oct 16 2009 I'll write up a test in a minute, but for the specific type of lookahead...
- Nick Sabalausky (25/56) Oct 16 2009 No sweat :)
- Ellery Newcomer (13/82) Oct 17 2009 Does GOLD let you manually specify how to resolve the ambiguities? Cuz
- Nick Sabalausky (15/27) Oct 17 2009 No. Reduce-reduce are errors and require adjusting the grammar according...
- Nick Sabalausky (19/23) Oct 17 2009 I already answered regarding the parsing stage, but I should point out t...
- BCS (4/8) Oct 17 2009 What it will do is parse the "{", parse an expression and /then/ use wha...
- Walter Bright (5/8) Oct 19 2009 My recommendation is to forget about parser generators and just build
- Justin Johansson (9/18) Oct 19 2009 Walter is 110% correct. Over the years I've expended enormous amounts
- BCS (10/13) Oct 17 2009 LALR needs to be able to unambiguously determine all the /completed/ pro...
- Ellery Newcomer (3/22) Oct 17 2009 Small world :)
- BCS (2/26) Oct 17 2009 If mine did that I'd shoot him (a scorching e-mail :)
- Nick Sabalausky (8/20) Oct 17 2009 You should both feel lucky. The best I had was a class where we filled i...
- BCS (2/11) Oct 18 2009 And I'm not even at a well know CS school. I'd have asked for my money b...
- Nick Sabalausky (60/73) Oct 19 2009 Oh man, I've fought and lost many battles with schools that were enormou...
- Walter Bright (3/4) Oct 19 2009 The only software course I took at Caltech was a Fortran one. I can't
- Ellery Newcomer (2/32) Oct 17 2009 It's probably because he can't make us write a LALR parser by hand.
- BCS (3/13) Oct 18 2009 For a small language he could. My prof has done several 2-4 production g...
- Nick Sabalausky (15/16) Oct 17 2009 Gold's documentation has a lot of good starting point information:
- Nick Sabalausky (4/21) Oct 17 2009 Also, you can use GOLD to actually step through the parsing process, so
- Walter Bright (7/9) Oct 19 2009 That's one of my gripes about compiler classes, they expend enormous
- Ellery Newcomer (3/15) Oct 19 2009 Had the last one been in the summer and not during classes while I'm
- BCS (3/18) Oct 19 2009 I'd love to, but I'm broke. OTOH I might get lucky and have a job by the...
- Leandro Lucarella (9/18) Oct 16 2009 And the back-end is not free! You can't distributed and I don't think it
- Denis Koroskin (23/35) Oct 16 2009 I see no point in porting backend. It's still in C++ and easily accessed...
- Lutger (22/47) Oct 16 2009 I think this list is what the toolchain might look like after it already...
- Eric Suen (11/30) Oct 16 2009 Because of many programming language is not design for speed, there is
- Jacob Carlborg (4/39) Oct 17 2009 I think it says somewhere on the digitalmars site that there is not much...
- language_fan (3/4) Oct 17 2009 He makes "nice" html presentations of the language, demonstrating small
- Lutger (6/12) Oct 17 2009 DMDscript, the garbage collector, the runtime and phobos are written in ...
- Walter Bright (6/11) Oct 18 2009 Doing this would make it more difficult than necessary to move D to new
- Jacob Carlborg (7/52) Oct 17 2009 As I said later in the message, that it would be the optimal and
- Lutger (6/8) Oct 17 2009 Sure. But think of it this way: GtkD *is* the native controls (for Gnome...
- Justin Johansson (6/82) Oct 16 2009 Excellent. This is beginning to look like a Manifesto!
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
Jacob Carlborg Wrote:IDE: DescentPoseidon + 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
On 10/16/09 13:03, digited wrote:Jacob Carlborg Wrote: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.IDE: DescentPoseidon + 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
Jacob Carlborg schrieb:On 10/16/09 13:03, digited wrote:Needs debugging, but can run. I wanted to port it to the jface.text editor component, but lost motivation :)Jacob Carlborg Wrote: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.IDE: DescentPoseidon + 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
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 =forthe 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 =beeasier. 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 CarlborgGtkD supports Glade.
Oct 16 2009
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:Yes, but GtkD doesn't use native controls.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 CarlborgGtkD supports Glade.
Oct 16 2009
Jacob Carlborg wrote:On 10/16/09 12:58, Tomas Lindquist Olsen wrote:A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.GtkD supports Glade.Yes, but GtkD doesn't use native controls.
Oct 16 2009
"Christopher Wright" <dhasenan gmail.com> wrote in message news:hbarno$188s$1 digitalmars.com...Jacob Carlborg wrote: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.On 10/16/09 12:58, Tomas Lindquist Olsen wrote:A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.GtkD supports Glade.Yes, but GtkD doesn't use native controls.
Oct 16 2009
On 10/17/09 07:06, Nick Sabalausky wrote:"Christopher Wright"<dhasenan gmail.com> wrote in message news:hbarno$188s$1 digitalmars.com...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).Jacob Carlborg wrote: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.On 10/16/09 12:58, Tomas Lindquist Olsen wrote:A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.GtkD supports Glade.Yes, but GtkD doesn't use native controls.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
"Christopher Wright" wroteJacob Carlborg wrote: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 EricOn 10/16/09 12:58, Tomas Lindquist Olsen wrote:A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.GtkD supports Glade.Yes, but GtkD doesn't use native controls.
Oct 17 2009
On 10/17/09 10:31, Eric Suen wrote:"Christopher Wright" wroteI think Azureus looks quite native and if they haven't changed anything they're using SWT.Jacob Carlborg wrote: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.On 10/16/09 12:58, Tomas Lindquist Olsen wrote:A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.GtkD supports Glade.Yes, but GtkD doesn't use native controls.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
On 10/17/09 00:23, Christopher Wright wrote:Jacob Carlborg wrote: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.On 10/16/09 12:58, Tomas Lindquist Olsen wrote:A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.GtkD supports Glade.Yes, but GtkD doesn't use native controls.
Oct 17 2009
Jacob Carlborg wrote:On 10/17/09 00:23, Christopher Wright wrote:And the tabs are everywhere, and no attempt was made to make them look native to any platform.Jacob Carlborg wrote: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.On 10/16/09 12:58, Tomas Lindquist Olsen wrote:A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.GtkD supports Glade.Yes, but GtkD doesn't use native controls.
Oct 17 2009
"Christopher Wright" <dhasenan gmail.com> wrote in message news:hbcg2t$20ih$1 digitalmars.com...Jacob Carlborg wrote:And they take up an *enormous* amount of space. I can't actually use them and see their labels at the same time.On 10/17/09 00:23, Christopher Wright wrote:And the tabs are everywhere, and no attempt was made to make them look native to any platform.Jacob Carlborg wrote: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.On 10/16/09 12:58, Tomas Lindquist Olsen wrote:A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.GtkD supports Glade.Yes, but GtkD doesn't use native controls.
Oct 17 2009
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
Denis Koroskin wrote:On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg <doob me.com> wrote: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.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
On Fri, 16 Oct 2009 16:20:31 +0400, Ary Borenszweig <ary esperanto.org.ar> wrote:Denis Koroskin wrote: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.On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg <doob me.com> wrote: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.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
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:Let us know when it's availableDenis Koroskin wrote: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.On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg <doob me.com> wrote: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.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
"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
Nick Sabalausky wrote:"Denis Koroskin" <2korden gmail.com> wrote in message news:op.u1v7jdgco7cclz korden-pc...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.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
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbak0n$q5b$1 digitalmars.com...Nick Sabalausky wrote:Yea, like I said, "FWIW" ;)"Denis Koroskin" <2korden gmail.com> wrote in message news:op.u1v7jdgco7cclz korden-pc...All but the hard parts :)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.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
Nick Sabalausky Wrote:"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbak0n$q5b$1 digitalmars.com...There are a zillion tutorials relating to parsing on the web. Try googling: parsing theory tutorial 2nd hit: An introduction to parsing Cheers Justin JohanssonNick Sabalausky wrote:Yea, like I said, "FWIW" ;)"Denis Koroskin" <2korden gmail.com> wrote in message news:op.u1v7jdgco7cclz korden-pc...All but the hard parts :)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.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
"Justin Johansson" <no spam.com> wrote in message news:hbamfa$v3b$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."Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbak0n$q5b$1 digitalmars.com...There are a zillion tutorials relating to parsing on the web. Try googling: parsing theory tutorial 2nd hit: An introduction to parsingNick Sabalausky wrote:Yea, like I said, "FWIW" ;)"Denis Koroskin" <2korden gmail.com> wrote in message news:op.u1v7jdgco7cclz korden-pc...All but the hard parts :)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.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
Nick Sabalausky wrote:"Justin Johansson" <no spam.com> wrote in message news:hbamfa$v3b$1 digitalmars.com...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 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."Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbak0n$q5b$1 digitalmars.com...There are a zillion tutorials relating to parsing on the web. Try googling: parsing theory tutorial 2nd hit: An introduction to parsingNick Sabalausky wrote:Yea, like I said, "FWIW" ;)"Denis Koroskin" <2korden gmail.com> wrote in message news:op.u1v7jdgco7cclz korden-pc...All but the hard parts :)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.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
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbap0k$141i$1 digitalmars.com...Nick Sabalausky wrote: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> ')' -------------------------------------------------------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
Nick Sabalausky wrote:"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbak0n$q5b$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. And how about actual ambiguity? How well does GOLD handle that?Nick Sabalausky wrote:Yea, like I said, "FWIW" ;)"Denis Koroskin" <2korden gmail.com> wrote in message news:op.u1v7jdgco7cclz korden-pc...All but the hard parts :)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.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
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbaom1$138v$1 digitalmars.com...Nick Sabalausky wrote: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)"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbak0n$q5b$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 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?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
"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...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> ')' -----------------------------------------------------------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,
Oct 16 2009
Nick Sabalausky wrote:"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbaom1$138v$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 :) 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 wrote: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)"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message news:hbak0n$q5b$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 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?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 17 2009
"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
"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
Hello Ellery,But what I'm wondering about LALR is will it have to back up if it chooses wrong,LALR can't backupor 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
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
Walter Bright Wrote:Ellery Newcomer wrote: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 JohanssonANTLR 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
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
BCS wrote:Hello Ellery,Small world :) For some reason, my professor seems to be skipping LR parsing.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
Hello Ellery,BCS wrote:If mine did that I'd shoot him (a scorching e-mail :)Hello Ellery,Small world :) For some reason, my professor seems to be skipping LR parsing.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
"BCS" <none anon.com> wrote in message news:a6268ffb7838cc1d4346badae4 news.digitalmars.com...Hello Ellery,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 wrote:If mine did that I'd shoot him (a scorching e-mail :)(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
Hello Nick,"BCS" <none anon.com> wrote in messageAnd I'm not even at a well know CS school. I'd have asked for my money back.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.
Oct 18 2009
"BCS" <none anon.com> wrote in message news:a6268ffb8018cc1e47bb9fc55e news.digitalmars.com...Hello Nick,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."BCS" <none anon.com> wrote in messageAnd I'm not even at a well know CS school. I'd have asked for my money back.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.
Oct 19 2009
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
BCS wrote:Hello Ellery,It's probably because he can't make us write a LALR parser by hand.BCS wrote:If mine did that I'd shoot him (a scorching e-mail :)Hello Ellery,Small world :) For some reason, my professor seems to be skipping LR parsing.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
Hello Ellery,BCS wrote:For a small language he could. My prof has done several 2-4 production grammars, by hand, on the board, in class!Hello Ellery,It's probably because he can't make us write a LALR parser by hand.For some reason, my professor seems to be skipping LR parsing.If mine did that I'd shoot him (a scorching e-mail :)
Oct 18 2009
"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
"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...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.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
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
Walter Bright wrote:BCS wrote:Had the last one been in the summer and not during classes while I'm 2500 miles away, I would have.(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
Hello Walter,BCS wrote: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?(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
Ary Borenszweig, el 16 de octubre a las 14:20 me escribiste: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 cometasI 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
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 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?And the back-end is not free! You can't distributed and I don't think it can be ported.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
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 buildsClearly 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 JDTDescent 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
"Lutger" wroteJacob Carlborg 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, 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, EricHere 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 buildsClearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context.
Oct 16 2009
On 10/17/09 04:22, Eric Suen wrote:"Lutger" wroteI 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.Jacob Carlborg 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, 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, EricHere 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 buildsClearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context.
Oct 17 2009
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
language_fan wrote:Sat, 17 Oct 2009 10:22:55 +0800, Eric Suen thusly wrote: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.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
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
On 10/16/09 19:18, Lutger wrote:Jacob Carlborg wrote: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.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 buildsClearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context.GtkD doesn't use native controls, DFL is only for windows (last I checked).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 JDTDescent 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
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
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 CarlborgExcellent. 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