You are right it is standard compatible behavior. Thx.
The problem is that in code like following doesn't produce source-
position information and syntax-violation has datum instead of syntax
object.
So there is no way to automatically find problem location.
Let me check if I got this situation correctly:
1. it is due to the reconstructed syntax object which can have
multiple source-position informations.
2. programmer should handle such situations manually i.e. by
introducing dummy xform rules just for emitting correct syntax-
violation.
Correct?
--
Bogdan
(library (sample source-position-test)
(export myform)
(import (rnrs))
(define-syntax xform
(lambda (stx)
(syntax-case stx (keyword)
[(xform (<name>) keyword)
#t]
[(xform <name> . <rest>)
(identifier? #'<name>)
#'(xform (<name>) . <rest>)])))
(xform myform
'non-keyword)
)
On Sep 2, 7:43 pm, Abdulaziz Ghuloum <[email protected]> wrote:
> On Sep 2, 2009, at 8:38 PM, Abdulaziz Ghuloum wrote:
>
>
>
>
>
> > On Sep 2, 2009, at 8:24 PM, kub wrote:
>
> >> I have following problem which looks like a bug:
> >> syntax-violation thrown from eval has invalid syntax inside
> >> (contains symbol).
>
> > If you look at the condition thrown, it'd look something like
>
> > #[compound-condition
> > (#[&who guard]
> > #[&message "invalid syntax"]
> > #[&syntax (guard) #f]
> > #[&source-position "./t.sls" 43]
> > #[&trace #<syntax (guard) [char 43 of ./t.sls]>])]
>
> > which looks perfectly valid.
>
> From r6rs-lib about &syntax:
>
> Form should be the erroneous syntax object *or a datum*
> representing the code of the erroneous form.
>
> Ikarus right now only puts a datum in the &syntax condition.
>
> Aziz,,,
