Hi Chris:
>From an implementation standpoint, it is probably easier to perform
>instantiation first and then resolution. From a documentation standpoint, it
>is probably also easier to describe how generic instantiation works if it is
>considered as a separate process from resolution.
If the rules for instantiation or resolution state that a function definition
with an explicit argument in a given position (or with a given name) will
always be selected in preference to one with a generic argument in the same
position (or with the same name), then we can prune the instantiation tree as
we go along (as an optimization). (This may be one reason why the two
processes are intertwined in the present implementation.)
In case I forgot to offer explicitly, I think it would be good to update the
spec following your recent clarification of the disambiguation code. I think I
would enjoy that task (unless you'd like to reserve it to yourself.)
Tom H.
________________________________
From: Chris Wailes [[email protected]]
Sent: Wednesday, December 11, 2013 3:41 PM
To: Tom Hildebrandt
Cc: [email protected]
Subject: Re: [Chapel-developers] The instantiate Function and Generics with
Query Types
My suspicion is that when a query type is present not all of the symbols get
substituted "correctly" when the function is copied. It might be possible to
fix this behavior by adding a loop to instantiate() that substitutes
type-variables as they become available. This would get rid of a recursive
call in the (newly re-named) filterCandidate family of functions, thus
simplifying the codebase and also removing some redundant work from the
function resolution process. This would also probably allow us to call
computeActualFormalAlignment and computeGenericSubs once instead of multiple
times like we are now.
While addressing this issue would certainly make my life easier it isn't
strictly necessary for my work. I would certainly be willing to work with you
on this if you are interested.
- Chris
On Wed, Dec 11, 2013 at 4:49 PM, Tom Hildebrandt
<[email protected]<mailto:[email protected]>> wrote:
Hello Chris:
I am aware of this behavior. If I recall correctly, generic instantiation can
resolve more than one argument at a time, but does not necessarily resolve all
generic arguments at one go. I have not discovered the cause for when generic
arguments are resolved in multiple batches. It appears that once all generic
arguments are resolved, we make one more pass through resolution.
I suspect that this is intended to catch cases where generic arguments are
resolved ambiguously. However, in practice I think we quit from generic
instantiation as soon as we have instantiated any non-generic version. If
those impressions are correct, we could probably collapse out the last
recursive call to gatherCandidates and obtain the same behavior overall.
It's probably relatively easy for me to add precision to my claims above; if
you need that information right away, let me know and I will fill in the gaps.
Tom Hildebrandt
________________________________
From: Chris Wailes [[email protected]<mailto:[email protected]>]
Sent: Wednesday, December 11, 2013 1:18 PM
To:
[email protected]<mailto:[email protected]>
Subject: [Chapel-developers] The instantiate Function and Generics with Query
Types
If a generic function with a query type is passed to the instantiate() function
another generic function will be returned. It ends up taking several round
trips between addCandidate() and instantiate() to produce a non-generic
function. This seems like both odd and expensive behavior. Unfortunately I
don't have the time to puzzle this one out so I wanted to alert the developer
community in the hopes that someone else might be able to fix this.
- Chris
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
