"I think it's perfectly possible to discuss and improve on the idea without needing a runnable example. You're right that I could have explained the idea better, though."
Agreed. I'm giving you feedback on what would help me understand the idea. Sometimes if an idea has too many subtle nooks and crannies it helps me to see running code. That doesn't compel you to provide it, of course.
"I was just looking for some feedback."
You're not just looking for feedback, you're aggressively/excitably demanding it :) But you'll be more likely to get it from me (as opposed to super boring meta-feedback, and agonized grunts about your writing quality) if you provide runnable code. Pseudocode is no different than english prose.
"Nor am I expecting people to immediately jump in and start using message passing.."
I'm not sure what you're expecting when you say things like "what more do I have to do?". What more do you have to do for what?
(Btw, the answer to the question 'what more do I have to do' is.. give me runnable code :) I usually start out talking about an idea; if it is neither shot down nor embraced I go build it. If it's still neither shot down nor embraced I try to build stuff atop it. Keep doing that until you run into limitations or (slim chance) you build something so impressive people have to pay attention. Platforms need killer apps.)
---
"Go's interfaces actually look an awful lot like message passing."
Argh, here we go again..
(annotate 'reader ; py-arc
(fn (m b)
(case m
'read ...
'string ...)))
Since you can write this in arc today, it's utterly confusing and distracting to me that you keep harping on it.
"what if `isa` tested for an interface?"
This seems to be the absolute crux of your idea. This needs changes to ac.scm. But it has absolutely nothing to do with message passing. Messages are not types, and your suggestion is to augment the type system with a keyword called interface or object that isa can accept. If you made that change, arc would support 'message passing' according to you. Am I right?
I'll summarize my position again. I buy that interfaces are foundational, but lots of things are foundational. Unification like in prolog, pattern matching like in haskell, lazy evaluation like in haskell, messages like in smalltalk, function calls like in lambda calculus. That something is foundational doesn't necessarily make it a good fit for a specific language. To show that something foundational is a good fit in arc and also backwards-compatible, provide runnable examples that look good/short and behave intuitively. Show us that existing mechanisms in arc can coexist with the new feature, that it occupies a niche that they don't already provide. No hand-wavy ellipses.
---
"I'm not saying it's a bad thing that wart differs from pgArc, I was just explaining why I haven't immediately jumped in and started using wart."
No explanation necessary. I really don't think wart needs to be part of this conversation. Just compare your approach with extend and we don't have to keep on going on about "backwards compatible? at least it runs!" and "I don't care about running it, it's not backwards compatible." :)
"Since you can write this in arc today, it's utterly confusing and distracting to me that you keep harping on it."
Having built-in types like table/cons/etc. written in the same way, rather than as opaque blobs in Racket.
---
"I'm not sure what you're expecting when you say things like "what more do I have to do?". What more do you have to do for what?"
"What more do I have to do to demonstrate that message passing has advantages over extend?"
I asked that because it seemed that people weren't convinced that message passing was actually better than extend. This was unfortunate because:
1) It appeared to ignore the evidence that I was presenting
2) It seemed to basically dismiss message passing, but without explaining why. How am I supposed to know how message passing is flawed, unless people explain?
If the dismissal was caused by not understanding my idea, then it's my fault for not explaining well enough.
---
"[...] This needs changes to ac.scm."
Yup!
---
"But it has absolutely nothing to do with message passing. Messages are not types, and your suggestion is to augment the type system with a keyword called interface or object that isa can accept."
You're right: message passing is the low-level idea. Interfaces are built on top of message passing, but aren't necessary to support message passing.
---
"If you made that change, arc would support 'message passing' according to you. Am I right?"
No, in order for Arc to support message passing (at least in my mind), it would be necessary for the built-in types to also use message passing. As you pointed out, user-created Arc code can already use message passing, but that's not useful if you want to create something that behaves like a built-in type.
---
"[...] provide runnable examples that look good/short and behave intuitively."
Kay. I'll need to patch up py-arc first, though, because right now it doesn't support basic stuff (I'm looking at you, `apply`). Once I get py-arc into a decent enough shape, it should take less than a day to get message passing working.
"Having built-in types like table/cons/etc. written in the same way, rather than as opaque blobs in Racket."
"in order for Arc to support message passing, it would be necessary for the built-in types to also use message passing"
Are you planning to replace (f x) everywhere with (x f)? That hardly seems backwards-compatible. (Forgive me if this is a stupid question. I have zero 'expertise' since I haven't read 75% of what you have written in this thread.)
If you provide a way to handle (f x) as an 'f message to x, then you shouldn't need to implement primitives.
"It seemed to basically dismiss message passing, but without explaining why. How am I supposed to know how message passing is flawed, unless people explain?"
You have to try it :) It's pretty clear that nobody here has tried quite what you're proposing, so what you thought of as dismissal was just people thinking (like me for the past few weeks) that they had nothing to add since they haven't tried it, and wanting to reserve judgement until they had an opportunity to play with an implementation. But maybe that's just me :)
...but that's all hidden behind functions, so ordinary Arc code doesn't need to know that. In other words, `apply` would automagically convert (my-table 'something) into (my-table 'get 'something), so Arc code can't tell the difference. That's why it's backwards compatible.
---
"Or are you seeing dismissal in statements rather than silence?"
Mostly rocketnia, but that's fine since they now understand what I'm talking about, so we can actually discuss the idea. :P Their dismissal seemed to be because of a conflict in motivations.
