Eclipse Community Forums: TMF (Xtext) » Managing LocalScopeProvider

Help

Home

Home » Modeling » TMF (Xtext) » Managing LocalScopeProvider

Show: Today's Messages :: Show Polls :: Message Navigator

Managing LocalScopeProvider [message #676409]

Sat, 04 June 2011 08:44

Daniel Le Berre

Messages: 82
Registered: July 2009

Member

I did several experiments using different LocalScopeProvider implementation. However, it does not look like changing the behavior of the application.

I am now wondering if the problem does not lie in our grammar:
http://code.google.com/p/alloy4eclipse/source/browse/trunk/fr.univartois.cril.xtext.als/src/fr/univartois/cril/xtext/Als.xtext

The issue is that all PropertyName objects are shared locally.

 pred reflexive[r: A -> A] {
 	all a: A | a -> a in r
 }

 pred irreflexive[r: A -> A] {
 	no a: A | a -> a in r
 }

here a,b, and r correspond to the same instance of PropertyName. I would like them to be different.

I was expecting that using a

fragment = exporting.QualifiedNamesFragment {}

would solve the problem, by forcing the local scope provider to be
org.eclipse.xtext.scoping.impl.ImportedNamespaceAwareLocalScopeProvider
(instead of SimpleLocalScopeProvider)

in the generated AbstractRuntimeModule.

but it does not change anything Sad

I must have missed something here.

Report message to a moderator

Re: Managing LocalScopeProvider [message #676416 is a reply to message #676409]

Sat, 04 June 2011 09:25

Christian Dietrich

Messages: 14669
Registered: July 2009

Senior Member

Hi,

just a hint after a first short look: qualified names are by default calculated by the attribute "name" of the element and the qualified names of their parents. so maybe you have an name atttribute missing at certain places. fix this in your QualifiedNameProvider.

~Christian

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Managing LocalScopeProvider [message #676419 is a reply to message #676416]

Sat, 04 June 2011 09:45

Daniel Le Berre

Messages: 82
Registered: July 2009

Member

Thanks Christian.

Yes, that's probably the problem. We did not respect that naming convention.

Thanks a lot!

Daniel

Report message to a moderator

Re: Managing LocalScopeProvider [message #676421 is a reply to message #676419]

Sat, 04 June 2011 10:04

Christian Dietrich

Messages: 14669
Registered: July 2009

Senior Member

Hi,

and as sven already and i month ago did suggest you should consider to get rid of the the import uri stuff. btw do you have somewhere an test models - hard to play arround with alloy without kowing alloy.

~Christian

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Managing LocalScopeProvider [message #676422 is a reply to message #676421]

Sat, 04 June 2011 10:07

Daniel Le Berre

Messages: 82
Registered: July 2009

Member

Hum, gave it a first try, but it did not work better.

It there an easy way to debug the local scoping?

Report message to a moderator

Re: Managing LocalScopeProvider [message #676423 is a reply to message #676422]

Sat, 04 June 2011 10:12

Christian Dietrich

Messages: 14669
Registered: July 2009

Senior Member

Hi,

the problem might be the configuration of the stuff in the modules

when i do the following

(1) change workflow to

			// scoping and exporting API
			//fragment = scoping.ImportURIScopingFragment {	}
			//fragment = exporting.SimpleNamesFragment {}

			// scoping and exporting API 
			fragment = scoping.ImportNamespacesScopingFragment {}
			fragment = exporting.QualifiedNamesFragment {}
			 fragment = builder.BuilderIntegrationFragment {}

and runtime module to

public class AlsRuntimeModule extends fr.univartois.cril.xtext.AbstractAlsRuntimeModule {
	
	@Override
	public Class<? extends IValueConverterService> bindIValueConverterService() {
		return AlsConverters.class;
	}
	
	@Override
	public Class<? extends IQualifiedNameProvider> bindIQualifiedNameProvider() {
		return AlsQualifiedNameProvider.class;
	}
		
}

width

public class AlsQualifiedNameProvider extends
		DefaultDeclarativeQualifiedNameProvider {
	
	public String qualifiedName(Predicate p) {
		return p.getPredicateName().getName();
	}

}

i get at least the "r" problem solved.

~Christian

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Managing LocalScopeProvider [message #676424 is a reply to message #676422]

Sat, 04 June 2011 10:27

Daniel Le Berre

Messages: 82
Registered: July 2009

Member

If you install A4E from the marketplace, creating a new Alloy project will create a library of Alloy models in your workspace.

I get rid of importURI now to see if it changes something.

Report message to a moderator