"define something that looks like a table, and Arc automatically treats it as if it were a built-in table"
Bringing http://arclanguage.org/item?id=14268 back here, how would you convert code like (isa x 'table) into a method framework? Wouldn't it require getting rid of types altogether?
"how would you convert code like (isa x 'table) into a method framework?"
Haha... that's what I've been explaining all along! That's the whole point of message passing: defining a low-level framework that makes it easy to both create new types, and also extend existing types.
Go seems to do this really well. Functions can ask for a specific interface, which is defined as a set of operations. But types don't have to declare that they implement the interface. http://golang.org/doc/go_tutorial.html
I still don't see what this has to do with methods, though. (I still can't follow that humongous comment[1]). Both C++ and Java have methods. No language but Go tests for an interface by seeing the functions it supports.
And this isn't the same as duck typing at all. Arc does duck typing just fine. In arc or python there's no way to convey tableness or any other ness. You just use the operations you care about, and hopefully any new types remembered to implement them.
Duck typing has no contract, Java has too rigid and inextensible a contract. Go is just right. And you're hosed in any of them if you write code of the form if (isa x table) ..
[1] I think I've missed half your comments in recent weeks. Either because they're so long and hard to follow, or because there's just too many of them and I forgot to go to the second page of new comments. The latter is a weakness of this forum structure. For the former, well, I think you spend too much time describing methods. Most of us have seen them in other languages. What you suggest is subtly different, and the subtleties are lost in the verbiage.
Which is why runnable examples are useful. You're right that wart differs from arc in subtle ways. That's why I have unit tests, to enumerate all the subtleties. I think you're calling it out (fairly) for lots of gritty details, and then doing the same thing even more egregiously.
Or maybe I just suck at reading comprehension compared to the rest of the group here :)
"Go seems to do this really well. Functions can ask for a specific interface, which is defined as a set of operations. But types don't have to declare that they implement the interface. http://golang.org/doc/go_tutorial.html "
So... Go's interfaces actually look an awful lot like message passing. Here's a comparison:
type reader interface { // Go
Read(b []byte) (ret int, err os.Error)
String() string
}
(annotate 'reader ; py-arc
(fn (m b)
(case m
'read ...
'string ...)))
(object reader ; py-arc, with sugar
read (b) ...
string () ...)
The idea is, every object is a collection of methods, and also a type. You can just call the methods directly, bypassing the type (this is duck typing), or you can check the type to make sure it implements the interface you want... or you can use coerce to change it's interface. Here is an example of the three ways, assuming foo implements the reader interface:
Message passing is simply the low-level way to create objects + methods... or prototypes. Or rulebooks. Or other things. To put it an other way, objects are just macros that expand to message passing.
Think of it like continuations and iterators. Continuations are lower-level than iterators, and it's possible to create iterators by using continuations. Message passing is the low-level idea, which can be used to create higher-level things, like prototypes, objects, or interfaces.
---
"Duck typing has no contract, Java has too rigid and inextensible a contract. Go is just right. And you're hosed in any of them if you write code of the form if (isa x table) .."
But what if `isa` tested for an interface? In other words, (isa x 'table) would be like saying, "does x support the table interface?"
---
"I think I've missed half your comments in recent weeks. [...] For the former, well, I think you spend too much time describing methods."
Yeah, I've probably been a bit too excitable about this... ^^;
---
"I think you're calling it out (fairly) for lots of gritty details, and then doing the same thing even more egregiously."
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. I think it's good to try out different approaches. Nor am I expecting people to immediately jump in and start using message passing... especially since message passing probably isn't useful for everybody.
I was presenting my ideas in the hope of getting useful feedback... so that my ideas can be improved, or rejected. I know that you guys are smart, and by presenting my ideas here, you all have already helped me improve them. I was just looking for some feedback (which I'm finally getting, which is good).
Also, 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.
"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.
"So... Go's interfaces actually look an awful lot like message passing."
That's a bit of a tautology. ^_^ If I'm not mistaken, you took the term "message-passing" from its object-oriented "foo.bar( baz )" context to begin with.
---
"Yeah, I've probably been a bit too excitable about this... ^^;"
Well, I (rocketnia) can't blame you for that, and I can't blame you for not having runnable examples either. I tend to be guilty of both those things a lot, and this discussion is a great example. >.>
