For the record, that's true, but I do follow a coercion pattern sometimes. See the end of http://arclanguage.org/item?id=14220: "To digress a bit, coercion is a positively useful design pattern when...."

As it happens, 'each is one of those times I'd use a coercion pattern. I'd probably define these utilities, with these dependencies:

  each  -->  some  -->  seqify  -->  entries  -->  keys  -->  unwrap-my-table

One way to add evidence is to actually have an implementation of an arc-like language with methods (like I have done with wart). And I don't mean half-baked pseudocode that I have to spend time massaging. (http://arclanguage.org/item?id=14288) Who knows if I would massage it like you would have? You're leaving too much unspecified to persuade me.

"What more do you want? Should message passing do tap dancing too?"

I'm not going to respond if you talk like that.

http://arclanguage.org/item?id=14261

Look at the first example there. That is a perfectly reasonable and trivial thing to do (creating a table that can inherit from another table). Message passing is less than half the size of wart... And that was without implementing iso and fill-table, which would make wart even more verbose...

That is not "moving parens around". This is a clear example where message passing is less than half as verbose as extend. Message passing should always be at least as good as extend, and in some situations will be significantly better. If you would rather use extend and write programs that are over twice as long, then go ahead... but I thought one of the main points of Arc was brevity.

---

"I'm not going to respond if you talk like that."

It was a joke.

---

"One way to add evidence is to actually have an implementation of an arc-like language with methods (like I have done with wart)."

As said, I plan to implement this in py-arc.

---

"Keep running with your ideas instead of waiting for us to catch up. If they're good you'll eventually bring us around. Expecting validation from others before moving onward is a recipe for misery. So we're fools. Ignore us."

If you would rather use extend and write programs that are over twice as long, then go ahead

How would your approach clone from strings rather than from tables? Those are the sorts of questions I am talking about. Are methods useful if they can only clone tables?

The main point of arc is brevity across a range of programs.

"As said, I plan to implement this in py-arc."

Let me look at an example that is a bit more string-oriented: we want to make a string that can do substring searches with function notation. In other words, we want this to work:

  (= my-string (pos-string "foobar"))
  (my-string "foo") -> 0
  (my-string "bar") -> 3
  (my-string 0)     -> #\f
  (my-string 3)     -> #\b

  (def pos-string (x)
    (annotate 'string
      (fn (m k . rest)
        (case m
          'get (case (type 'k)
                 'string (posmatch k x)
                         (apply x m k rest))
               (apply attr x m k rest)))))

  (def pos-string (orig-string)
    (annotate 'string
      (fn (message key . rest)
        (if (and (is message 'get) (isa key 'string))
          
          ; This message represents a function call with a string as the
          ; first argument. Let's use 'posmatch for that.
          (posmatch key orig-string)
          
          ; We don't handle this message. Let's use 'attr to propagate
          ; raw message to the original.
          (apply attr orig-string message key rest)))))

"Can it be done without extending every single built-in that uses strings?"

There aren't that many axiomatic things strings do in Arc. In my mind, a custom string type would only have to support two operations: being called as a function; and being coerced to a lazy list, sent through a function, and coerced back. If a string-like thing supports those two behaviors, the core utilities should be able to handle it.

Arc's strings also support 'sref, but I pretend they don't. :-p

The "being coerced to a lazy list, sent through a function, and coerced back" utility may seem overcomplicated. It's the solution I prefer to enable this behavior:

  arc> (map inc "abcde")
  "bcdef"

---

"There aren't that many axiomatic things strings do in Arc"

Yeah, I know. Tables seem to be the big pain point. Possibly conses too, if somebody wanted to extend those... tables seem like they'd be the most common thing to extend, though, and also the trickiest.

---

"[...] being coerced to a lazy list, sent through a function, and coerced back [...]"

Oh! Oh! I know! Let's use message passing! :P We can give strings an 'iter message! Just like Python! Whooo! I'm reminded of the Jamie Zawinski quote, "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems."

Actually, I think it'd just be easier to define a `coerce` rule for 'iter, no need for message passing in that situation. Now, as for the actual creation of iterators, that could be done with message passing. :P

Then again... you're right that if pos-string uses the same type 'string as built-in strings, then `coerce` won't be able to know that it should use pos-string... unless you added in a message to the iterator, of course. But then that won't play as well with coerce...

Fixed! Now it oughta be less buggy. ^^

---

"Tables seem to be the big pain point. Possibly conses too[...]"

I could be wrong, but I think it's enough for a table to extend 'keys, function call behavior, and 'sref. <Insert usual disclaimer that there'd need to be predicates like 'supports-keys in the absence of failcall.>

For Penknife's purposes, the only reason I care about cons cells is that they're eager implementations of nonempty lazy lists. They should support function call behavior, 'sref, and the one and only lazy list operation:

  (iffirst first rest seq
    <...thing to do with first and rest if the seq isn't empty...>
    <...thing to do if the seq is empty...>)

Message passing is general... it can apply to all the built-in types, and can also apply to all user-created types. It does increase brevity across a range of programs. You could even write all Arc code in that style, but I don't recommend that. I'm restricting my discussion of message passing to data types because message passing is clearly superior with regard to data types. I make no claims about the superiority of message passing with regard to things other than data types.

I've been using specific examples because as aw mentioned (http://arclanguage.org/item?id=14264) it's important to explain the problem that it solves, and also demonstrate how it solves the problem... but the concept is general.