Matthias Neubauer <xxxxxx@informatik.uni-freiburg.de> writes:

> Martin Gasbichler <xxxxxx@informatik.uni-tuebingen.de> 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