Arc Forumnew | comments | leaders | submitlogin
1 point by stefano 5985 days ago | link | parent

A and B should provide macros to let C write:

  (with-A what%ever)
  ...
  (with-B what%ever)
CLSQL modifies the read table to let you write embedded SQL queries such as [select "A" [where [= ...]]] and similar (I've never studied the exact syntax, but this should give you the idea). The special reader in CLSQL can be activated/disactived through function calls that modifies the default reader.


1 point by almkglor 5985 days ago | link

But B doesn't want to treat #\@ or whatever syntax specially. Why should B bend over backwards to support this?

For that matter: what if C wants to use a macro in A within the context of a macro in B or vice versa?

  (with-A
    (macro-A
       @foo
       (with-B
         (macro-B
           (prn "this is:" '@foo)))))
?

> The special reader in CLSQL can be activated/disactived through function calls that modifies the default reader.

Not a bad idea. Difficult in SNAP though - which default reader? I'd have to add yet another process-local variable.

-----

2 points by cchooper 5981 days ago | link

It looks like CLSQL needs reader macros to switch the syntax on and off locally. If Arc had reader macros, then you could do this:

  #.(with-A (mac macro-A ..blah..blah..in special A syntax))
Assuming 'with-A is a function that set the read table locally, and macro-A uses quasi-quote to generate its result, this will produce a macro that produces standard Arc syntax, even though it's written in A syntax.

With reader macros, 'w/html could be implemented even if de-sugaring were moved to the reader, although you'd have to call it with #. all the time.

It makes sense to me that macros should always expand to vanilla Arc syntax (or maybe even pure s-exps without any ssyntax) so that they are portable across environments.

-----