Re: Ann: SWI-Prolog 7.1.0

On 11/25/2013 03:51 PM, Alan Baljeu wrote:
>>   The usefulness of each of the changes I've implemented has been> doubted by at least one person.  Generally the argumentation is that
>> it breaks things and `*I* don't need it'.
>
> Put me in with Jeff on this.
> If the past were otherwise, I would have functor(X, f, 0), !,X == f() so that
> all predicate calls use the ().  If you make the code so that in most all cases
> f() and f behave the same that might be okay as well, but it's a recipe for
> confusion when there's different meanings depending on the syntax.
>
> But my main argument is not about breakage or uselessness.  I'm prepared to fix
> broken code and actually use new features.  But I find the features are confusing
> when you try to do the advanced meta-stuff that Prolog is supposed to be good at.
> What about code like this:
>
> invoke(Map, Pred, Args, Result) :-
>     F =.. [Pred|Args],
>     Result = Map.F.
>
> Apparently nothing of the sort is possible.

Using =.., yes.  That is because maps are designed to cooperate with 
name().  So, you need the new stuff as below and all works just fine.

invoke(Map, Pred, Args, Result) :-
      compound_name_arguments(F, Pred, Args),
      Result = Map.F.

Yes, if you could start again, you could have avoided some of this 
confusion.  I would have been in favour of changing functor/3, but
it breaks too much.  I've always felt that =.. was a bad idea.  Not
only because it works on atomic data, but also because the right
hand is a list, but the first element plays a special role, and
even worse, this role depends on whether or not there are
additional arguments (e.g. X =.. [42] is legal).  Surely, you can
can defend this from a logical perspective, but from a software
engineering point of view it is weird at best (at least, that is
my opinion).

	Cheers --- Jan