Given the way I defined a Bank-Account, you could implement this rather simply:
(def deposit (x . args)
(apply x 'deposit args))
Or, with akkartik's implementation, which I agree is nicer and better:
(def deposit (x . args)
(apply x!deposit args))
And you could make another "object" and give it a distinct 'deposit "method" and it would work fine.
So... it seems that one can easily implement these things in Arc. If you have some project in mind for which you want OO stuff, you can just do the things posted in this thread, and tell everyone how it goes if you like.
If you think OO should be put into the core of the language, well, there's a certain resistance to adding features just because someone suggests it. The core would become large, disorganized, and difficult to maintain if we did that. So, you would have to give a convincing argument as to why it's worth putting in there, and a demonstration of how useful it is in some real project of yours is probably the best argument you could give.
This kind of OO with closures is a fun experiment and looks very elegant at first sight. I love the (x!deposit 50 "meh") version for its simplicity, the use of ssyntax, and the fact that you can pass x!deposit around as a first class function. Thanks to macros, you can of course easily come up with a nice syntax for the definitions:
However, the approach has some issues in real life use. First, every bank account instance replicates the method table and so takes up more memory the more methods the class defines, and each method is a closure that takes up memory as well. Also, this hash table obviously needs to be built every time an instance is created. Another big problem that follows from the above is that when you add or redefine methods on the class, existing instances are left with the old implementation. And there is no way to implement inheritance here.
I guess it is possible to remedy most or all of those problems by sacrifying methods as closures and instead do:
(= bank-account-mt
(obj check-pass (fn (self o pw)
(unless (is o!pw pw)
(err "Wrong password!")))
deposit (fn (self o x pw)
(self 'check-pass pw)
(++ o!money x))
withdraw (fn (self o x pw)
(self 'check-pass pw)
(if (< o!money x)
(err "Not enough money.")
(-- o!money x)))
check (fn (self o pw)
(self 'check-pass pw)
o!money)
change-pw (fn (self o new-pw pw)
(self 'check-pass pw)
(= o!pw new-pw))))
(def Bank-Account (password)
(let o (obj money 0 pw password)
(afn (method-name . args)
(apply (bank-account-mt method-name)
(cons self (cons o args))))))
Again using a macro to improve readability and writability. Adding inheritance is left as an exercise for the reader.
I'm sure this doesn't surprise you, but here's a quick version of 'defclass that uses a syntax similar to your first example and an implementation similar to your second example:
Nice, and you even changed it so x!deposit returns a function again! This does of course add some overhead since a closure is constructed every time you call a method, but still.
One thing I'm not quite happy with is that one has to write o!money. Would it somehow be possible to hide the o? Would it be possible to use !money or .money, or does the parser not allow that? And how to pass the hash table from the afn to the methods without polluting their namespaces? It could be done using a gensym, but then it is not possible to add methods to the method table outside defclass.
It deals with lists and strings well, which is decent: Arc's only other sequence-like type is the table (I don't think you'd ever want to treat symbols as a sequence of 1-character symbols; you'd just use a string). Tables would work better if they were properly coerced, cf. the comment above tablist and listtab in arc.arc.
The more I think about it, the more I like this model. Conceptually, it seems that map should behave like
(def map (f seq)
(map-as (type seq) f seq))
even if it's not implemented like that -- all the coercions would surely be slow. (Tangential: map would also need to handle multiple sequences.) But it makes more sense for map and coerce to at least have compatible behavior. Plus, map's current behavior is a degenerate case of the coerce-compatible map:
I've spent some time thinking about how to extend it for multiple-dispatch, and I didn't want to also think about setting the arg index to dispatch on.
(def mapstr (f . seqs)
(string (accum a (for i 0 (- (apply min (map1 len seqs)) 1)
(a (string (apply f (map1 [_ i] seqs))))))))
arc> (mapstr [string "." _] "test")
".t.e.s.t"
And we can plug that into the definition of map:
(def map (f . seqs)
(if (some [isa _ 'string] seqs)
(apply mapstr f seqs)
;; the rest is the same as the arc3.1 def
(no (cdr seqs))
(map1 f (car seqs))
((afn (seqs)
(if (some no seqs)
nil
(cons (apply f (map1 car seqs))
(self (map1 cdr seqs)))))
seqs)))
arc> (map [string "." _] "test")
".t.e.s.t"
Though you know, it's funny, my brain doesn't actually like it that map returns different things depending in the types of its arguments. In the same way that a long run-on sentence is annoying if I can't tell what's it's saying until the end, if I see a map I don't know if it's returning a list or a string or whatever until I've looked at its arguments and seen what they are.
So I might like map to always return a list, but still have it treat a string as if it were a list of characters. The example then becomes:
Really useful stuff for beginners like me. On a side node, I think examples would be useful in addition to the definition. (This is usually how I learn.. I watch the examples and I only read definition if I don't understand.)
Also, I think we really need a standard module system..
I think the colon is his convention for within the definition, as a visual marker to distinguish keyword parameters from others. When you later call a function or macro defined as such, you won't need to prepend the colon to arg you're passing (similar to how mine was called in within the definition but could be fruitloops when I called it).
Edit: On second thought, probably does use the colon when calling the function as well.
The prettiness wasn't a concern; as programmers we're used to needing hyphens or underscores, to ignoring parentheses and focusing on indentation. The colon's like that.
