Hello Robert,
thank you for taking the time to read my proposal.
On 3/25/11 5:48 AM, Robert Jacques wrote:
First and foremost, I would strongly recommend against looking at
Thrifts internals; if you do, the project _should not_ be submitted to
Phobos. (Thrift is Apache License 2.0 which isn't compatible with the
Boost License). Alternatively, you could aim to get the library into
etc.*, or simply make it a D source project. I do feel that aiming for
Phobos would strengthen your application though.
This can certainly be discussed, but I don't think including this
project into Phobos would be the best choice – at least as long as an
external »interface compiler«, i.e. generator would be used –, but
rather trying to make it a part of the official Thrift project. This is
how Thrift support was done for other languages, and having the code
generator implementation in another project than the library it targets
seems not like a wise thing to do.
Although I'm not a lawyer, I have been involved with D long enough to be
aware of a large part of the issues which can originate from Phobos
being Boost-licensed. If we decide that we want to have Thrift support
in Phobos itself, it would, strictly speaking, become hairy with regards
to IP anyway, because at least as far as I can see, some protocol
details are in fact implementation-defined.
Figuring these protocol details out from the code is just what I meant
to do anyway, I'll clarify the draft with regard to this.
[…] But one of the major advantages of CTFE is that there is no difference between regular D functions and CTFE D, so you can develop a full Thrift IDL parser/code generator in D and then use it as part of a build to today and an input to a string mixin tomorrow.I think playing up D's strengths, and that you are coding with an eye to
the future, would strengthen your application.
To be honest, I don't think this will be possible with D CTFE in thee
near future until somebody steps forward and radically improves the
current CTFE implementation (thinking of it, this might be a nice
project for GSoC as well).
To back my pessimism a bit: I was doing a simple CTFE implementation of
Gaussian elimination some weeks ago. Coming up with a version DMD would
accept for compile-time values took me something like ten minutes,
complete with runtime unittests. However, it wasn't until I spent two
more afternoons of debugging (and two new wrong-code Bugzilla entries)
until the CTFE results would actually match the runtime values computed
by the same piece of code.
And that was for code specifically written to be CTFE-friendly. In my
experience, trying to reuse non-trivial pieces of normal runtime code
not written with CTFE in mind results in even more problems – for
example, you can't even really use std.algorithm if you want your code
to run under CTFE at the moment.
These issues make me skeptical about whether taking a possible future
CTFE implementation into account is worth the hassle, even more so given
the scope of the project (the official Thrift parser is something like
3.5 kLOC, with another 4 kLOC for the actual C++ code generator).
Regarding your writing, it's fairly solid, though it feels a bit too
familiar for a formal proposal of work.
Yes, I am aware that it is written in a rather colloquial style,
decidedly too colloquial if I were to apply e.g. for a research grant.
But as this, as far as I know, is not even going to leave the D
community, I was not at all sure about the right level of formality.
Thanks for the suggestion, though, as I was planning to give it a
stylistic overhaul before the official submission anyway.
While I don't have the time for a mentorship, I have been working on an
update to std.json, std.variant/algebraic as well as my own binary
serialization library, and am willing to share code and/or talk
serialization/de-serialization design.
Thank you for the offer, I'll certainly contact you if this project
should be approved. Also, being able to build on a solid JSON library
will probably also be helpful for this project, as Thrift includes a
JSON-based protocol.
David
