(is foo 'cons)  -> t
  (is foo 'table) -> t

I'm thinking something like this:

  (def isa (x typ)
    (.typ:testify type.x))

  (extend testify (x) alist.x
    [some _ x])                ; uses testify on '_ too!

Nope. I don't see a problem with overriding `is`, if that's what you want to do. If you don't want to override `is`, then just don't. Hell, you could override `is` and use testify, if you wanted to.

The point of the `is` attribute is that your object might have a custom idea of equivalence relationship. It's up to you, the designer of the object, to use a sane definition of "equivalence".

Now, if you had suggested to use `iso` instead of `is`, then I could be down with that, but then things like `isa` would need to be changed so they used `iso`... I'm not against the idea, but it would cause incompatibility with Arc/3.1.

I'll also note that the concept of something being eq to multiple things is not exactly new:

  (is nil ())
  (is nil '())
  (is nil 'nil)

---

By the way, originally I extended `isa`, which did work fine, as long as you used `isa` only, but I really wanted it to be perfectly seamless. And, by doing this, I also get another benefit: objects can have a type of object and table, so (isa foo 'object) works:

  (= foo (object))

  (isa foo 'table)  -> t
  (isa foo 'object) -> t

I agree, but your extension to 'is already violates the mathematical definition of an equivalence relation, so it's already insane as far as I'm concerned. For 'is to be an equivalence relation, if (is foo 'cons) and (is foo 'table), then anything equivalent to 'cons must be equivalent to 'table, and that renders the type checks rather useless.

---

"Now, if you had suggested to use `iso` instead of `is`, then I could be down with that, but then things like `isa` would need to be changed so they used `iso`... I'm not against the idea, but it would cause incompatibility with Arc/3.1."

Yes, I consider the pervasive use of 'is to be a flaw of Arc. I'm happy Wart doesn't approximate Arc in this way, and I don't design my languages/libraries to approximate Arc in this way either.

---

"(is nil ())"

When I use 'is, I'm asking if there's any possible way for me to distinguish the values. IMO, all ways to distinguish nil from () in Arc are "nonstandard," so (is nil ()) is just fine.

Right, so if your object has a type of both cons and table, it should definitely act like both a cons and a table, meaning it should have a car, cdr, etc.

---

"Yes, I consider the pervasive use of 'is to be a flaw of Arc. I'm happy Wart doesn't approximate Arc in this way, and I don't design my languages/libraries to approximate Arc in this way either.

[...]

If there were a way to distinguish them, I wouldn't want (is nil ()) to be true. We could still have (iso nil ()), since 'iso can still be an equivalence relation with that constraint. (Everything 'iso to nil would be 'iso to () as well.)"

Alrighty then, it looks like we have a bit of a viewpoint clash. You're seeing `is` as being like `eq`: super-strict, checking for exact equivalence. That's totally fine. I'm seeing `is` as being similar to, but a little bit looser than `eq`.

So perhaps what would be nice is if Arc had 3 operators: eq, is, and iso. eq is stricter than is, which is stricter than iso. Or perhaps we could just get rid of `is` completely and just use `eq` and `iso`.

In any case, those are incompatible changes, so given aw's position with ar, I'm not exactly planning to change ar in that way, even on my fork. Now, if we're talking about Arubic, then yes, perhaps Arubic could be designed differently, using iso everywhere rather than is.

But in the context of ar, I think overloading `is` in this way is the most reasonable choice, given how much of Arc uses `is`. Remember: my goal with this library is to allow you to easily and concisely create both new data types, and also data types that resemble existing data types, like tables.

Thus, I want objects to be as seamless as possible with the existing language. Unfortunately, that means that if the existing language made some poor choices, my library might end up doing something that's kludgy or hacky to make it work. Or hell, maybe the language is perfectly fine, and my library is just hacky and kludgy. :P

We're miscommunicating spectacularly today. XP

If any one thing is equivalent to both 'cons and 'table, then everything equivalent to 'cons must be equivalent to 'table (for us to be talking about an equivalence relation). This means that if anything's type 'is the symbol 'cons, then its type 'is also 'table. All conses are tables. The converse holds too: All tables are conses.

This is absurd (in a non-mathematical way ^_^ ), so we shouldn't let it get that far: Either you must believe that 'is is not an equivalence relation, or you must accept you're not using 'is propahlay. Anyway, I think you are consciously resigning yourself to one or both of those things, in order to "get things done within existing Arc code."

Personally, I'm very worried Arc-compatibility in ar will hold it back in ways like this.... I'm going to do what I can to help establish compatibility anyway though.

---

"So perhaps what would be nice is if Arc had 3 operators: eq, is, and iso."

Aahhhh, no way. XD I think Akkartik says it pretty well at http://arclanguage.org/item?id=13690: "But the problem isn't that it's impossible to find the one true semantic for equality or coercion, it's that the language designers didn't put their foot down and pick one. Don't give me two different names with subtle variations, give me one strong name."

This helps because there's just one utility for people to use and extend, not a variety of utilities which compete for attention. And as I say at http://arclanguage.org/item?id=12803, if we need a different notion of equality, we can define a wrapper type with its own 'iso support which compares its contents using that new notion.

Woah, hey, that gives me an idea... :P

---

"This is absurd (in a non-mathematical way ^_^ ), so we shouldn't let it get that far:"

You sure about that? :P

In all seriousness, I considered representing tables in Arubic as alists (or possibly plists). But that's getting off-topic...

---

"This helps because there's just one utility for people to use and extend, not a variety of utilities which compete for attention."

Absolutely. So I went in and extended `is`. But now you're saying that extending `is` is bad because you want `is` to behave like `eq`. :P It was part-serious and part-joking, since although it would solve this particular problem, I can understand your reluctance to add in a zillion equality-testing things.

---

"Perhaps ar should provide 'eq and each Arc variant running on ar should choose its own notion of equality."

Sounds good to me, provided that I can use Arc's `is` when I want to. In other words: ar provides eq, Arc/ar provides is, and Arc variants can choose to use either one, both, or neither.

---

"Personally, I'm very worried Arc-compatibility in ar will hold it back in ways like this...."

Me too. Personally, I want to just go in and rip up things, and have a backcompat.arc file that smooths over things, but alas... Hell, that's what I did on my fork, and backcompat.arc is loaded automatically, so it behaves almost exactly[1] like Arc/3.1.

---

* [1]: The primary difference is when you want to extend something. For instance, let's say you wanted to extend "no". But my fork doesn't use "no", it uses "not", so you'd be extending the wrong thing. Stuff like that. Probably possible to work around, but ugh.

As I'm sure you're aware, conses and tables are an arbitrary part of the example. ^_^ If you wanted anything to act as both a 'num and a 'cons, then all conses would be nums too.

---

"Me too. Personally, I want to just go in and rip up things[...]"

Yeah... I wonder if I should be forking your ar instead of working on aw's. >.> It would become a fork of a fork of a fork of an Arc. :-p Maybe since it's hard to pull-request all those changes, you could treat your ar as a separate project?

Of course, I was joking. Wait a second... we could Church encode numbers... then they really would be conses...! (I wonder how much longer I could keep this up :P)

---

"Maybe since it's hard to pull-request all those changes, you could treat your ar as a separate project?"