On Sep 2, 2009, at 9:30 PM, kub wrote:
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.
Correct. Syntax problems may have multiple causes. It's not
always the immediate source code as written in, say, a library
that causes a syntax error.
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.
Multiple source positions or none at all, yes.
2. programmer should handle such situations manually i.e. by
introducing dummy xform rules just for emitting correct syntax-
violation.
I don't know what you mean exactly. In general, a macro should
check, to the extent possible, that its input is valid. If not,
Ikarus tries to reconstruct (in the trace) some of the context
that causes the error.
(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)
)
So, here you have (xform myform 'nonkeyword) expanding to
(xform (myform) 'nonkeyword) which does not match either
rule and causes a syntax violation. The step in the middle
does not have source information since it was constructed
by the xform macro, so, you can't get exact source position
for it. All Ikarus gives is the expansion steps (starting
from the first one which hopefully does have syntax info)
as you can see (reading the trace backwards):
Unhandled exception
Condition components:
1. &message: "invalid syntax"
2. &syntax:
form: (xform (myform) 'non-keyword)
subform: #f
3. &trace: #<syntax (xform (myform) 'non-keyword)>
4. &trace: #<syntax (xform myform 'non-keyword) [char 270 of ./
t.ss]>
Makes sense?
Aziz,,,
