[gambit-list] Need review for an open-source book/library on Computation at Compile Time (using Gambit)

Bill Six billsix at gmail.com
Mon Aug 1 12:21:38 EDT 2016


Thanks for taking a look!  Comments inline:

On Aug 1, 2016 10:02 AM, "Marc Feeley" <feeley at iro.umontreal.ca> wrote:
>
> [Sorry for the repeated posting but I’m having problems with my email…]
>
> Hi Bill. I have little time so here are my quick comments…
>
> 1) Bug is an interesting project and it shows you have a good
understanding of the Gambit internals.  Your book may help users better
understand Gambit’s namespaces and macros.

Thanks!

>
> 2) It seems that unit tests can only be attached to single function
definitions (with your libbug-private#define form).  In my experience, unit
tests must sometimes check that two or more functions work together
correctly, so it is awkward to attach these tests to a specific function
definition.  For this reason, I think unit tests should be decoupled from
the function definitions, but in the same file close to the functions
tested.  This could be done with a new special form called “unit-test” for
example.  It would have the additional benefit of not requiring your
libbug-private#define form.
>

Interesting, I'll look into the necessary changes.  (Btw, every test can
reference any previously defined procedure/macro, so if you define
procedure "foo" and then define "bar", the tests for their interaction can
be in "bar"'s test section)

> 3) Can you explain how unit tests for internal function definitions (non
toplevel) are handled?

I currently don't handle them.  That's my biggest unsolved problem. (You
are smart! :-))  For instance, to implement "destructuring-bind", I needed
a nested procedure "tree-of-accessors", but to test it, I needed to extract
it to a top level form.  I'm not sure how to solve the problem generally,
especially if the nested procedure reference captured variables.

>
> 4) Your project seems to be driven by several goals: unit testing
framework, literate programming, and a new lexical syntax.  An
all-or-nothing approach like this will probably hinder acceptance by other
users.  How hard would it be to separate things out to be more modular? For
example, using the literate programming support without the new lexical
syntax.

Those are the goals for libbug itself.  Both the LaTeX support and the
lambda literal support are currently implemented as preprocessors, and are
invoked in libbug's Makefile.  So they are optional from the perspective of
programs which link against libbug; to those programs, libbug can just be a
regular Gambit library!  (My demo executable which links against libbug
does not use the literate programming preprocessor
https://github.com/billsix/bug/tree/master/demo)

Thanks again, I sincerely appreciate the feedback!

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20160801/f715c079/attachment.htm>


More information about the Gambit-list mailing list