Re: Ann: SWI-Prolog 7.1.0

On 26/11/2013 09:49, Nicos Angelopoulos (Univ of York) wrote:
> 	There is at least one more way to proceed here, if i am not misinterpreting your alternatives.
> 	functor/3 could be made to fail/except on atoms.
> 	It seems to me more natural for functor/3 to work on compounds.
>
> 	This would break some code, but it might regularise the language.
> 	I am not at all certain myself what is best here, but failing to see this alternative
> 	altogether does not feel right.
> 	It is likely that I am (doubly) biased here. I don't think I have much code that
> 	depends on functor( Atomic, Name, 0 )  and if i have some I would n't mind changing it.
>          Second bias is that code that is not maintained, should not dictate.
>          I am probably missing something obvious, so I would appreciate some examples
> 	in which one would want to use functor/3 with atomic in its first argument.
>
> 	Certainly this is not a decision SWI should-have-to/can take on its own, maybe
> 	people that are involved in standarisation have a view on this and can move this forward.

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.

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

-----------------------------------------------------
*We could arg/3 for both, but I think that would only
add to the confusion.