<p dir="ltr">Thanks for taking a look!  Comments inline:</p>
<p dir="ltr">On Aug 1, 2016 10:02 AM, "Marc Feeley" <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>> wrote:<br>
><br>
> [Sorry for the repeated posting but I’m having problems with my email…]<br>
><br>
> Hi Bill. I have little time so here are my quick comments…<br>
><br>
> 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.</p>
<p dir="ltr">Thanks!</p>
<p dir="ltr">><br>
> 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.<br>
></p>
<p dir="ltr">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)</p>
<p dir="ltr">> 3) Can you explain how unit tests for internal function definitions (non toplevel) are handled?</p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
> 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.</p>
<p dir="ltr">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 <a href="https://github.com/billsix/bug/tree/master/demo">https://github.com/billsix/bug/tree/master/demo</a>)</p>
<p dir="ltr">Thanks again, I sincerely appreciate the feedback!</p>
<p dir="ltr">Bill</p>