View mode: basic / threaded / horizontal-split · Log in · Help
March 07, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Wednesday, 7 March 2012 at 21:15:46 UTC, dnewbie wrote:
> Zach the Mystic - I can't compile it.

Still not working?
March 07, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
It's working..

Pretty cool :)



On Thu, Mar 8, 2012, at 12:07 AM, Zach the Mystic wrote:
> On Wednesday, 7 March 2012 at 21:15:46 UTC, dnewbie wrote:
> > Zach the Mystic - I can't compile it.
> 
> Still not working?
> 
> 
> 
>
March 08, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Wednesday, 7 March 2012 at 23:35:48 UTC, dnewbie wrote:
> It's working..
>
> Pretty cool :)

I think you're starting new threads each time you respond. You 
should find a way to respond to only the posts you want and not 
start a new thread each time. Not that I don't like the free 
advertising, but yeah.

Thanks for trying out ddmd-clean!
March 08, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
Zach the Mystic wrote:

> Check it out:

Done. Congrats!

-manfred
March 08, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
"Zach the Mystic" <reachMINUSTHISzachgmail@dot.com> wrote in message 
news:cibxxwrywnorlxwthent@forum.dlang.org...
> On Wednesday, 7 March 2012 at 20:46:40 UTC, Andrej Mitrovic wrote:
>> Hi,
>>
>> which version of the compiler can this be built with?
>>
>> I get this with 2.058:
>> dmd\binExp.d(324): Error: function dmd.binExp.EqualExp.isBit of type
>> bool() overrides but is not covariant with
>> dmd.expression.Expression.isBit of type int()
>> dmd\binExp.d(324): Error: function dmd.binExp.EqualExp.isBit does not
>> override any function
>
> Well, I was using 2.057
>
> But obviously you've found a bug I can fix rather quickly!
>
>

You should check, but I think isBit is dead code anyway.
March 08, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
"Zach the Mystic" <reachMINUSTHISzachgmail@dot.com> wrote in message 
news:afqmbmvuvizvgfooefqj@forum.dlang.org...

> I'll gladly put a license on it if the leaders of the community tell me 
> which one to use ( Artistic, libpng, Boost ).
>
> Zach

It will need to be the same license as the frontend (GPL/Artistic).  It 
should be at the top of each c++ source file.
March 08, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, 8 March 2012 at 01:38:43 UTC, Daniel Murphy wrote:
>
> You should check, but I think isBit is dead code anyway.

I think it is. I've left a number of dead codes because it helped 
me understand the whole system better. There's a lot of isXXX() 
functions which come in handy, so maybe isBit will too. I have no 
reason to cut it until I fully understand that it's not going to 
be useful.
March 08, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, 8 March 2012 at 01:43:26 UTC, Daniel Murphy wrote:
> "Zach the Mystic" <reachMINUSTHISzachgmail@dot.com> wrote in 
> message
> news:afqmbmvuvizvgfooefqj@forum.dlang.org...
>
>> I'll gladly put a license on it if the leaders of the 
>> community tell me which one to use ( Artistic, libpng, Boost ).
>>
>> Zach
>
> It will need to be the same license as the frontend 
> (GPL/Artistic).  It
> should be at the top of each c++ source file.

It looks like the license is going to have to be GPL because it 
says so strictly in dmd's readme.txt. Somehow that license scares 
me, though. The "Free Software Foundation" seems like a very 
Orwellian institution to me. I hope it doesn't scare users away.

So be it.
March 08, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 3/7/12 5:02 PM, Zach the Mystic wrote:
> Check it out:
> https://github.com/zachthemystic/ddmd-clean/
>
> This program is an adaptation of the work done by the ddmd team:
> http://www.dsource.org/projects/ddmd
>
> I described most of it in the README. I hope it runs smoothly for you. I
> only ran it on MAC OSX, and I don't know much about github or about how
> to get things running smoothly for others.
>
> Don't expect miracles. The parser is NOT up to date, e.g. => with the
> lastest lambda syntax.
>
> I'll gladly put a license on it if the leaders of the community tell me
> which one to use ( Artistic, libpng, Boost ).
>
> Onward and upward to IDE functionality!
>
> Zach

Very nice!

I wonder, how did you port it?

And also, how are you going to maintain it synchronized to the lasted 
dmd version?

I ask, because I ported dmd to Java and it was really hard to maintain. 
I almost had to do it manually.

Of course, it will be much easier to diff, copy to the D code and then 
clean the code a bit. But since the files are different (the names, the 
extensions, where things are located), I guess it will be a PITA and 
you'll eventually quit.
March 08, 2012
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, 8 March 2012 at 02:32:11 UTC, Ary Manzana wrote:
>
> Very nice!
>
> I wonder, how did you port it?

Manually!
It was hard, but I'm new enough to programming in general that it 
was just as much of a learning process as a tedious grind or 
something.

> And also, how are you going to maintain it synchronized to the 
> lasted dmd version?

I'm under the impression that the syntax of the language changes 
much more rarely than the semantic and backend. While I don't 
have much experience with software maintenance, it will 
definitely be easier to maintain a mere parser than an entire 
semantic and backend.

I have two more things to say here, actually. One, you know, in a 
perfect world there would not even _be_ a D compiler written in 
C++ (i.e. only one written in D!), so I don't see why additions 
to this compiler have to be precisely like they are in dmd. They 
just need to be consistent with the language specification.

But two, I have a prospective use for this program which I am 
going to explore further. The idea is that the closer any given 
part of a compiler is to the human-readable code structure - i.e. 
the lexer is very close, the parser is a little further away, 
semantic even further, etc. - the more useful it will be as a 
development tool. As long as you can reverse any given 
compilation process - e.g. a parser is reversed by a code 
generator, a lexer by a "token generator", etc. - you can go 
backward and show the current state of the program to the user on 
the screen.

So instead of focusing on getting ddmd to work as a full-fledged 
compiler, I ( we? ) could focus on adding features which are 
useful for the development process. For example, say we are able 
to implement templates, which happen pretty soon after parsing, I 
believe, and also a reverser which allows us to put their current 
state to screen. Now we could look at the structure which WOULD 
be generated when compiled. CTFE may also be within reach, but 
I'm not at all sure because I know very little about it.

My immediate goal is to make an editor which doesn't work so much 
with text files as with fully parsed syntax trees, and merely 
converts them to code for displaying on the screen, and for 
writing to file to be sent to the actual D compiler.

Continuing with this theme, I've thought about some of the 
problems I might encounter ahead. But I'm rather excited about 
the solutions too. One obvious problem is that a parsed program 
is likely to be much more memory intensive than a text file. The 
solution I imagine to this problem is to literally convert chunks 
of a program BACK into text when they go offscreen. In other 
words, you're storing it as text, but editing it as a program 
tree. Not only would this text take up less memory, but it would 
also be easy to search through as text if that were the preferred 
editing style for the moment. It would also make writing the 
whole thing to file much faster, which will be extremely 
necessary because the whole process hinges on being able to 
quickly convert your tree to file so that it can be picked up by 
dmd, for example. Also, you could easily use any text editing 
capabilities you'd already implemented on non-D files.

Another thing I enjoy fantasizing about in this regard, is a 
program which duplicates its already parsed objects, hands them 
directly to its built-in compiler, and waits for the result 
without even needing to write to a file.

Anyway, the first thing I need is a gui, and a code generator 
capable of coloring its output appropriately, so I'm working on 
that, but it's not (even close to) ready for show yet!
1 2 3 4 5
Top | Discussion index | About this forum | D home