"...then anything equivalent to 'cons must be equivalent to 'table, and that renders the type checks rather useless."
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
In any case, I think an object library designed more in line with a perfect ideal Arc would probably be designed differently than mine, and I'm okay with that, since mine is designed to get things done within existing Arc code.
"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."
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.
But in ar, maybe you're right. From http://arclanguage.org/item?id=248, it's clear that your lax interpretation of 'is is consistent with pg's intentions for it. Perhaps ar should provide 'eq and each Arc variant running on ar should choose its own notion of equality.
"All conses are tables. The converse holds too: All tables are conses."
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.
So, if I can get a perfect compatibility layer, then sure, let's go with that, but as long as it's imperfect, then there will always be some niggling corner case which could be used as justification for not changing ar.
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?
Eh, I'm not usually one to make an Arc spinoff from existing source anyway. I'm more likely to either give advice from the sidelines or start from Racket (or JavaScript) and implement utility layers on top of it until I have a system I like. So don't worry about my participation either way, heh. ^_^;
"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."
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?"
Yeah, I'm kinda leaning toward that, especially since some of my changes break backwards compatibility, and aw has made it pretty clear that Arc/ar is aiming at compatibility.
"I wonder how much longer I could keep this up :P"
Probably until we reach "Everything's an object." Then we can take a look at all the ways we distinguish certain objects from others, and we can start all over again. ^_^
