Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Scoping and Overload Resolution(Recommended overloaded operator resolutiion strategy)
Scoping and Overload Resolution [message #1733850] Wed, 01 June 2016 13:21 Go to next message
terry mcgarr is currently offline terry mcgarrFriend
Messages: 6
Registered: June 2014
Junior Member
Hi,
I have a DSL which allows function/operator overloading. My resource description strategy in combination with my qualified name provider exports publicly declared operators in the index. For example
    package x.y.x
    public op (int x, int y) -> int

would be exported in the index as 'x.y.z.plus' and life is good.

Now that life is fine and dandy we can go and retrieve them from the index. Currently I allow any operator combination, for example AnyType1 = AnyType2 + AnyType2 and let my type system sort it out. It calls a subsystem that manually queries the index, filters the results on operator name and finds a match. So for something like
int x = expr1 + expr2

We are looking for all publicly exported operators with name 'plus' and matching formal parameter types
val typeArg1 = expr1.type
val typeArg2 = expr2.type
operator = findBinaryOperator("plus", typeArg1, typeArg2){
    objectDescriptions = findAllTheCandidates
    //!!!!! Resolve all the descriptions to match formal parameter types
    return matching op (or not)
}

The exclamation mark overkill on the resolve proxies part is where I feel it is shaky (although it works fine). Because, while the resource description strategy limits the index size to a minimum (unless the user is declaring 100s of publicly exported overloaded operators in each file in which case he deserves all he gets in my opinion) the proxies may still be splayed across many resources.

It would be nice if we could filter the descriptions without having to resolve all the candidate proxies either by

  1. Name Mangling
  2. using EObjectDescription.UserData

These boil down to more or less the same thing, encoding the formal parameter types in the naming. With name mangling we get a unique name for each overloaded operator and with user data we get multiple names but each with unique user data. My concern is that in trying to encode the formal parameters (which will cross-reference types naturally) I will need the FQN of the type references. Now, although these must have already been resolved by my scope provider (or if not the whole tree is invalid anyway so who cares) is it always safe (or indeed never safe) to call get FQN on the type refs of the formal parameters when creating the EObjectDescription? (Given that the operator declaration has been linked and validated already). For example,
    unaryop name= ID  (typeRef = [type] )

then in creating the FQN or EObjectDescription call
operatorFQN = stuff + typeRef.getFQN

Or is this going to get me in a pickle?

So the questions remaining for me are:

  1. What has everyone done/tried
  2. Is there a standard 'xtext' way of doing this
  3. Is it safe to call getQualifiedName on the parameter type cross-references during index export




[Updated on: Wed, 01 June 2016 13:23]

Report message to a moderator

Re: Scoping and Overload Resolution [message #1733852 is a reply to message #1733850] Wed, 01 June 2016 13:33 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13181
Registered: July 2009
Senior Member
What has everyone done/tried
for sure
Is there a standard 'xtext' way of doing this
the standward way is not to do this but to use xbase
Is it safe to call getQualifiedName on the parameter type cross-references during index export
no it is not - at least for non local cross references. xtext does indexing first and then resolves cross references


Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Scoping and Overload Resolution [message #1733855 is a reply to message #1733852] Wed, 01 June 2016 13:37 Go to previous messageGo to next message
terry mcgarr is currently offline terry mcgarrFriend
Messages: 6
Registered: June 2014
Junior Member
Thank you very much for your swift reply. Ohhhh if I could use xbase I would be a happy bunny (xbase rocks) but life is tough sometimes Sad
Re: Scoping and Overload Resolution [message #1733857 is a reply to message #1733855] Wed, 01 June 2016 13:44 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13181
Registered: July 2009
Senior Member
p.s:

if your references are not import based you can simply use the node model to read the parameter types


Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Scoping and Overload Resolution [message #1733859 is a reply to message #1733857] Wed, 01 June 2016 13:48 Go to previous message
terry mcgarr is currently offline terry mcgarrFriend
Messages: 6
Registered: June 2014
Junior Member
Yes that was a thought I had too but they may be import based. It's probably not too bad just fetching the operators from the index and caching the results. How bad can it be (as the captain of the Titanic was heard to say)?
Previous Topic:How to register Packages in the global EPackage.Registry Instance?
Next Topic:xtext create custom import wizard
Goto Forum:
  


Current Time: Tue Nov 12 08:05:14 GMT 2019

Powered by FUDForum. Page generated in 0.02967 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top