Arc Forumnew | comments | leaders | submitlogin
1 point by Pauan 4928 days ago | link | parent

"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.



1 point by rocketnia 4928 days ago | link

"You sure about that? :P"

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. ^_^;

-----

1 point by Pauan 4928 days ago | link

"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.

-----

2 points by rocketnia 4928 days ago | link

"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. ^_^

-----