When I first discovered (or invented it) I called CallStream an “JavaScript Interfacing Mechanism”. Which was unnecessary self limitation.
CallStrem is much more than that. It is an Interfacing Concept. Which is most easily expressed in functional languages. As a “concept” it can be applied on all different levels: from the micro level of inter-object communication inside programs inside the particular run-time, to the higher level of inter-component communication on some computing platform , to the macro level of inter-service communication over diverse computing platforms and most importantly between: “screen” and a ” cloud”.
I shall be updating this post with useful “good things”, which I hope the comments, hopefully attached to this post will bring.
4 thoughts on “RFC : CallStream as an Interfacing Concept”
The Python version looks mostly like the JavaScript version:
It’s an interesting trick, but I don’t think I’d want to use it in a real system for two reasons. First, it only seems to work with
destructive functions because there’s no way for the handler to return values. I try very hard to avoid destructive operations because humans
are bad at tracking complex state mutations over time. Second, I just can’t think of any serious problem I have that this would solve. Then
again, I’ve admittedly only spent ten minutes thinking about it. :)
Gary
Thanks Gary ! I was wondering myself if and how would , someone who knows Python, implement CallStream …
However. “destructive functions” : this is yet unknown term for me? Functions which you call “destructive”, which return no values, are used everywhere. Asynchronous, or event driven, programming is based on functions which do not return values. They call function which is given as an argument, a.k.a. “call back function”, a.k.a. “callback”.
Above is one simple example.
obtain_the_result()could return some value but it does not have to.I definitely would not call these “destructive functions”. I hope I understood your terminology ?
“tracking complex state mutations over time” : I think we have ways to cope with this ? For example: Every user talking to (using) RDBMS with SQL , is faced with this. Still she can “track” the state of the data over time. I am not sure I follow here this issue in the context of CallStream? I think you understood properly that CallStream concept, totaly decouples the user/caller from the state that is inevitably operated on, “somewhere in the back”. Thus state is inevitably “changed over time”, but nothing is stopping you to send a callback to obtain the current state.
I think it is trivial to add the feature above , to your Python-ized CallStream ;)
–DBJ
Hi Dusan,
Yeah, this is interesting concept, thanks for research. In the functional programming it’s called a self-reproducible or self-replicative function (if interested, I mention it in closures article — http://dmitrysoshnikov.com/ecmascript/chapter-6-closures/#definitions).
Another interesting application of such self-replicative function can be e.g. declarative form of registering some data. E.g. instead of having (semantically) two functions:
and
It can one self-replicative and declarative nodes function. So, we just declare nodes:
Of course, it’s less effective than passing an array, but, repeat — just an interesting an d maybe elegant approach (I saw it before in c.l.javascript group).
However, didn’t use in on practice myself yet.
Dmitry.
@Dmitry, thanks for the short analysis. Of course I know that you do understand how nicely callbacks significance gets elevated even more when using them in the CallStream enabled interefacing.
I am sure You will be very interested in this too :
http://weblogs.asp.net/bleroy/archive/2010/07/01/oh-yeah-callstream-is-great-to-express-monads.aspx
–DBJ