Re: Ann: SWI-Prolog 7.1.0

Dear Jeff, 

On Tue, 26 Nov 2013 10:45:48 +1100
Jeff Schultz <[email protected]> wrote:

> On 26/11/2013 09:49, Nicos Angelopoulos (Univ of York) 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.
> 
	 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.
	  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

> 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."
> 
> 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?)
> 
> 
>      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. 

Nicos Angelopoulos
---
http://stoics.org.uk/~nicos
_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog