my system uses duck typing: if it supports these arguments, use it. all you need to do is define something that looks like a table, and Arc automatically treats it as if it were a built-in table.
I see, yeah you're right. The alternative to duck typing would be subtypes. Ugh.
No need to extend Arc's built-ins to convince it that, "yes I really really really want this to be a table."
You're saying more than that, you're saying how. That logic is common to both approaches. Your approach is superior anytime user code has language like if (isa x 'table) ... Otherwise the two are equivalent in power.
I always treated branching on types as a code smell. wart basically grew out of trying to remove every case of that pattern in the arc codebase. You've given me something to think about, thanks.
By the way... I know using (case) is ugly. On the bright side, my system doesn't care how you write the actual function, just so long as you follow the interface. So you could use wart's :case for it as well:
(def my-table ()
...)
(def my-table (m) :case (is m 'keys)
...)
(def my-table (m k) :case (is m 'get)
...)
(def my-table (m k v) :case (is m 'set)
...)
...at least, I think that's how :case works? I actually like the wart style. That's supposed to be equivalent to this:
(= my-table (fn (m k v)
(case m
'keys ...
'get ...
'set ...)))
So yeah, it doesn't matter how you define your function (case or :case or `if` or extend or whatever), just so long as it follows the interface.
P.S. My goal here isn't necessarily to increase raw power, it's to increase extensibility and conciseness. Being able to do the same thing, but in a very hacky and verbose way doesn't sound appealing to me. So if wart has equivalent power, that's great! But I want to do better. I want to have equivalent power and make it shorter and make it more extensible.
Yeah that was the half of your point I understood when I was peddling wart :) But yes wart won't handle user code that checks the type of an object if that is important to you.
