| Scoping and Overload Resolution [message #1733850] |
Wed, 01 June 2016 13:21  |
 terry mcgarr
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
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
- Name Mangling
- 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:
- What has everyone done/tried
- Is there a standard 'xtext' way of doing this
- 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  |
|
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
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03452 seconds
] 
Search
Help
Register
Login
Home
