Some standard questions

[Jan Wielemaker]

Hi,

Considering to add some mostly trivial things to the library, I have the
following issues on which I would like your opinion:


        * I wanted a predicate to take the first N elements from the head
        of a list.  SICStus has prefix_length(?List, ?Prefix, ?Length),
        which makes it also natural to add their prefix(?List, ?Prefix).
        YAP however defines prefix(?Prefix, ?List).  dec10 doesn't have it.

        What do other Prolog systems have and what do we want here?

        * SWI has sublist(:Pred, +List, -ElementsForWhichPredSucceeds)
        This comes from the dec10 library.  SICStus has
        include/3 with the same arguments and semantics.  YAP has neither.
        Proposals?

        * None of these systems appear to have something that splits a
        list in one pass into things for which some pred succeeds and
        one for which it fails.  Is there some de-facto standard for
        this?

        * After YAP, I added a library(apply_macros) that does goal
        expansion on some of these predicates to compile them away.
        Currently deals with forall/2, once/1, ignore/1 and maplist/2...
        (any number of lists) For the latter I need to be able to
        generate an auxilerary predicate.  I am in doubt about the
        interface.  My first impression was to define the hook

            goal_expansion(+GoalIn, -GoalOut, -ListOfAuxClauses)
           
        One issue is that YAP defines goal_expansion(+GoalIn, +Module, -GoalOut),
        which would cause another compatibility problem while we want to get
        rid of incompatibilities.  On the other hand, YAPs choice is a
        bit unconventional and not needed if you implement prolog_load_context/2.
        For now I decided to add

            compile_aux_clauses(+List)

        Which compiles the clauses (or directives) of List, associating
        them with the current file location (i.e. they are wiped out on
        a reconsult) and ensures the notion of the currently loading
        predicate is not changed, so we get no discontiguous warning
        on the next clause.

        We would need this anyway to implement goal_expansion/3 as
        above.  Comments?  Alternatives?

        Thanks --- Jan


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Richard O'Keefe]

On 15 Nov 2007, at 9:35 am, Jan Wielemaker wrote:

> Hi,
>
> Considering to add some mostly trivial things to the library, I  
> have the
> following issues on which I would like your opinion:
>
>
> * I wanted a predicate to take the first N elements from the head
> of a list.  SICStus has prefix_length(?List, ?Prefix, ?Length),
> which makes it also natural to add their prefix(?List, ?Prefix).
> YAP however defines prefix(?Prefix, ?List).  dec10 doesn't have it.

SICStus Prolog gets this from Quintus Prolog;
library(length) defines
        append_length/[3,4]
        {proper_,}prefix_length/3
        {proper_,}suffix_length/3
        rotate_list/[2,3]
        sublist/[3,4,5]

The date on my copy of library(length) is 1990, but it's older than  
that.
The comment in the file says
        The predicates in this file were inspired by some written
        by Edouard Lagache for Automata Design Associates Prolog.
        The file in question was called stdlist.pro.
        No aspect of this code imitates any aspect of his code.

The argument order for prefix/2 is taken from library(list_parts); the
date on my copy is 1989 but it is a couple of years older than that.  In
fact a version of library(list_parts) was posted on the net (by me, with
Quintus approval) to try to establish some sort of consistency in the
Prolog community.  So about 20 years later I find that no-one was  
listening?

The irony is that back then I was expecting that the _length  
predicates would
be obsolete by now because I expected Prolog compilers to be able to  
handle
        length(Prefix, Length),
        append(Prefix, _, List)
by themselves without such heavy hinting.

I note that pllib.htm found reason to swap the argument order for  
prefix/2
to make it a simple projection of append_append_length/7, so it is not
open-and-shut.

>
> What do other Prolog systems have and what do we want here?
>
> * SWI has sublist(:Pred, +List, -ElementsForWhichPredSucceeds)
> This comes from the dec10 library.  SICStus has
> include/3 with the same arguments and semantics.  YAP has neither.
> Proposals?

library(more_maps) has {in,ex}clude/[3,4,5]
The date is 1988 but I think they may be older.  See The Craft of  
Prolog.

> * None of these systems appear to have something that splits a
> list in one pass into things for which some pred succeeds and
> one for which it fails.  Is there some de-facto standard for
> this?

more_maps:partition/5 is a three-way split.




------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Richard O'Keefe]

PS: include/N and exclude/N are also in pllib.htm
(http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm)

I have had very few comments about that; Jan certainly knows about it
and didn't find any fault with include/N and exclude/N last year...

------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Samer Abdallah]

On 14 Nov 2007, at 20:35, Jan Wielemaker wrote:

> * None of these systems appear to have something that splits a
> list in one pass into things for which some pred succeeds and
> one for which it fails.  Is there some de-facto standard for
> this?

one option would be to model a suite of list processing predicates
on the list functions found in functional languages, eg those in the
Haskell List module:

http://haskell.org/ghc/docs/latest/html/libraries/base-3.0.0.0/Data- 
List.html#v%3Aspan

The operation you mention is called 'partition' in the Haskell library,
but there are lots of other functions which might be useful too, such
as take, drop, takeWhile, dropWhile, not to mention the high-order
folding and scanning functions.


samer.


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Jan Wielemaker]

On Wednesday 14 November 2007 22:54:07 Bart Demoen wrote:

> > * I wanted a predicate to take the first N elements from the head
> > of a list.  SICStus has prefix_length(?List, ?Prefix, ?Length),
> > which makes it also natural to add their prefix(?List, ?Prefix).
> > YAP however defines prefix(?Prefix, ?List).  dec10 doesn't have it.
> >
> > What do other Prolog systems have and what do we want here?
>
> hProlog [ :-) ] has take/3 and its mode is a bit more restrictive:
> arg1: ground int
> arg2: spine list
> arg3: ?
> Of course, since written by Tom Schrijvers, modelled after take in Haskell.

Choice enough :-(  Nobody thinks we should actually not extend the list
library?  More isn't always better!

> > * SWI has sublist(:Pred, +List, -ElementsForWhichPredSucceeds)
> > This comes from the dec10 library.  SICStus has
> > include/3 with the same arguments and semantics.  YAP has neither.
> > Proposals?
>
> Haskell has filter for such a thing. Do you want Pred to be semidet ?

The current sublist/3 handles Pred as semidet. I think SICStus include/3
does the same.

> >         For now I decided to add
> >
> >             compile_aux_clauses(+List)
>
> Maybe I am too tired, but I do not understand: is this a query in a
> file, a directive, a fact ... ? How does it do the "compiling away of"
> a thing like maplist, in particular, how does the goal
> maplist(...,...,...) get replaced by its specialized version ?

Roughly

goal_expansion(maplist(Pred, List), AuxGoal) :-
        <invent name for AuxGoal>,
        <create AuxGoal>
        <create clauses for AuxPred>
        compile_aux_clauses(AuxPred).

It is a bit better, as maplist, given a number of argument lists, the
name of Pred and the number of extra arguments needs the same aux
predicate, so we compute that name and test whether it already exists.
See:

http://gollem.science.uva.nl/git/pl.git?a=blob;f=library/apply_macros.pl;h=32026fd68b0c69cb38c02167836b2e85beb5b743;hb=3a312899996ef9a7f5119ca8ac53d0d108620094

        --- Jan


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Jan Wielemaker]

On Thursday 15 November 2007 01:06, Richard A. O'Keefe wrote:
> On 15 Nov 2007, at 9:35 am, Jan Wielemaker wrote:

> I note that pllib.htm found reason to swap the argument order for
> prefix/2
> to make it a simple projection of append_append_length/7, so it is not
> open-and-shut.

Thanks for the history. It doesn't really happen to make the final
decision though :-( Thanks for the link the pllib.htm though. Somehow
I've missed its existence.  I've now bookmarked it.

> > What do other Prolog systems have and what do we want here?
> >
> > * SWI has sublist(:Pred, +List, -ElementsForWhichPredSucceeds)
> > This comes from the dec10 library.  SICStus has
> > include/3 with the same arguments and semantics.  YAP has neither.
> > Proposals?
>
> library(more_maps) has {in,ex}clude/[3,4,5]
> The date is 1988 but I think they may be older.  See The Craft of
> Prolog.

library(more_maps) is nowhere on the web.

> > * None of these systems appear to have something that splits a
> > list in one pass into things for which some pred succeeds and
> > one for which it fails.  Is there some de-facto standard for
> > this?
>
> more_maps:partition/5 is a three-way split.

Thanks.  Sofar I took the following actions:

        * removed built-in sublist/3, moving it to library(backcomp)
        as deprecated predicate to avoid breaking code.
        * Added a new library apply.pl holding (sofar) include/3,
        exclude/3 and partition/5.  I will move maplist there too,
        but as it is used quite frequently by other built-ins this
        requires a bit more consideration.

This leaves some issues

        * All Prolog systems put these things in different libraries.
        How do we solve that!?  Possibly we should not make it worse
        by defining yet another library though.  Better proposals than
        apply.pl?  Move into lists.pl (like SICStus)?  It wouldn't
        be my first choice.

        * I'm not totally happy with partition/5.  The thee way split
        appears a bit of an overkill to me in many situations.
        There are many boolean tests you'd like to use right away.
        Consider splitting a list in atoms and numbers.  You get:

        somepred(Atom, <) :- atom(Atom), !.
        somepred(_, >).

                partition(somepred, List, Atoms, _, Rest).

        This not only saves little typing over writing it as a
        recursive predicate itself, but it also makes it not
        easier to read in my opinion.

        Smaller, Equal and Larger are not always meaningful terms.
        What about adding partition(:Pred, +List, -Accepted, -Rejected)?
        I must more like:

                partition(atom, List, Atoms, Rest).

        Cheers --- Jan


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Tom Schrijvers-2]

>> hProlog [ :-) ] has take/3 and its mode is a bit more restrictive:
>> arg1: ground int
>> arg2: spine list
>> arg3: ?
>> Of course, since written by Tom Schrijvers, modelled after take in Haskell.
>
> Choice enough :-(  Nobody thinks we should actually not extend the list
> library?  More isn't always better!

In this case it is. Haskell has a fair number of list functions that are
standardized for years and years and nobody complains there.
One of the quickest solutions is to take all suitable Haskell functions,
about which the Haskell people have already thought, and simply port them
to Prolog. Then you can start to relax modes and types in subsequent
iterations.

I would say that not doing anything for fear of getting it wrong is much
worse than doing something which has a slight inconvenience like not
exploiting the full power of Prolog. If it works in some cases, we gain
over the current situation in which we have to write our own code all the
time. If you don't do anything then people all write their own versions
anyway and nobody benefits at all.

You won't get any consensus up front about which precise definitions
(everyone has their favorite definitions and calling conventions), but you
don't need consensus. There is a much more pressing need for a library
irrespective of its exact definition. I for one would support any library
if the alternative means no library at all.

It is my hope that everyone can at least agree with that point of view
and encourage Jan and Vitor to adopt a standard library for both their
systems. Jan did not say it explicitly in his message, put his is the
point right, one standard library for SWI-Prolgo and Yap?

Cheers,

Tom

--
Tom Schrijvers

Department of Computer Science
K.U. Leuven
Celestijnenlaan 200A
B-3001 Heverlee
Belgium

tel: [phone]
e-mail: tom.schrijvers@...
url: http://www.cs.kuleuven.be/~toms/

------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Markus Triska-2]

Tom Schrijvers <Tom.Schrijvers@...> writes:

> In this case it is. Haskell has a fair number of list functions that
> are standardized for years and years and nobody complains there.

I agree with most of what Tom wrote. For example, one important
predicate that I frequently need for constraint programming is
transpose/2. That function is available in Haskell. It is also in
library(lists) of SICStus 4, and is mentioned in Richard's draft
library proposal. I also often need append/2 (which is called `concat'
in Haskell). Again, it is available in SICStus 4 as well. In my
opinion, these predicates should definitely be included in SWI.

Haskell's `take' is also very useful, and I think a better name for a
(more general) corresponding Prolog predicate is list_prefix_length/3,
and naturally list_prefix/2 for the projection. This would avoid
confusion with the existing prefix/2 variants and also make the
argument order clearer. Any name suggestions for Haskell's `drop'?


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Jan Wielemaker]

Hi Markus,

On Friday 16 November 2007 10:19, Markus Triska wrote:

> Tom Schrijvers <Tom.Schrijvers@...> writes:
> > In this case it is. Haskell has a fair number of list functions that
> > are standardized for years and years and nobody complains there.
>
> I agree with most of what Tom wrote. For example, one important
> predicate that I frequently need for constraint programming is
> transpose/2. That function is available in Haskell. It is also in
> library(lists) of SICStus 4, and is mentioned in Richard's draft
> library proposal. I also often need append/2 (which is called `concat'
> in Haskell). Again, it is available in SICStus 4 as well. In my
> opinion, these predicates should definitely be included in SWI.

Added append/2. I'm a bit in doubt about transpose/2, also following
Vitor's comment. I think the SICStus 4 approach to put everything into
library lists is not the way to go. Transpose/2 is a matrix predicate
and should not be in library lists. Not for clarity and I think using
fairly small libraries makes it easier to agree on them and get standard
implementations.

One option would be to start on matrices. A problem is that, depending
on the task, there are several sensible representations of matrices in
Prolog. Both lists, terms-in-terms and a single term of size N*M comes
to mind.  What about library(matrix_as_list)?

> Haskell's `take' is also very useful, and I think a better name for a
> (more general) corresponding Prolog predicate is list_prefix_length/3,
> and naturally list_prefix/2 for the projection. This would avoid
> confusion with the existing prefix/2 variants and also make the
> argument order clearer. Any name suggestions for Haskell's `drop'?

take is called prefix(Prefix, List) in Richards proposal, SICStus < 4
and YAP.  It is called prefix(List, Prefix) in SICStus 4.   I think the
idea of list_prefix(List, Prefix) indeed makes sense.   Opinions?
Drop is called suffix/2.

        --- Jan


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Jan Wielemaker]

Hi Vitor,

On Friday 16 November 2007 11:40, Vitor Santos Costa wrote:
> I am really happy to follow whatever smarter people decide here :)

We can use some opinions :-)  I really would like to extend the
libraries *and* improve compatibility.

> In general I agree with Jan that lists is overextended.
>
> Probably the smart thing to do would be to have a general lists
> library for compatibility and smaller libraries that would be
> reexported from lists. New stuff would go there.
>
> ciao has something like this:
>
> DECLARATION: reexport/2:
>
>     Usage: :- reexport(Module, Preds).

Makes sense. For cross-referencing purposes it might be wise to demand
that reexport declarations should immediately follow the module
declaration (or at least be before the first non-directive, so we don't
have the read the whole file to find the exports). What about :-
reexport(Module) to simply pass all public predicates? Especially if
enhancing compatibility becomes an issue, we might also want a way to
state

        * re-export all except for these
        * re-export name/arity as newname

Possibly something link this?

        :- reexport(lists, except([ is_list/1,
                                    list_concat/2 as append
                                  ])).


I.e. re-export all of library lists as-is, but do not re-export is_list/1
and re-export list_concat/2 as append/2.  The as/2 notation can also be
used in the positive notation.  Eventually this would also open the way
for :- use_module(list, [list_concat/2 as append]).

> But this is drifting a bit away from the discussion :)

As far as I'm concerned this is in scope. We need a bit more structure
and common ground for the libraries. For one thing, reexport makes it
pretty easy to push a new directory in front of the file-search path and
present a different set of libraries with different exports without the
need to really duplicate code.

        --- Jan


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[alanb-2]

> Haskell's `take' is also very useful, and I think a better
> name for a (more general) corresponding Prolog predicate is
> list_prefix_length/3, and naturally list_prefix/2 for the
> projection. This would avoid confusion with the existing
> prefix/2 variants and also make the argument order clearer.
> Any name suggestions for Haskell's `drop'?

%% list_nth_tail(List, N, Tail)
%% list_nth_tail(+, +, -) det
%% list_nth_tail(-, +, +) det, leaving vars in the head positions of List
%% list_nth_tail(+, -, +) semidet

------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Markus Triska-2]

Jan Wielemaker <wielemak@...> writes:

> I'm a bit in doubt about transpose/2, also following
> Vitor's comment.

I did not receive that. Vitor, could you please send it to me? Thanks!

> I think the idea of list_prefix(List, Prefix) indeed makes sense.
> Opinions? Drop is called suffix/2.

There should be an argument denoting how many elements to drop; to
avoid overloading "_length", I suggest in analogy to Haskell:

   list_prefix_take/3
   list_suffix_drop/3

and their projections list_prefix/2 and list_suffix/2.

------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Markus Triska-2]

"Vitor Santos Costa" <vscosta@...> writes:

> I think Haskell's filter is much better name than include :)

I agree; what about extending filter/3 to distinguish between:

   filter(true(P), Ls1, Ls2)    and
   filter(false(P), Ls1, Ls2)

or, defaultyly:

   filter(p(...), Ls1, Ls2)    and
   filter(\+ p(...), Ls1, Ls2)


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Jan Wielemaker]

On Friday 16 November 2007 17:04, Markus Triska wrote:

> "Vitor Santos Costa" <vscosta@...> writes:
> > I think Haskell's filter is much better name than include :)
>
> I agree; what about extending filter/3 to distinguish between:
>
>    filter(true(P), Ls1, Ls2)    and
>    filter(false(P), Ls1, Ls2)
>
> or, defaultyly:
>
>    filter(p(...), Ls1, Ls2)    and
>    filter(\+ p(...), Ls1, Ls2)

One might like to filter the failing goals from a list of goals. I.e.
filter(\+, Goals, Failing) in the current version. Looks like this
proposal is too ambiguous.

        --- Jan


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Markus Triska-2]

Jan Wielemaker <wielemak@...> writes:

> One might like to filter the failing goals from a list of goals. I.e.
> filter(\+, Goals, Failing) in the current version. Looks like this
> proposal is too ambiguous.

The first version is completely unambiguous:

   filter(true(\+), Goals, Failing)

But it's a bit more verbose than include/3...too bad.

------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Paul Singleton]

Markus Triska wrote:

> There should be an argument denoting how many elements to drop; to
> avoid overloading "_length", I suggest in analogy to Haskell:
>
>    list_prefix_take/3
>    list_suffix_drop/3

Verbs seem inappropriate in the names of relations.

Wot's to be avoided in overloading "_length"?

I like names which remind me of the order and meaning
of args, so _length is good, even though I have to
remember that this is the length of the prefix not of
the list.  Well I don't expect names to be a formal
specification...

Paul Singleton

------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Markus Triska-2]

Paul Singleton <paul@...> writes:

>>    list_prefix_take/3
>>    list_suffix_drop/3
>
> Verbs seem inappropriate in the names of relations.

I agree completely. According to Merriam-Webster:

take, noun, 1c: the number or quantity (as of animals, fish, or pelts)
                taken at one time

drop, noun, 4 a: the distance from a higher to a lower level or
                 through which something drops

Is there a problem with these nouns?


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Richard O'Keefe]

On 15 Nov 2007, at 1:45 pm, Samer Abdallah wrote:
> The operation you mention is called 'partition' in the Haskell  
> library,
> but there are lots of other functions which might be useful too, such
> as take, drop, takeWhile, dropWhile, not to mention the high-order
> folding and scanning functions.
>

I wrote the 'include' (= Haskell's filter) and 'exclude' (= filter+not)
some years before Haskell existed.  I never did add a predicate that  
combined
them because I never found a use for it.  Having used Haskell since  
Haskell
1.2, I've never found a use for 'partition' in Haskell either.  In  
Haskell
it is important to have 'partition' so that you can *incrementally*  
deliver
prefixes of the results for infinite lists.  Prolog is effectively a  
strict
language, not a lazy one, and in a strict language there is little or no
advantage to having 'partition' rather than calling 'include' and  
'exclude'.
There *is* however a big advantage to having the two calls:
        include(satisfactory, Candidates, Foo),
        exclude(satisfactory, Candidates, Bar)
Done this way, it is easy to figure out which argument is which.  But  
if you
write
        haskell_partition(satisfactory, Candidates, Foo, Bar)
which of the last two arguments holds the elements that pass the test  
and
which the ones that fail?

take and drop we already have under other names.
scanlist/(N+3) and cumlist/(N+3) provide folding and cumulating from  
the left.

In short, there is no need to copy stuff from Haskell when we can  
copy it
from *OLD* Prolog libraries that already had it.


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[Jan Wielemaker]

On Tuesday 20 November 2007 02:32, Richard A. O'Keefe wrote:

> There *is* however a big advantage to having the two calls:
> include(satisfactory, Candidates, Foo),
> exclude(satisfactory, Candidates, Bar)
> Done this way, it is easy to figure out which argument is which.  But
> if you
> write
> haskell_partition(satisfactory, Candidates, Foo, Bar)
> which of the last two arguments holds the elements that pass the test
> and
> which the ones that fail?

Funny enough, I started this because I am writing some RDF graph
filtering code that needs a lot of these style of filtering operations
(like filtering all resources that are individuals of some class, but
also the remaining ones for futher processing). This wasn't the first
time, so I started looking in some resources. I failed to find what I was
looking for (somehow missed the name partition) and started some
discussion here.

Surely, satisfactory/1 can be expensive and you want to avoid evaluating it
twice.  Of course we could define source translation to fix this, but
it isn't easy as the include and exclude calls need not be adjacent.

I don't think anyone would define partition(:Pred, +In, -Neg, +Pos), but
of course I may be wrong :-) If I had to define it without history I
would got for partition(+In, :Pred, -Pos, -Neg), as one writes all list
processing predicates using the input list as first argument to exploit
clause indexing, followed by additional input arguments, followed by
output arguments.

> In short, there is no need to copy stuff from Haskell when we can
> copy it
> from *OLD* Prolog libraries that already had it.

I agree.  Surely if there is nothing wrong with the old definitions.

        Cheers --- Jan


------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...

[alanb-2]

Jan wrote:
> I don't think anyone would define partition(:Pred, +In, -Neg,
> +Pos), but of course I may be wrong :-) If I had to define it
> without history I would got for partition(+In, :Pred, -Pos,
> -Neg), as one writes all list processing predicates using the
> input list as first argument to exploit clause indexing,
> followed by additional input arguments, followed by output arguments.

If it weren't for this clause-indexing matter, I would find partition(:Pred, +In, -Pos,
-Neg) the most likely form.  In a Haskell language I would be able to do
   let p = partition (> 0) in ....

Analogous Prolog:
?-   Pos_Nonpos = partition(>(0)),   call(Pos_Nonpos, [1,-3,4,0,-5], Pos, Nonpos]).
Pos_Nonpos = partition(>(0))
Pos = [1,4]
Nonpos = [-3,0,-5]

This brings to mind a question: Why should clause indexing be an issue?  It seems to me an
implementation (byte compiler) can simply look at a list of clause heads and see which
arguments are indexible [answer: the ones with varying literal structure] and create indices
accordingly.  

------------
For further info, please visit http://www.swi-prolog.org/

To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-mail>"
in its body to majordomo@...