Re: how to extend a capability on a data source?

On Nov 3, 2013, at 10:44 PM, David Barbour <[email protected]> wrote:

> On Sun, Nov 3, 2013 at 9:06 PM, Rob Withers <[email protected]> wrote:
> I had what I thought was an interesting thought.  From the perspective of Smalltalk (and other languages, grumble), functions are objects, if you are lucky.  I had the thought that perhaps the functional community views objects as functions.  Does that make any sense?
> 
> There is some truth to that. Objects would certainly be more compositional if modeled as dependently typed functions. But how functional programmers think of OO is probably shaped more by Luca Cardelli's and William Cook's works on the subject.

I’ve never heard of them.  Were they Smalltalkers?  If not, then where do they know their objects from?   Was their OO language of choice inheriting Smalltalk’s closure-based collection protocols, high order functions, meta and, of course, dynamic, late-binding typing?  If not, then it may be a hack language better termed Object-Based, rather than Object-Oriented, and you guys are all learning the wrong stuff.  They did cover dynamic OO languages, didn’t they?  That was the original conceptualization and delivery of a running-all-the-time OO system is and adding static typing to that is just   wrong, as exhibited by the contestants.  Groovy is groovy.

Were you aware that you can build a Y-combinator in Smalltalk?  So, Smalltalk can do the execution environment stuff of a functional language, without sweating all the type theory.  I did state that I was an imperitivist, did I not? :)

Say, is that where the functional languages got these ideas from?  Smalltalk?  Seriously, what I do know about functional languages, with a little scala, is wonderful.  I just wish I could dynamically install another hooha into a case clause, so I could build a typed, language-based runtime event system.  I guess some instrumentation may be handy.

>> Those properties together would make the Resolver linear, and would ensure that the promise is fulfilled once and only once (modulo divergence of the resolver computation).
> 
> To my recollection, this is precisely what Elib delivers.
> 
> When I say "ensure", I think I'm saying something stronger than you're hearing. Elib does not make a *static guarantee* that a resolver is called exactly once. If a programmer simply drops the resolver, it is never called, and thus Elib needs a concept of "broken" promises. It is also possible for a programmer to call a promise twice, which Elib addresses using state. With linear types, you would be unable to drop the promise, and unable to call it twice: the type system would reject the program.

How can you do agile team development if the code won’t compile for some silly reason?  The Elib implementation builds a context that reliably manages affine and relevant interactions.  South Carolina Summertime Honey Peaches or Figs, same result.

>> As an interesting side note, if you use linear types for continuations you can also eliminate the send-response paradigm (all responses can be modeled as sends to continuations, which cannot be dropped). 
> 
> This is what my event framework provides, with using one-way sends.
> 
> You statically enforce that nobody forgets to respond using the one-way send, and that nobody calls the one-way send twice?

Why do I want to statically enforce some type in a dynamic, distributed, heterogeneous environment?  Just dynamically enforce it and go to the next item on your task list.


I can’t absorb more theoretical discussion, right now, especially with the work week starting.  Thanks for the discussion.  Could you post a link to your code so I could take a look at the implementation of these ideas you are discussing, over the next days? 

thanks,
rob

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk