View mode: basic / threaded / horizontal-split · Log in · Help
September 02, 2008
D parser in tango or phobos
Hi

When building tools for manipulating d code, you practical always need a
parser.

So, why not include a d parser as part of the runtime library,
in that way the it is much easy to write code tools.

dmd itself might even use the same parser, which
will insure that the parser support the latest version of d and it will
be a nice start for a incremental d compiler.


-- 
Crowdnews.eu - a social news site based on sharing instead of voting.
Follow me on CrowdNews http://crowdnews.eu/users/addGuide/42/
September 02, 2008
Re: D parser in tango or phobos
在 Tue, 02 Sep 2008 15:37:38 +0800,Knud Soerensen  
<4tuu4k002@sneakemail.com> 写道:

> Hi
>
> When building tools for manipulating d code, you practical always need a
> parser.
>
> So, why not include a d parser as part of the runtime library,
> in that way the it is much easy to write code tools.
>
> dmd itself might even use the same parser, which
> will insure that the parser support the latest version of d and it will
> be a nice start for a incremental d compiler.
>
>

It's not easy to have a complete working bug free parser.  
dsource.org/projects/dparser

and there're something else like Aziz's dil, and pragma's ddl subproject  
enki generated
dparser, also Jascha's parser generator APaGed(which is also capable of  
generating a
 simple parser).



dparser provides a lot more semantic analysis than those others as far as  
I can see, while
there're a lot bugs in it.

Dil should be the cleanest. There're a lot great ideas. While a lot  
semantics not done yet.

It's your choice to choose


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
September 03, 2008
Re: D parser in tango or phobos
davidl wrote:
> 在 Tue, 02 Sep 2008 15:37:38 +0800,Knud Soerensen
> <4tuu4k002@sneakemail.com> 写道:
> 
>> Hi
>>
>> When building tools for manipulating d code, you practical always need a
>> parser.
>>
>> So, why not include a d parser as part of the runtime library,
>> in that way the it is much easy to write code tools.
>>
>> dmd itself might even use the same parser, which
>> will insure that the parser support the latest version of d and it will
>> be a nice start for a incremental d compiler.
>>
>>
> 
> It's not easy to have a complete working bug free parser.
> dsource.org/projects/dparser
> 
I know this is why I made the suggestion.

The idea is that tool developer should have a stable platform
base his tool upon.

Such he doesn't have to patch the parser every time a new version of dmd
hits the web.


-- 
Crowdnews.eu - a social news site based on sharing instead of voting.
Follow me on CrowdNews http://crowdnews.eu/users/addGuide/42/
September 03, 2008
Re: D parser in tango or phobos
在 Wed, 03 Sep 2008 21:51:47 +0800,Knud Soerensen  
<4tuu4k002@sneakemail.com> 写道:

> davidl wrote:
>> 在 Tue, 02 Sep 2008 15:37:38 +0800,Knud Soerensen
>> <4tuu4k002@sneakemail.com> 写道:
>>
>>> Hi
>>>
>>> When building tools for manipulating d code, you practical always need  
>>> a
>>> parser.
>>>
>>> So, why not include a d parser as part of the runtime library,
>>> in that way the it is much easy to write code tools.
>>>
>>> dmd itself might even use the same parser, which
>>> will insure that the parser support the latest version of d and it will
>>> be a nice start for a incremental d compiler.
>>>
>>>
>>
>> It's not easy to have a complete working bug free parser.
>> dsource.org/projects/dparser
>>
> I know this is why I made the suggestion.
>
> The idea is that tool developer should have a stable platform
> base his tool upon.
>
> Such he doesn't have to patch the parser every time a new version of dmd
> hits the web.
>
>

What you're asking is simply impossible. It's equivalent to why we don't  
have a bug-free
frontend.



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
September 06, 2008
Re: D parser in tango or phobos
On Wed, 03 Sep 2008 16:33:11 +0100, davidl <davidl@126.com> wrote:

> 在 Wed, 03 Sep 2008 21:51:47 +0800,Knud Soerensen  
> <4tuu4k002@sneakemail.com> 写道:
>
>> davidl wrote:
>>> 在 Tue, 02 Sep 2008 15:37:38 +0800,Knud Soerensen
>>> <4tuu4k002@sneakemail.com> 写道:
>>>
>>>> Hi
>>>>
>>>> When building tools for manipulating d code, you practical always  
>>>> need a
>>>> parser.
>>>>
>>>> So, why not include a d parser as part of the runtime library,
>>>> in that way the it is much easy to write code tools.
>>>>
>>>> dmd itself might even use the same parser, which
>>>> will insure that the parser support the latest version of d and it  
>>>> will
>>>> be a nice start for a incremental d compiler.
>>>>
>>>>
>>>
>>> It's not easy to have a complete working bug free parser.
>>> dsource.org/projects/dparser
>>>
>> I know this is why I made the suggestion.
>>
>> The idea is that tool developer should have a stable platform
>> base his tool upon.
>>
>> Such he doesn't have to patch the parser every time a new version of dmd
>> hits the web.
>>
>>
>
> What you're asking is simply impossible. It's equivalent to why we don't  
> have a bug-free
> frontend.
>
Its not impossible just difficult.
One of the first questions some people ask when
told about a new language is "what is it written in?"
If its not written in itself they ask why. If the answer is not compelling  
they
may walk away.
If D ever intends to supplant C as the main systems programming language
it will have to get over this hurdle.
A problem is that the language is itself not that stable. You could write  
a D
compiler in D1.0 but why bother when it will soon be obsolete. Writing a D  
compiler in
D2.0 is a moving target which makes it harder to hit but to quote full  
metal jacket
"you've just got to lead them a bit".

Python has a python parser written in python. The main interpreter is  
written in C for portability.
That is a good reason and the same reason applies for D. Why in this day  
and age C++ isn't considered
portable by most such project is beyond me.
I particularly like gcc's approach of bootstraping itself to full  
functionality. Its a shame the insides
are so gnarly.

Regards,

Bruce.
September 06, 2008
Re: D parser in tango or phobos
Bruce Adams:
> One of the first questions some people ask when
> told about a new language is "what is it written in?"
> If its not written in itself they ask why. If the answer is not compelling  
> they may walk away.

Yet, probably 98% of programmers don't care of that. Like most programmers of C#, Java, Python, Perl, Lua, Ruby, Tcl, etc. I'd like to have a D compiler written in D, but there are more urgent/important things to do, I presume.


> A problem is that the language is itself not that stable. You could write  
> a D compiler in D1.0 but why bother when it will soon be obsolete.
> Writing a D compiler in D2.0 is a moving target

Creating a back-end requires lot of work, so it may be better to use the one of GCC and LLVM, and save your time to improve the language itself.

And another possibility is to use D1 to write a compiler for D2 :-)


> Python has a python parser written in python. The main interpreter is  
> written in C for portability.

There is also a full Python interpreter (and JIT) written in Python in the works, it's named PyPy.

Bye,
bearophile
September 06, 2008
Re: D parser in tango or phobos
Bruce Adams wrote:
> On Wed, 03 Sep 2008 16:33:11 +0100, davidl <davidl@126.com> wrote:
> 
>> 在 Wed, 03 Sep 2008 21:51:47 +0800,Knud Soerensen 
>> <4tuu4k002@sneakemail.com> 写道:
>>
>>> davidl wrote:
>>>> 在 Tue, 02 Sep 2008 15:37:38 +0800,Knud Soerensen
>>>> <4tuu4k002@sneakemail.com> 写道:
>>>>
>>>>> Hi
>>>>>
>>>>> When building tools for manipulating d code, you practical always 
>>>>> need a
>>>>> parser.
>>>>>
>>>>> So, why not include a d parser as part of the runtime library,
>>>>> in that way the it is much easy to write code tools.
>>>>>
>>>>> dmd itself might even use the same parser, which
>>>>> will insure that the parser support the latest version of d and it 
>>>>> will
>>>>> be a nice start for a incremental d compiler.
>>>>>
>>>>>
>>>>
>>>> It's not easy to have a complete working bug free parser.
>>>> dsource.org/projects/dparser
>>>>
>>> I know this is why I made the suggestion.
>>>
>>> The idea is that tool developer should have a stable platform
>>> base his tool upon.
>>>
>>> Such he doesn't have to patch the parser every time a new version of dmd
>>> hits the web.
>>>
>>>
>>
>> What you're asking is simply impossible. It's equivalent to why we 
>> don't have a bug-free
>> frontend.
>>
> Its not impossible just difficult.
> One of the first questions some people ask when
> told about a new language is "what is it written in?"
> If its not written in itself they ask why. If the answer is not 
> compelling they
> may walk away.
> If D ever intends to supplant C as the main systems programming language
> it will have to get over this hurdle.
> A problem is that the language is itself not that stable. You could 
> write a D
> compiler in D1.0 but why bother when it will soon be obsolete. Writing a 
> D compiler in
> D2.0 is a moving target which makes it harder to hit but to quote full 
> metal jacket
> "you've just got to lead them a bit".
> 
> Python has a python parser written in python. The main interpreter is 
> written in C for portability.
> That is a good reason and the same reason applies for D. Why in this day 
> and age C++ isn't considered
> portable by most such project is beyond me.
> I particularly like gcc's approach of bootstraping itself to full 
> functionality. Its a shame the insides
> are so gnarly.

I completely agree. Aside from the sheer prestige of having a D compiler 
written in D, I think the language and especially the compiler & 
toolchain quality itself would benefit from Walter excessively using his 
 own language. After all, he has to walk around the same traps 
everybody else does when using D/DMD. I also think D should provide a 
whole toolchain written in D1, namely frontend, backend, testing, 
documentation and building (we have the last one already with DSSS, 
fortunately). Another benefit of this would include the possibility to 
actually use the D frontend for third party tools, since it's written in 
D. Of course, we have an open source frontend already, but it's written 
in C and poorly documented - no offense intended -, thus actually not 
really usable unless you spend quite some time digging through the 
source and writing D wrappers for it.

Frankly said, I would have thought of D1 written in D1 as the next step 
in  language development, instead of a "forked" experimental D2 
compiler. But that's just me.

Kind regards,
Alex
September 06, 2008
Re: D parser in tango or phobos
On 2008-09-06 19:56:25 +0200, Alexander Panek 
<alexander.panek@brainsware.org> said:

> Bruce Adams wrote:
>> On Wed, 03 Sep 2008 16:33:11 +0100, davidl <davidl@126.com> wrote:
>> 
>>> 在 Wed, 03 Sep 2008 21:51:47 +0800,Knud Soerensen <4tuu4k002@sneakemail.com> 写道:
>>> 
>>>> davidl wrote:
>>>>> 在 Tue, 02 Sep 2008 15:37:38 +0800,Knud Soerensen
>>>>> <4tuu4k002@sneakemail.com> 写道:
>>>>> 
>>>>>> Hi
>>>>>> 
>>>>>> When building tools for manipulating d code, you practical always need a
>>>>>> parser.
>>>>>> 
>>>>>> So, why not include a d parser as part of the runtime library,
>>>>>> in that way the it is much easy to write code tools.
>>>>>> 
>>>>>> dmd itself might even use the same parser, which
>>>>>> will insure that the parser support the latest version of d and it will
>>>>>> be a nice start for a incremental d compiler.
>>>>>> 
>>>>>> 
>>>>> 
>>>>> It's not easy to have a complete working bug free parser.
>>>>> dsource.org/projects/dparser
>>>>> 
>>>> I know this is why I made the suggestion.
>>>> 
>>>> The idea is that tool developer should have a stable platform
>>>> base his tool upon.
>>>> 
>>>> Such he doesn't have to patch the parser every time a new version of dmd
>>>> hits the web.
>>>> 
>>>> 
>>> 
>>> What you're asking is simply impossible. It's equivalent to why we 
>>> don't have a bug-free
>>> frontend.
>>> 
>> Its not impossible just difficult.
>> One of the first questions some people ask when
>> told about a new language is "what is it written in?"
>> If its not written in itself they ask why. If the answer is not compelling they
>> may walk away.
>> If D ever intends to supplant C as the main systems programming language
>> it will have to get over this hurdle.
>> A problem is that the language is itself not that stable. You could write a D
>> compiler in D1.0 but why bother when it will soon be obsolete. Writing 
>> a D compiler in
>> D2.0 is a moving target which makes it harder to hit but to quote full 
>> metal jacket
>> "you've just got to lead them a bit".
>> 
>> Python has a python parser written in python. The main interpreter is 
>> written in C for portability.
>> That is a good reason and the same reason applies for D. Why in this 
>> day and age C++ isn't considered
>> portable by most such project is beyond me.
>> I particularly like gcc's approach of bootstraping itself to full 
>> functionality. Its a shame the insides
>> are so gnarly.
> 
> I completely agree. Aside from the sheer prestige of having a D 
> compiler written in D, I think the language and especially the compiler 
> & toolchain quality itself would benefit from Walter excessively using 
> his   own language. After all, he has to walk around the same traps 
> everybody else does when using D/DMD. I also think D should provide a 
> whole toolchain written in D1, namely frontend, backend, testing, 
> documentation and building (we have the last one already with DSSS, 
> fortunately). Another benefit of this would include the possibility to 
> actually use the D frontend for third party tools, since it's written 
> in D. Of course, we have an open source frontend already, but it's 
> written in C and poorly documented - no offense intended -, thus 
> actually not really usable unless you spend quite some time digging 
> through the source and writing D wrappers for it.
> 
> Frankly said, I would have thought of D1 written in D1 as the next step 
> in  language development, instead of a "forked" experimental D2 
> compiler. But that's just me.
> 
> Kind regards,
> Alex

I think that having a compiler of a language written in itself is 
certainly nice from the intellectual point of view, but not immediately 
useful in any sense, and frankly unimportant for most people, even if 
it gives some real benefits to the language development.

Anyway if for you it is so important go and help out
	http://code.google.com/p/dil/
:)
Fawzi
September 06, 2008
Re: D parser in tango or phobos
Fawzi Mohamed wrote:
> On 2008-09-06 19:56:25 +0200, Alexander Panek 
> <alexander.panek@brainsware.org> said:
> 
>> Bruce Adams wrote:
>>> On Wed, 03 Sep 2008 16:33:11 +0100, davidl <davidl@126.com> wrote:
>>>
>>>> 在 Wed, 03 Sep 2008 21:51:47 +0800,Knud Soerensen 
>>>> <4tuu4k002@sneakemail.com> 写道:
>>>>
>>>>> davidl wrote:
>>>>>> 在 Tue, 02 Sep 2008 15:37:38 +0800,Knud Soerensen
>>>>>> <4tuu4k002@sneakemail.com> 写道:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> When building tools for manipulating d code, you practical always 
>>>>>>> need a
>>>>>>> parser.
>>>>>>>
>>>>>>> So, why not include a d parser as part of the runtime library,
>>>>>>> in that way the it is much easy to write code tools.
>>>>>>>
>>>>>>> dmd itself might even use the same parser, which
>>>>>>> will insure that the parser support the latest version of d and 
>>>>>>> it will
>>>>>>> be a nice start for a incremental d compiler.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> It's not easy to have a complete working bug free parser.
>>>>>> dsource.org/projects/dparser
>>>>>>
>>>>> I know this is why I made the suggestion.
>>>>>
>>>>> The idea is that tool developer should have a stable platform
>>>>> base his tool upon.
>>>>>
>>>>> Such he doesn't have to patch the parser every time a new version 
>>>>> of dmd
>>>>> hits the web.
>>>>>
>>>>>
>>>>
>>>> What you're asking is simply impossible. It's equivalent to why we 
>>>> don't have a bug-free
>>>> frontend.
>>>>
>>> Its not impossible just difficult.
>>> One of the first questions some people ask when
>>> told about a new language is "what is it written in?"
>>> If its not written in itself they ask why. If the answer is not 
>>> compelling they
>>> may walk away.
>>> If D ever intends to supplant C as the main systems programming language
>>> it will have to get over this hurdle.
>>> A problem is that the language is itself not that stable. You could 
>>> write a D
>>> compiler in D1.0 but why bother when it will soon be obsolete. 
>>> Writing a D compiler in
>>> D2.0 is a moving target which makes it harder to hit but to quote 
>>> full metal jacket
>>> "you've just got to lead them a bit".
>>>
>>> Python has a python parser written in python. The main interpreter is 
>>> written in C for portability.
>>> That is a good reason and the same reason applies for D. Why in this 
>>> day and age C++ isn't considered
>>> portable by most such project is beyond me.
>>> I particularly like gcc's approach of bootstraping itself to full 
>>> functionality. Its a shame the insides
>>> are so gnarly.
>>
>> I completely agree. Aside from the sheer prestige of having a D 
>> compiler written in D, I think the language and especially the 
>> compiler & toolchain quality itself would benefit from Walter 
>> excessively using his   own language. After all, he has to walk around 
>> the same traps everybody else does when using D/DMD. I also think D 
>> should provide a whole toolchain written in D1, namely frontend, 
>> backend, testing, documentation and building (we have the last one 
>> already with DSSS, fortunately). Another benefit of this would include 
>> the possibility to actually use the D frontend for third party tools, 
>> since it's written in D. Of course, we have an open source frontend 
>> already, but it's written in C and poorly documented - no offense 
>> intended -, thus actually not really usable unless you spend quite 
>> some time digging through the source and writing D wrappers for it.
>>
>> Frankly said, I would have thought of D1 written in D1 as the next 
>> step in  language development, instead of a "forked" experimental D2 
>> compiler. But that's just me.
>>
>> Kind regards,
>> Alex
> 
> I think that having a compiler of a language written in itself is 
> certainly nice from the intellectual point of view, but not immediately 
> useful in any sense, and frankly unimportant for most people, even if it 
> gives some real benefits to the language development.

There might not be an immediate impact of glory, but still, my point 
about third party tools still stands. The DMD frontend as it is now is 
not easily usable as such. Thus, it's not only "certainly nice from the 
intellectual point of view", but also from a practical point of view - 
i.e. the view of any developer that might want to interact with the 
semantics of D code that is not compiled with the program.

> Anyway if for you it is so important go and help out
>     http://code.google.com/p/dil/
> :)

I know about dil, and I neither have the qualification nor the time to 
work on a compiler. I'm already involved in too many projects around D. ;)

Kind regards,
Alex
September 07, 2008
Re: D parser in tango or phobos
Alexander Panek wrote:
> I completely agree. Aside from the sheer prestige of having a D compiler 
> written in D, I think the language and especially the compiler & 
> toolchain quality itself would benefit from Walter excessively using his 
>  own language. After all, he has to walk around the same traps everybody 
> else does when using D/DMD. I also think D should provide a whole 
> toolchain written in D1, namely frontend, backend, testing, 
> documentation and building (we have the last one already with DSSS, 
> fortunately). Another benefit of this would include the possibility to 
> actually use the D frontend for third party tools, since it's written in 
> D. Of course, we have an open source frontend already, but it's written 
> in C and poorly documented - no offense intended -, thus actually not 
> really usable unless you spend quite some time digging through the 
> source and writing D wrappers for it.
> 
> Frankly said, I would have thought of D1 written in D1 as the next step 
> in  language development, instead of a "forked" experimental D2 
> compiler. But that's just me.

After that we could also finally get rid of the C runtime library on 
this way and reduce the overall size of the compiled applications. These 
are two further important points - at least in my opinion.

In VC I'd love the fact that it is possible to write applications that 
are only a few kb small and also to compile them without including the C 
Runtime library at all. It would be great if that was also possible in D.

LLAP,
Sascha
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home