Re: pengines extension to html_requires

Ok, but note also that on the JS side, you can _always_ leave out the
options argument and let it default to {}, since this is how JS was
designed in the first place. One could argue that it would be nice to
keep as much as symmetry as possible between the JS methods and the
Prolog predicates.

Having said that, since you are the maintainer of the whole of
SWI-Prolog and its libraries, I think you should have the final say
here. I'm happy either way. We can always add predicates without
options if we find that people want them.

Best,
Torbjörn

On Sun, Feb 9, 2014 at 2:46 PM, Jan Wielemaker <[email protected]> wrote:
> 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
>



-- 
Torbjörn Lager
Professor of General and Computational Linguistics
Department of Philosophy, Linguistics and Theory of Science
University of Gothenburg
Box 200, SE-405 30 Gothenburg, Sweden
Phone: +46317864962