That seems like a very interesting idea, and I haven't had time to fully digest it yet, but here are some of my first thoughts.
(1) I don't really like having to write (call car x); that adds a layer of complexity, and I'm just going to want to write (car x), thus losing benefits down the line. It might be nicer to by default do things polymorphically, and then only specify "I want thiscar" when we need it.
(2) If you just define a way to say "I implement this function" in the core, and leave out interfaces, then they can be added on later. If you just define interfaces in the core, going the other way requires lots of extra one-function interfaces. Don't do it! Provide interface functionality, but put that on top of the core.
(3) Using a polymorph to store methods (and everything else) is a wonderfully clever bit of metahackery, and really does seem to allow pretty much anything you want: it's all in the getmethod. Uniformity is very powerful: look at Smalltalk and Lisp. Now look at Java. Quick, look at Lisp again! :)
(4) With the way you make things explicit, it feels like you're pretty much implementing an ugly OOP system on top of Arc. Again, make more things implicit--that way it won't feel like classic OOP, and thus (hopefully) won't be used like classic OOP. call feels like a long-winded way to do a message send (à la Smalltalk); if that's explicit, it feels like we're Greenspunning Smalltalk. Instead, let's integrate the feature. (I don't know if that was clear at all... it's related to point 1.)
I can't wait to see what people do with this--the more I think about it, the more I like this idea.
(2) Could be done, and have interfaces simply act as a shortcut way of saying "I have (for objects) or need (for functions) the following: a, b, c, and d"
(4) LOL. We're making an informally-specified, ad-hoc, bug-ridden implementation of half of CLOS. ^^
"We're making an informally-specified, ad-hoc, bug-ridden implementation of half of CLOS"
That's what I thought when I was thinking about solutions for these problems :)
I think (1) could be solved simply by using redef on each polymorphic function : if car becomes polymorphic, just encapsulate the desired behavior in a new definition of car that will do the dynamic dispatch for you. If you want a specific version of car (e.g. the array implementation), just call it explicitly : (array-car x) .
(1) Yep, I agree. You'd want to put the polymorphisn all the way down, so you nearly never have to actually use call in your code.
(2) Again, agreed. Implement features on top of the system, rather than within it, just like Arc!
(4) Might be tough to make everything completely implicit. Ideally, the whole thing should be invisible, like it didn't even exist, but works anyway. All suggestions for doing that are welcome.
(4) Actually, I think we're in agreement there, I just didn't say what I meant too well :) In fact, one of the reasons your post may look so explicit is that you're discussing how to implement the system, and thus have to deal with a lot of "low-level" code, the way the first few lines of arc.arc look nothing like most Arc you'll actually use (safeset, etc.). For instance, call certainly appears to be such a feature—used to get the system working (and possibly sometimes used the way Ruby uses its #send method), but not in every case. Similarly, since you're discussing implementing the system, of course implementation details will show through. At any rate, if the goal for the "end-user" is invisibility/integration/implicit behaviour (which I think all mean roughly the same thing in this context), then we're in agreement.
Yes, I wasn't disagreeing with you, just pointing out that it might not be easy. As you say, some of this will just disappear because it's low level and will be buried right at the bottom where you implement the basic type operations. Hopefully it'll all turn out like that, but I'm not counting my chickens yet.
