Re: SRFI-19 patch, or: strange syncase implications

[Rob Browning]

Matthias Koeppe <address@hidden> writes:

>  2)  For some reason, in the definition of the `date' record type,
>      `make-date-unnormalized' was made the constructor, but
>      `make-date' was used everywhere; see the patch below.

This is my fault.  I added the normalization layer for times and then
thought we might want the same thing for dates, but I forgot to make a
final pass.  For now, I took your fix.  We won't normalize dates
(since we don't do math on them, you can only create them directly,
 and the behavior when you pass values outside the defined ranges is
 undefined anyway...)

>  3)  The implementation uses a simple syntax definition to provide a
>      syntax for extracting optional arguments, but this seems to cause
>      breakage.  In the patch, I have used (ice-9 optargs) instead of
>      (ice-9 syncase) for handling optional arguments in order to work
>      around the problem.

Alternately, we could just handle the arguments directly.  No real
need for the syntax really.  I just did the simplest thing -- I just
did a (if (null? <optarg>) default (car <optarg>)) for now.

> Here is information on how to reproduce the syntax-rules breakage (with
> the unpatched srfi-19.scm):  Type
> 
>         (date->string (make-date-unnormalized 0 1 2 3 4 5 6 7) "~Y")
> 
> Guile hangs until interrupted.  No backtrace is available.  Once (I
> think I was tracing `priv:date-printer'), I got 
> 
>         "lazy-catch handler did return."
> 
> I believe this must be related to the syncase system because the
> problems went away when I used (ice-9 optargs) instead of (ice-9
> syncase).

This sounds a lot like a bug reported the other day with syncase.  I
wonder if it's module scoping related...

Anyway, thanks for the help.  These problems should be fixed in CVS
now -- though I can't build ATM.  autogen's having indigestion on my
just upgraded system:

$ ./autogen.sh 
autoheader: error: shell error while sourcing /tmp/ah20029/traces.sh
configure.in:383: error: AC_LANG: unknown language: 
aclang.m4:124: _AC_LANG_SET is expanded from...
aclang.m4:133: AC_LANG is expanded from...
./aclocal.m4:116: GUILE_NAMED_CHECK_FUNC is expanded from...
configure.in:383: the top level
guile-readline...

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930