Here's a hopefully clearer and less buggy version of your example:
(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"
This is implemented in pg-Arc using a 'coerce back to the input type, but if a pos-string has a type of 'string, then coercing the output to its original type will probably just make a core string, rather than a pos-string.
"less buggy"? You're using k when it should be key. :P It is shorter, though, so thanks for that.
---
"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...
I guess that is one example where the current way of coerce + extend + new-type-every-time is actually better.
"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...>)
If cons cells are mutable and allowed to be improper, then they need 'scdr too, and it might be more elegant to add 'scar, 'car, and 'cdr.
