[gambit-list] Truck-Factor by mtov

Marc Feeley feeley at iro.umontreal.ca
Thu Jul 23 15:06:32 EDT 2015


Adding the R7RS module system to Gambit would be great!  Unfortunately, it requires a very good understanding of the Gambit internals (AST representation, parsing, environment representation in interpreter and compiler).  So before tackling such a project a contributor needs to get a better overview of the whole system.  That’s the point of (some of) the tasks I mentionned.

Documenting and writing unit tests for all the Gambit features requires looking through the source code, figuring out the function of a primitive, and testing it out (in essence writing basic unit tests).  And it *does* increase the truck-factor because those doing this will have a better understanding of the system, and other people reading the docs will also have a better understanding of the system.

Another task (not on the previous list) achieving the same goal is a refactoring of the Gambit runtime system to use the “define-library” form (https://github.com/feeley/define-library) which is very close syntactically to the R7RS module system but lacks hygiene.  This task would help clean up the source code of the runtime system (in particular it would get rid of many of the ## prefixes), it would expose the dependencies between the runtime system modules, and make the source code easier to read, understand and modify.

In fact, let me suggest you do this for _num.scm, since it is a big piece of code that’s not easy to understand and could benefit from the module system.

As for writing libraries for Gambit, that could be done with define-library in preparation of a fully R7RS compliant Gambit.  Helping out with extensions to SchemeSpheres and LambdaNative would also be good indirect contributions to Gambit.

Marc


> On Jul 23, 2015, at 2:05 PM, Bradley Lucier <lucier at math.purdue.edu> wrote:
> 
> On 07/23/2015 10:52 AM, Marc Feeley wrote:
> 
>> Here are some ideas off the top of my head:
>> 
>> - documenting all Gambit features
>> - writing unit tests for all those features
>> - maintaining Gambit packages for all linux distributions
>> - writing tutorials and use cases
> 
> 
> Marc, I once had a summer job at the National Research Council on Montreal Road outside of Ottawa, where my supervisor told me to find something interesting to do; if I couldn't find something to do, then the default job was to flowchart his main application program.
> 
> Which I thought would be *boring*.
> 
> Those things you list are useful, but they sound *boring*, and they won't increase the truck factor at all.
> 
> In 1998 you proposed to me to rewrite the Gambit bignum code; to me, that wasn't boring, and I'm still thinking about it today.  (Hell, I even used some new algorithms picked up from some research papers.)
> 
> Once Gambit has a module system of some kind, then people can begin to contribute the kind of libraries that Chicken and Racket have in spades.
> 
> Will the R7RS module system be sufficient for this purpose?
> 
> Making Gambit R7RS compliant would help things.  Whoever does it will have to learn something of Gambit's internals, I'm sure it's interesting to *someone*, and it would increase the truck factor by at least a fraction.
> 
> There must be other projects that:
> 
> 1.  Require someone to learn something about Gambit's internals.
> 2.  Have a specific goal to work towards.
> 3.  Increases the truck factor.
> 4.  Is interesting!
> 
> For example, if someone said "I have a big project about such-and-such and if Gambit only did <whatever> better" then, depending on what <whatever> is, it might be another good way for someone to get into Gambit internals and contribute something.
> 
> Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4839 bytes
Desc: not available
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20150723/2bdeb55f/attachment.bin>


More information about the Gambit-list mailing list