[Grace-core] [Minigrace] minor nits - should imports be inherited

[Michael Homer]

On Fri, Nov 29, 2013 at 6:45 PM, Andrew P Black <black at cs.pdx.edu> wrote:
>
> On 28 Nov 2013, at 14:23 , Michael Homer <mwh at ecs.vuw.ac.nz> wrote:
>
>> On Fri, Nov 29, 2013 at 6:58 AM, Andrew P Black <black at cs.pdx.edu> wrote:
>>> Michael,
>>> Are you saying that the "is local" annotation that you previously proposed is not a good idea?  I don't see why having a name in an outer scope, that is explicitly declared to be local,  would stop me from re-using that name in an inner scope.
>>> Yes, we have a no shadowing rule,  but if the name is not accessible, then it's not being shadowed, right?
>> The dialect doesn't change the semantics of the language. All it can
>> do is raise errors. It can't get you out of the shadowing rule. All it
>> can do is not raise one itself, which means the shadowing check will
>> instead.
>
> Yes, I'm afraid that you are right.  This is an interesting shortcoming of our dialect mechanism that ought to be mentioned in the paper.
There was some oblique discussion in the static dialect section, I
think, but that will be gone now.
> Is it enough to make us drop the no shadowing rule?
I don't think it's a significant problem. It only appears when client
code wants to declare a variable by the same name as the dialect does,
which is fairly easily avoidable on both sides (or definitely an
error).

For imports specifically it's prevented if they aren't made available
to the client, which I still think is the right thing to do anyway.
You can think of the names bound by import as being in another scope,
or aliases, so that they never leak into clients.

It might still be worth punting the rule into dialects anyway. We get
the most power by making the very core language as unrestricted as
possible, just like we did with types, and I don't see much downside.
-Michael