The work I'm doing now is based on the idea that you only need to
instantiate a function's signature for the resolution process.
Instantiating the whole body (and all of the type constructors and other
assorted work involved in the full instantiation process) can be put off
until you know that a generic is, in fact, the best candidate. This should
save time during the resolution process as well as avoid attaching a bunch
of unused generics to the AST and keeping them in memory.
As for updating the spec, feel free to go ahead with it yourself. I know
that Jeremy was also interested in working on that, but he's currently in
the middle of finals season.
- Chris
On Wed, Dec 11, 2013 at 7:11 PM, Tom Hildebrandt <[email protected]> wrote:
> 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]> 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]]
>> *Sent:* Wednesday, December 11, 2013 1:18 PM
>> *To:* [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
