guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI-64 module and SRFI-78 module -- archive file attached


From: Sunjoong Lee
Subject: Re: SRFI-64 module and SRFI-78 module -- archive file attached
Date: Mon, 14 May 2012 06:22:09 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Hi, Noah;

Thanks for comments.

On 05/13/2012 Noah Lavine <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]