[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
(eval `(let ((x 1))
,(let ((x 2))
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 >.
>> .< .~ (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
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.