I demonstrated how 'extend could, and although there'd often be more code to write given languages or core library designs where the extension problem is hard, I wouldn't phrase it in as magical a way as doing your programming for you.

I'm not suggesting that a new operation will work on existing values without you specifying the behavior for those values; I'm suggesting that you're given the ability to specify behavior for existing values in the first place.

---

"You're saying lisps cover this side, right? So it makes sense to focus on just the other half."

It's not something that can be solved one piece at a time. Pauan's prototype system makes it hard for a programmer to tell whether a given value is really a core 'table or just inherits from 'table, and that makes makes it hard to specify new behaviors that only apply to cases low on the inheritance hierarchy.

Using the prototype system, I'm sure we can make a new kind of value with support for certain existing operations, but then it'll be hard to make a new operation with support for that kind of value.

---

"I think Arc already supports both sides, but it almost seems an accidental property of the implementation. Most lisps don't support extensibility, they lock down the primitives."

Right, that's a big reason I still use Arc, rather than some other language that's solved its expression problem. I see that as being kind of an emergent feature of having this particular language be so unrestrictive of the programmer. Intentional or not, it's a good language to explore the kind of extensibility I'm interested in. ^^

---

"I speculate that in the dawn of time a lisp introduced equal because they needed to compare lists and couldn't change eq."

Whatever the case, I use weak hash tables, I'd expect a well-designed weak hash table to do an 'eq comparison (the alternative being for unreachable keys to stick around in case an equivalent one is constructed), and at that point I could implement 'eq like so:

  (def eq (a b)
    (.b:weak-table a t))

Even if we accept prototypes (which aren't necessary for message passing), that's not true. Data types could have a 'type message that would return it's low-level implementation, in the rare event that you actually needed it. Or they could have a 'proto message that would return what their prototype is.

Also, perhaps you are unaware of how prototypes work in JavaScript... it is quite easy to tell (once you know how) whether something is an Array, or simply inherits from Array [1] (it is pretty much never necessary to actually do this, though...) It is also possible to get completely fine-grained control, so you can extend all arrays, or a specific subset of arrays, or an individual array.

But that's beside the point, because I'm not talking about prototypes (http://arclanguage.org/item?id=14305).

---

* [1] Object.prototype.toString.call(foo) will return "[object Array]" if and only if foo is an actual array. If it's a "subclass" of Array, then it will be "[object Object]" Clunky? Yes. But that has nothing to do with prototypes; it's clunky because prototypes in JavaScript suck. Prototypes can be done in a much more elegant way.

Pretty much. That's what I'm doing: focusing on the other side. Which, in the case of data types at least, makes programs significantly shorter and easier to write.