-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04-01-12 10:57, Marijn wrote:
> On 03-01-12 20:15, Eli Barzilay wrote:
>> Two hours ago, Marijn wrote:
>>> Hi,
>>>
>>> for/hash is giving me a syntax-error, but the error is in
>>> macro-expanded code which is not shown by default and which is
>>> also seemingly inaccessible via the macro-stepper. The for/hash
>>> expression works outside my macro, so I guess it's my fault,
>>> but it would help if the syntax-error could be a bit more
>>> informative. The code: [...]
>
> Thanks for taking the time to look into this.
>
>> 4. It's now easy to continue reducing it to the core of the
>> problem:
>
>> (define-syntax with-variables (syntax-rules () ((_ (a ...))
>> ((with-variables a) ...)) ((_ a) a))) (with-variables (let* ((y
>> 1)) 2))
>
>> Looks like you're doing a code walk (which is what makes me think
>> that this is too complex for whatever it is you're trying to
>> do), and treat some names in a special way. The problem is that
>
>> ((with-variables a) ...)
>
>> is creating a function application so the error is the same as
>> just entering `let*' to get its value -- and the only error that
>> it can throw at this point is a "bad syntax" with the whole
>> expression, which is just `let*'.
>
> It took me a while to understand what you're saying here, but if I
> am not mistaken you're saying that the result of the
> macro-expansion is a function-application with `let*' (or
> `for/hash') in the function position. Then when #%app looks that
> name up in the environment it doesn't find anything and thus
> complains about it. What I would then expect is that it complains
> about an undefined variable `let*'.
>
>> 5. And BTW, the reason it doesn't work is that the first
>> expansion gets to
>
>> ((with-variables let*) (with-variables ((y 1))) (with-variables
>> 2))
>
>> and this form is not a macro -- so it's expanded as a function
>> call,
>
>> (#%app ...same...)
>
>> and the rest is obvious.
>
> It's not so obvious to me why this should degenerate into a
> function call; I'd say it depends on the result of (with-variables
> let*).
Okay, so I thought about this some more... and while I still think
this is weird behaviour, for my current code it is rather academic, as
it would just fail with unexpanded macro-calls in the arguments of
let*. Which means that I've again fallen into the trap of not thinking
hard enough about how macros are different than functions. Basically,
my idea was to transform:
(dependent-boxes
((a)
(b (* 2 a))
(c (+ 2 a b))))
into something which would automatically propagate changes in any
cell/box to any other box which was dependent on it. Pretty much
exactly like a spreadsheet does. As target for that transformation I
had chosen something like:
(letrec
((value-store (mlist (mcons 'a #f) (mcons 'b #f) (mcons 'c #f)))
(rule-store (make-hash
`((a . ,(lambda () ""))
(b . ,(lambda () (* 2 (value-store-ref 'a))))
(c . ,(lambda () (+ 2 (value-store-ref 'a)
(value-store-ref
'b)))) ))))
...)
together with surrounding structure such that values could be entered
and read and such that for each value-change, dependent boxes would be
updated automatically. Before today I though this was a pretty sweet
setup. But even if my macro had worked as I had intended, it wouldn't
have respected lexical scope within rules. So I guess it's back to the
drawing board for me. (I don't recall there being any logic to using
an alist for the value-store and a hash-table for the rule-store.
Probably that's just how things grew...)
Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8EcwcACgkQp/VmCx0OL2xEyQCggrb6Fq2hc5EB2ujJGsS/SNpH
RBQAoJf0wk6t6P/zESx8xBwAZnTCsit6
=3zAm
-----END PGP SIGNATURE-----
____________________
Racket Users list:
http://lists.racket-lang.org/users
