Arc Forumnew | comments | leaders | submitlogin
1 point by Pauan 1345 days ago | link | parent

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.



1 point by akkartik 1345 days ago | link

Hmm, so each value in arc would carry around a table mapping messages to functions?

-----

1 point by Pauan 1345 days ago | link

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. ^^;

-----

2 points by akkartik 1345 days ago | link

"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.

-----

1 point by Pauan 1345 days ago | link

"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.

-----

1 point by akkartik 1345 days ago | link

Once I make the connection to smalltalk, wrapping these objects in the (annotate ..) layer seems redundant. Just get rid of types entirely.

We're probably going to rediscover why a s-expression syntax for smalltalk is a bad idea, but it should be a fun process.

I'm reminded of this thread: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

-----

1 point by Pauan 1345 days ago | link

"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.

---

Neat! In the link you mentioned, I found this: http://okmij.org/ftp/Scheme/oop-in-fp.txt

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

-----

1 point by akkartik 1345 days ago | link

Are you planning to have all say string values contain a pointer to the same table instance, or give each string value its own copy of the table?

-----

1 point by Pauan 1345 days ago | link

Not sure. Either way could work. That seems to be more of an optimization, though. The interface should work the same either way.

-----

1 point by akkartik 1345 days ago | link

It probably bears thinking about. It'll affect, for example, how you say, "I want all tables to have this new operation."

-----