Arc Forumnew | comments | leaders | submitlogin
3 points by rocketnia 4824 days ago | link | parent

> So just treat it as a bug in arc3.1--it probably won't even cause problems most of the time, because it's kind of a rare case--and fix it in your own ac.scm, and assume that it will be fixed in future users' Arc implementations.

I'm all too happy to do that. ^_^ Note that it'll probably mean I've introduced bugs to Rainbow and Jarc. :-p

Part of the reason I've harped on the state of affairs that causes me to write (do x), as well as the reason the state of affairs isn't altogether bad (that it makes macros that generate macro forms a tiny bit less susceptible to variable capture), has been in the hope that people will become confident that it's really annoying. ^^;

I honestly didn't know I'd be the only one actively defending it (rather than merely leaving things the way they are or upvoting), so I continued to give it the benefit of the doubt. Let's not do that. :)

> it probably won't even cause problems most of the time, because it's kind of a rare case

Actually, I use local variable names that clash with macros all the time, and that's why I started my (do x) and (call x) patterns in the first place. :) If I remove the cruft right away, my code will almost certainly break until everyone has upgraded. Dunno if anyone but me is going to suffer from my (published) code breaking, but hey. :-p

---

By the way, in this case, I was programming to a different core language implementation--in fact hacking on something core to that implementation--and I admit I cargo culted.



1 point by rocketnia 4824 days ago | link

Here's a patch for ar: https://github.com/rocketnia/ar/commit/3e2a1396c898caaf2dfe6... ^_^

It oughta make locals shadow macros, but again, it's untested.

-----

2 points by aw 4824 days ago | link

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 4823 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.

-----