Arc Forumnew | comments | leaders | submitlogin
1 point by almkglor 5877 days ago | link | parent

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.

1 point by absz 5877 days ago | link

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
  class MyClass
    includes MyMixin # Like "implements MyMixin"
  foo =
  if foo.is_a? MyMixin
    puts "is-a"
    puts "has-a"
  # 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.


2 points by almkglor 5876 days ago | link

I vote we settle on a name first, because we need it to refer to stuff when we talk about it ^^