"It's not using the function car to get the message... it's using the symbol 'car."
Whoa. Should methods/messages be first-class like functions? Can I pass them around, store them in symbols, generate objects with gensym'd methods? How does 'call by name' interact with all that?
We can provide feedback about these things until we're blue in the face and it won't count for a thing because the first attempt at implementation will run into some blazingly obvious issue that we all missed. Why expend so much collective attention so inefficiently when you can just build it and see what happens?
"Whoa. Should methods/messages be first-class like functions?"
Sure, why not? I actually envision them being implemented as functions, but other ways are possible. In JavaScript, methods are ordinary functions.
As for messages being first-class... they sorta already are, in the sense that the messages are symbols. I don't see much reason to give messages a special type; they can just be symbols.
---
"How does 'call by name' interact with all that?"
Hm... not sure.
---
"Why expend so much collective attention so inefficiently when you can just build it and see what happens?"
Because py-arc is in a pretty sad state right now. :P Once it's spruced up, implementing message passing should be trivial.
"Because py-arc is in a pretty sad state right now. :P Once it's spruced up, implementing message passing should be trivial."
:) I think you're underestimating the difficulty of this. You need isa to somehow simulate a set of messages to an object before deciding that yes, it fits that interface. I have no idea how to do that without causing undesirable side effects. Performance is another concern.
I think interfaces work in Go because it's statically typed.
It doesn't need to simulate anything... if something has a type of 'table, then it uses the table interface. If something has a type of 'stream then it uses the stream interface. Thus, isa could work exactly the same way it does in pgArc[1].
* [1]: Of course, when I try to implement multi-types, then isa would need to change, but that's not strictly speaking necessary right now.
Yes, basically. That means if you want to create a custom table type, you only need to create an annotated function that maps messages (symbols) to behavior (functions), and voila, it all works seamlessly.
---
I find it amusing that your explanation pretty much sums up thousands and thousands of words that I've said. I really am too verbose. ^^;
"I find it amusing that your explanation pretty much sums up thousands and thousands of words that I've said. I really am too verbose. ^^;"
You were probably more intelligible to everyone else; I seem to have been uncommonly dense :) What you're describing is indeed message passing. I think I was misled by your code snippets.
You're basically describing an s-expression syntax for smalltalk.
"You were probably more intelligible to everyone else; I seem to have been uncommonly dense :) What you're describing is indeed message passing. I think I was misled by your code snippets."
I was implementing message passing by using functions + closures, so it's definitely a weird form of it... most languages implement message passing with objects + methods. So, your confusion is understandable.
"Once I make the connection to smalltalk, wrapping these objects in the (annotate ..) layer seems redundant. Just get rid of types entirely."
So... what... just use duck typing for everything? :P Duck typing is easier, but has a greater possibility for strange bugs and conflicts. But Arc is a LFSP, so that might be a good fit for Arc.
Which, in fact, describes something almost completely identical to my message passing idea, except that it's more verbose in Scheme than in Arc. It even demonstrates prototypical inheritance.
The only difference is that they're using a separate function to represent each method... whereas in my examples, I've basically written the methods "inline" so there's only one function. However, I did demonstrate one way to give each method a separate function: http://arclanguage.org/item?id=14368
