Precisely! Now, just make emacs replace "no" and "not" functions also, and you'll have what I was asking for.
However, my point is also that doing this kind of thing should be within the scope of PG's work - providing a "reference IDE" to show how he intends Arc code to be interacted with.
andreyf, I completely agree with you. How people write code in a language is -- from a user experience perspective -- part of the language in a very real sense. I've written about this before. http://plpatterns.com/post/37655849/1-2-n
Using symbols like ¬ and λ is a start. Paredit is even better. But I think programmers are stuck in the mindset that source code has to come from an ASCII text file. If you truly get the idea that code is just data, there's no reason why your "IDE" shouldn't be integrated with the language and provide a higher-level representation of the data you're editing. Also, depending on the task, you may want to view different aspects of your code. You can think of your source as the model in an MVC where multiple views and editing styles for the same data-structure are possible.
Once you view your code simply as data, all sorts of possibilities open up. The so-called Source Code In Database site has tons of examples of these features. http://mindprod.com/project/scid.html
Programmer A decides he or she wants to specially treat #\@. Programmer B decides he or she doesn't. Now, load Programmer B's code into Programmer A's environment. Oh, and Programmer B has been writing a lot of functions with "@" in their names.
If you're not going to allow #\@ to be specially treated, why should you specially treat #\., #\!, #\~ or #\: ?
#\' and friends, after all, aren't intrasymbol syntax. In fact, #\. is treated differently from within the context of a symbol from within the context of a list.
This is where "code is spec" fails, bad. Me, I say, someone has to choose one or the other, define it as "this is spec!", and everyone follows it. Your move, PG?
If the reader can be configured (e.g. by specifying wich read table to use) then two modules that uses different reading conventions can coexist by simply using their own configuration.
Now programmer C wants to use both programmer A's module and programmer B's module. Which readtable does he use so that he can freely intermix macros from A with macros from B, which have different expectations on the reader?
Reader hacking is nice, but I don't see it often in CL libraries (note: counterexamples are welcomed; it's not like I've made an exhaustive search for them). Any reader hack must make the cut of being a good, generic enough meaning that it will always be used by everyone; take for example the Arc-type [ ... _ ... ] syntax
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.
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.
I'm speculating here, but maybe I'm in a hurry and I want to use something in my macro without taking the time to rewrite it so that it produces an s-expression.
I actually don't know if having a macro expand into a function value would be useful for anything; I just noticed a way to do it and posted the solution in case it would be useful to somebody someday. (Not realizing that apparently this has been fixed in Anarki already).
Parameters look interesting, but the man page suggests that there's a pretty significant overhead in code tree nodes to using them. Do you think we can get that functionality cheaper?
The thing I like about my approach is the simplicity - everything expands to sets. If we had parameters, we'd probably want to modify set so that it worked on them. In that case, this approach would still work, and would be the most idiomatic way to do it.
It also separates functionality nicely, since it would work with any thread mechanism that allowed per-thread variables (all of them). Because it only expands to set calls, it's a general mechanism for dynamic binding, and the thread stuff should "just work" if they're used together.
We can't know what is "significant overhead" without testing. Arc already has its own overhead, so for all we know the added overhead of using parameters might be utterly insignificant. Or not.
Certainly a layered approach is a good idea: an underlying mechanism that provides bug-free dynamic binding functionality, and then a macro layer that allows people to use the functionality in a convenient and easy way.
You might be able to use set with MzScheme's thread local variables if you also used something like using "protect" to restore values on exceptions; but you wouldn't be able to use set with MzScheme's parameters because you need to specify what is the scope that you want the parameter to have a new dynamic value within.
The key challenge to using MzScheme's parameters is that you'd need a way to have Arc compile a variable reference "foo" into a Scheme parameter call "(foo)". However if someone did that I expect the result would be simpler because we wouldn't need the code to set and restore the values ourselves.
