https://github.com/billsix/bug/blob/master/src/bug.pdf

On Mon, Aug 1, 2016 at 12:14 AM, Adam adam.mlmb@gmail.com wrote:

Yes PDF please. If you don't want the current PDF to remain on the Internet, maybe you can upload it and then remove it in fixnum days.

2016-08-01 9:03 GMT+08:00 Bill Six billsix@gmail.com:

...

Marc, et al.,

I'm finishing writing an open-source book/library on Computation at Compile Time, using Gambit. Before I self-publish it, I would like feedback.

The book is about augmenting the compiler with the code which it is compiling, thus treating the compiler as an interpreter. Testing dominates the compile-time computation, as each procedure in the book is collocated with tests for that procedure. Should any test fail, the library does not get built.

Sound interesting? The code is at https://github.com/billsix/bug, but I will send my current PDF on request.

Bill Six

---

Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

Thanks for taking a look! Comments inline:

On Aug 1, 2016 10:02 AM, "Marc Feeley" feeley@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