I've a function that binds a list of lists to to variable 'world', and a function that prints out this world.
(def makeworld (x)
(let z nil
(repeat x (= z (cons nil z)))
(repeat x (= z (map [cons nil _] z)))
(= world z)))
(def show ()
(each x world
(each y x
(pr (if (is y nil) #\. y) #\space))
(pr #\linefeed)))
The world can then be seeded with trees, or shrubs or monsters or whatever. Anyway, as the world is a list of lists, it functions as a two-dimensional array.
If in arc I want to access a point in this two-dimensional list / array, I need to enter ((world 0) 3), and the basic question was how to change arc (macrowise) to make (world 0 3) be equivalent to ((world 0) 3). I already worked around it by now.
To answer your question: you're assuming that there is a list called 'list', and in my initial example I described a function that took the name of the list as first argument.
The problem with multiple values being subsequent accesses is it would also interfere with a useful syntax (not actually in Arc, but I mean insofar as deciding which it should mean), and that's subsequence indexing. It's been discussed all over the place, e.g. http://arclanguage.org/item?id=449
With the assumption that one of them takes that syntax, what should be used for the other? How about (seq '(0 3 ...)) or (seq (0 3 ...))? It would similarly be fitting for any number of arguments, be they dimensions or indices, though I would vouch to use the list for n-dimensional indexing as the case of subsequences seems more common. Plus the use of a list distinguishes the one type of access from the other without having to go (...((seq 0) 3) ...).
Not that any of this helps your problem. Just something I noticed.
Oh, I get it. No, this is not something you can do with macrology because there is no room for a macro in your desired syntax (where you just want the list itself and the index values). As you say, if you'll make room for another token it can just be a function (which would be fun to generalize to N dimensions). As for making ((list (list 42)) 0 0) return 42, I think you need to is suggest it as a (very reasonable) enhancement to Arc.
I see you have corrected the above by switching to a different name (a reasonable way to go) but it might be fun to see if you can stick with one and expand differently based on whether one or more than one value is supplied (meaning of course you need to support what we call &rest in CL in the parameter list of twodimlist. What I do not know is how well Arc likes to expand a macro into code referencing the same macro.
