Re: [Jason-bugs] Fw: Anonymous variables are not renamed correctly. (public repost)

[Jomi H. <jom...@gm...>]

Tim,

I finally understand the problem! It is the whether R is

> [wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1)].

or

> [wrapped(_1), wrapped(_2), wrapped(_3), wrapped(_4), wrapped(_5)].


But I need to analyse it more carefully. Your solution seems to  
introduce other problems (it do no pass in the jUnit and asUnit  
tests). (it could be a problem in the tests, of course.)

Thanks,

Jomi

On 01/12/2009, at 01:15, Tim Cleaver wrote:

> Jomi,
>
> My understanding is that anonymous variables in prolog work  
> identically to normal variables except a unique name is generated  
> for each use. The wrap predicate in the example I provided will  
> generate in jason:
>
> wrap([_ | Rest], [wrapped(_) | Result]) :-  wrap(Rest, Result).
>
> wrap([1, 2, 3, 4, 5], Result).
> Result = [wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1),  
> wrapped(_1)].
>
> (or some renaming of. i.e. _7 across the board or whatever).
> Although each _1 variable is a unique java unnamed variable  
> instance, the unifier treats them as the same unnamed variable due  
> to their same name. See: UnnamedVar.java:clone.
>
> if (hasValue()) {
>    return getValue().clone();
> } else {
>    UnnamedVar newv = new UnnamedVar(getFunctor());
>    newv.myId = this.myid;
>    if (hasAnnot())
>        newv.addAnnots(this.getAnnots().cloneLT();
>    return newv;
> }
>
> They don't get new names because they don't have a value and their  
> names are already _1 (or whatever) so new UnnamedVar("_1")
> calls into
> super(name.length() == 1 ? "_" + (varCont++) : name)
> i.e. supplying "_1" to the normal variable constructor.
>
> Unification bottoms out at getting the value of the anonymous  
> variables out of a hashmap (see Unifeir.java:unifyTerms:191-192).  
> Hashmaps use hashcode to test for equality. Since variables and  
> anonymous variables use the hashcode of their functor as their  
> hashcode, multiple instances of an anonymous variable with the same  
> functor will be seens as the same variable. Thus, once one of the  
> clones attains a value in the unifier, all instances do. I have  
> attached some JUnit tests that show this.
>
> Prolog on the other hand (which you can see if you issue the query  
> "trace." before your query)
> will produce:
> Result= [wrapped(_1), wrapped(_2), wrapped(_3), wrapped(_4),  
> wrapped(_5)].
> i.e. unique anonymous variables from the perspective of a unifier  
> (new anonymous names).
> (or some renaming of i.e. _3, _4 etc or whatever).
>
> The reason p(b,a) = p(_,_) works is that it is equivalent to p(b, a)  
> = p(_1, _2). again, where _1 and _2 are unknown variable names to  
> any applicable unifier. The resulting unifier in this instance would  
> be {_1 = b, _2 = a} obviously.
>
> This is the behaviour my patch aims to introduce. However, not  
> knowing what else has changed since 1.3.1, I can't be sure it is  
> still applicable ;^). Also, I cannot be sure what complications  
> unifying predicates may introduce and, thus, haven't taken this into  
> account. Hopefully this helps explain the patch and I apologise if  
> this is all old news to you.
>
> regards,
> Tim
>
>
>
>       
> __________________________________________________________________________________
> See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/
>
>
>       
> __________________________________________________________________________________
> Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
> Enter now: http://au.docs.yahoo.com/homepageset/ 
> < 
> Tests 
> .java 
> > 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev_______________________________________________
> Jason-bugs mailing list
> Jas...@li...
> https://lists.sourceforge.net/lists/listinfo/jason-bugs

-- 
Jomi Fred Hubner
Department of Automation and Systems Engineering
Federal University of Santa Catarina
PO Box 476, Florianópolis, SC
88040-900 Brasil
http://www.das.ufsc.br/~jomi