Actually, I never refuted that point. Tables have always had a keys, call, and set attribute. Even while providing all three, it still ended up being far less verbose than wart (at the time). If you have improved wart so that it's less verbose, that's great.

---

"It's mostly just moving parens around. (http://arclanguage.org/item?id=14314) "

I can agree with you that with proper macros, like defcall or defset, you can indeed make extend much less verbose. That doesn't change the fact that at the time I made those remarks, extend was indeed much more verbose.

In fact, rocketnia was at one point describing rulebooks, which used a macro to do all the fancy extend shenanigans. (Or at least, I think that's what it does)

---

"Pauan, does ar support vals? Or is there no need?"

No need. In Arc/ar `keys` and `vals` use `each`, and `each` uses `maptable`, so my implementation extends maptable and gets everything for free.

---

"If it's down to subjective preferences, would I use message-passing in arc? Since it seems to provide no advantage or hook that I can't reimplement in isolation I'm happier giving each such hook its own top-level def."

I'll note two things:

1) I used message passing to implement objects, but the idea of message passing is possible in other areas, like functions. So I'm going to assume you were talking about my object.arc library.

2) The point of this is not necessarily to enable you to do new things that you couldn't do before... in fact object.arc itself uses extend to accomplish what it does.

The point is to make dealing with data types easier and (in some cases) less verbose. One of the problems with extend is inefficiency... if you have to extend things every time you create a new clone, for instance, that'll add up if you make multiple clones.

With objects, you just extend once and then use the interface. Secondly, you can easily change an object's attributes at runtime, which is a lot clunkier and harder to do with extend. You can also implement delegation a lot easier. For instance, I am planning on adding in a get-attribute attribute that would let you seamlessly and easily delegate to another object:

  (= foo (object ...))

  (= bar (object get-attribute (fn (k)
                                 (get-attribute foo k))))

As always, it is possible to do everything with extend, but that does not mean that everything is easy. I'll also note that I do indeed use extend quite a bit, and even decided to give up on my coerce-to-fn idea (ala Anarki) and just use extend.

The point was not to replace extend, the point was to say, "oh boy, extend is pretty clunky in these few areas... hm, let's fix that!" And so I did.

One of my goals was to allow you to create something with type 'table and have it seamlessly work just like existing tables. That goal has been accomplished.

I'll note that namespaces in my import.arc library are seen by Arc as... tables. Which is why w/namespace works on tables. There is no special 'namespace type, they're just tables. That's because I'm viewing types as an interface, and so my object.arc library makes that easy.

---

I'd also like to note that it really doesn't matter whether anybody likes my object.arc library or not. Let's suppose I was wrong and extend is fantastic and perfect and my object.arc library is just redundant... well, then we can get rid of it and just not use it.

On the other hand, let's suppose that extend is fantastic, but there are a few areas where it's clunky and verbose... then you can use extend most of the time, only loading up my library when you actually want the functionality it provides.

Before, it was about getting it into Arubic's core, so I had more of a vested interest in it. But now it's just a normal library, so we can simply use it or not as we wish.

Whether you would actually use such a macro in practice, I don't know, but it was relevant to my point that you can use a macro to make extending less verbose.

  // Define a constructor _.Seq and a rulebook _.iffirstRb.
  lathe.deftype( _, "Seq", "iffirstRb" );
  
  // Define a constructor _.Seq using an existing rulebook.
  lathe.deftype( _, "Seq", _.iffirstRb );

Yeah, it's a pain if you program in a prototype-based style.

"..at the time I made those remarks, extend was indeed much more verbose."

No, that example hasn't actually changed much. My earlier example had defcall and defset (http://arclanguage.org/item?id=14244). I believe versions also are in anarki. I deliberately left out fill-table and each because they were unnecessary. The only reason I bring it up now is that I feel able to discuss real code on the right column.

Actually, it's a pain anytime you have a function that constructs objects, like the built-in `table` function in Arc. To work around that, you might give it a special type, like 'my-table and then use extend only once... but then where do you store the actual functions? The obvious place is to store them in a hash table... but then you're right back to objects. :P

---

"I deliberately left out fill-table and each because they were unnecessary."

You're right, that wasn't a fair comparison of wart. I apologize. I hadn't actually used wart, so I was going off of what you said, and also my experience with Arc/3.1, where you would actually need to extend things like iso, maptable, etc.

So perhaps my point should have been more along the lines of "god Arc/3.1 is too verbose with data types", since it would seem that ar and wart are both far better than Arc/3.1.

---

Basically, if the object has a `keys` attribute, it uses that, otherwise it iterates over the object's attributes. So by extending maptable, my library gets keys, vals, and each, all for free.

This lovely property is because of Arc, though, not my library.

---

However, it does demonstrate that it's more convenient to simply create an object, rather than having to create a new type (like 'heir) and then use defcall, defcoerce, etc.

So the real point isn't that my library is perfect, the point is that our current way of thinking of types is flawed. We should either try to improve it (which my library does), or dump it entirely and use something completely different (rocketnia seems to prefer this approach).

Ultimately, I think the reason dealing with data types is clunky is because our type model is clunky. extend vs. objects is an interesting debate, but as you pointed out, with proper support, extend is more-or-less just as concise as objects in most circumstances.

So the real question is about dealing with types. How do we differentiate different things? My object.arc library provides one possible way. Using extend provides a slightly different way.

Indeed. I think I prefer creating new types because I don't like something that looks like a string but isn't. Rails, for example, has these things called scopes that encapsulate sql queries. If you try to print a scope you see an array. But if you treat it like an array you can end up in sixteen different subtle kinds of trouble.

Then again, the current interfaces in Arc are fairly lax... conses mostly just need to support car, cdr, call, and set... tables need to support call, set, and keys.

So for making things that behave like tables, it just makes sense to give them a type of table, since the interface is so easy to adhere to. Like namespaces in import.arc, for instance. It makes sense to give them a type of table.

---

However, you're right that sometimes you might want something that's similar to, but slightly different than an existing type... in which case you'll probably want something else. On the OOP side you have subclasses and prototypes. On the Arc side you have... uh... extend, I guess, which is more general.

So let's imagine that object.arc is basically a thin skin over extend... in which case we might as well treat objects and extend as equivalent, since anything objects can do, extend can too.

I remember being sorta-vaguely interested in it a long while ago, but never tried it. Now that I've learned Arc, all I can see is that the examples would be half as short (or shorter!) with macros. :P

If I were to strictly translate the example on their home page, it might look like this:

  (def make-color-trait (c)
    (trait color (fn () c)))

  (def make-point (x y)
    (trait-compose (make-color-trait 'red)
                   (trait getx  (fn () x)
                          gety  (fn () y)
                          print (fn () (string x '@ y)))))
                          
  (= p (make-point 0 1))
  (p 'color) -> 'red

---

Also, apparently traits were invented in Self... which also invented prototypes (!):

Your example of something that claims to be an array but gives you trouble if you treat it like an array strikes me as more an issue with that particular bad implementation...

Interesting question though: what would treating types like interfaces look like from an Arc point of view? I'll have to think about that one :)

In Lathe/arc, I filter on the first argument's type using "ontype" or multiple first arguments' types using "ontypes":

  (use-fromwds-as rc (+ lathe-dir* "orc/orc.arc"))
  (= my (nspace))
  
  ; These are already defined in orc.arc, but I'm redefining them here
  ; for the sake of example.
  
  (rc:ontypes rc.oiso2 (a b) (cons cons) my.cons
    (and (rc.oiso2 car.a car.b) (rc.oiso2 cdr.a cdr.b)))
  
  (rc:ontype rc.otestify () fn my.fn
    self)
  
  ; General pattern:
  ;
  ; (rc:ontypes <rulebook> <parameters>
  ;     (<type of a leading parameter> ...) <rule label (optional)>
  ;   <implementation>)
  ;
  ; (rc:ontype <rulebook> <parameters other than the first>
  ;     <type of the first parameter> <rule label (optional)>
  ;   <implementation, where "self" is the first parameter>)

In orc.arc, this comes with an inheritance system I don't use much, but I've found I use 'ontype itself a lot when defining new types. Porting the inheritance system would be hard without porting Lathe's rule precedence system along with it.

Update: I've been mulling adding 'def :type' to wart for some time, so that I can say (def prn(x) :type 'integer ..) rather than (def prn(x) :case (isa x 'integer) ..).:

  (extend-macro def(name params &body body) :case (iso :type (car body))
    `(def ,name ,params :case (isa ,(car params) ,(cadr body))
       ,@(cddr body)))

https://github.com/akkartik/wart/commit/9559f27eec3994d9779b...

Update 2 hours later: Turns out if isa can handle a list of types, so can :type.