Discussions related to Visual Prolog
User avatar
Jan de Lint
VIP Member
Posts: 83
Joined: 6 Mar 2000 0:01

Promises in VP 8

Unread post by Jan de Lint »

Where can I find the documentation or the example for promises?
Regards,
]an
User avatar
CalmoSoft
VIP Member
Posts: 73
Joined: 17 Oct 2006 5:49

Unread post by CalmoSoft »

Hello Jan,

For the examples you can run "\bin\setupExamples.msi"
The documentation is in "\appData\doc"
(vip.chm and Language_Reference.pdf)

Greetings,
Gal Zsolt
(~ CalmoSoft ~)
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls »

Futures and promises are new things in our world. The examples are to be found in the webSocket parts of the in the webService example program (IDE: Help -> Install Examples...). You can read a little about it and futures in WebSocket futures.
Regards Thomas Linder Puls
PDC
User avatar
Jan de Lint
VIP Member
Posts: 83
Joined: 6 Mar 2000 0:01

Unread post by Jan de Lint »

OK The keyword webservice is all I needed.
I must say that I just got my arms around promises and observables in Angular and was looking for the equivalents in VP 8.
Can anybody tell me if futures are the equivalent of observables? Can you 'subscribe' to futures?
I think this is all exiting new stuff! :o
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls »

No, futures are not equivalent to observables.

observables are related to "event streams".

futures and promises deal with single asynchronous operations.

If you consider the webSocket stuff then we offer a read operation, that can will perform one read operation which will complete some time in the future.

In a system with observables we would have implemented the read operations in a predesigned loop and you would then observe a stream of webSocket message events.

It seems that many people have faith in Reactive Extensions (ReactiveX).

=== Begin prejudice ;-) ===

I am however not convinced, because I think it seems to repeat a problem that has been seen before in other "event" contexts (for example SAX parsing of XML documents).

The problem arise when you somehow need to "merge" the results of several (semi-)independent event sources (i.e. observables).

As the simplest possible example let us simply imagine that that we have two event sources whose events will always match-up in pairs; you need one of each to create a "merge".

In synchronous code you could imagine this (oversimplified) loop:

Code: Select all

clauses     loop(S1, S2) :-         E1 = S1:read(),         E2 = S2:read(),         merge(E1, E2),         loop(S1, S2).
S1 and S2 are the "event sources" (for example a webSocket).

Such a loop can without much problems made asynchronous using await and/or futures.

It is however quite difficult to attach observers to S1 and S2 which can perform such a merge. The observers are too independent of each other; and thus very difficult to "synchronize" with each other.

ReactiveX library have several kinds of operations that performs "merge/synchronize" operations. The loop above corresponds to a zip of the two event sources.

Consider this slight modification:

Code: Select all

clauses     loop(S1, S2) :-         E1a = S1:read(),         E1b = S1:read(),         E2 = S2:read(),         merge(E1a, E1b, E2),         loop(S1, S2).
The code is still very simple and understandable: we combine two pieces of data from S1 with one from S2

I do not know how ReactiveX code corresponding to this looks like (if it exists), but I fear that it is not as easy and straightforward as the modification I made.

=== End prejudice ===
Regards Thomas Linder Puls
PDC
User avatar
Jan de Lint
VIP Member
Posts: 83
Joined: 6 Mar 2000 0:01

Unread post by Jan de Lint »

Thanks Thomas!
The reactiveX library contains some 68 different operators on observables and your story illustrates why that large number would be necessary. A practical point is that the programmer needs to remember to unsubscribe from the observable when finished, otherwise the events will continue to consume memory behind the scene.
I like the (dot or :) chaining of operators. If you consider the object the operators act upon as a state and each operator adds to the state then operators down the line also have access to the intermediate results. But that is a matter of conventions.
Regards,
]an
Post Reply