[swift-evolution] Beef up Imports

[Developer]

I'll admit, Agda does seem to use 'renaming' to enable notational preference first and foremost.  I'm not sure of too many Swift authors who would put something like that too high on their list of concerns, so +1.  Drop renaming.

~Robert Widmann

2016/01/07 1:53、Kevin Ballard via swift-evolution <swift-evolution at swift.org> のメッセージ:

> The reason why I say that we don't really need renaming is because you only need renaming in order to avoid conflicts, and you can avoid conflicts just by using a qualified import instead. As an example, if I want to import some library that declares its own Result type, but I of course have my own Result type as well, then I might say something like
>  
> import FrobLib hiding (Result)
> import qualified FrobLib (Result)
>  
> This will get me all of FrobLib except for Result, and also let me use `FrobLib.Result` whenever I do need to reference that library's Result type. Or if I need to reference it frequently I might even say
>  
> import qualified FrobLib as F (Result)
>  
> so I can just use `F.Result`.
>  
> In my experience, there's not much need for renaming once you can do this with qualified imports.
>  
> -Kevin Ballard
>  
>> On Tue, Jan 5, 2016, at 05:44 PM, Simon Pilkington wrote:
>> I like the fact that this would retain simplicity for basic uses - developers could continue to use 'import Mod' and not even know about the more advanced syntax unless they need that power. The additional syntax seems like a natural progression from the base case.
>>  
>> Kevin, I understand the motivation for not really needed renaming for qualified imports but it feels like we would still need them for unqualified/global ones.  Do you think this is a valid use case? As suggested previously I think this would be least confusing/ambiguous by using a seperate renaming syntax -
>> import Mod hiding (x,y) renaming (z as zz)
>>  
>> An import statement such as above could equally be handled by seperate imports - one for hiding and one for renaming - and it might be worth being flexible and support both styles.
>>  
>> +1 to submodules as well, particularly if integrated into SPM to help optimise/reduce compile times when a module depends only on part of an otherwise related group of functionality that should be vended/consumed/versioned together.
>>  
>> -Simon
>>  
>>> On 29 Dec 2015, at 11:47 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>>>  
>>> I like the idea here, but I'm not sold on the syntax. I also do explicitly want an `import qualified`. And with qualified imports, I question whether we really need to support renaming in the import syntax here.
>>>  
>>> I'm tempted to say we should just crib Haskell's import rules (https://wiki.haskell.org/Import), with the minor change that importing members by name still makes them accessible via the module name too (in Haskell `import Mod (x, y)` makes `x` and `y` visible but does not make `Mod.x` or `Mod.y` visible). This lets you say things like
>>>  
>>> import Mod // imports Mod and all its members
>>> import Mod () // only provides access to protocol conformances declared in Mod, doesn't actually import anything
>>> import Mod (x,y) // imports `x` and `y`, which are also accessible as e.g. `Mod.x`, but does not provide `z` or `Mod.z`
>>> import qualified Mod // imports Mod but all access to members has to go through it, e.g. `Mod.x`
>>> import qualified Mod (x,y) // imports Mod but only provides access to `Mod.x` and `Mod.y` but not e.g. `Mod.z`
>>> import Mod hiding (x,y) // imports Mod and its members except for `x` or `y`
>>> import qualified Mod hiding (x,y) // imports e.g. `Mod.z` but not `Mod.x` or `Mod.y`
>>> import Mod as Foo // imports Mod and renames the module to Foo, so e.g. `x` and `Foo.x` are accessible
>>> import Mod as Foo (x,y) // renames Mod to Foo, provides `x`, `y`, `Foo.x`, and `Foo.y`
>>> import qualified Mod as Foo // renames Mod to Foo, all members are accessible via the module e.g. `Foo.x`
>>> import qualified Mod as Foo (x,y) // renames Mod to Foo, provides access to `Foo.x` and `Foo.y` but not e.g. `Foo.z`
>>>  
>>> Furthermore, you can have multiple import statements from the same module, so you can say something like
>>>  
>>> import qualified Mod
>>> import Mod (x,y)
>>>  
>>> to provide access to all of Mod qualified with the name, and additionally import `x` and `y` as unqualified identifiers.
>>>  
>>> -Kevin Ballard
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>  
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/151674c1/attachment.html>