This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.
Matthias Neubauer <neubauer@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> Martin Gasbichler <gasbichl@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> Yeah yeah, you're right of course! But still, ...
>
> val prog : ('a, int) code = .<let x_2 = 1 in 2>.
>
> # .! prog;;
> - : int = 2
>
> ..., the result still is 2! That's the point! Andre seemed to suggest
> at the beginning of this thread that either 1 or "no result" would be
> sensible results for this example. I think returning "1" is the wrong
> thing here, because this seems to contradict lexical scoping
> completely. Either return "2" by adding cross-stage persistence (CSE),
> or return an error without it as you suggest.
I don't suggest to return an error but to return "1". As I said
before, lexical scoping does not apply because (SYNTAX 2) is data. You
don't expect
(eval `(let ((x 1))
,(let ((x 2))
'x)))
to evaluate to anything else but 1, right?
>> But you don't need it because a macro is a source-to-source
>> transformation and UNQUOTE (as SRFI-72 and MetaOCaml provide it)
>> already does the trick:
>>
>> let prog = .< let x = 1 in
>> .~ (let m () = let x = .< 2 >. in
>> .< .~ x >.
>> in
>> .< .~ (m ()) >.) >.;;
>
> Sure, you don't need it. But just compare the two code fragments from
> above: to achieve the same result without CSP, you have to insert even
> more UNQUOTEs and SYNTAX brackets in your macro than before.
No, you don't need to add more SYNTAX clauses than before. Actually,
the SYNTAX clause on the right-hand side of the "let" fixes another
bug in your example and points to an important difference between
macros and MetaOCaml: In MetaOCaml you can transport arbitrary values
to a higher stage, but as a macro is a source-to-source
transformation, you can only transport code.
> It gets even worse, if x is not just a value but a more complicated
> expression.
Hu? x is not a value but a variable. Which expression do you want to
be more complicated?
> With CSE, it is simpler to write macros to achieve the same result.
No, all you save is a comma before the variable name.
> So why not just allow it? Are there any drawbacks?
Sure: The model you need to describe this is far more complicated and
it violates the correspondence to (QUASI)QUOTE.
--
Martin