Arc Forumnew | comments | leaders | submitlogin
2 points by aw 4802 days ago | link | parent

Thanks! I incorporated your patch and waterhouse's test.

(I ended up moving the check for lexical variables into the extension to ac-call to simplify macex).

However, this raises an interesting issue.

setforms calls macex which calls ac-macro?.

So do we still have the same bug with set expressions?

That is, even with this patch, can we construct a set expression that incorrectly treats a lexical variable reference as a macro?



1 point by rocketnia 4801 days ago | link

I was hoping to actually try running some code last night, but no dice. Anyway, that sounds like it would in fact be a problem. In fact, in Arc 3.1 at least, 'defset things are looked up at compile time, and 'get is given special treatment. Try something like this:

  (= foo (table) bar (table) baz (table) qux (table)
     quux (list nil nil))
  (mac get1 (x) `(,x 1))
  (let ref bar (= (ref foo) 2))
  (let get idfn (= ((get baz) qux) 3))
  (let cadr car (= (cadr quux) 4))
I wouldn't worry about 'get too much. It's inconsistent in just the same way as metafns are, so it's just one more in a list of names we shouldn't overwrite or use for local variables.

The setforms case is a bit more troublesome. Maybe they shouldn't be macro-like, and should instead be special-case extentions of 'sref? If the return value of 'get were its own type with 'defset and 'defcall support, that case could be eliminated too.

-----