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.
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.
i would have to disagree about how common the single variable thing is. at least in my own code, i have many more withs than i have let's with multiple statements. but then, i try to do functional programming whenever i can.
and also, arc is at least a little geared toward functional style. in my other comment i brought up that one of the things pg liked about his if version is that the explicit 'do' makes non-functional code more obvious.
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. :)
Why would GC be unnecessary for stateless servers? Something needs to free memory once the response is committed. Either the interpreter, the server, or your webapp. I prefer the interpreter - that's why I'm not using C.
actually, arc does use the same namespace, that is most of the cause of this problem. if they were in different namespaces, there would be no problem with variables shadowing built-in functions. you still have to worry about variable capture, but it's a much less significant problem.
note: i'm not saying i don't like the same namespace thing. it actually shortens a great deal of code, and eliminates CL's stupid ass #' garbage.
