unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Per Bothner <per@bothner.com>
To: Noah Lavine <noah.b.lavine@gmail.com>
Cc: guile-user@gnu.org, Sunjoong Lee <sunjoong@gmail.com>
Subject: Re: SRFI-64 implementation for Guile 2.0
Date: Thu, 19 Apr 2012 21:21:21 -0700	[thread overview]
Message-ID: <4F90E441.6030803@bothner.com> (raw)
In-Reply-To: <CA+U71=Ngdw9sycZtaqAHPMQZj9VKmQAic1EPRQgN+_D1npDTKw@mail.gmail.com>

On 04/19/2012 07:50 PM, Noah Lavine wrote:
> Hello!
>
> I'm a bit confused by this conversation. Do you want to merge this
> code into Guile, or into the reference implementation of SRFI 64?
>
> If it's into Guile, I can't speak for the maintainers, but I think we
> would love to have it. We do like supporting SRFIs.

I think it would be great to get SRFI-64 into Guile.

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.

I tried loading the reference implementation into Guile, and it
seems to work, albeit only with the basic (portable) functionality:;
see the end of this message.

Better support includes source-line-numbers, and exception trapping,
which are of course implementation-specific.  But my goal was
that support could be added by modest changes.  For example
line numbers are handled by the %test-source-line2 macro,
which is defined inside a cond-expand.  Could support be added
for Guile inside the cond-expand?

Now it is possible there may be more structural problems with the
reference implementation, and I'm certainly willing to consider those.
But I'm unclear if that is the case.

Sample run of the reference implementation:

$ guile -l ~/Kawa/work1/gnu/kawa/slib/testing.scm --
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /home/bothner/Kawa/work1/gnu/kawa/slib/testing.scm
;;; /home/bothner/Kawa/work1/gnu/kawa/slib/testing.scm:978:8: warning: 
possibly wrong number of arguments to `eval'
;;; compiled 
/home/bothner/.cache/guile/ccache/2.0-LE-8-2.0/home/bothner/Kawa/work1/gnu/kawa/slib/testing.scm.go
GNU Guile 2.0.5-deb+1-1
Copyright (C) 1995-2012 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (test-begin "vec-test")
%%%% Starting test vec-test  (Writing full log to "vec-test.log")
$1 = ("vec-test")
scheme@(guile-user)> (define v (make-vector 5 99))
scheme@(guile-user)> (test-assert (vector? v))
scheme@(guile-user)> (test-eqv 99 (vector-ref v 2))
scheme@(guile-user)> (vector-set! v 2 7)
scheme@(guile-user)> (test-eqv 7 (vector-ref v 2))
scheme@(guile-user)> (test-eqv 8 (vector-ref v 2))
FAIL
scheme@(guile-user)> (test-end "vec-test")
# of expected passes      3
# of unexpected failures  1
scheme@(guile-user)>

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
$ cat vec-test.log
%%%% Starting test vec-test
Group begin: vec-test
Test begin:
Test end:
   result-kind: pass
   actual-value: #t
Test begin:
Test end:
   result-kind: pass
   actual-value: 99
   expected-value: 99
Test begin:
Test end:
   result-kind: pass
   actual-value: 7
   expected-value: 7
Test begin:
Test end:
   result-kind: fail
   actual-value: 7
   expected-value: 8
Group end: vec-test
# of expected passes      3
# of unexpected failures  1
$

Adding line-number importation woudl of course make this much nicer.
Running the same on Kawa yields:
%%%% Starting test vec-test
Group begin: vec-test
Test begin:
   source-file: "/dev/stdin"
   source-line: 3
   source-form: (test-assert (vector? v))
Test end:
   result-kind: pass
   actual-value: #t
Test begin:
   source-file: "/dev/stdin"
   source-line: 4
   source-form: (test-eqv 99 (vector-ref v 2))
Test end:
   result-kind: pass
   actual-value: 99
   expected-value: 99
Test begin:
   source-file: "/dev/stdin"
   source-line: 6
   source-form: (test-eqv 7 (vector-ref v 2))
Test end:
   result-kind: pass
   actual-value: 7
   expected-value: 7
Test begin:
   source-file: "/dev/stdin"
   source-line: 7
   source-form: (test-eqv 8 (vector-ref v 2))
Test end:
   result-kind: fail
   actual-value: 7
   expected-value: 8
Group end: vec-test
# of expected passes      3
# of unexpected failures  1

Also the FAIL printed to stderr lists the file and line number:

|kawa:7|# (test-eqv 8 (vector-ref v 2))
/dev/stdin:7: FAIL
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/



  reply	other threads:[~2012-04-20  4:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12 21:53 SRFI-64 implementation for Guile 2.0 Sunjoong Lee
2012-04-14  1:39 ` Sunjoong Lee
2012-04-14  2:06   ` Per Bothner
2012-04-14 12:43     ` Sunjoong Lee
2012-04-15 20:35       ` Sunjoong Lee
2012-04-20  2:50         ` Noah Lavine
2012-04-20  4:21           ` Per Bothner [this message]
2012-04-20 10:19             ` Sunjoong Lee
2012-04-20 18:27               ` Per Bothner
2012-04-20 20:53                 ` Sunjoong Lee
2012-04-20 15:18             ` Ludovic Courtès
2012-04-20 17:36               ` Sunjoong Lee
2012-04-21 23:08                 ` Ludovic Courtès
2012-04-23  6:07                   ` Sunjoong Lee
2012-12-28  3:22                     ` Per Bothner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F90E441.6030803@bothner.com \
    --to=per@bothner.com \
    --cc=guile-user@gnu.org \
    --cc=noah.b.lavine@gmail.com \
    --cc=sunjoong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).