https://zhuanlan.zhihu.com/p/40356993

我们再来看看绝句基于类似 Haskell 的自定义中后缀『记法』，能和这样DSL形式泛滥的『泛向编程语言』有多大的差别。

无需多说，进行计算机编程的第一步是掌握编程语言。

绝句的思想，进行计算机编程的第一步是掌握模式化解决问题的思路，比如顺序、判断、重复。

第一，当前主流的编程语言对于普通人还是太难了，即使是最简单的Javascript、Python、PHP等，也都有太多的知识点，比如闭包、作用域、位运算、迭代器、继承。为了让行业外人士能够容易掌握，中文编程一定不能照搬主流语言，而要对它们进行简化，去除复杂的知识点。

我很同意，但那些知识点举几个例子日常使用是不存在任何问题的，作用域以词法作用域照着语感实现不就好了吗，继承难道不是最自然的事情吗。

第二，要“信达雅”。好的外文的翻译要“信达雅”，好的中文编程也要“信达雅”，像一篇文章一样，少用符号，多用文字，要让人容易读，容易理解。

此外，还不能滥用创造者视角，不否定符号的价值、不能一切皆文字。好的创造者要从用户的角度考虑问题，而不为解决特定问题随意修改语法。

第三，不要有太多嵌套。

所以函数式编程和文法布局的设计都是很重要的。

C#语言中实现用控制台打印”你好”的程序是

控制台.打印(“你好”);

Z语言实现打印“你好”的程序是这样写的

控制台打印“你好”

绝句实现打印『你好』的程序是这样写的：

说("你好")

“标准库定义”
【只可内联】内联的事 说(话：文) 为
  说(话)；说完了()

也可以：

说点("你")；说点("好")；说完了()

（我是刻意为了和Kotlin对应的，好像没有刻意与Kt拉开距离的必要）
或者对应上面的代码，

控制台去说("你好")

不过用『记法』也可以这样，

引记法 绝句.符号 「写」
引 控制台.标准输出 “just a joke”
标准输出写"你好"

面向对象，就是一群对象互相发『消息』、互相驱使的过程，而这个『驱使』的动词为「去」。利用暴露的「取者」「置者」访问对象状态的动词为「的」，两者皆可的符号就是「.」了。
记法，是绝句的自定义中缀运算符。

Z语言程序没有点号，没有括号，末尾没有分号，看起来和一般的中文句子没有两样，中国人理解起来非常容易。

绝句为了一些迷之原因（可能是为了兼容不同的编程风格？）加上了「.」（我可能决定要去掉？）
末尾怎么不能有分号了，若此人之为男，说("👻")、说("👻")。 （记法「之」）还不行么

（哦，想起来了，此人.为男也不失为一种编程风格，但我现在对不使用引记法的绝句代码表示怀疑。）

C#取成员用‘．’号，比如
T．年龄
Z语言是这样
T的年龄

绝句也是一样，不过不存在所谓的静态字段，而是和Kotlin一样采用了 companion object（面向对象本来就不应该有所谓的静态成员的，只该有类、对象、架构器、方法、属性）

去除new
绝句也不要new就能调用架构器

var P=new点(0,0);

P=点(0,0)

量P=元二(0、0)

Ｃ＃语言是 函数名称＋参数列表
Ｚ语言是 函数部分１＋参数１＋函数部分２＋参数２＋．．．

void 打开文件（文件，读写方式）
以（读写方式）打开（文件）

绝句可以选择基于记法的EDSL，上面的『多参并列』其实我以前连字典树都不会写的时候也想过，就是老绝句（「预处理器」版本的）
为了语言的明确性，我不能这样设计。

属别名 路径 = 文
事 打开文件(模式：打开模式、文件名：路径)：文件……
这是一般方法，量 hello = 打开文件(打开模式.只读、"hello.txt") 。

定记法 「模式」
扩物 文 为
  事「模式」(模式：打开模式)：元二<路径、打开模式> = 元二(我、模式)

事 打开文件(目标：


元二<路径、打开模式>

)：文件……
这是EDSL内部专用语言定义式，量 hello = 打开文件("hello.txt" 模式 打开模式.只读)。


省略主语
枚举类可以省略主语
比如枚举enum读写方式{只读方式，只写方式，读写方式}

绝句的枚举不可能像C一样没有规范地随便给作用域做变通，一般来讲这是需要「引」引入的。

引全 打开模式 “import OpenMode.*”

例物 打开模式 为
  只读、只写、读写

这样就可以了。之前有一次我想了想是否要花精力尝试支持自定义前缀如「以~」
可是后来我觉得，中文编程关键在于编程，而不是一切皆中文表述，与常见的表达顺序兼容是很重要的，Scala虽好但是很可怜。绝句完全可以在内部提供一个 以(T)：以句法 函数，然后随便定义引用扩物来实现『全中文编程』，但那还有规范可言吗？所以我后来没加……（何况加上也很莫名其妙，严重加大了代码风格的不确定性）

打开文件（文件Ｗ，读写方式．只读方式）;

以（只读方式）打开（文件Ｗ）
打开文件("hello.txt"模式只读)

稍微往远处走走，你会发现仅就以上例子而言，更『灵活』的语法反而不如更死板的Kotlin扩展式：

用户配置文件=以（只读方式）打开（文件Ｗ） 

量 用户配置文件 = 打开文件(只读、"hello.txt") 

看不出区别。如果要加入异常处理呢？

尝试
  用户配置文件=以（只读方式）打开（文件Ｗ） 
捕获 打开失败
  用户配置文件=空

量 用户配置文件 = 尝试，打开文件(只读、"hello.txt") 。
  接迎 打开失败成误，误去输出()、回。

那么，如果有可选的参数（比如最经典的，Kotlin 的 Iterable<T>.joinToString(……)）呢？直接的中文调用模式是难以利用默认参数的，尽管这样表达基本不需要显示写出参数名。

汉语、汉字是美的、富有信息量的，但只有你开始重视程序算法、程序表述方式的美，使得它在保持简单漂亮的同时也能尽可能干净利落，才有可能把两个美有机结合在一起，最终完美地实现一个编程语言、编译器需要解决最本分的工作——让人编程、让人又快又好地编程。
『玉有灵性，反之也有邪性。』，事物往往都有两面性。

汉语编程，做好了能够让刚入门的中国人像编程大师一样肆意实现出各种曾经复杂难懂的逻辑，做差了，以纯汉字表达的程序会不留情面地显现出汉字丑陋的一面，更难看、更难懂，令语文老师觉得满篇不合体、缺语素，也可能让刚想试水的工程师最终悻悻离开，不能实用。 #statement #PLT 🤔

🤔duangsuse 昨天晚上想到了一些话，愿意分享给大家。 #statement

duangsuse（虽然一点也不好）是如何编程的呢？
他编程，是一个从整到零，再从零到整的过程。

首先是把一个相对比较大的目标，拆分成许多能够比较简单实现的小目标。
比如，把一个操作纷繁复杂的类(class)，抽提出实现了很多接口的类。

接着是和自己争论实现的难点和复杂性，继续重新拆分和重新组织继承、数据依赖这样的关联，偶尔还会为一些经常联系在一起的东西(比如 Database, Controller) 起一些首字母简写，记住。
比如，它会把二进制流读取器弄成 class Reader: BaseDataReader, ByteReader, ReadControl 而不是把所有这些操作，放在一个类里面。

然后是实现这些小目标。

最后，他按照在实现小目标时早已预备好的思路，把许多子程序组装成整个程序。

如何做出好吃的糖炒板栗？大的小的分开炒。一起炒的话，小的糊了大的没熟，怎么也不好吃。

如何写出好看的程序？每个部分分开写。写成一坨的话，两个事情里类似的子过程，差异不大，却让人迷迷糊糊分不清，怎么也不好看。

fun <R> Producer<R>.retry(n: Cnt, terminate: PredicateOn<R>): R?
= sequence { invoke() }.take(n)
.dropWhile { it != null && !it.terminate() }
.firstOrNull()

fun <R> simplier_retry(n: Int, terminate: PredicateOn<T> = { true }, op: Producer<R?>): R? {
for (_i in 1..n) {
val res = op() ?: return null
if (terminate(res)) return res
}
return null //这是一个『线性查找』的控制流模式，可以用sequence抽提成定义式的形式。
}

堆砌从简单到复杂，再到写不下去、开始忌惮自己的维护；设计从复杂到简单，最终对代码的一切都了若指掌。

有人说『从不写bug所以不需要debug』，相信吧，他们是对的。其实本来就不应该有bug，最精炼的代码，基本上在纸面debug就够了。
有人觉得『A4纸编程』是很NB的大佬才能做的事情，为什么平常人不能做？难道他们真的连『广播体操』打着节拍都不会跳了么？要编程就得有能上A4纸写的勇气才行。

android { compileSdkVersion(26)
  defaultConfig {
    applicationId("org.sample")
    minSdkVersion(6); targetSdkVersion(19)
    versionCode(1); versionName("1.0")
  }
  buildTypes {
    release { minifyEnabled(true); proguradFiles(defalutProguradFile, "progurad-rules.pro") }
  }
  sourceSets {
    main.java.srcDirs += 'src/main/kotlin'
  }
  compileOptions {
    sourceCompatibility = Java8
    targetCompatibility = Java8
  }
  kotlinOptions {
    targetJvm = "1.8"
  }
}

为了使得代码稍微好看、好记那么一点点，我甘愿打破一切所谓的『代码风格』，拒绝使用任何刻板的自动格式化器毁坏我对布局的整理，甚至哪怕设计一门新的编程语言来或多或少的修补Kotlin的华点也在所不辞。因为我明白，编程语言只是『做菜』的材料，厨师的刀功、能力，才是程序设计最重要的东西。

外表看起来漂亮、看起来不乏味单调或者不「多余」，很多时候才是最大的陷阱。我更在乎程序的灵魂，而不仅仅是它那任何一个解析器都能机械地识得的形式。

堆砌者开始不明白自己要写什么且只有编写简单程序的功底，所以开始是简单的，但也正因为不知道自己要做什么，所以越写越复杂。
随着他们从别处的模板复制来的逻辑越来越多，对代码整洁、布局顺序的着眼率越来越低，整个项目会走上重构越来越耗时、越来越难以扩充和测试的死胡同。

设计者一开始就明白自己要做什么样的东西，它的基础目的是什么、必须要什么算法、大概会有哪些逻辑重复、使用了什么外部API和抽象、未来可能有怎样的变化，所以随着逐步的细化程序越来越简单、代码复用程度越来越高、维护越来越轻松。

简单不是因为愚蠢，而恰恰是对自己和别人的精力限制有着清醒而深刻的认识。大智若愚，深深认识自己的「蠢」并且着实去解决它。
编程不是为了显得自己有多高明、多数学，而是想尽可能直白、尽可能好地定义完程序为解决问题所必须要做的事。

你是要「堆砌」出你的程序，还是要最终坚持着把它「设计」完？
你觉得你的程序只是给一个人、一个人的项目用，还是把它发布出去，让所有人都能少做本不愿下的苦功？

把世界视为过程，还是对象？是不是要有 closure（闭包）这种东西方便抽提执行逻辑？是不是要有 sequence 来表示一种…… 计算过程和结果的序列？
决定吧，以后不仅仅要学会利用别人的API编程，更要明白编程这件事，除了模式识别，在『修改别人的代码』『仿照有效代码的样子』外还剩下什么。

编程不再乎对一个项目「累积写了多少时间」，而在于你对你的目的和编程的「道」，有多大程度的了解。

因为「项目」只是某个时间的状态，它只能表示现在，而「方法」则是变化率，它代表着未来。
授人渔，而不只授人鱼。
争得渔，别老是争得鱼。

啧啧啧，虽然易语言提供了语言运行环境、IDE和基础库，但它身为『面向对象编程语言』居然连基本的中文语序都做不到，还和洋文一样把操作放在前边。我深深感到这5kw纳税人的钱是用到刀背上了。

我们来对比一下迫真易语言的『容易度』和绝句的『容易度』

这里易语言的代码风格我参考了 Kotlin(1space) 的格式。

引入 apr;
公开 类 启动类 {
 公开 静态 启动() {
  整数 数量;
  控制台.输出行("请输入将要生成的随机数个数:");
  数量 = 控制台.输入整数();
  随机数集合.显示(数量);
  随机数集合.显示();
 }
}
公开 类 随机数集合 {
 公开 静态 显示(整数 生成个数=10) {
  字节集 临时字节集;
  整数 I,J;
  内存池 局内存池 = 创建 内存池;
  控制台.输出行("下面开始生成"+生成个数.到文本+"个随机数====>");
  计次循环(生成个数,J) {
   临时字节集 = 随机数.生成随机数(1,局内存池);
   I = 字节集类.到整数(临时字节集);
   控制台.输出行(整数类.到文本(I));
  }
  控制台.输出行("<========随机数已生成");  控制台.输入文本();//暂停屏幕滚动用
 }
}

我几乎忍不住要喷了。整数类.到文本(1)，这也能够算是面向对象？它知道啥叫封装么？

引记法 绝句.符号 「~次」
引 Apache.PortableRuntime

例 随机生成: 应用程序 为
  实现的事 入口() 为
    说("请输入将要生成的随机数个数:")
    量 数目 = 听去数一()
    随机数集去说(计=数目)
    随机数集去说()
例 随机数集 为
  事 说(计：计数 = 10) 为
    量 存池 = 内存池()
    量 随机数组：组<数>
    说("下面开始生成${计}个随机数====>")
    对计次里的 j，
      随机数组 = 随机数器去生成随机数(长=1、分配器=存池)
      量 I = 随机数组去化数()
      说(I去化文());
    说("<========随机数已生成")；听去行一() “暂停屏幕滚动用”

然鹅，我这还是给易语言留了面子的情况，要知道绝句完全可以把这段程序写得更好看：

引记法 绝句.额联 「令为」
引记法 绝句.符号 「以」
引记法 绝句.符号 「~个」
引记法 绝句.符号 「化」

引 Apache.PortableRuntime

例 随机生成: App 为“皮一下，标准库里不一定有这个别名，当然绝句也可以用上「类物别名」的”
  实现的事 入口() 为
    说("请输入将要生成的随机数个数:")
    量 数目 = 听去数一()
    说("下面开始生成${数目}个随机数====>")
    随机数之集去取(数目个) 令为，它以(" ")去接并()。令为(::说)
    说("<========随机数已生成")
    听去行一() “暂停屏幕滚动用”

例 随机数之集：随机数集()

物 随机数集 为 “也可以是单例的”
私下、晚成的“lateinit”变参 存池：内存池
事 取(次：数目)：行<数> 为
存池 = 内存池()
量 随机行：行<数> = 行一()
解对 次里的_，随机行去加入(随便一数())。
回随机行
私下的事 随便一数()：数
= 随机数器去生成随机数(1、分配器=存池)
去化数()

淫王19年终于又出博文了啊，我待会看看，感谢推送。 #blog

我吃饭回家路上考虑了一下

首先为了能够实现

函数，〖x0〗x0。
函数，〖x0〗
  x0

这种逗号表示法的形式，这个样子的逗号表示法类似：
逗号块(逗号修饰, 体)……

同时，我也终于决定抛弃了逗号表示法的 {} 替换：

若p { op0() } 否则 { op1() } “不允许。”

毕竟绝句不需要像 Haskell 那样 \case ox (Some x) -> 切换布局块和非布局块版本的语法，逗号表示法「，、。」是比较简单的。
现在这个开闭符号是『reserved』了。

然后，绝句也可以利用记法、扩物和内联的物兼容传统汉语的表示形式（比如『把(x)加进xs』）
这个扩展将在标准库的 绝句.严格中文 里实现。

然后，绝句的相对Kotlin的一些语法扩展：

「为」布局定义、「其中」布局定义、逗号表示法、第二|三人称的「你」「它」、「的」「去」、『记法』和「」中缀链、『』名字、【】注解、汉字数值常量表示。

""" 为 是对 raw string 的布局化扩展，之间区间 (0,1) 个空格，多了不算。
关于其中是否支持 $, ${} 一说，Kotlin 是支持的，不打算改变。

逗号当然也包括顿号的。比如：对用户里的，好人里去划掉(它)、坏人里去划掉(它)。

一些常见语法：

对…里的(名)……
对…里的你…… “第二人称”
对…里的…… “第三人称”
若你… …… “第二人称「若」” （删掉，这个语法其实是冲突的，而且在正常代码里也无必要。
【无参注解】
【带参注解 参0、参1、...】

判断……
判… ……
（「它」第三人称中缀简写）
判属… ……（于、它）
判存… ……（于、它）

所有判断都可以有语句形式和表达式形式，表达式形式的分支必须有穷举性。
「、」是逗号表示法里常见的语法，只不过不同结构有不同表现形式。
提供的「上皆……」都是副作用的形式，表达式里不允许。
「否则……」在表达式里也允许，这时预期的不是效果而是值。

一些规范化修订：

解量、解对、判属于、判存于、「空则」逗号表示法

重复若、重复……若。

绝句的面向文件定义结构：

包、记法（定、引） 、引(成)、引全(除)
属别名、类物别名、常参、类、物（造于、初）、例、事、量（取者、置者、代者）、变参。

突然想起来，:: 是引用文件级事和架构器？
架构器不是函数？？？ 🤪
那么就没必要区分属别名和类物别名了，都一样。

我决定了，第一设计稿应该把「变参」初始化的 = Expr
改成 初 Expr，要不然显示不出参量变化的精髓。
变参现在是

变 属名 角括名字 初 Expr
变 属名 名字 ws1 初 Expr

（变数 和 初0）
的形式

还有，「包」在汉语里不应该还是原来的 package (qualified-name); 形式

包 (复名) 为

这样（其中，复名是复合名称的意思）

PKNF(ParserKt Normal Form) 是一种形式化文法描述语言，它可以为 ParserKt 生成有效化、优化的代码（比如合并前驱、分支遮盖式前驱重排序）
合并前驱的功能可以让

变 属名 角括名字 初 Expr
变 属名 名字 ws1 初 Expr

变成利用 ParserKt 递归下降上下文相关解析来判断翻译成类似这样：

变量 ('变' 属名)|变参 后继:(anychar) where
  后继:(run c) caseA|caseB
  caseA lookahead:('『' ) 角括名字 '初' Expr
  caseB 名字 '初' Expr

它只需要能够对任意两个子结构取 succeeder union （交集）和 succeeder complement （补集）就可以启发式合并分支了

complement 角括名字 名字 = setOf('『')
complement 名字 角括名字 = setOf()

— 所以只要出现的字符是'『'，就只可能是角括，否则只可能是普通名字。

但是PKNF开发比较复杂，而且理论上的很多东西暂时不完善（也别指望它们太完善）
所以一时间ParserKt是不可能用上PKNF来定义自己的上下文敏感语法的，尽管PKNF已经被我完全形式化定义好了（以它自己描述它自己……），要用可能是一年后了。

令做(run)、令为(let)、令置为、顺手(also, (T)效果)、交给(支持 (T)* 的 also)
有若(takeIf)
成文(toString) 成码(hashCode)

滤出(filter)、映至(map)

存一(find+不空)、存仅一(single)、皆是(all)、皆非(none)

后来我发现它们有点不规范。
令为(let)、令做(run)、令试(runCatching)、顺便(also)
有若(takeIf)、有非(takeUnless)
对(to)
化文(toString)、化记码(hashCode)
滤出(filter)、映至(map)
存一(find)、存仅一(single)、皆是(all)、皆非(none)

apply, use 比较让中国人不明所以、with 已该被换为let。

—取此即值(get)、置值于此()
……我突然觉得绝句的『直接值代理』有很大问题了，我不知道它是为了什么，根本不应该让程序员能够做出这种定义。
代为取值(getValue)、代为置值(setValue)

语言结构方面，术语统一为：
常量(literal)、言(expression)、句(statement)、体(block)、构(syntax structures)、书(file)

然后继承方面，顶部类型最好还是『分配』而不是值（即便这样有点『结构化编程』式了……）。

包『绝句』为
开放的物『分配』为
【内建】、待例、算符的事 问全等(另：分配)
类『可度』为
  量 大小：计数
扩物『可度』为
  记法「之为」的量 之为空 “……”
类『可度长』为
  量 长度：计数

本来我打算让 none 变成「存零」的，可是那样 all 就不好命名了，只好引入记法「皆」。

未来绝句标准化到一定程度后我会开始考虑如何将他实现，以何种单位编译、要翻译到什么语言。

rust 在还没有编译器的时候，它的第一个编译器被起名为 rustboot
虽然绝句还不能怎么样呢（大概可能只暂时会做符号解析的工作）
我觉得，第一个只能输出Kotlin源代码的翻译器就叫『绝句 序』吧……

我从很早的时候就藐视所有试图给我打分的人。我从来没有觉得竞赛的主办者有任何资格来评价我，所以从大学开始我就没参加过任何竞赛：ACM，IOI…… 现在一看到这种东西，看看他们的主办者，出题人和裁判们是什么水平，都觉得可笑。当然我就更加不会在乎任何人说我是否“成功”。

不支持，人只有追求更好和自己不在乎的事情，有舍有得而已。这么说太绝对，何况你怎么能武断他们技术不怎么样。

淫王也是可怜，估计他经常被一些清华的校友嘲讽什么的，还好我估计本科都上不了，不担心被别人唾弃。

总之我是感觉王垠的观点有点太绝对了，做技术嘛也不要太抱怨一些东西，别人蠢那他们蠢他们的，我是无所谓。

要是他们蠢到影响我生活了，我会尝试少招惹他们，实在不行就离开，我相信只要有能力到一定程度，大门都是敞开的。社会是公平的。

👆 现在开始我会逐渐使得pinned message稍微有点意义了。

本来不该就这么快结束的，可我觉得思路和细节已经基本在我上面写的例子里显示出来了（比如量『a』=1；变文『s』这种不带空格的类词法解析定义），所以我觉得还是继续写我的 e2im-2、Binarie、ParserKt 吧……


嗯……其实不对，我还有许多设计笔记没有发的，而且最重要的中缀操作符、优先级，我都没任何定义。
下次吧，毕竟一时半会也实现不了。

@duangsuse 话说最近那个文言语言是你的嘛？

#zhihu https://zhuanlan.zhihu.com/p/91353256

https://t.me/dsuset/6816; https://t.me/dsuse/12085 @吴烜 你说的大概上没有问题，可略微有点无力，如果不嫌长的话可以看看我的。如果你想了解关于布局文法上下文相关解析（也可以在分词的阶段做）或可动态扩展中缀链解析(infix subparser)或汉字数值解析和格式化输出的内容我可以帮说几句，上面的链接可能要科学地上网才能访问。

我觉得没有必要呀。
编程，其实是符号编程，比如汇编，就是明显的符号。
后来高级语言了，使用有语义的符号。
比如if，for，case
其实他们还是符合.。
查查英文字典，case是啥意思，和代码里的case有关系吗？
英文更适合表示符号。
中文不适合“符号”这种表达方式。
再来看命名。
这个看项目。
以前做过一个工程车辆的销售项目，他们有n多表格，表格都要做到数据库里面。
那么字段名就直接用表格里的名字好了。
（有点表格是中文，有点表格是英文，有的表格是中英文双语的。）
于是用英文还是中文，就是一件很自然的事情了，没必要强求，也没必要强推。

—
"case this object of" 在 Google Translate 里是『案此对象(为)』的意思。

我们所有有点英文语感的人都会觉得它是『判此对象为』，案『情况(case)』处理的意思。


难道存但仅存一点点语义上的关系就不叫关系？照这个逻辑类似 ES6 的 let { name: its_name } = obj; Python 的 ''.join([1,2,3]) 这样罕见的颠倒情况（很不好找，因为英文中文语序的确区别很大，英文时基本不会让人觉得和自然语言区别很大）本该再多加设计、等号也不该分长等号赋值和短等号判定了。


而 for (name in iterable) 这个算是直接对应了吧？为什么中文就不能用非『符号』的表达形式 对iterable里的name……？语言不是符号？


至于强推什么的，其实哪怕是之前 5kw 的易语言我也没见人迫害 521，『中文编程』一直以来都是很克制的。（当然，也是很少有人愿意观看的）

—
中文命名不需要驼峰命名: https://zhuanlan.zhihu.com/p/40098652

在有类型声明的代码中, 类型前缀并不建议使用. 一定要的话, 中文前缀照样可以.

连字符, 与驼峰同理.

看到的中文命名实例中, 命名风格大同小异. 母语同是中文, 用词风格趋同只是时间问题. 还是那句话, 路是走出来的, 规范更是实践中形成的.
—
是的，比如最经典的 "abc".startsWith("a")，要在中文的思维方式里自然地表达出来就得使用「以」这个介词来连接两个对象。

如果这一点设计好了（比如 Z语言的序列式函数应用，比如 "abc"以("a")始()），绝对是不需要驼峰英文分词的。

否则的话 "abc".以始("a")或者好一点，"abc".开头为("a") 这种，那只能说是暴殄天物了，好歹也是所谓『夜鬼哭』的汉字啊。

—
命名规范怎么考虑中文呀。
中文没有大小写，那么什么驼峰了啥的完全用不上。
类型前缀（比如intAge）也没法弄前缀。
vue里面的连字符，比如v-if，my-form，的-也，对于中文来说这个减号也没用。
总之，基本没法用。
—
>v-if，my-form


那个 '-' 不叫减号，这里是破折号(dash)的意思，详情 Scheme 命名风格。

比如：

scheme

(define (histogram vector-of-words)
(define hash (make-hash))
(for ([word (in-vector vector-of-words)])
(hash-set! hash word (add1 (hash-ref hash word 0))))
hash)

—
好吧，你开心就好。另外听过无代码吗？
—
无代码nocode 是一些 别有用心 的前端们的笑话，没有啥实际效用。


只要人活着就得吃饭，它试图否定目标的价值（比如，活着。）而没有任何理由，然后提醒你只要不活了就可以不吃饭，当然只是个笑话啊。


我赌五毛弄出这个项目的前端不知道 JSON 形式化文法是啥子。

引记法 绝句.符号 「与」
引记法 绝句.符号 「止」
引记法 绝句.符号 「步长」

量 人物类型 = 表一("唐僧"对"人"、"孙悟空"对"猴")
解对人物类型里的(人、型)，说("$型 $人")。

“人 唐僧”
“猴 孙悟空”

量 人物 = 行一("唐僧"、"孙悟空"、"猪八戒"、"沙僧")
解对人物与索引里的(人、引)，说("$引 $人")。 “记法「与」的事 与索引……”

“0 唐僧”
“1 孙悟空”
“2 猪八戒”
“3 沙僧”

量 问题 = 行一("名字"、"追求"、"喜爱颜色")
量 答案 = 行一("玄奘"、"真经"、空)

解对问题与(答案)里的(问物、回复)， “对何<另项>皆有事 「与」(另：可迭<另项>：可迭<元二<项、另项>>)”
说("你的${问物}是什么？答曰，${回复}")

对零止10步长2里的，说(它)。

“with open(file) as f: f.close()”
尝试文件(径)去开启()成书，书去写文("emmm")。
接迎打开失败不常，告警("emmmmm: $径")。
“终焉，书去关闭()。”

对何<项> 项：有序<项> 皆有
事 冒泡排序(动片：动切片<项>) 为
  对动片的索引里的『某针』，
    对(某针后..动片的末引)里的『此试』，
      若动片[此试]小动片[某针]，动片去交换(此试、某针)。
对何<项>皆有
扩物 动切片<项> 为
  事 交换(甲：引数、乙：引数) 为
    我[甲] = 我[乙]；我[乙] = 老甲
  其中，
    量 老甲 = 我[甲]


例 『某易语言而不是易飞扬程序』: 应用程序() “还有『带参应用程序』” 为
  实现的事 入口() 为
    量 a = 听去数一()
    量 b = 听去数一()
    若a大b，交换(a、b)。“假设这是1.0，绝句有存储抽象”
    a定「不大b」
    说("$a $b") “绝句可没有啥『调试说』”
    回效果 “当然是不必显式写出来的”
“
def 妖精(能耐, 名字='白骨精', 降服者='孙悟空', 原形='骷髅'):
    print("尽管善于" + 能耐 + ", "
      + 名字 + "仍被" + 降服者 + "制服,"
      + " 变回" + 原形)
      ”
事 说妖精(妖精：文、原型：文、能耐：文、降服者：文) 为
  说("尽管善于${能耐}，${妖精名}仍被${降服者}制服，变回${原型}")
例 西游记: 应用程序() 为
  实现的事 入口() = 说妖精("白骨精"、"白骨"、能耐="变化"、降服者="孙悟空")
“绝句暂时不打算支持 partial application”
量 说白骨精：(文)效果 = 函数，〖能耐〗说妖精("白骨精"、"白骨"、能耐、降服者="孙悟空")。

看来设计类型推导方法是个苦差事啊，学术派一点要用 unification 归一化，而且逻辑式 miniKanren 好像不也是用 unification state&goals？
看来多态推导有点麻烦…… 大概还是写的出吧。

“Java:”
“if (true) { System.out.println("OK"); }”
“「易」语言：”
“如果 真 那么打印"OK"结束如果”
若真，说("OK")。
若组件[i]之为已创建，组件[i]去销毁()。
若你组件[i]之为已创建，你去销毁()。 -- 不能这样！改回

“我这时觉得绝句真的是美得像天使一样，干净利落不带空白，和没有逗号表示法的语言比。”

记法，是绝句里为了拟自然语言加入的自定义介词。
一般来讲，它的处理过程不必多加空格，所以词法类似+-*/等符号，必须在标识符读取过程里时刻检查，往往会用动态 Trie 树进行这种解析。

定记法 「问」
引记法 绝句.额联 藏「对」
引记法 绝句.额联 藏「+」 “尽管这可能是绝句语法上的华点之一，它们不特殊、所有和语法结构无关的东西（那些东西一般都是全角或中文词）都不特殊。”


“
包 绝句.标量
定记法「+」
定记法「-」
“……”

物『数』 为
  “……”
  【内建】【名字合法化】待例、记法「+」的事『+』(另：数)：数
  “这时，尽管+已经是一种记法，它依然可以被『』括住作为名字的一部分甚至全部，而在符号解析过程中这是有效的。”
  “『』形式的名字不被称为合法化，只是叫『角括号名字』而已，合法化的意思是即便它对目标语言不合法，也自动mangle这个name而不是报错。”
”

但是以上好像是在朝着Scala的方向走，原因仅仅是为了支持标准库怎么这么地（而且大家都不知道『数』是不是该在标准库定义一个），实在是必须多想想。
而且这样，「算符」这个修饰，还有1去加(2)这种用法就泡汤了，运算符优先级实现也本不是记法会考虑的事情，那如何呢……

定义基于中缀记法的事（当然必须是中缀单参数的方法「事」啊，噢不，介于「之为」这样的记法导致的问题它也可以记「量」）时候，可以选择：

记法「之」的事 之存一(条件：命题<项>)：真假

其中『之存一』这个函数名必须以中缀字面开头。或者，

记法「对」的事 对(另：项）：元二<项、项>

绝句里，「~上」这种后缀记法只允许使用「的」访问的属性使用。

记法「~上」的量 上面：位置

绝句没有Kolin的infix关键字，就是因为它用的是不必加空格的记法系统，虽然这个方式的结合性、优先级也基本是没改。

解析的结果是记法（也就是「的」「去」的替换符）的字面形式（比如他对她、他上里，「对」和后缀的「~上」）
基本可以说是等价 他去对(她)、他的上。
语言类型分析过后，就有机会找到前表达式base对应的记法定义，进行进一步的处理。

记法访问(左表达式、记法名、右表达式)

https://zhuanlan.zhihu.com/p/53416369 #async

#security 忍不住让我想到了以前的 war dial-up 攻击。

Facebook Messenger is removing the ability to find someone by entering their phone number

Facebook Messenger正在删除通过输入其电话号码来查找某人的功能

来源：
https://twitter.com/wongmjane/status/1210864489358184448