Actually, I am arguing for a "contains as a part" semantics. arc.arc does have polymorphism - there are functions that work on sequences like lists, strings, and tables. The problem, however, is that some of them don't work on user-defined types without munging with 'isa.
What I'm proposing is abstracting some very "basic operations" such as 'car and 'cdr, put them in some "types" (really closer to type classes/abstract base class), and then have the built-in types "contain as a part" the "basic operation type". Then the arc.arc polymorphic functions will work based on the "basic operation type" instead of the actual is-a type, and user-defined types don't have to munge 'isa.
But if you think about it as an abstract base class/mixin/interface, then the standard terminology is "is-a". For instance, in Ruby:
module MyMixin # Like an interface
...
end
class MyClass
includes MyMixin # Like "implements MyMixin"
...
end
foo = MyClass.new
if foo.is_a? MyMixin
puts "is-a"
else
puts "has-a"
end
# Output: "is-a"
I'd rather see the "basic types" not as a collection of basic components, but as a collection of basic interfaces one can implement, or basic type classes one can be a member of, or what-have-you; what I'd really rather do is duck most of it, like Ruby does. If I can define car and cdr for my type, map should work seamlessly.
Regardless, it sounds like a lot of the voices here are in agreement over some common set of the features this plan proposes, which is a good thing. Perhaps we should set the naming quibbles aside for now and try to flesh that out. Or perhaps we should settle on a name for what we are about to flesh out. Either way, it looks like something good could well emerge from this thread.
