The verbosity isn't in the actual declaration. It's in the need to extend built-in functions. My system avoids that completely: no extending.
As for extending user functions... consider this: what about code that expects something of type 'table? Your prototype is of type 'heir... so that won't work. My system does work in that situation. That can be mitigated by having functions coerce to 'table, and then define a defcoerce for heir, but why jump through so many hoops when you can get all that for free?
To put it another way, my system uses duck typing: if it supports these arguments, use it. This means that all you need to do is define something that looks like a table, and Arc automatically treats it as if it were a built-in table. No need to extend Arc's built-ins to convince it that, "yes I really really really want this to be a table."
"what about code that expects something of type 'table?"
I blame that code for its lack of extensibility. It should just go ahead and use the value as a table, trusting the extensions to be there (and using failcall to recover, of course ^_^ ).
If it must do a boolean check to determine the value's features (perhaps because failcall isn't available, or because it needs to fail fast), it shouldn't do a direct type check. Instead, it should call another global function dedicated to the inquiry of tableness (which is probably too specific an inquiry anyway, most of the time). That way, people can extend the tableness function too.
Extensibility isn't the only benefit of avoiding [isa _ 'table]. It also becomes possible to have a single value that supports table operations and (say) input stream operations at the same time. It's probably a silly combination, but a custom type based on an association list could warrant it.
You're missing the point... the problem is not when the function expects something of type table... it's when the function needs to change it's behavior based on the interface. Consider `each`. It needs to change it's behavior depending on whether it's a table or a cons or a string. How is using (table? foo) better than (isa foo 'table)? Both are the same as far as extensibility goes. And in fact, you can do that right now, in Arc:
(def table? (x) (isa x 'table))
And you're also missing the whole point of message passing... message passing enables duck typing, which means it's possible to write a function that doesn't care what it's type is, as long as it supports the required message.
You're trying to solve the symptom... I'm trying to solve the problem. What I'm saying is that re-extending all the relevant built-ins is ridiculously inefficient and verbose, and that there's a far better way. Message passing not only drastically reduces verbosity, but it also solves the problem you mentioned.
"Consider `each`. It needs to change it's behavior depending on whether it's a table or a cons or a string."
Yes. In a world with failcall, it can try treating the value as a table in one rule, as a cons as another rule, and as a string in a third rule. In a world without failcall, it can do the same thing, but with the help of extensible global functions 'atable, 'acons, and 'astring. That's merely a specific example of what I just said.
---
"How is using (table? foo) better than (isa foo 'table)? Both are the same as far as extensibility goes."
Sure, there's not a whole lot of difference between extending 'table? and extending 'isa. However, in my mind 'isa has a clear role as a way to check the most specific possible feature of a value: the kind of internal data it has.
One could go all the way down, making a (deftype wrap-foo unwrap-foo isa-foo) form that eliminates the need for 'annotate, 'rep, 'isa, and 'type altogether. In this example, 'isa-foo would be a function that indicates support for 'unwrap-foo, and 'wrap-foo would be a simple data constructor that makes an encapsulated value with nothing but innate support for 'unwrap-foo. (In a system with failcall, 'isa-foo is pretty much redundant.)
This is basically how the Kernel draft deals with custom types (except without an eye toward extensibility), but I haven't been inspired to go quite as far as this in practice. I think programmers should be free, if discouraged, to break encapsulation of values they don't know the nature of, like Arc programmers can when they use 'type and 'rep.
"And in fact, you can do that right now, in Arc[...]"
Cool, huh? :-p
Obviously pg-Arc hasn't been built from the ground up this way, but Arc Forumgoers have had an awful lot of extensibility ideas since Arc 3.1 was released, and pursuing any one of them in Anarki would change the core so much as to turn it into a separate language. That's why I don't call Penknife a version of Arc.
---
"And you're also missing the whole point of message passing... message passing enables duck typing, which means it's possible to write a function that doesn't care what it's type is, as long as it supports the required message."
That's the whole point of extending global functions too. I don't care what something's type is, as long as all the utilities I use have been extended to deal with it.
As I mentioned above with 'deftype, the 'extend approach can go all the way down to the level of making the 'type function itself merely a reflection tool. Obviously pg-Arc isn't built this way, but we've had an awful lot of extensibility ideas here since Arc 3.1 was released, and pursuing any one of them in Anarki would practically turn it into a separate language. (That's why I don't call Penknife a version of Arc.)
"Yes. In a world with failcall, it can try treating the value as a table in one rule, as a cons as another rule, and as a string in a third rule."
How? I've provided concrete examples where my solution is significantly shorter at creating new data types than the current solution, while still retaining `isa`, while avoiding problems. If you have a solution that can do all that, then please present it.
---
"In this example, 'isa-foo would be a function that indicates support for 'unwrap-foo, and 'wrap-foo would be a simple data constructor that makes an encapsulated value with nothing but innate support for 'unwrap-foo. (In a system with failcall, 'isa-foo is pretty much redundant.)"
Why? My system already does things similar to that, but in a very simple way, that's compatible with pgArc.
---
"However, in my mind 'isa has a clear role as a way to check the most specific possible feature of a value: the kind of internal data it has."
This is precisely what I meant when I said that I think the current view of types is fundamentally wrong. A table is not a hash. It's an interface that could potentially be implemented as a hash... or something else. Arc leaves it unspecified, which I consider to be a Good Thing.
---
"That's the whole point of extending global functions too. I don't care what something's type is, as long as all the utilities I use have been extended to deal with it."
...but as I've already mentioned repeatedly (and demonstrated in a post), that way is significantly more verbose than it has to be. My solution solves that, in a way that is more hackable/extendable/succinct. That is the goal of Arc, yes? Hackability and succinctness? I still have not seen a solution that matches mine for succinctness, let alone extensibility. Please provide one, if you're not convinced that my way is superior. Then I will back down.
Note that they're using the message-passing idea: after an iterator has been created, you can call it with 'status?, 'dead?, 'alive?, or 'kill! to get/set it's private data.
What I'm suggesting is to treat all compound data types like that. You can then create function wrappers around them, which is in fact what they did too: note the definition of `iterator-empty?`
Every individual iterator has it's own private state, so it doesn't make sense to require extending built-in functions every single time you create a new iterator. Instead, you define a function wrapper (like `iterator-empty?`) that accesses the internal data for you. No need to extend anything! That conciseness is what message passing gives you.
"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. >.>
my system uses duck typing: if it supports these arguments, use it. all you need to do is define something that looks like a table, and Arc automatically treats it as if it were a built-in table.
I see, yeah you're right. The alternative to duck typing would be subtypes. Ugh.
No need to extend Arc's built-ins to convince it that, "yes I really really really want this to be a table."
You're saying more than that, you're saying how. That logic is common to both approaches. Your approach is superior anytime user code has language like if (isa x 'table) ... Otherwise the two are equivalent in power.
I always treated branching on types as a code smell. wart basically grew out of trying to remove every case of that pattern in the arc codebase. You've given me something to think about, thanks.
By the way... I know using (case) is ugly. On the bright side, my system doesn't care how you write the actual function, just so long as you follow the interface. So you could use wart's :case for it as well:
(def my-table ()
...)
(def my-table (m) :case (is m 'keys)
...)
(def my-table (m k) :case (is m 'get)
...)
(def my-table (m k v) :case (is m 'set)
...)
...at least, I think that's how :case works? I actually like the wart style. That's supposed to be equivalent to this:
(= my-table (fn (m k v)
(case m
'keys ...
'get ...
'set ...)))
So yeah, it doesn't matter how you define your function (case or :case or `if` or extend or whatever), just so long as it follows the interface.
P.S. My goal here isn't necessarily to increase raw power, it's to increase extensibility and conciseness. Being able to do the same thing, but in a very hacky and verbose way doesn't sound appealing to me. So if wart has equivalent power, that's great! But I want to do better. I want to have equivalent power and make it shorter and make it more extensible.
Yeah that was the half of your point I understood when I was peddling wart :) But yes wart won't handle user code that checks the type of an object if that is important to you.
