[swift-evolution] [Proposal][Discussion] Qualified Imports

Robert Widmann devteam.codafi at gmail.com
Thu Jul 21 11:02:02 CDT 2016 


~Robert Widmann

2016/07/21 8:21、Colin Barrett via swift-evolution <swift-evolution at swift.org> のメッセージ:

> I'm not sure how any of that's relevant to what I said. (I'm on my phone. Please excuse any incoherence or typos.) Your module system from the other proposal is, like in Haskell, tied to the directory structure of the project, which is in my mind an anti-pattern.

This thread is about qualified imports.  I initially thought you mean the import system wouldn't scale to accommodate ML-style modules.   Now I see this is just about modules.  We need to postpone this discussion until that proposal comes up, or use the old thread to voice this please.


> And I don't believe either SML or OCaml have a way to selectively import (open in ML terms), much less do renaming. Using ML style modules a bunch has me convinced. Beyond first-class modules, the key aspects of ML germane to this proposal in my mind are: qualified import by default (module statement) and separating identifier search (open statement) from re-exporting (include statement). Local open is also a big deal.

It is a big deal, we know about it, and we wanted it.  It is out of scope for this proposal.

> 
> For anyone else in the thread curious about ML modules, my friend Danny wrote this up a while ago, it's quite good http://jozefg.bitbucket.org/posts/2015-01-08-modules.html
> 

Seconded.  Fine blog. 

> -Colin (via thumbs)
> 
>> On Jul 21, 2016, at 2:28 AM, Robert Widmann <rwidmann at apple.com> wrote:
>> 
>> This approach in no way rules out that direction and the syntax here was built with a module system in mind.  Agda modules admit the kind of abstraction you’re looking for, but they call them Parameterized Modules and they take after Coq’s sections rather than SML’s module functors.  I can assure you, this proposal has nothing to do with Haskell and everything to do with trying to approach scoping and imports with their mindset.
>> 
>>> On Jul 20, 2016, at 10:18 PM, Colin Barrett <colin at springsandstruts.com> wrote:
>>> 
>>> Thanks for writing these up, I found them clear and easy to read.
>>> 
>>> While I don’t know the precise inspirations, both of these drafts seem more or less in line with the sorts of modules and importing that’s found in Haskell. I’d much prefer these facilities not be added to Swift. I would much rather see Swift develop in the direction of ML and add something like first-class modules and (module) functors. After writing a lot of both Haskell and ML family languages, I can say from experience that the Haskell-style approach is broadly inferior.
>>> 
>>> I have no idea if first-class modules are on the Core Team’s collective mind, but it’s what I’d advocate for.
>>> 
>>> -Colin
>>> 
>>>> On Jul 20, 2016, at 2:52 PM, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Hello all,
>>>> 
>>>> I’d like to thank the members of the community that have guided the revisions of this proposal.  We have decided to heed the advice of the community and break down our original proposal on modules and qualified imports into source-breaking (qualified imports) and additive (modules) proposals.  As qualified imports is the change most suited to Swift 3, we are pushing that proposal now as our final draft.
>>>> 
>>>> It can be had inline with this email, on Github, or as a gist.
>>>> 
>>>> Thanks,
>>>> 
>>>> ~Robert Widmann
>>>> 
>>>> Qualified Imports Revisited
>>>> Proposal: SE-NNNN
>>>> Authors: Robert Widmann, TJ Usiyan
>>>> Status: Awaiting review
>>>> Review manager: TBD
>>>> Introduction
>>>> 
>>>> We propose a complete overhaul of the qualified imports syntax and semantics.
>>>> 
>>>> Motivation
>>>> 
>>>> The existing syntax for qualified imports from modules is needlessly explicit, does not compose, and has a default semantics that dilutes the intended meaning of the very operation itself. Today, a qualified import looks something like this
>>>> 
>>>> import class Foundation.Date
>>>> This means that clients of Foundation that wish to see only Date must know the exact kind of declaration that identifier is. In addition, though this import specifies exactly one class be imported from Foundation, the actual semantics mean Swift will recursively open all of Foundation's submodules so you can see, and use, every other identifier anyway - and they are not filtered from code completion. Qualified imports deserve to be first-class in Swift, and that is what we intend to make them with this proposal.
>>>> 
>>>> Proposed solution
>>>> 
>>>> The grammar and semantics of qualified imports will change completely with the addition of import qualifiers and import directives. We also introduce two new contextual keywords: using and hiding, to facilitate fine-grained usage of module contents.
>>>> 
>>>> Detailed design
>>>> 
>>>> Qualified import syntax will be revised to the following
>>>> 
>>>> import-decl -> import <import-path> <(opt) import-directive-list>
>>>> import-path -> <identifier>
>>>>             -> <identifier>.<identifier>
>>>> import-directive-list -> <import-directive>
>>>>                       -> <import-directive> <import-directive-list>
>>>> import-directive -> using (<identifier>, ...)
>>>>                  -> hiding (<identifier>, ...)
>>>> This introduces the concept of an import directive. An import directive is a file-local modification of an imported identifier. A directive can be one of 2 operations:
>>>> 
>>>> 1) using: The using directive is followed by a list of identifiers for non-member nominal declarations within the imported module that should be exposed to this file. 
>>>> 
>>>> // The only visible parts of Foundation in this file are 
>>>> // Foundation.Date, Foundation.DateFormatter, and Foundation.DateComponents
>>>> //
>>>> // Previously, this was
>>>> // import class Foundation.Date
>>>> // import class Foundation.DateFormatter
>>>> // import class Foundation.DateComponents
>>>> import Foundation using (Date, DateFormatter, DateComponents)
>>>> 2) hiding: The hiding directive is followed by a list of identifiers for non-member nominal declarations within the imported module that should be hidden from this file.
>>>> 
>>>> // Imports all of Foundation except `Date`
>>>> import Foundation hiding (Date)
>>>> As today, all hidden identifiers do not hide the type, they merely hide that type’s members and its declaration. For example, this means values of hidden types are still allowed. Unlike the existing implementation, using their members is forbidden.
>>>> 
>>>> // Imports `DateFormatter` but the declaration of `Date` is hidden.
>>>> import Foundation using (DateFormatter)
>>>> 
>>>> var d = DateFormatter().date(from: "...") // Valid
>>>> var dt : Date = DateFormatter().date(from: "...") // Invalid: Cannot use name of hidden type.
>>>> d.addTimeInterval(5.0) // Invalid: Cannot use members of hidden type.
>>>> Import directives chain to one another and can be used to create a fine-grained module import:
>>>> 
>>>> // This imports Swift.Int, Swift.Double, and Swift.String but hides Swift.String.UTF8View
>>>> import Swift using (String, Int, Double) 
>>>>              hiding (String.UTF8View)
>>>> Directive chaining occurs left-to-right:
>>>> 
>>>> // This says to 1) Use Int 2) Hide String 3) rename Double to Triple.  It is invalid
>>>> // because 1) Int is available 2) String is not, error.
>>>> import Swift using (Int) hiding (String)
>>>> // Valid.  This will be merged as `using (Int)`
>>>> import Swift using () using (Int)
>>>> // Valid.  This will be merged as `hiding (String, Double)`
>>>> import Swift hiding (String) hiding (Double) hiding ()
>>>> // Valid (if redundant). This will be merged as `using ()`
>>>> import Swift using (String) hiding (String)
>>>> Because import directives are file-local, they will never be exported along with the module that declares them.
>>>> 
>>>> Impact on existing code
>>>> 
>>>> Existing code that is using qualified module import syntax (import {func|class|typealias|class|struct|enum|protocol} <qualified-name>) will be deprecated and should be removed or migrated. 
>>>> 
>>>> Alternatives considered
>>>> 
>>>> A previous iteration of this proposal introduced an operation to allow the renaming of identifiers, especially members. The original intent was to allow file-local modifications of APIs consumers felt needed to conform to their specific coding style. On review, we felt the feature was not as significant as to warrant inclusion and was ripe for abuse in large projects.
>>>> _______________________________________________
>>>> 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/20160721/a7e65a0f/attachment.html>

More information about the swift-evolution mailing list