[mercury-users] Mercury Anarchive proposal

Ondrej Bojar bojar at csse.unimelb.edu.au
Fri Feb 23 19:28:45 AEDT 2007


Julian Fondren wrote:
> The Erlang community has 'jungerl', a 'jungle of Erlang code',
> as a source code repository with easy addition of maintainers,
> as with your idea, and I think it has not been nearly as
> successful as much simpler schemes in e.g. the Ruby community,
> which originally had a 'Ruby Application Archive' that didn't
> even host the projects it listed and linked to.

Could you describe in a more detail what could have made the difference? I 
know Erlang and Ruby only by name, so I cannot really assess if the main 
reason could not be simply the attractiveness of the language. Or possibly 
just a random coincidence (caused by attractiveness of the language) so that 
more active people ended around Ruby than around Erlang?

>>           # ideally, the pre-commit validation would not allow 
>> committing if
>>           # any package fails some of the tests after your change that 
>> were
>>           # successful before your change
> 
> Why is this ideal?  The most amazingly test-driven project I've
> seen, the Perl6-in-Haskell Pugs project, -needs- failing tests.

A test that should fail is easily changed to a test that must not fail.

If you are implementing a compiler/interpreter, you surely wish to have tests 
that fail to compile. If you are collecting a set of useful routines, I cannot 
see any point in having tests checking that a routine does not succeed -- I do 
not mean that a semidet predicate would fail (that is a success), I mean a 
test ensuring that a routine does never finish.

> If no tests fail, then the project is done!
                   ^ and all thinkable inputs have been checked to return
                     expected outputs

> The alternative to 'version spaghetti' is: a constant mild
> earthquake as one project incompatibly updates and N other
> projects no longer build.  Both of these alternatives require
> maintenance to clean things up, but when 'version spaghetti'
> gets bit-rotten, things just get a bit ugly.  When your
> preference gets bit-rotten, even a little bit, everything
> is exploded and useless.

I do not quite understand you, but I surely prefer the constant mild 
earthquake and all contributors authorized to do the little maintenance needed.

>> 2. People are kindly asked to stick to coding style of the package 
>> they are
>> modifying. Bringing your own package, you can bring your own style.
> 
> They are kindly asked to do something you intend to enforce? :-)

I was speaking of formatting issues. Once there is an 'indent' program for 
Mercury, I would enforce uniform formatting convention and the term 'coding 
style' would reduce to variable naming, breaking code into subroutines, level 
of commenting, algorithm design...

Thanks for all your comments,
   Ondrej.

-- 
Ondrej Bojar (mailto:obo at cuni.cz / bojar at ufal.mff.cuni.cz)
http://www.cuni.cz/~obo
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the users mailing list