guile-user
[Top][All Lists]
Advanced

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

Re: SRFI-64 implementation for Guile 2.0


From: Per Bothner
Subject: Re: SRFI-64 implementation for Guile 2.0
Date: Thu, 19 Apr 2012 21:21:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1

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
address@hidden   http://per.bothner.com/



reply via email to

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