~Robert Widmann
2016/07/21 8:21、Colin Barrett via swift-evolution <[email protected]> のメッセージ: > 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 <[email protected]> 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 <[email protected]> >>> 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 >>>> <[email protected]> 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 >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
