Having both fn and afn brings additional complexity. The only difference between fn and afn is that an afn form introduces self as an implicit local variable. Why shouldn't fn act like afn, and afn just go away from the language? In current implementation of Arc, afn is less efficient than fn, but eliminating unused let form of self is the job of optimizers, not language designers.
Minimizing the number axioms is good. Minimize the number of convenience macros is a different proposition. Most conditionals and closures don't need anaphora, so when I see the plain if or fn I know not there's nothing funny going on. The anaphoric versions tell me I need to look for the it/self references before I'll understand what I'm reading.
Other things we shouldn't do include eliminating let in favour of the more general with, and then eliminating with in favour of the more general withs.
Of course, (withs (a (foo) b (bar a) c (baz b)) ... ) is really just:
I insist that having every function implicitly have a self-reference is bad. Sometimes I want a function's sense of self as being some other object - say a table representing a set of functions. Sorry, but I want control over the names I'm using - and the separation of 'afn, 'fn, and 'rfn gets me that control.
The above just gets worse when I need several nested afn's each with a few dozen fn's that need to recurse on the parent. Being able to select or not select the implicit shadowing of 'self is important to me.
"All processes are impermanent ... All processes are afflicted ... All phenomena are not ‘Self’; when this is seen with knowledge, one is freed from the illusion of affliction. This is the pathway to purity." ^^ ^^ >.<
In this example it's not the end of the world, but it would cause problems in code that's generated by other code, e.g. by macros.
I experimented for a while with having if just be aif, and it was not good. There are times you want to back off from maximally using anaphoric variants, just as there are times you don't want to use [] or ./! notation even though you could. E.g. when it's nested. And if you don't have the non-anaphoric variants, you never can.
they should be separate just in case someone has another desire to use the self symbol for something. if someone uses if, they don't expect any symbols to be shadowed. if they use aif, they know what to expect.
Most OO languages don't just "implicitly bind" self; self (or this) is usually a reserved word. A conflict with another variable is made impossible because you can't say "int this = 4" in Java or C++. As pointed out, Python already makes the binding explicit.
Further, let us imagine for a moment that lambda closures and class instances are ... different things.
not all of them. python, for example, does it explicitly. self is a convention, but you can call it anything you want.
and arc shouldn't do something just because other languages do it. it should do things based on whether they are the best way to do it. and i personally think it's a bad idea to introduce those kind of automatic symbol bindings into constructs which are so fundamental to the language, like fn and if.
Pardon the tangent, but in Perl 5 what you call the instance of the class is up to you. Conventionally it's $self, and the constructor is often new(), but these can be whatever you want. Unless you use a special CPAN module that does the work for you, the common idiom in declaring methods is
sub method {
my $self = shift;
...
}
You could name it $myself, $this, or even $the_object if you wanted.
