(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?"

What would that do? Would it just be the same as (wipe car.foo), or what?

---

"(w/self foo (bar<-x ...))"

It would be equivalent to:

  (zap cdr foo)

  (scdr foo nil)

  (= foo '(1 2 3 4))

  (del (car foo)) -> (2 3 4)

  (del (cdr foo)) -> (2)

  (= foo '(1 2 3 4))

  (del (foo 2)) -> (1 2 4)

  (= foo '(1 2 3 4 5 6 7))

  (del (foo 1 4)) -> (1 6 7)

"Then how do you usually invoke a method on an object? I guess what I mean is, what's the shortcut for (w/self bar (bar<-x ...))?"

No shortcut yet, but the idea is that hopefully you won't need to most of the time. The point of defining methods like `call` is that you don't call them directly:

  (= foo (object call (fn () ...)))

  (foo ...)

What's the advantage 'del gives me? Wouldn't my programs have fewer tokens if I directly used (zap cdr foo) instead of (del car.foo)?

Right now 'del looks like a smorgasbord of special-case utilities which could all have shorter tailor-made alternatives. Ideally what I like to see is a utility with an abstract enough description that I can build new tools upon it and straightforwardly extend it to make all my tools handle a new case. (Basically I have the same indifference to 'del as I have to 'coerce. ^_^ )

---

"The point of defining methods like `call` is that you don't call them directly"

Okay, I thought it might be something like that. ^_^ But in that case, it reminds me of Racket's structure type properties again. It's up to you to decide whether that's a flattering comparison or not, but you didn't seem to like them the last time.

---

"One idea would be that get-attribute would return a binded form, so you could just call (foo<-x ...) directly, without needing w/self[...]"

That's what I was intuitively thinking would happen. ^_^ I usually wouldn't say that, though. Perhaps I've been working in JavaScript for too long now. :-p

---

"[...]but still allow w/self to override it."

Er, even my currently weird intuition doesn't like that kind of inconsistency. >.>

What about making 'get-attribute a metafn? That is, ((get-attribute a b) ...) would expand into something like (invoke-attribute a b ...) the same way ((compose a b c) ...) expands into (a (b (c ...))).

Then when you want to call foo's x from bar, you say something like this:

  (w/self bar
    ((do foo<-x) ...))

This would take a bit of language-core-hacking. Metafns are special-cased like special forms in official Arc--and even in your fork of ar, even though you're using gensyms for special forms. I would have tried to "fix" that in Arc a long time ago, but my new design for custom syntax was so different from Arc's that I considered it part of Penknife instead. The most straightforward way to get started in ar would probably be to design metafns as macros which expanded into literal macros, and then to let literal macros expand even when they're not in functional position.

---

Abstraction and readability. Let me answer your question with a question: why do we need (= (car foo) ...)? you can just use scar! Or why do we need (= (foo 'a) ...)? We can just use things like sref!

For the same reasons that overloading = to understand things is nice, overloading del to understand things is nice. So, if you feel that using (scar foo ...) is better than (= (car foo) ...), then by all means use (zap cdr foo), but I personally like using the = forms, and so I like del for the same reasons.

I'll note that there is a defdel, which lets you create new "del" stuff, similar to defset. And you can extend dref as well, just like extending sref. It's basically the exact same idea as =, except it's applying to deletion rather than assignment.

And let me say one more thing. How would you easily and concisely implement this, which deletes a range of elements:

  (= foo '(1 2 3 4))

  (del (foo 1 2)) -> (1 4)

  (= foo '(1 2 3 4 5 6 7))

  (del (foo 0 nil 2)) -> (1 3 5 7)

---

"It's up to you to decide whether that's a flattering comparison or not, but you didn't seem to like them the last time."

I didn't like how they automatically created stuff like exn-message, rather than letting you do (foo 'message). That's different from disliking the overall idea.

---

"Perhaps I've been working in JavaScript for too long now. :-p"

JavaScript does have bind... :P

  foo.bind(this)

"This would take a bit of language-core-hacking."

Or I could just use dynamic variables, which is what I'm doing. It's quite simple: if self is bound, use that, otherwise use the object. Basically, self defaults to the current object, while letting you override it with w/self.

This is actually very similar to JavaScript:

  foo.method(...)
  foo.method.call(bar, ...)

  (foo<-method ...)
  (w/self bar (foo<-method ...))

I was originally going to use that as an example. ^_^

Arc's notion of assignment follows the abstract, informal contract that (= (foo ...) bar) changes whatever (foo ...) returns. This means we can have utilities like 'zap and 'swap that treat something as both a "get"-like expression and a "set"-like expression. I don't see 'del having a contract like that, so I don't see why "it's nice to be able to bundle them up."

I'd implement your range deletion examples like this...

  (mac del (place start (o howmany 1) (o step 1))
    ...)

---

"I didn't like how they automatically created stuff like exn-message, rather than letting you do (foo 'message). That's different from disliking the overall idea."

Ah, okay. That works for me.

---

"JavaScript does have bind... :P"

I'm already fully aware a JavaScript programmer can control the value of "this" using call, apply, or bind. ^_^

All I'm talking about is the way that foo.bar( baz ) calls the value of foo.bar with foo as "this," but if you instead define idfn() and say idfn( foo.bar )( baz ), then "this" is the root object. That's not the most elegant semantics in the world, but I'm saying my intuition is somehow in line with it right now.

(The "root object" aspect isn't part of my intuition, though. I'm fine with idfn( foo.bar )( baz ) using anything for "this", including treating it as a dynamic variable like you are.)

---

"Or I could just use dynamic variables, which is what I'm doing."

Again, I was already taking that for granted and not arguing with it. Instead, I was talking about a way for (foo<-x ...) to automatically use (w/self foo ...), the way JavaScript foo.x( ... ) is like foo.x.call( foo, ... ).

---

"It's quite simple: if self is bound, use that, otherwise use the object."

That's not reassuring....

I'm particularly concerned about the case where we're using (foo<-method ...) from inside another object's method. I'm afraid the self variable will already be bound then, so instead of calling the method on foo, we'll end up calling it on the current object. As a workaround, we'll have to say (w/self foo (foo<-method ...)).

del's contract is that it zaps the variable to whatever dref returns. It is more analogous to = than you think. In fact, it's exactly the same idea, only the name is different, and it's purpose is different.

So, my point still stands. If you think that (= (car foo) ...) is good, then why is (del (car foo)) bad? You may think, "well, I don't think that's useful". Fine. There's plenty of Arc functions I don't think are useful. Just don't use del, then.

But in the same way that = being general-purpose is obviously useful, del being general purpose is obviously useful. For instance, how do you delete an attribute?

  (del foo<-bar)

  (del-attribute foo 'bar)

Did you define new functions "get-foo", "set-foo" and "del-foo"? Well, nobody has to know about "del-foo" because you can just use defdel, in the same way that nobody needs to know about scar, because you can just use (= (car ...) ...)

And nobody has to know about set-foo, because you can use defset... and nobody has to know about get-foo, because you can use defcall. Notice the pattern, here?

---

"The specific case I'm interested in is the one where we're using (foo<-method ...) from inside another object's method. I'm afraid the self variable will already be bound then, so instead of calling the method on foo, we'll end up calling it on the current object."

If the name and purpose are different what's left? :p

Slices and steps don't currently work with '=. So they feel bolted on to del.

Of course. I don't recall ever conflating the two, and I think we should allow for both assigning to slices, and deleting slices. In fact, then deletion could use assignment, so this:

  (del (foo 0 1))

  (= (foo 0 1) nil)

  (= (foo 0 1) nil)

(FYI: The ..< I'm using is Groovy's notation for half-inclusive ranges, inspired by Ruby's ... notation but less ambiguous with Groovy's other syntax. I also prefer it for its obvious asymmetry.)

It would probably make more sense to use (slice foo ...) to get a slice and (= (slice foo ...) ...) to put it back.

This isn't ideal, as far as I'm concerned, 'cause it means we don't always get what we put in:

  arc> (= foo '(a b c d e f g))
  (a b c d e f g)
  arc> (= (slice foo 1 3) '(x y))
  (x y)
  arc> foo
  (a x y e f g)
  arc> (slice foo 1 3)
  (x y e)

  arc> (= foo (table))
  #hash()
  arc> (= (foo 'a 1) nil)
  nil
  arc> foo
  #hash()
  arc> (foo 'a 1)
  1

  (= (foo 0 1)   '(3 4))   ; splice a list into the first element
  (= (foo 0 nil) '(1 2 3)) ; replace the list with a different one

  (= (cut foo 0 1) '(3 4))

In tables, (foo 0 1) already means the same thing as (or foo.0 1). But hmm, maybe you're not interested in slicing tables. That's fine, then. ^_^

By the way, newLISP does something like that with (0 1 foo): http://www.newlisp.org/downloads/newlisp_manual.html#implici...

The other issue was that I think at some point you were using (foo 0) to mean a one-element slice, and that would definitely be ambiguous with regular old indexing.

---

"Hm... why not use cut rather than slice?"

What would a table slice even mean? They're not even ordered. The closest thing would be a table that has a subset of the keys of another table, but that wouldn't use numeric indexing.

---

"The other issue was that I think at some point you were using (foo 0) to mean a one-element slice, and that would definitely be ambiguous with regular old indexing."

I was? (foo 0) should always be an element, not a slice. Ah well, it doesn't matter. If I did use that, I was incorrect.

I'll note that (del (foo 0)) is equivalent to (= (foo 0 1) nil) so perhaps that confused you.

---

"Arc's 'cut accepts start and stop positions, and your slicing examples instead use a start position and a length."

They did? I always thought of it as being a start/end position, like cut. So for instance:

  (= foo '(1 2 3 4 5 6))

  (= (foo 2 5) nil)

  foo -> (1 2 6)

  (= foo '(1 2 3 4 5 6))

  (cut foo 2 5) -> (3 4 5)

Hence my "but hmm." ^_^

---

"I'll note that (del (foo 0)) is equivalent to (= (foo 0 1) nil) so perhaps that confused you."

Yeah, that's probably it.

---

"I always thought of it as being a start/end position, like cut."

It's hard to tell because you use 0 as the start pretty often, but here are the two examples I was going off of:

From http://arclanguage.org/item?id=14656:

  (= foo '(1 2 3 4 5 6 7))

  (del (foo 1 4)) -> (1 6 7)

  (= foo '(1 2 3 4))

  (del (foo 1 2)) -> (1 4)

  (subset x 'foo 'bar 'qux)

  (x 0 1)

  (foo 'a 'b 'c)

By the way, sref has a terrible argument signature:

  (sref foo value key)

  (sref foo key value)

  (= (foo 0 1) 'bar)

  (sref foo 'bar 0)

  (sref foo 'bar 0 1)

---

Yeah, I think I noticed that at one point a long time ago, and I consider it to be a bug. (I promptly forgot about it. XD;; ) I never rely on that behavior, but then I don't extend things in the Arc core much either, for cross-implementation compatibility's sake.

---

"To be fair, having the key as the last argument is great for slices"

I think that's the reason it is the way it is. I've ended up designing some of my utilities the same way. For instance, I usually give failcall the signature (func fail . args), which is very similar to sref's (func new-value . args). I'd probably call 'sref "setcall" if I were to reinvent it.

  (= (sig 'msec nil))

  (= (sig 'msec))

  (= (sig 'seconds nil))

  (= (sig 'seconds))

That was my first reaction as well. I see one general new idea here, though: to extend indexing to return not just places but slices like in python and Go.

  (= l '(1 2 3 4))
  (l 1) ; 2
  (l 0 2) ; '(1 2)
  (= (l 0 2) '(3)) ; l is now '(3 3 4)

  (= l '(1 2 3 4))
  (= l.0 nil) ; l is now (nil 2 3 4)
  (= (l 0 1) nil) ; l is now (2 3 4)

It is in Python. Would it be useful in Arc? We already have cut, which does the same thing:

  (cut '(1 2 3 4) 0 2) -> (1 2)

  foo = [1, 2, 3, 4]
  foo[0:2] = [0]
  foo -> [0, 3, 4]

  del foo[0:1]
  foo -> [3, 4]

  del foo[:]
  foo -> []

And del is identical to assigning to [].

  >>> foo = [0, 1, 2]
  >>> foo[0:1] = []
  >>> foo
  [1, 2]

  (object print (fn () "%custom printing!%"))

  (letr self (object)
    (set-attribute self 'print
      (fn () (+ "#<table of length " len.self ">"))))

  (letr self (object print (fn () (+ "#<table of length " len.self ">")))
    self)

And soon I'll try changing it so you don't even need the letr:

  (object print (fn () (+ "#<table of length " len.self ">")))

In this kind of situation I use a utility I call 'named:

  (named foo bar)
  -->
  (ret foo nil (= foo bar))

What was that word I used to tactfully criticize your writing those many months ago? Well, Pauan is making you look good >;)

This is where something like Lathe's secretargs might come in handy. If we made a secretarg for "the object the function is invoked on", then it's like every function in the language has it as a lexical parameter. Traditional function calls just pass a default value, and traditional functions just ignore it; you have to use special-purpose forms to define secretarg-aware functions and pass those arguments in. Is this close to what you have in mind?

A failure secretarg is how I hacked in failcall to Arc--and now JavaScript--and I'd also make a secretarg if I ever felt the need to implement keyword arguments. (Secretargs are essentially first-class keyword args without names, but one of them can hold a more traditional keyword table or alist.) The catch is that things like Arc's 'memo and JavaScript's Function#bind() aren't written with secretargs in mind, so they're not especially seamless with the language. But I think it would be cool to add secretargs to ar on a more core level. ^_^

Here's where I originally talked about secretargs: http://arclanguage.org/item?id=13825

And here are my implementations in Arc and JavaScript:

https://github.com/rocketnia/lathe/blob/master/arc/dyn.arc (search for "secretarg")

Hello dynamic variables!

---

"Is this close to what you have in mind?"

Sorta. The idea is close, but your way looks too verbose. I want it to be really short and simple, so having to define methods in a special way does not sound good to me. I want them to be plain-old functions.

I have an idea for what I'm going to do, and I think it'll work, because in ar, lexical variables always take precedence over dynamic variables, from what I can tell.

By the way, right now I only care about ar compatibility, since ar has nifty stuff like dynamic variables, which I've come to love. This not only should make the library shorter and easier to understand, but I honestly can't care much about compatibility, because my library kinda needs defcall, which isn't standardized[1] (and isn't even in Arc/3.1 at all)

---

Secretargs happen to be implemented in terms of dynamic boxes. The benefit of secretargs is that you can always pass the default value just by making a normal function call; you don't risk propagating the existing dynamic value into the call. Whether that's important in this case is up to you. ^_^

I agree that Arc has essentially no de jure standards[1], and I think that's a good thing.

---

Anyway, I think any discussion of modules really depends on the nature of the language. How are people likely to compose their programs? Erlang programs can be updated on the fly. Arc programmers tend not to treat libraries as black boxes. As for me personally, I like to generate my programs by writing other programs. Sometimes a separation of modules is useful so that some can be autocompleted in an IDE or separately compiled. There's a wide range of crazy spins on collaborative (and otherwise modular) programming which might provoke different ideas of the term "module."

I consider it to be a prototype of what Penknife is supposed to be like, but with no module system or custom syntax. It's mostly for fun and so I have something to run when my only runtime is a browser, but I wouldn't be surprised if an s-expression parser over lathe.js turned into a pretty viable hack of a language.

That hype about Node.js is a bit exaggerated though. I haven't read this, but it seems like a more realistic explanation of what's going on with the asynchronous IO: http://blog.mixu.net/2011/02/01/understanding-the-node-js-ev...

Reminds me a bit of UML. :-p

"Achieving this kind of separation has been the focus of much open-implementation research. A primary focus has been the concept of computational reflection, which explores issues of how modules can provide interfaces for examing and adjusting themselves - that is, how modules can provide meta-interfaces. Although this may sound somewhat esoteric, it is exactly what open implementations need - an interface for controlling the implementation strategy that sits behind the primary interface." (http://www2.parc.com/csl/groups/sda/projects/oi/ieee-softwar...)

And that reminds me of dependency injection frameworks. ^_-

That's not to say Kiczales has UML or dependency injection in mind, just that those camps (or at least their stereotypes) worry about the same things. ...Which probably isn't surprising, since it's all programming. :-p

Speaking of which, I've actually been worried about both these issues recently.

I've had a massive interactive story idea in mind for a few years now (http://rocketnia.wordpress.com/2009/04/26/dun-dun-dunnnnn/), and the task of planning out such a story currently has me thinking in terms of describing the automaton-like system of the fictional world in terms of several subplot descriptions which somehow coexist and flesh each other out (no clue how yet).

Meanwhile, I just looked at my Penknife draft in a somewhat new light today, as a language which needs as obvious an implementation of things as possible in order for the action of extending a core utility to have predictable consequences. I've already been avoiding complicated algorithms for fear that they'd be wrong, have unstable APIs, or be hard to customize, and at some point I probably even thought about this practice as a form of putting the implementation out in the open, but something feels different about saying that today. Dunno if it's good or bad. ^_^

It's actually kind of an example in (the most advanced part of) the Racket getting started pages:

> Given the "many" example, it’s a small step to a web server that accepts arbitrary Racket code to execute on the server. In that case, there are many additional security issues besides limiting processor time and memory consumption. The racket/sandbox library provides support to managing all those other issues. (http://docs.racket-lang.org/more/index.html)

The racket/sandbox module reference has another example:

> For example, here is a quick implementation of a networked REPL... (http://docs.racket-lang.org/reference/Sandboxed_Evaluation.h...)

Can you set the car of a string to an arbitrary value, like you can with a cons? Is "" nil?

Yes and yes. I plan for the only difference between strings and conses is that A) they have a type of 'string, in addition to a type of 'cons, and B) they display differently, surrounded by "" rather than ()

Generally speaking, strings will only contain characters (since that's what the string constructor does), but I don't see why they can't contain arbitrary stuff, if you want to do that.

I like the name iso. is raises philosophical questions about what makes two things equal. iso neatly sidesteps them by evoking the precise image of structural equality.

---

Oh, oops. Sorry! XD I guess I figured that the name 'is is so good that something oughta use it. And for some reason, I'm not currently concerned that the name "is" should be restricted to the most picky kind of equality operator (as I was in that thread).

---

"iso neatly sidesteps them by evoking the precise image of structural equality."