[GSoC Proposal] Statically Checked Measurement Units

[David Nadlinger]

On 3/29/11 2:33 PM, Cristi Cobzarenco wrote:
> Surely, .mangleof returns unique strings?
Yes, .mangleof returns unique strings for types. The stringof property 
which was suggested by other people here on the NG, however, is not unique.

> […] Thanks a lot for your feedback, I feel this
> collaboration will help D in the end, no matter whose proposal gets
> accepted (if any). I am a bit confused regarding your GSoC proposal,
> aren't you a mentor?

No, I'm just hoping to participate in this GSoC as a student as well.

To clarify the situation: Having experienced how incredibly useful 
dimensional analysis is in many areas of science, I have long been 
interested in possible ways of using unit systems in programming to gain 
additional type safety. Earlier this year, before a possible application 
to GSoC was even brought up in the D community, I started to work on a D 
implementation of an unit system. I finished a working prototype, but 
didn't have the time yet to implement a flexible unit conversion scheme 
and, more importantly, extend the documentation and examples so I could 
put it up for discussion at the D NG.

Then, it was announced that Digital Mars would participate in this 
Google Summer of Code, and surprisingly it didn't take long until 
someone added an unit system to the ideas page. As I was considering to 
apply to GSoC anyway, this seemed like a natural fit. However, Andrei 
also put up the idea of a D implementation of Apache Thrift, which 
caught my attention as I have been waiting for the opportunity to have 
an in-depth look on it for quite some time now.

As I am equally interested in both topics, and students are allowed to 
submit a large number of proposals (20?), I decided to just write 
project proposals for both of them and let Walter/Andrei/… choose which 
one they like better, if any. I decided to start with the Thrift one, 
and planned to submit my units proposal later in the application period. 
After publishing my first draft here at the NG, I also contacted Andrei 
for his opinion on whether it would make sense to submit a second 
proposal, given that he seemed quite interested in the Thrift idea.

Now, back to topic: I am absolutely sure that collaborating on this 
project will lead to better results (I mean, that's how open source 
software works after all), but there is a problem: By the GSoC rules, 
it's not possible for students to work in teams on a single project. The 
dilemma I hinted at is that if we start working together right now, 
we'll probably end up with two almost identical proposals/applications 
for the same project, which doesn't really seem desirable.

Also, I'm increasingly doubtful that an units library would be a good 
fit for a Summer of Code project in the first place, which is also why I 
finished my other proposal first:

As Don said, I think that while it certainly is a nice demonstration of 
the metaprogramming capabilities/type system expressiveness of a 
language, it might not be too useful for the »general public«, compared 
to other features. Don't get me wrong here, I'm personally very 
enthusiastic about the idea, and I can imagine many possible ways in 
which a flexible unit system could be used to avoid bugs or to clarify 
interfaces. But: The concept isn't new at all – for example, during my 
research I stumbled over papers dedicated to units in programming 
languages dating back to 1985 –, but I have yet to see units actually 
being used in production code.

My second concern is the extent of the project: After spending two 
weekends on it, I have a working prototype of a units library, and, if I 
understood you correctly, you have one as well. They surely both lack 
some features and a lot of polish and documentation, but I think it 
would probably take neither of us three full months of work to get them 
into a state suitable for inclusion in the Phobos review queue.

For these reasons, I really started to wonder if it wouldn't be the 
better idea to just merge our projects and work on getting the result 
into shape independent of GSoC when I saw your proposal – even more so 
since our design/implementation ideas have shown to be quite similar. I 
don't want to discourage you from applying at all, and I will probably 
still submit a proposal for it nevertheless, but I think this should be 
discussed.

David