Pack Ann: options (introducing en_list/2).

[nicos.ang...@gmail.com]

New pack "options" available on the server.

This is a stoics.infrastructure pack for handling option arguments.
The main concept is to treat options as naive Prolog lists which the
programmer can manipulate and specialise if they need to, while providing a
small number of predicates that manage basic common operations on options.
Options come into their own in the context of SWI packs, as making
code publicly available to others often involves allowing for variations
in the behaviour of the code.

Some distinctive features of pack(options)

  * minimal "magic" behind the scenes

  * processing debug(Dbg) terms which optionise calls to debug/1

  * allows sloppy (un-listed) single option argument  (en_list/2)

  * defaults might depend on input

  * can-do cascading  (options of distinct predicates should be disjoint)

  * uniform access to user specific file-based defaults


Comes with a simple example,

   ?- [pack(options/examples/ex_sort)].

   ?- ex_sort( [a,b,e,c,b], Ord, true ).
   Ord = [a, b, c, e].
   ?- ex_sort( [a,b,e,c,b], Ord, debug(true) ).
   % Input list length: 5
   % Output list length: 4
   Ord = [a, b, c, e].
   ?- ex_sort( [a,b,e,c,b], Ord, order(>) ).
   Ord = [e, c, b, a].
   ?- ex_sort( [a,b,e,c,b], Ord, duplicates(true) ).
   Ord = [a, b, b, c, e].
   ?- ex_sort( [a,b,e,c,b], Ord, [duplicates(true),order(>)] ).
   Ord = [e, c, b, b, a].

   Create file $HOME/.pl/ex_sort.pl with content
   order(>).

   ?- ex_sort( [a,b,e,c,b], Ord, true ).
   Ord = [e, c, b, a].

   Default for user is now order(>) which can still be over-ridden at invocation
   ?- ex_sort( [a,b,e,c,b], Ord, order(<) ).
   Ord = [a, b, c, e].

more info:
http://stoics.org.uk/~nicos/sware/options

---
Nicos Angelopoulos
http://stoics.org.uk/~nicos

[Wouter Beek]

​Dear Nicos,​

​Thanks for sharing another​ Prolog pack with the community!

On Sun, Jul 5, 2015 at 10:20 PM, <nicos.ang...@gmail.com> wrote:

This is a stoics.infrastructure pack for handling option arguments.
The main concept is to treat options as naive Prolog lists which the
programmer can manipulate and specialise if they need to, while providing a
small number of predicates that manage basic common operations on options.
Options come into their own in the context of SWI packs, as making
code publicly available to others often involves allowing for variations
in the behaviour of the code.

​How does this pack relate to library(option) and SWI7 dicts?

There seem to be several ways to do options in SWI-Prolog now, which is probably a good thing, but I'm not sure what the advantages/disadvantages of the respective approaches are. I know that Jan is moving away from library(options) to SWI7 dicts and I try to do the same thing in my code.

Would there be use cases where your pack would have benefits?

​
Just ​curious what your thoughts on this are.

---
Best regards

​!​

,

Wouter Beek.

Email: wou...@moonhog.net

WWW: moonhog.net

Tel: +31647674624

Best regards,

Wouter Beek.

Email: wou...@moonhog.net

WWW: moonhog.net

Tel: +31647674624

--
You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+...@googlegroups.com.
Visit this group at http://groups.google.com/group/swi-prolog.
For more options, visit https://groups.google.com/d/optout.

[Nicos Angelopoulos]

Dear Wouter,

On Mon, 6 Jul 2015 22:11:39 +0200
Wouter Beek <wou...@moonhog.net> wrote:

> There seem to be several ways to do options in SWI-Prolog now, which is
> probably a good thing, but I'm not sure what the advantages/disadvantages
> of the respective approaches are. I know that Jan is moving away from
> library(options) to SWI7 dicts and I try to do the same thing in my code.
>
> Would there be use cases where your pack would have benefits?
> ​
> Just ​curious what your thoughts on this are.
>

These things are mostly a matter of familiarity.
If you do a couple of projects with one library you start thinking in its terms, and use it more often.
I made this library available mostly because most of my packs already use bits of it.

The library "happened" after a number of discontinued attempts. It is often
easy to over complicate these things. pack(options) hopefully retains some simplicity.
Also in options I can implement things that are non-standard.

The main idea behind pack(options) is that options can be composed by arguments (options
given at call) and defaults. You simply need to append these and let the programmer pick
left-to-right to find first relevant option. A major distinctive feature is that defaults
can be defined in a single place. So using the example

http://www.swi-prolog.org/pack/file_details/options/examples/ex_sort.pl

code for ex_sort looks like,

-- Defaults
ex_sort_defaults( [duplicates(false),order(<)] ).

-- Documentation
/** ex_sort( +List, -Ordered, +Opts ).
Opts do :
duplicates(Dupl=false) blah blah blan
order(Ord=<) blah blah blah
...
*/

-- Code
ex_sort(...,Args) :- ...
options_append( ex_sort, Args, Opts ),
options( order(Ord), Opts ),
...

So both for documenting and changing the defaults, things are in
specific places and kept tidy together. No need to change the code itself when changing defaults.
:

I think the test is that with a minimum of familiarisation you
can parametrise your code with out having to think too much.
Overall pack(options) is fast to get used to and easy to work with, while perhaps library(option)
is more appropriate for proper software engineering.

I don't know enough about dictionaries to comment.
I suspect pack(options) itself can be implemented with dictionaries.
the interface for main predicates options_append/n and options/2 would be unchanged
but "adding" options to options list has to be via a new predicate abstraction

Hope it helps,

Nicos