SRFI 253: Data (Type-)Checking Arthur A. Gleckler (13 Aug 2024 19:13 UTC)
Re: SRFI 253: Data (Type-)Checking Marc Nieper-Wißkirchen (13 Aug 2024 19:46 UTC)
Re: SRFI 253: Data (Type-)Checking Artyom Bologov (13 Aug 2024 20:11 UTC)
Re: SRFI 253: Data (Type-)Checking Retropikzel (14 Aug 2024 05:44 UTC)
Re: SRFI 253: Data (Type-)Checking Retropikzel (14 Aug 2024 05:55 UTC)
Re: SRFI 253: Data (Type-)Checking Retropikzel (14 Aug 2024 06:43 UTC)

Re: SRFI 253: Data (Type-)Checking Artyom Bologov 13 Aug 2024 20:11 UTC

Hi Marc,

> What do you think of adding R6RS support as well?  By this, I mean, in particular, the condition hierarchy.  For example, wrong
> arguments should raise an &assertion condition with an appropriate `who' argument.

The sample implementation (impl.generic.scm) kind of relies on condition
hierarchy, because it uses assert on R6RS. I might've used `&assertion'
or called `assertion-violation', but I thought that `assert' is more
optimized than my hand-coded re-implementation and thus relied on it
instead.

Another argument in favor of assert is that one likely ends up in
debugger when catching assertion violation anyway. And, supposedly, one
can query the debugger for `who' the assertion was raised from.

But not all implementations have a sophisticated enough debugger,
true. I guess it's up to implementations there. The only thing I can
(and probably should) do is make the third argument to `check-arg' a
mandatory `who' argument. But that is questionable change—this argument
might end up unused on half of the implementations. Forcing it is not
nice.

Thanks for sowing the seeds of doubt in my mind! I have to think about
it some more.

Thanks,
--
Artyom Bologov
https://aartaka.me