Group notes on modules

20200211.txt

幻の上帝 20:51:42
* 模块化是模块化设计的单位，不必然是程序组织的单位。
* 即便是程序中的实体，不同种类的抽象可以当作模块：函数、类、翻译单元……
* 语言设计中直接抽象单一的模块不应该阻止用户使用不同层次的抽象实现模块化设计；并且，不应当添加心智包袱。
* 这个意义上，语言中添加叫做“模块”的特性，本身就一种动机上的混乱。
幻の上帝 20:53:35
* 语言可以有模块系统，但根本上，至少在适合通用目的领域的语言中，匹配模块的粒度应该让用户而不是语言设计者替用户选择，因此所谓的模块至少不能作为内建的特性提供。
* 通用目的语言可以有辅助构建模块系统的特性。这样的特性应该是可编程的，并且尽量对已有的特性友好——包括复用已有的特性，而不是引入新的、特设的(ad-hoc) 复杂规则。
幻の上帝 20:53:41
C艹这里反正统统不合格。
幻の上帝 20:54:28
嚷嚷要加“模块”这种东西的C艹用户脑子基本上都被门夹过，还迫害其他正常用户；他们不清楚模块是什么，反而diss了清楚模块是什么的用户。
幻の上帝 20:54:28
嚷嚷要加“模块”这种东西的C艹用户脑子基本上都被门夹过，还迫害其他正常用户；他们不清楚模块是什么，反而diss了清楚模块是什么的用户。
幻の上帝 20:55:09
Tech:

https://github.com/FrankHB/pl-docs/blob/master/en-US/calling-for-language-features.md#module-systems
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 20:55:20
那么像我这样单纯希望自动生成声明元数据的算是哪种【
夏幻呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 20:55:38
那么像我这样单纯希望自动生成声明元数据的算是哪种【
幻の上帝 20:55:42
这属于一种有限制的反射。
幻の上帝 20:55:50
但是反射本身也是 aji 的。
幻の上帝 20:56:06
https://github.com/FrankHB/pl-docs/blob/master/en-US/calling-for-language-features.md#reflection
幻の上帝 20:56:38
区别是 C艹 不钦定反射也没法收场了，迟早要有类似的 aji 。
但模块还不至于这样，更多的就是因为鼓吹模块的用户自己理解有问题，所以尤其欠骂。
幻の上帝 20:58:06
@二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 有一些可用性成问题的例子。
但是至少原则上是能做对的。
http://klisp.org/docs/Environments.html#Environments
幻の上帝 20:58:45
Module没有被作为feature，但是相关的原语（而且其实并不primitive）仍然足够让用户自己定义module system。
幻の上帝 20:58:59
比起一坨spec里又臭又长维护性几乎等于零的破烂高下立判。
夏之花想 20:59:25
这个跟py那种模块有什么不同吗
夏之花想 20:59:31
或者js那种
幻の上帝 20:59:36
说白了，C++的这种module作为feature来设计的现有方案和一大坨类似物，自身就是在嘲讽modularization。
幻の上帝 20:59:56
py和js的有更多甩不掉的primitive，需要开洞。
幻の上帝 21:00:23
不过即便开洞也比C艹这种正常。
幻の上帝 21:01:37
所以这是第一点：首先搞清楚需求，要知耻，不要名不正言不顺得这样下作。
幻の上帝 21:01:58
注意我说这叫module是欠骂，解决方案也是错的，但没说C++有这种需求一定就是错的。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:02:17
那么有没有良好定义的module
幻の上帝 21:02:26
C艹不合实际，算了吧。
夏之花想 21:02:28
原教旨module球
幻の上帝 21:02:46
这不是什么原教旨，module本来就不是你C艹发明的东西。
幻の上帝 21:02:57
甚至都不是搞软件搞出来的玩意儿。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:03:00
脱离C++范畴的广义上，module应该有的功能和它被期望做什么呢
幻の上帝 21:03:06
我之前在找的丢失的一段里面就一坨考据。
幻の上帝 21:04:31
太抽象的不说，首先要求是用户能控制范围自己定义的东西。
你语言能提供module，但不应该直接把这种东西就叫做module，而跟其它本来正常能叫module的东西冲突，制造混乱。这是很简单就能避免的事情。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:04:51
就是希望是个正交的概念吗
幻の上帝 21:05:19
其次用户需要的是import和部分代替include的东西，这个需求不是完全不合理的，但怎么看都很尴尬。
幻の上帝 21:05:56
如果打算最起码地在这个需求范围内作对，就先得把#include和#define头剃平了。
幻の上帝 21:06:03
光这个WG21就没底气做。
幻の上帝 21:07:01
比如干掉#define，最简单干净的，直接糊hygienic macro，外加兼容层（和现在C艹 module同等层次地肮脏，但适用性显然更好）。
幻の上帝 21:07:07
然而WG21连这个都做不到。
幻の上帝 21:07:26
还跳出来Herb Sutter糊什么metaclasses。
幻の上帝 21:07:52
很多feature之间内部的依赖都没理清楚。
幻の上帝 21:08:11
提了一坨proposal，整起来一看根本就是外行大杂烩。
幻の上帝 21:08:22
你觉得我对谭×等级的小学生能有好话？
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:08:44
那帝球觉得rust的macro怎么样
幻の上帝 21:09:45
或者为了教化这坨小学生以及你们，我要写比他们的proposal长10倍的材料去科普？
做梦。
因为我说的客观上都是很接近入门的东西。不是我胡说，是多数C艹用户自己孤陋寡闻就在闭门造车乱搞。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:09:48
实际上我是想顺便问问rust的module设计如何，不过说实话我不太喜欢rust那套
幻の上帝 21:10:11
Rust的macro是目的正确了那么点但模块化不怎么成功的feature。
幻の上帝 21:10:30
还有什么compiler plugin的骚味儿、、、
幻の上帝 21:10:33
也是比较拉仇恨的。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:10:40
不成功的点是说import需要额外标记吗
幻の上帝 21:10:49
只是没C艹那么多腐烂的历史包袱罢了。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:11:11
compiler plugin的问题在哪。。
幻の上帝 21:11:29
其实不那么容易比较，因为Rust好的地方是和其它东西合起来用的体验比较正确地满足了实际的合理需求，但本身的设计也就这样。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:11:39
唔
幻の上帝 21:11:50
更多是语言维护和演化上的问题。
幻の上帝 21:12:35
对用户来讲没C艹那么烂。
因为实际上就是没有和对应C++ module的真实需求那么大的影响。
幻の上帝 21:12:49
不依赖compiler plugin足够折腾好多东西了。
幻の上帝 21:13:04
不像C艹说你不学习module就是异端的架势。
夏之花想 21:13:06
那asteria呢
幻の上帝 21:13:16
Asteria有这设计？
幻の上帝 21:13:28
根本就没管这个问题吧。
幻の上帝 21:14:18
C艹module还有个现实司马的东西是之前的副作用——没法彻底干掉非module的并行的东西。
可以预见将来会是#include的破烂和module群魔共舞的灾难场景。
幻の上帝 21:14:28
对lib maintainer来讲好日子（？）到头了。
幻の上帝 21:14:35
（原本就没什么好日子就对了。）
幻の上帝 21:14:56
而且又没cargo之类能帮助这方面擦屁股的东西。
幻の上帝 21:15:31
这个问题上你也不可能让cmake担保结局会好哪去。
幻の上帝 21:15:45
虽然cmake设计有自己的司马问题，不过这里还算不上头等问题。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:15:57
emmm
幻の上帝 21:16:14
相比之下让cmake或者什么什么来支持module，这个指望本身就是说，“你们什么时候和我们一起下地狱吧”。
夏之花想 21:16:18
@幻の上帝 @幻の上帝 额
幻の上帝 21:16:19
所以说欠骂了。
幻の上帝 21:16:32
到头来谁都没好处。
幻の上帝 21:16:46
名义上解决了问题，实际上只会增加problem factory。
夏之花想 21:16:48
不是说允许import原来的头文件吗
幻の上帝 21:17:38
然后？
lib maintainer该选择测试和发布哪种？
cmake这样的该支持哪种？
幻の上帝 21:18:27
这种基本兼容性基本只有最下游的用户才可能随便说说“选一种就没事了”，一往上直接就是可用性打折，要么就是工作量翻倍。
幻の上帝 21:18:34
（如果没遇到bug的话。）
幻の上帝 21:19:39
某种意义上这还真不如字面上的“compiler plugin”呢……
幻の上帝 21:20:33
如果C艹这样的语言要提供名字叫compiler plugin的特性，势必逼出来某种IR当metadata而不是一坨屑ad-hoc syntax，反而离解决问题更近了也说不定……（ABI单独炸妈另说。）
幻の上帝 21:21:49
当然，我不是说给一坨IR（CIL或者某种固定bytecode什么乱七八糟的）就一定是更正确的选择，但至少比不理顺feature之间的dependency而直接往里面塞syntax后补票semantics在方法论上正常多了。
幻の上帝 21:21:53
现在就整个胡搞。
幻の上帝 21:23:16
然后就是推动这个的，除了提proposal以外，还有嚷嚷这个feature啥时候能用的无知用户。
幻の迷弟（二次元唢呐呐呐呐呐呐呐呐呐呐） 21:23:42
这个feature啥时候能用
幻の上帝 21:23:42
这就回到一开始要婊的破事上来了。
你不明真相，看不清潜在的后果，还能不明自己的需求么。
幻の上帝 21:23:58
你越是关心能用，破事就越多。
幻の上帝 21:24:38
这个feature最好的下场本来就是应该withdrawn，等先把其它更严重的一些设计搞清楚了再说，而不是为了C艹2b发版本这种逗比理由来推。
幻の上帝 21:24:56
现在的下场估计也就比export好点了。
幻の上帝 21:25:07
区别是趋之若鹜的会很多，所以一时半会儿消停不了。
幻の上帝 21:25:15
C艹用户又要被迫学习无用的捡垃圾技能了。
幻の上帝 21:25:32
以及面对翻倍的碎片化。
幻の上帝 21:28:03
当然我知道有人一直想问，“正确”一点所谓叫做module的feature如何来支持的设计，本来应该是什么样的？
（不得不复读，C艹现在是别想了。）
原则上来说，为了至少能够复用语言特性，要体现可选作为module的实体需要是语言中的一等对象。
这个意义上基本所有所谓的静态语言都是没有资格去直接支持的，因为它们没能力编码什么叫做“静态”。
（C艹用很扭曲的方式搞了坨constexpr/consteval什么的破烂，很遗憾，对此基本没什么现实帮助。）
λCrLF·º⁷¹º 21:29:23
@二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 @二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 c++ 的module对应到rust里应该是crate。rust的module是一个不那么灵活版本的c++的namespace
幻の上帝 21:29:48
如果强行允许这种实现方式，可以考虑直接让语言支持mceval，但现有主流的所谓静态语言这样做复杂度早就爆炸到不切实际了。
所以真要搞，现在只有动态语言能用。没有一个静态语言有资格去现实地实现所谓的原生模块支持而不引入各种二逼问题——这就是现状。
λCrLF·º⁷¹º 21:30:57
mceval 是啥
幻の上帝 21:31:13
meta circular evaluator
幻の上帝 21:31:41
正好标榜Turing complete（
λCrLF·º⁷¹º 21:31:45
唔
夏幻最腻害辣 21:32:30
你们说的每个字都康的懂，但连起来就不知道什么意思了
幻の上帝 21:32:44
真这样搞没啥意义了，跟什么都TMP差不多不能忍。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:33:04
rust的module默认和文件名关联我就很不喜欢
幻の上帝 21:33:23
实际上动态语言这样实现都没多大现实意义，除了测试用途。
因为解释开销过于感人。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:33:29
所以也有钦定特殊文件名的点
幻の上帝 21:33:47
所以实际要搞肯定还是要语言提供直接的支持（虽然不会直接是所谓的模块）。
λCrLF·º⁷¹º 21:33:48
可以用#[path="xxx.rs"] 换名
λCrLF·º⁷¹º 21:33:54
但是这个大概不是重点
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:33:59
所以说是默认
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:34:30
其他的还有无法多个文件直接往mod里声明成员
幻の上帝 21:34:37
然后效果应该能做到专治各种“我不喜欢”。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:34:41
所以flatc生成的一坨我没法直接用
幻の上帝 21:34:49
因为不喜欢就是应该能自己撸的。
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:34:52
我希望是能用户定义的
二次元声呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐呐 21:35:06
是啊，我也希望这样
幻の上帝 21:35:11
本来钦定什么东西算module也是用户的自由，所以滑滑的不喜欢是有道理的。
λCrLF·º⁷¹º 21:35:41
Mmmm，怎么说呢，代码大概率还是给别人读的。
λCrLF·º⁷¹º 21:36:14
你自定义就代表别人要学习你的自定义【
幻の上帝 21:36:16
这样或不这样设计和给人读不矛盾。
幻の上帝 21:36:36
本来模块的组织风格就是需要约定的。
幻の上帝 21:37:00
退一步讲，设计语言的时候钦定一种默认的也没问题，但非得说只有一种就更好那是颠倒黑白了。
幻の上帝 21:37:47
一个基本事实是“模块化”本身其实并不包含模块应该长什么样的约定。
幻の上帝 21:39:44
而且其实还到模块那么普遍就有问题。
Java package长package的鸟样，.NET namespace长.NET namespace的熊样，但你去掉Java和.NET的前缀，说凡是package就必须像gayva一样和VFS路径关联，凡是namespace都应该和assembly搞基，那就是往用户头上屙屎了。
因为package和namespace已经是很抽象的概念了。而module这里更普遍。
幻の上帝 21:40:05
还到→还没到
夏之花想 21:40:50
那module应该换一个什么名字呢
幻の上帝 21:40:57
所以作为用户你横竖都要学习约定。
为什么会有一种学习了某种语言的钦定，其它约定就不存在了的错觉？
幻の上帝 21:41:47
非得字面上搞的话，大多数用户想要的应该只是一种importable object。
幻の上帝 21:42:15
而另外一些用户想要能自己部署的更接近传统意义上的package。
幻の上帝 21:42:35
不管你要啥，或者两个都要，先让这些只要其中一种的用户之间打一架吧（
幻の上帝 21:48:37
提问：超时。
习题：略。
最后，我知道的更有点建设性意义的做法：
* 看到潜在的问题，提早退避，避免无辜株连。
* 自己设计语言解决自己发现认为有必要解决的问题，拒绝无脑跪舔添乱。
* 自己设计更加超过语言职能的具体的解决方案（比如，能应付当前 C艹 开发任务的包管理器），而不是指望现有的残疾自行进化完全。为了自觉不给业界添乱，可以不发表；但是至少得去考虑一下解决方案的思路和因此导致的问题，而不是一问三不知。