Re: [boost] GSoC: Enforcing Code Feature Requirements

Subject: Re: [boost] GSoC: Enforcing Code Feature Requirements
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2010-04-03 00:43:18

On Fri, Apr 2, 2010 at 5:19 AM, Vicente Botet Escriba
<vicente.botet_at_[hidden]> wrote:
>
>
>
> Gottlob Frege wrote:
>>
>> On 3/31/10, Andrew Sutton <andrew.n.sutton_at_[hidden]> wrote:
>>>> Ok I completety get it now. So, thumb up for me :)
>>>>
>>>
>>> This seems like an interesting idea. I think it might factor nicely into
>>> my
>>> PhD dissertation which seems to involve both concepts and software
>>> maintenance issues.
>>>
>>> Andrew Sutton
>>> andrew.n.sutton_at_[hidden]
>>
>>
>> I've been thinking lately that concepts and test cases and APIs and
>> documentation are all intertwined.
>>
>> D (language) allows unit tests to be coded right beside the implementation
>> code.
>> Concepts describe constraints that must be successfully 'passed' -
>> like unit tests.
>>
>> APIs and documentation often include example-code.
>>
>> unit tests are often the best examples, and often the best^H^H^H^H
>> only documentation of the API - ie the API does this - and is suppose
>> to do this - because that's what the unit tests test for.
>>
>> Docs can be written in the code comments (eg javadocs), but concepts
>> and unit tests (particularly in D) are right in the code.
>>
>> Obviously very vague ideas at the moment.  Maybe I should read up on
>> Knuth's WEB again...
>>
>>
>
> Tony, You lost me. Where do you want to go?
>
> Best,
> Vicente
>

Well, considering it was only a vague idea that has been floating
around in the back of my head, and that I wrote the email at 2am, I'm
not surprised it made little sense.  Let me try again.  And start by
saying, and this is somewhat my point, I don't know where it goes.
Maybe it is something a grad student can take and run with.  Or if
someone wants to pay my bills and feed my family, I'll investigate it
further :-)

(I should also mention that it has probably veered somewhat from your
original post about 'Code Features' and Meyers' article, and had more
to do with Andrew Sutton's response and mention of concepts and
software maintenance.  But even 'Code Features' was about verifying
necessary constraints, so I suppose it applies as well.  As I will
hopefully explain in the following...)

The idea(s) is that concepts (ala C++) are a way to *verify* that the
types passed in meet the necessary requirements.  Now this
verification is somewhat weak (more syntactic than semantic) but let's
call it verification for now.  (For more semantic checking, see David
Musser's (of STL fame) recent work on provability algorithms.)

Unit tests are also a form of verification. So there seems to be a
possible avenue of research here - using concepts as unit tests, or
merging the 2 ideas.  I think the D language, with its inherent
support for unit tests, and with its easy handling of compile-time
code, might be a an interesting testbed for some of these ideas.

Unit tests are also a form of documentation.  Sometimes the only
documentation, or at least the only accurate documentation - ie if the
docs say that the sort function is a stable-sort, but the unit-tests
don't test for 'stability' then I'd be wary as to whether the sort
really is stable - maybe it once was, but via 'fixes' and
'optimizations' is no longer meeting its claims.

And concepts are also a form of documentation.
sort<RandomAccessContainer c, StrictWeakOrder comparitor>()...
*documents* the requirements for the types necessary for sorting.  And
in general, we are always striving for 'self-documenting code'.
(Again this would be a place to mention Knuth and his WEB language,
which somewhat turns the code-document relationship on its head.)

So they all seem to be interrelated.  Makes me start to think that
over time we might be able to merge them into something more powerful.
 I have no idea what that would end up looking like.

As a start, maybe if the h file or interface of the class was
- member functions, etc - which we have now
- documentation
- unit tests
- concepts

in some consistent language, we'd have more maintainable code...

And importantly, they would need to be interrelated/merged enough that
the documentation *could not!* get out of sync with the unit tests,
which got out of sync with the concepts, which was out of sync with
the member functions.

ie if it is not consistent, it doesn't compile.  The more merged those
items are, the easier it would be to stay consistent.  If I need to
repeat that 'the comparison is a strict weak order' or 'the function
leaves the container sorted' in the code, comments, unit tests, and
concepts, then I'll go crazy (as I do now!).  I'd rather say it once.

Tony