Hi, Noah; Thanks for comments.
On 05/13/2012 Noah Lavine <[email protected]> writes: > Second, since your changes add compatibility for several Scheme > implementations, have you thought about trying to make them part of > the reference implementation? You would probably have to email Per > Bothner to ask him, but that might be the best way to make your > changes available to all of the implementations you are making it for. > If not, I hope Guile would like to have it, but I think you are > targeting more than just Guile. When I'd made my srfi-64.scm to pass srfi-64-test.scm, a test suite for the SRFI 64 itself, on Guile 2.0.0, I felt happy and remembered my googling to search a SRFI 64 implementation working on Guile. Now, the filename of srfi-64.scm is srfi-64-port.scm and the new srfi-64.scm file uses it with include-from-path. Hum... I use Guile 2.0.5 now. Anyway, I'd sent a email to Per Bothner and he had commented on it. On 04/13/2012 Per Bothner <[email protected]> writes: > This is nice. It would be great if the Guile port would be merged > into the reference implementation, presumably using cond-expand. > That way bug-fixes or changes in one could be more easily be > merged into the other. I'd misunderstood his words then. In the reply for you, Per wrote: On 04/20/2012 Per Bothner <[email protected]> writes: > My suggestion was that it would be nice (but not essential) > if the Guile implementation could be based on and merged back into > the reference implementation, perhaps using cond-expand to > encapsulate the Guile-specific changes. > > Unfortunately, this Guile port seems like a complete rewrite: > The diff (relative to the reference implementation) is over twice as big > as than the original reference implementation! This makes it difficult > to evaluate the changes, which makes it difficult to accept it as an > update to the reference implementation. I was hoping the Guile port would > be a modest set of changes to the reference implementation; this is > not. After his first comments, I'd misunderstood it of course, I found the reference implementation does not pass srfi-64-test.scm on Chicken and Gambit either. I fixed it with my srfi-64.scm. After his second comments, a reply for you of course, I understood his first comments and made a patch file for the reference implementation. That patch was just for Guile and not included fix for Chicken and Gambit. On 04/21/2012 Per Bothner <[email protected]> writes: > Much better. I applied your patch to the reference implementation, > and that seems to work. I source file name and line numbers, which > makes things much more pleasant. I'm waiting Per publish a new version of the reference implementation. In the mean while, I had realized my srfi-64.scm had a bug; I'd used cond-expand-provide within cond-expand and that made a problem. So, I renamed srfi-64.scm to srfi-64-port.scm and wrote a new srfi-64.scm using it with include-from-path. Talking about Gambit, there are a Black Hole, a moudle system for Gambit, module called srfi; srfi moudle has test.scm and it's a almost testing.scm, a Per's reference implementation. So, it would fail to srfi-64-test.scm, I think. Talking about Chicken, there a egg, a module system for Chicken, moudle called test; test moudle is very similar to SRFI 64 but not is. I'd failed to compile the reference implementation on Chicken. Of course, srfi-64-port.scm can be compiled. On Kawa and Rocket, the reference implementation would work well. My point is SRFI 64 support on Guile would be helpful to people want to write a portable test code. For me, I'm contented with Guile 2.0 now but might want to write a Gambit or Chicken code someday and want not to study syntax for writing a test code itself again. Is SRFI 64 perfect? Of course not, but I would re-use my own test codes if it's based on SRFI 64, I think. So, I'd avoid making srfi-64-port.scm go from SRFI 64 specification. SRFI 78 module is a bonus; I'm not sure that be a right expression, a bonus. SRFI 78 is a very simple application of SRFI 42 and Guile supports SRFI 42 already. Thanks.
