SRFI-64: test exception symbol

SRFI-64: test exception symbol

[Vladimir Zhbanov]

Hi,

In SRFI-64, is there a way to test what exception raised using
test-error() or anything else?  I know about looking into test
logs (if 'test-error' is used), though that's not what I need.  I
need a way to be sure a test raises the exception it should raise.

Thanks in advance

-- 
  Vladimir

(λ)επτόν EDA — https://github.com/lepton-eda

Re: SRFI-64: test exception symbol

[Vladimir Zhbanov]

On Thu, Apr 30, 2020 at 06:06:21PM +0300, Vladimir Zhbanov wrote:
> Hi,
> 
> In SRFI-64, is there a way to test what exception raised using
> test-error() or anything else?  I know about looking into test
> logs (if 'test-error' is used), though that's not what I need.  I
> need a way to be sure a test raises the exception it should raise.

To clarify things a little: in our project (in one of a dozen
test-suites :)) we already have a function that does checking of
what I'm asking about:

(define (%assert-thrown key thunk)
  (catch key
         (lambda ()
           (thunk)
           (throw 'test-failed-exception
                  (simple-format #f "  assert-thrown: expected exception: ~S"
                                 key)))
         (lambda (key . args) #t)))

Is there something like this in SRFI-64?

-- 
  Vladimir

(λ)επτόν EDA — https://github.com/lepton-eda

Re: SRFI-64: test exception symbol

[Taylan Kammer]

On 30.04.2020 17:55, Vladimir Zhbanov wrote:
> On Thu, Apr 30, 2020 at 06:06:21PM +0300, Vladimir Zhbanov wrote:
>> Hi,
>>
>> In SRFI-64, is there a way to test what exception raised using
>> test-error() or anything else?  I know about looking into test
>> logs (if 'test-error' is used), though that's not what I need.  I
>> need a way to be sure a test raises the exception it should raise.

The test-error form takes two optional operands before the test 
expression.  It's defined as:

<start snip>

(test-error [[test-name] error-type] test-expr)

Evaluating test-expr is expected to signal an error. The kind of error 
is indicated by error-type.

If the error-type is left out, or it is #t, it means "some kind of 
unspecified error should be signaled". For example:

(test-error #t (vector-ref '#(1 2) 9))

This specification leaves it implementation-defined (or for a future 
specification) what form test-error may take, though all implementations 
must allow #t. Some implementations may support SRFI-35's conditions, 
but these are only standardized for SRFI-36's I/O conditions, which are 
seldom useful in test suites. An implementation may also allow 
implementation-specific "exception types". For example Java-based 
implementations may allow the names of Java exception classes:

;; Kawa-specific example
(test-error <java.lang.IndexOutOfBoundsException> (vector-ref '#(1 2) 9))

An implementation that cannot catch exceptions should skip test-error forms.

<end snip>

My SRFI-64 implementation allows the error-type operand to be a 
predicate (one-argument procedure that returns a Boolean) to allow 
maximum flexibility.  It's found here:

https://github.com/TaylanUB/scheme-srfis


- Taylan

Re: SRFI-64: test exception symbol

[Vladimir Zhbanov]

Hi Taylan,

On Fri, May 01, 2020 at 11:58:41AM +0200, Taylan Kammer wrote:
> On 30.04.2020 17:55, Vladimir Zhbanov wrote:
> > On Thu, Apr 30, 2020 at 06:06:21PM +0300, Vladimir Zhbanov wrote:
> > > Hi,
> > > 
> > > In SRFI-64, is there a way to test what exception raised using
> > > test-error() or anything else?  I know about looking into test
> > > logs (if 'test-error' is used), though that's not what I need.  I
> > > need a way to be sure a test raises the exception it should raise.
> 
> The test-error form takes two optional operands before the test expression.
> It's defined as:
> 
> <start snip>
> 
> (test-error [[test-name] error-type] test-expr)
> 
> Evaluating test-expr is expected to signal an error. The kind of error is
> indicated by error-type.
> 
> If the error-type is left out, or it is #t, it means "some kind of
> unspecified error should be signaled". For example:
> 
> (test-error #t (vector-ref '#(1 2) 9))
> 
> This specification leaves it implementation-defined (or for a future
> specification) what form test-error may take, though all implementations
> must allow #t. Some implementations may support SRFI-35's conditions, but
> these are only standardized for SRFI-36's I/O conditions, which are seldom
> useful in test suites. An implementation may also allow
> implementation-specific "exception types". For example Java-based
> implementations may allow the names of Java exception classes:
> 
> ;; Kawa-specific example
> (test-error <java.lang.IndexOutOfBoundsException> (vector-ref '#(1 2) 9))
> 
> An implementation that cannot catch exceptions should skip test-error forms.
> 
> <end snip>

Well, I'm aware of this, thank you :-)

> My SRFI-64 implementation allows the error-type operand to be a predicate
> (one-argument procedure that returns a Boolean) to allow maximum
> flexibility.  It's found here:
> 
> https://github.com/TaylanUB/scheme-srfis

Thank you, I'd really like to try your implementation together
with my code. Though I don't know how :-(

The issue with this solution is how I would use the code and
integrate it into our project.

The first question: supposed that I already have guile installed
(together with its own srfi's) and have downloaded your
repository, how can I use your modules in my own code then?

The second one: how to make your code available for our code in
the spread of distributions our project builds on?  Probably,
there is a way to uniformly integrate some parts of it
(e.g. srfi-64) to our project?  Or should I require distribution
packagers working on packaging of our project to package your code
as a some new package, too?  Not sure, how to achieve this and if
this is possible at all.

Any hints?

-- 
  Vladimir

(λ)επτόν EDA — https://github.com/lepton-eda

Re: SRFI-64: test exception symbol

[Taylan Kammer]

On 01.05.2020 21:20, Vladimir Zhbanov wrote:
> 
> The first question: supposed that I already have guile installed
> (together with its own srfi's) and have downloaded your
> repository, how can I use your modules in my own code then?
> 
> The second one: how to make your code available for our code in
> the spread of distributions our project builds on?  Probably,
> there is a way to uniformly integrate some parts of it
> (e.g. srfi-64) to our project?  Or should I require distribution
> packagers working on packaging of our project to package your code
> as a some new package, too?  Not sure, how to achieve this and if
> this is possible at all.
> 

I believe the latest version of Guile supports R7RS libraries, so 
theoretically all you need to do is to add the path to the repository to 
the load-path of Guile, and you should be able to import (srfi 64).

I don't know if Guile's embedded SRFI-64 is also available as (srfi 64) 
or only as (srfi srfi-64) but even if it's the former, I think adding a 
directory to the load-path will override it.  You can tell from the 
standard output format whether you're running the standard 
implementation or mine; my version is much more verbose by default.

Adding to the load path can be done by setting GUILE_LOAD_PATH, by using 
the -L command-line switch, or by using the `add-to-load-path' form in code.

As for the second question:

There is sadly no standardized way to distribute R7RS libraries (e.g. 
the standard doesn't define something like a "load path" and how to 
influence it).

However, most of my project (including the SRFI-64 bit) is under the 
permissive (non-copyleft) SRFI license, which I think is equivalent to 
BSD-2.  (This is because most of my project is R7RS library wrappers for 
the existing reference implementations; I use the GPLv3 for new code I 
write.)  So you could simply copy the relevant files and bundle them in 
your project along with other Scheme code.

Happy to help if you have further questions.  (If I don't respond, which 
would be because I don't check the mailing list often, feel free to 
remind me by sending a mail directly to me without the list in CC so the 
mail lands in my primary INBOX.)

- Taylan