Re: Ann: SWI-Prolog 7.1.0

On 11/26/2013 01:08 PM, Nicos Angelopoulos wrote:
>
> Dear Jeff,
>
> On Tue, 26 Nov 2013 10:45:48 +1100
> Jeff Schultz <[email protected]> wrote:
>>
>> Do you mean change functor(a, a, 0) to fail?
>>
>> I think I'd rather aim for some form of peaceful co-existence between
>> the Prolog data model and a().  Along with a lot of code, there are
>> thirty years of textbooks that would be broken by your proposal.

I agree with Jeff here.  I dislike functor(42, 42, 0) or 42 =.. [42],
but `fixing' them in favour of something that is heavily doubted and
certainly still has to prove its value is IMHO a bridge too far.
As it is now, especially with Jeff's domain error on functor(a(),_,_),
they can peacefully coexists.   If you don't like it, simply don't use
it and nothing breaks.

>	 in terms of theory, whether a compound of zero arguments is
>           allowed or not is not central to understanding Prolog.
>          it will make sense in various places such as meta calls,  maplist( goal(), Arg1s, Arg2s )
>          and generally to make a distinction between atoms and 0 arity compounds (mostly used as callables?).
>
>	 in my view
>	 a. Prolog is a living language not a dead one.
>	     all living languages go through changes.
>               only interesting question is the direction of travel.

Also the speed matters and how much it breaks.

>	  b. there are a large number of features of Swi that are not explained
>                in any textbook. these are the features that make Swi a working tool
>                for programmers. we should also be considering future textbooks
> not only those of the past

True. It is time to write a textbook on how to program in SWI-Prolog.
SWI-Prolog allows for running the textbook examples, but that is only a
tiny part of it.

>> Prolog, even better than LISP, is spectacularly good at working with its
>> own code-as-data.  functor/3 and a couple of other built-ins are
>> essential for this, and need also to be fast and to generate compact
>> code when compiled---big code equals slow code.  This is now much harder
>> to achieve in *one* predicate because we have *two* incompatible forms
>> of "term with a name and no arguments."

Well, functor and =.. are pretty complicated due to all the cases. The
new compound_name_arity/3 and compound_name_arguments/3 are a lot
simpler. They would (in my opinion) have better then the overloaded
functor/3 and =../2, where I have rarely seen code actually using these
features and that little bit of code relying on this behaviour could
easily have been written otherwise. The general rewrite schema I use is
typically something along these lines, with additional clauses to
actually change the term, location and type checking depending on the
desired transformation.

rewrite(Old, New) :-
	compound(Old), !,
	compound_name_arity(Old, Name, Arity),
	compound_name_arity(New, Name, Arity),
	<do the arguments>.
rewrite(Term, Term).


>> The incompatibility of a and a() means that we will need a second set of
>> functor/3, arg/3,* =../2, and that any places where the incompatibility
>> matters to the existing predicates had best raise errors so that broken
>> code can be found and fixed.  Jan is providing the second set as
>> compound_name_arity/3 etc, and the original predicates now raise domain
>> errors on the new values.  (I assume the new ones raise domain errors on
>> atoms?)

2 ?- compound_name_arity(a, N, A).
ERROR: Type error: `compound' expected, found `a'
ERROR: In:
ERROR:    [6] compound_name_arity(a,_G1634,_G1635)

>>       Jeff Schultz
>>
>
>          why would there be inefficiencies introduced? why would code-as-data will no longer work ?
>
>          if you do things like   functor( Atom, atom, 0 ) and atom =.. [atom], where atom is not a callable
>          you should be worried about the logic of your code, not its efficiency.
>
>	a() is a compound term of zero arity. a is an atom. functor/3 should
>	only work on compounds and ìf you want to find if something
>	is an atom or a compound there are predicates for that.
>          Similarly for =..  It is more natural to be defined on compound terms.
>          Why do you need to call  atom =.. [atom]  ?
>	atom() =.. [atom], seems more natural, particualrly if callables are compounds.
>
>	Again, i am not sure that this is the way to go, but I am not convinced that it is n't either.
>         There is now, of course, a -traditional flag, for when compatibility with the past is paramount.
>          I think this flag is an excellent development and should provide the old-textbooks syntax; I appreciate that this
>          is extra work of course and comes with health risk warnings for the developers.
> Maybe -traditional should be the default, and non-traditionalists be
made to explicitly require the extensions.

That could be the outcome at some point in time but, for the time being,
I prefer to get the modifications accepted. Note that the change that
causes almost all compatibility issues is changing "...", which, funny
enough, is almost the least controversial one :-)   I could have introduced
the rest without telling anyone and I think we would have seen only a few
messages from confused people.

	Cheers --- Jan

_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog