On 22/03/2011 17:47, Luca Boasso wrote:
Hello,
I am Luca and I am finishing my master in computer engineering. I am currently
an intern at Panasonic in Cupertino.
My great passion has been always programming language design and implementation
and I am studying the D programming language.
I like to play with different languages and in my master thesis I created a
small DSL. I am familiar with parsing theory and I wrote simple parsers
by hand and with the help of ANTLR.
I am really interested in the following ideas (sorted by interest):
- http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#LexingandParsing
-
http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#ANTLRandJavabasedDparserforIDEusage
- http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#DtoolsinD
I think that I can give my contribution and I would be more than happy to work
with you. This would be for me a great opportunity to contribute to an open
source project and a way to learn more about D and parsing.
Could you give me more information about the help needed?
Thank you
Luca Boasso
The student is free to present their own ideas, or to flesh out in more
detail a proposal for existing ideas. The first two items
(LexingandParsing, ANTLRandJavabasedDparserforIDEusage) are fairly
concrete ideas.
The last one, D Tools in D is far more general, and can involve a lot of
different things. But there are two things that I would like to say
regarding that one. First, I think that for GSoC we should focus only on
proposals that, if completed successfully, would be usable and useful on
their own, or add something of value to another project/tool/library
that would be useful. In other words, I don't find it desirable to work
on a project that would need more work done on it afterwards to only
then make a usable tool or library (for example a D-based D parser).
The second, partially related to the above, is that I find that writing
certain kinds of D tools in D is a huge waste of time. The prime example
is IDE stuff. It is crazy to be reinventing the wheel here, to not use
the frameworks and functionality that existing IDE platforms (Eclipse,
Netbeans, Visual Studio, etc.) offer. (More like rebuilding a castle
than reinventing the wheel) In this IDE case, building a tool in D is
only worthwhile if you are able to integrate it with the IDE platform.
For some kinds of tools, like build tools, debuggers, this is fairly
easy. But for parsing and semantic functionality (for example, code
complete), it is much harder. But it is not unheard of. For example the
Goclipse plugin (Eclipse-based Go IDE) uses Gocode - an external daemon
process - for its core semantic functionality. (I haven't tried it yet
to see how well it works). But it's all very like the ideas presented
here: http://vimeo.com/16069687 by Steve Yegge regarding new toolchains.
My overall point is that people should think of delivering something of
value to D developers, and not just an incomplete project. And also make
it as sustainable as possible (easier to keep up to date with changes in
D or other tools).
Of course, all of this is my personal opinion, and doesn't necessarily
reflect the opinion of the rest of the community, or the D GSoC umbrella
organization.
--
Bruno Medeiros - Software Engineer
