Re: pengines extension to html_requires

On 02/09/2014 02:15 PM, Torbjörn Lager wrote:
>> P.s.    I would also not be against removing almost all the versions
>> >         without options.  That almost halves the number of exported
>> >         predicates and thus makes it quicker to assess the functionality
>> >         of the interface.  Anyone?

> I'm not sure. Predicates such as pengine_next/2 and pengine_stop/2
> will only very seldom be used with options. Having to nearly always
> have [] in the second argument would be unhelpful. And since
> pengine_ask/3 belongs to the same family, isn't it more consistent to
> keep pengine_ask/2 as well?

On the other hand, many of these are quite likely not used much directly
by the user anyway. The basic interface of pengines.pl is to provide
HTTP services and be able to use pengine_rpc/2,3. If we had really good
defaults for pengine_rpc/2, this would be a good candidate as programs
may well have many calls to pengine_rpc/2 scattered around the code.
That will be the case when we have some form of dynamic chunking.

Most of the other Prolog client interface implemented by pengines.pl is
there to create new high level primives because they involve building a
carefully designed state engine. This is expert stuff, creating
localised code where an extra [] doesn't add much of a burden. This is
also while there is only thread_create/3 and quite a few others that do
not come with option-free versions. Note that just thread_create(Goal)
would have made sense too, but it doesn't exist because creating a
thread running a goal requires one to think a bit about the overall
design of the application, should not happen scattered throughout the
code, and thus the burden of thread_create(Goal, _, []) is justified.

> I guess some versions without options can go, but I don't think that
> we want to reduce them with nearly half.

My preference would be to keep pengine_rpc/2 and pengine_output/1 because
it is used in programs you submit to pengines and maintains symmetry with
pengine_input/1.

Note that a small interface has advantages in itself: documentation,
understanding and reducing the risk of forgetting arguments.


	Cheers --- Jan