あらまし

• 「moduleのqualified nameをそのままexportする仕様変更」として、二つの対立するproposalが議論されている
  • まだ仕様も固まっていないので、リリースされるのは当分先
• 実現するとPrelude作りが捗る
• 「moduleのグループ」を設計しやすくなり、大規模なアプリケーションの開発が楽になりそう

「moduleのqualified nameをそのままexportする」とは？

Local modulesの例を超簡略化:

module A ( qualified module M1 ) where


import qualified Import1 as M1

• exportする側で👆のように書いて、

「moduleのqualified nameをそのままexportする」とは？

Local modulesの例を超簡略化:

module B where
import A ( module M1 )
-- あるいは、👇と書くとM1がexportする識別子が M1. なしで使える
import A ( import module M1 )

• importする側で👆のように書くと、M1.というprefix付きでImport1の識別子が使える

実現するとできそうなこと(1)

• 自作Preludeで「どのモジュールをどうqualifiedしてimportするか」を明示できるようになる
  • RIOではstrictなByteStringとlazyなByteStringを同じモジュールからexportするために
    type LByteString = ByteString
    なるものを定義しているが、そんな必要もなくなる！
  • ➡️Prelude作りがもっとお手軽に！

実現するとできそうなこと(1)

Prelude作りがお手軽になると…

• 「moduleのグループ」毎の依存関係を明示しやすくなり、大規模なソフトウェアの開発が楽になりそう
  • 「このディレクトリー以下のモジュールは同じディレクトリーのPrelude以外importしちゃいけない」みたいなルールを設定すれば、モジュール間の依存の可否を明示しやすくなる
  • cf. chromiumプロジェクトにおけるDEPSファイル

議論の流れ

1. deepfire: Structured module exports/imports #205
2. ⬇️「more compositional」にしよう
3. goldfirere: Local modules #283
4. ⬇️「実はそっくりな拡張を考えてたんだ」
5. michaelpj: WIP: First class modules #295
6. Local modules v.s. First class modules ⬅️ｲﾏｺｺ!

Local modules v.s. First class modules

どちらも「moduleのqualified nameをそのままexportする」を一般化して、

「moduleの中で入れ子のmoduleを定義」できるようにしている:

• どちらのproposalでも「Local Module」と呼ばれているもの

Local modules v.s. First class modules

First class modulesの例から:

module A (f, module Unsafe) where

f = Unsafe.g …

module Unsafe where
  g = …

Local modules v.s. First class modules

構文が違う（First class modules側の主張から）:

• Export specifiers
  • The export specifiers in [ghc283] are quite complex, and there are questions about how they should behave for nested modules etc. The export specifiers in this proposal are extremely simple: they just allow exporting a module name. All additional structure must be added by structuring the exported module.

Local modules v.s. First class modules

First class modules:

• ExportModuleNames: exportするときの構文の意味を変えよう
  • module M changes to exports the name M as a module binding.
    • 非互換な修正！
  • module M(a, b, .. c) exports M and some of its names.
  • module M(..) exports M and all of its names.
  • 山本悠滋注: qualifiedしたときの説明がないよ！exampleには出てるのに！

Local modules v.s. First class modules

Local modulesが変えようとしている構文:

11. Local modules may be exported with this export item:

export_item ::= ... | [ 'qualified' ] 'module' conid [ export_spec ]

• 🤔「First class modules」側の提案と大して変わらない？

Local modules v.s. First class modules

ほかにもLocal modulesは、importやmoduleに関して新しい構文を定義している

10. Local modules may be imported with this import item:

import_item ::= ... | [ 'import' ] 'module' conid [ import_spec ]

• 👆これは入れ子になっているmoduleをimportするときの構文
  • 例: import A ( import module M1 )
• 確かにちょっと複雑

実現するとできそうなこと(2)

どちらの提案であれ、moduleの作者がユーザーに、qualified importするのを強制できる

• Local modulesの「5」から:

module Data.Set ( Set, qualified module Set ) where

  import module Set ( Set )
  module Set ( Set, fromList ) where
    data Set = ...
    fromList = ...

所感

• 互いのexampleをもう一方に翻訳して欲しい…
• Local modulesの方が確かに複雑に見えるが、First class modules側には構文をどう拡張するかが定義されてない部分が多いので、イマイチわかりづらい
• Local modulesのBNF、Haskell 2010 Reportに載っているのとルールの名前が違うような…
• 議論を細かく追うことまではできなかったのですが
  • michaelpjのこの発言と
  • goldfirereのこの発言がポイント？