if no keyword match in A, then return a default response from E
else if no substitution in the response c picked from C, return c
else substitute and return
So you might be looking for something similar in Scheme, but I have no clue what. The next question then is whether Arc in fact works that way, ie, if you do get something similar defined in Scheme, will $(foo) get expanded before Arc gets to it, or will Arc get in the way.
Apologies for such useless info. btw, if you do end up wanting to Just Try It with the Scheme equivalent I think you will find comp.lang.scheme an excellent resource.
"variable capture like this happens maybe in 1/1000 uses of macros (thought it's already happened once to me, so I agree with your concern is valid)"
How did it happen?! Did you skip a uniq out of laziness, or did the lexical environment into which you expanded rebind an Arc keyword or one of your own function names or ____? Maybe lisp-1 necessitates hygiene, and lisp-1 is The Real Problem.
As a longtime very relaxed CLer I must say I completely do not appreciate the naming paranoia I have experience with Arc/Lisp-1. Funcall is precisely what problem? My massive codebase shows 340 defmacros and 201 funcalls, which if you think about it is an astonishing ratio. (Think "define" vs. "invoke".)
But the more functional the programmer the less likely they are to need temporary variables, so the count 1 should be more frequent! <g> In my CL experience it comes up often enough that I have a policy where the let will be at the toplevel in a function: I use &aux (to repeat, a CL hack):
(def my-fun (x y z &aux (temp (other-fun x y)))
...etc...)
Why? Yes I have a twenty-inch flat panel but I am still an almost obsessive indentation miser, and it just kills me to add a level of parens and indentation just to get one lousy temp variable. :)
Right, and the "score one" headline is about my concern that Arc abbreviations might not become second nature. My Arccells code uses a lot of it, but most times I had to go back and edit a (foo bar) into foo.bar cuz the (foo bar) just rolled off my fingers. Of course Arc and I are new to each other so it is too soon to tell, but it feels like my fingers now need a lookahead ability they may not be able to grow. I am especially suspect of the piping : ever catching on.
In this case, I guess the one variable LET syntax of Arc caught on pretty damn fast. :)
I'm sure you will remember to use foo:bar when the alternative is (fn args (foo (apply bar args)))
Using : only in the most important places might be a good thing. I.e not overuse it for (foo (bar x)) -> (foo:bar x) where it trades readability for 2 characters.
Sorry, I realized that would confuse things terribly only after posting, and would have edited it into a simple (let x 42..) after the fact to highlight the actual gaffe but decided it would be useful to share what is only coincidentally similar to Arcese in the syntax but identical in spirit.
What was posted was real CL code, but it leverages a sophisticated mechanism known as a reader macro. I imagine there might be similar hijinx in ac.scm supporting the Arc syntax, dunno.
I do not have to type that particular RDF URI very often (done, actually, after three times) so I do not abbreviate (except for the UFB (but let's not digress))).
For the same reason that pg is creating Arc, CL programmers like to take stuff that will be a pain to to type and effectively automate the typing with a reader macro.
The use of the colon to separate the RDF namespace from the specific label is a nice pun the CL usage for its namespace mechanism packages. I got a little inconsistent in my hackery and nicknamed the triple-cells CL package "3C", so if I had to reference the stmt-new function in a different package not using triple-cells I would say (3c:stmt-new...).
I don't know what to think about all this syntax. I think it is fine for pg to look for ways to make Lisp more concise and parens-free cuz he is a master of Lisp. But is everyone piling onto this experiment as savvy about the benefits of those parnes? Or are some just trying to turn Arc into C to get back to their comfort zone?
As for it being optional, the danger I see is that this punctuation stampede is encouraging noobs in their fear of parens. The fact is, anyone who gives Lisp a serious try never ends up in week two saying damn Lisp rocks but how do you people tolerate those damn parentheses!!??
That said, I did as much punctubreviation as I could doing Arccells and I did not hate it. Time will tell....
The problem is that instead of learning Lisp/Arc people are spinning their wheels trying to design it. I see very little sign here of people actually programming in Arc. If pg had just laid down the law folks would be using Arc instead of trying to fix a language whose excellent heritage is unknown to them. But I think some good ideas came out of the first wave of suggestions so I am undecided on the merits of the dictator's three-microphone town meeting.
"won't have anything worth releasing for months..."
Er, um, dude... it's Lisp, you are supposed to be able to release it every day. Please don't tell us you are still running the system specification document past the user acceptance committees.
Well, I do not totally agree with you there. I have programmed in Arc both for fun and work, and have also coded in Scheme a little, and I really find the . and ! syntax is really a good thing for structure access, mainly when you have nested structures. You know, when you have 3 or 4 opening parentheses at the same time. Too sad you can't fully use it in these situations.
But it's not a problem of fear of parentheses ; actually I couldn't find other cases where . and ! could be used without feeling a bit ugly (i.e. in calling functions or macros). Yes, parentheses & s-exprs are great, but I don't believe they should be the only syntax for accessing structures.
Don't worry anyway, I don't think Paul would integrate suggestions he considers weak, even if many of us asked it.
I would like to emphasize the bit "once that is working"... it can be a bit much to get the whole mechanism working at the same time as developing the macro. So get the flow going from a text file being read in to the correct function being called for that shape and maybe do a few shapes until you are sure the beast is about right, then do the macrology. Especially if a macro is in a separate file (as it should be) and you are not reloading the whole shebang each time you run, you'll go nuts running old code even after changing the macro if you just reload the macro-defining file. Add to that the fact that the mechanism itself will be a moving target... well, I like to divide and conquer these deals.
It probably varies. Natural language is a mess, and in the hands of geeks...ugh. So if I have an interesting function to understand I would just as soon see the code. But if I am looking at standard library stuff it will be hard to muck up the one very short sentence description. Add to that that we have a new language with a lot of shortcut syntax and that its a Lisp and a lot of non-Lispers are hopefully looking at the language, I think maybe the ball was dropped when we were told to just read the code, as much as I grok that sentiment. It is something I am much faster to say when we have people asking about application code in a language everyone asking is supposed to know.
