[plt-scheme] Pattern-matching macro chokes on conditional statement which would otherwise work.
What version of DrScheme are you running? There was a bug in the v371
debugger that would produce error messages like that, but it should
have been fixed in v372 (and in svn as of r7169 I think).
On Jan 19, 2008 10:28 AM, Ran Gutin <manicmessiah at gmail.com> wrote:
> (define (doublequoted-symbol? sym)
> (and (pair? sym) (eqv? (car sym) 'quote)))
>
> (define-syntax match
> (syntax-rules ()
> ((match vars [pfirst prest ...] body ...)
>
> (cond
>
> ((and (not (doublequoted-symbol? (quote pfirst)))
> (symbol? (quote pfirst)))
> (let ((pfirst (car vars)))
> (match (cdr vars) [prest ...] body ...)))
>
> ((eqv? pfirst (car vars))
> (match (cdr vars) [prest ...] body ...))
>
> (else #f)))
>
> ((match vars [] body ...) (begin body ...))))
>
> (match '(1 2 3) (one 2 three)
> (display three))
>
>
>
> Sorry for not commenting on the code, but here's a basic idea of what it
> SHOULD do:
> (match '(1 2 3) (1 2 3) (display 3)) should match perfectly and display 3 on
> the terminal (it doesn't).
> (match '(1 2 3) (one two three) (display 3)) works perfectly, and prints 3.
> (match '(1 2 3) ('one 'two 'three) (display 'one)) - This should fail to
> match the pattern altogether, as symbols which are already quoted are
> matched for equality, rather than used as identifiers as above. This dies
> miserably without returning #f.
> (match '(1 2 3) (one 2 three) (display three)) - This should immediately
> create an alias for the values 1 and 3 ('one' and 'three) and match the
> second values for equality. Unfortunately, this is not the case.
>
>
> (match '(1 2 3) (one 2 three)
> (display three))
> ... gives the following error:
> "let: bad syntax (not an identifier) in: 2"
>
> It seems to be completely ignoring the conditional.
> So I performed a test:
> (and (not (doublequoted-symbol? (quote 2)))
> (symbol? (quote 2)))
> ... actually returns FALSE. So then why is the conditional statement
> branching off completely wrong?
>
> And then, here's the real kill. I can't debug the damn thing.
> Doing so sends an alert window flying in my face, and a larger one behind
> it.
>
> "rest: expected argument of type <non-empty list>; given ()
>
> === context ===
> C:\Program Files\PLT\collects\mzlib\list.ss:295:2: rest
> C:\Program Files\PLT\collects\mztake\debug-tool.ss:804:10: can-step-out?
>
> rest: expected argument of type <non-empty list>; given ()
>
> === context ===
> C:\Program Files\PLT\collects\mzlib\list.ss:295:2: rest
> C:\Program Files\PLT\collects\mztake\debug-tool.ss:804:10: can-step-out?
>
> rest: expected argument of type <non-empty list>; given ()
>
> === context ===
> C:\Program Files\PLT\collects\mzlib\list.ss:295:2: rest
> C:\Program Files\PLT\collects\mztake\debug-tool.ss:804:10: can-step-out?
>
> rest: expected argument of type <non-empty list>; given ()
>
> === context ===
> C:\Program Files\PLT\collects\mzlib\list.ss:295:2: rest
> C:\Program Files\PLT\collects\mztake\debug-tool.ss:804:10: can-step-out?
>
> rest: expected argument of type <non-empty list>; given ()
>
> === context ===
> C:\Program Files\PLT\collects\mzlib\list.ss:295:2: rest
> C:\Program Files\PLT\collects\mztake\debug-tool.ss:804:10: can-step-out?
>
> rest: expected argument of type <non-empty list>; given ()
>
> === context ===
> C:\Program Files\PLT\collects\mzlib\list.ss:295:2: rest
> C:\Program Files\PLT\collects\mztake\debug-tool.ss:804:10: can-step-out?
>
> rest: expected argument of type <non-empty list>; given ()
>
> === context ===
> C:\Program Files\PLT\collects\mzlib\list.ss:295:2: rest
> C:\Program Files\PLT\collects\mztake\debug-tool.ss:804:10: can-step-out?"
>
> ^ Can someone tell me what the hell is going on?
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>