I'm guessing, but I suspect currently the only way to look up a symbol either requires explicit qualification of the symbol name or that the symbol be part of a class or instance declaration that implicitly qualifies method and associated type names. So for the implicit export list to retrieve the local symbol definition, it would have to explicitly request the local one instead of simply passing the name. (But getting the local names, without their definitions, wouldn't hit this. Maybe that should return explicitly qualified names, but I could see that causing problems with ghci; consider ":browse". And that it already handles qualification somewhat oddly because multiple modules can be in scope; "import" doesn't mean quite the same thing in ghci as in ghc, and can't without making its interactive use rather more painful when multiple modules are in scope.)

On Sun, Mar 17, 2019 at 2:30 PM Shayne Fletcher <shayne.fletcher@daml.com> wrote:

On Sun, Mar 17, 2019 at 2:23 PM Brandon Allbery <allbery.b@gmail.com> wrote:
Hm. You're probably right that it should only consider the locally defined one,

Cool.
 
but I can see why it would do this
Can you elaborate? Perhaps,
 
and wonder if there's even a good way to constrain that check currently.


indicates that you can see why it might be so based on knowledge of the implementation?

--
Shayne Fletcher
Language Engineer
c: +1 917 699 7763
e: shayne.fletcher@daml.com
Digital Asset Holdings, LLC
4 World Trade Center                                                        150 Greenwich Street, 47th Floor         
New York, NY 10007, USA
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


--
brandon s allbery kf8nh
allbery.b@gmail.com