bylx666/key-lang

目标是最精致的编程语言

Key Lang

轻快, 省心, 做最精致的编程语言.

1. 消去了引用的存在, 初学者也能轻松上手
2. 更短的循环, for!代替while(true)
3. 更方便的迭代器, for i:20即可循环20次
4. 更强大的match, 原生支持数字范围匹配
5. 有趣的extern, 用key代码直接操作动态链接库!
6. 区分整数和浮点数, 再也不用floor遍地跑
7. 原生类型支持, 动态类型检查, 大量减少判断量
8. 像js一样用{}字面量创建哈希表
9. 原生类型Buf让你轻松操作内存

更多特性请见Key语言官网.

在我17岁时, 就在只有标准库的情况下完成了整个工程, 并独自创建了Key语言官网和在线尝试Key语言两个网站. 这一切, 或许都只是我的成人礼罢了.

key-lang's Issues

[建议] 使用 Github 的一些特性来更好的维护本项目的 git 记录

• 本项目并没有做过 issue 与 commit 记录 / issue 与 pull requrest 记录的联动，这点属实不应该。比如 issue #3。

原因：这更像是一个基础的原则性问题。因为所有的项目，既然开源，在作者做出指向性修改的时候，都应该标定修改的位置，并在问题界面提供明确的入口，方便其他人进行 review，以及其他的操作。

修改建议：在进行 commit 的时候，加入 issue 编号来标定该 commit 用于修复哪项 issue。

• 本项目疑似没有进行 main branch protect。建议开启。

原因：我承认，在单人进行开发的时候，可能开启 main branch protect 并采取 branch merge 听上去有点自娱自乐，但是事实上这个能帮助你更好的进行版本控制。假如你后续写了两个功能，先写的功能 A 再写的功能 B，然后再加入一个功能 C 发现功能 A 会导致功能 C 出现问题，如果需要 revert 排查，使用 branch merge 就可以迅速的帮你关闭功能 A。按照你现有的方法，出现 bug 时回滚会导致功能 B 一块下线。修复结束后再加入功能 B 则会污染现有的 git 记录。

修改建议：开启 main branch protect 并在后续的开发中采取开 branch 开发的模式。

• 本项目的 README 过于简略。

原因：一个好的 README 应该绝不只是包含你认为你写的程序的特色，对于编程语言类库而言，可以参考 wenyan-lang/wenyan 项目。他们的 README 是非常用语言 README 中我认为最好的一个。

修改建议：你自己看着改。

比较函数时逻辑不是期望的

如下的代码：

// test.ks
let f() : 1;
log(f == f);

期望打印true，但实际打印了false

Congratulation! ✨

This is an amazing program, you're the same age as me, it's so awesome.
I'm honored to be the second starer. I wish u good luck on your entrance exams.

这真是一个了不起的项目 ,大佬和我同龄欸, 太厉害了叭.
很荣幸成为第二个 starer. 祝大佬高考加油 !

关于 readme/项目说明的两个建议

您好。因为我最近也在实现一个编程语言中的模式匹配的类型检查，看到你的语言里也有。在 readme 中，你声称你的 match “更强大”，但我看了基本上只是比 C 的 switch 更强，别的语言的模式匹配，我的理解上基本上是以匹配 enum/tuple 这类东西为主，字符串和数值都是附带的，然后带个完备性检查。而这个特性你没有实现。

另外“最精致”我觉得言过其实了，你列出的语言特性，我感觉都是比较常见的，要么就是实际上有 tradeoff 的语法便利性，在你的需求和默认提供的语法有冲突时它的便利性会立即消失。比如创建 hashmap 有特殊语法，我想要 treemap 怎么办。

You did a good job

鲜少有人能在你的年纪做出你的成就，请继续加油！

栈空间过小

84下递归主线程就提前死了

md用的全是裸指针，你写的是c还是rust？

你这写的是c还是rust啊？rust的特性一个都没有用上，你还是写c++吧，全是裸指针

一個小建議: 不禮貌的 pr 即使方法處理正確但也可以拒絕

過濾掉無用信息在 pr 中認真學習和思考自己的不足，不要太過在意上來就一副救世者姿態的人
慢慢控制好自己的情緒避免後續做出太多錯誤事情，從中慢慢改進和成長

雖然我只是**前端給不了你多少建議（我也十分感謝我寫出屎山放在GitHub上沒有被人網暴，我承認如果有我處理方式可能和你也差不多，人總是有自尊心），但是冷靜下來改正和虛心學習可以慢慢改變自己，加油！

key这个名字比较没有区分度.很难从搜索引擎搜索到.

key这个名字比较没有区分度.很难从搜索引擎搜索到.

递归的function#unzip方法导致栈溢出（期望提示递归unzip）

// test.ks
let inner() {
    log("inner here");
    func1.unzip();
}

let func1() {
    inner.unzip();
}

{
    func1.unzip();
}

祝福

不论如何，希望坚持开发开源精神，大胆尝试创新，祝福KeyLang发展越来越好！

支持一下

很不错，不管这个项目是否有用，能否坚持下去，对于一个年轻人都是一件值得称赞的事情。不要被某些言论所影响，保持兴趣。

一些建议

作为一个代码量比较大的开源项目，我认为您可以从这些方面来让这个项目更好地发展：

• 建议利用Github的Issue模板功能，给用户提供反馈问题的模板，能有效提升issue效率
• 可以写一下路线图，来让别人了解这个项目接下来会往哪里发展，也方便贡献者参与
• 虽然看到您已经为编程语言做了文档，但是对于编译器代码（也就是仓库中的代码），您还可以使用rust文档注释，配合cargo doc工具来生成文档，更有利于别人了解编译器的工作原理

支持arm系统

学长，您这个语言确实十分优秀，但是它无法在我的arm电脑上运行，希望支持arm系统，同时希望您高考顺利。

事件经过

这个 issue不是针对这个key lang，而是针对一场争端

在你发表任何你的意见之前，请先尽可能多地了解事件的经过。不过，如果你是鲁迅笔下的“那些人”…我就没什么好说的了。

总览

• 事件经过

• ​为什么出视频

• ​为何如此痛恨控评

• ​为何还要继续下去

因为我已经被 @Bylx666 封禁，故不能使用这个账户提出issue

事件经过

在这里我先比较完整地叙述一下事件经过，以免使得各位对事件经过和内容产生不必要的误解。

最开始我在B站刷到了key lang的视频，听完他干巴巴讲半天，没看到一行key代码，我也没有多关注这个（不过还是记下来了）。

（这一段不是很确认）后来该的视频被 @TabNahida 刷到，不同于我，他比较细致的看过 @Bylx666 的个人主页，以及Key语言官网什么的，他说Key官网的网页写的很好看。

之后他(TabNahida)发现了Blyx666主页的英语语法问题，提了一个issue…

因为他提了一嘴，我就抱着学习的想法去看了一下Key的源代码。

他的网页，他的视频…以及视频下被他挑选过的评论区，全是对作者，对key lang的表扬，赞美。

可是他华丽的网页之下所呈现的主体，key lang，它的源代码却是混乱不堪粗糙无比。就事论事，他的源代码质量真的很差…差在哪里我不会再重复了，这是不争的事实。

网页源代码的注释建议好好修改一下，别让人觉得一眼AI生成

然后我就提交了一个issue，也就是#10。

需要注意的是，这个issue是修改过的，它被我修改过两次，你可以直接在github上看到我修改之前的issue。

刚开始我只说"好高的代码质量，建议过亿遍clippy"，后面附上我的编辑器给出250+警告的截图。把我说的话用中文翻译一下，就是"你的代码的质量很低，建议仔细使用clippy修复代码"…如果你觉得我刚开始的语气也很不礼貌，我也没什么可说的了。

之后我发现他的代码不止没有通过clippy，还没有格式化，就在clippy后加上了rustfmt。

我并没有在#10中指出更多的问题，因为我在对#10进行第一次修改之后就在帮他修复代码中的warn，提交pr，也就是#11。

不可否认#11并没有尊重作者的缩进————但是这完全是可以加一行代码就解决的问题

#11里我只修复了全部253个warn，以及格式化代码，并没有对代码逻辑做任何改动，完全就是喂饭给他吃

写pr，读代码的过程中着实被他的代码恶心到了，我就修改了#10，加上了“这是我读过的最垃圾的代码，没有之一”，同时修改标题为“不建议使用rust”，也就形成个各位第一次看到的版本。

之后我收到了作者的回复…只能说他完全就没有去了解我的issue指出了什么，提出了什么建议。他只抓到我说他的很代码质量很差，于是就

• 评价我的行为：不过脑子

• 对于我的行为：不多评价

这就是作者对于提出建议的人的态度？

因为某些原因，我的情绪很不稳定，很快就写出了非常具有攻击性，充满阴阳怪气的#12。确实，#12语气很恶劣，但是这并不体现我对作者的尊重程度，而是作者对我的尊重程度。

那么他是怎么回应的呢?

• 对于我的PR，他说：“说到底你所谓的"优化"或许只是你的一厢情愿罢了”

• 对于我的态度，他说：“一丝不挂地表达出自己的优越, 我认可你的勇气.”

是谁先一丝不挂地表达出自己的优越的呢？

不止于此，基本上在从他的所有回复中，都可以体现他的优越

在内容上，在#12我额外指出了代码中的各问题，比如

• 滥用static mut：他说：“滥用”static mut同样是我自己的选择.

• 使用指针代替引用：他说：“用Rust贴近汇编的思维方式并不可耻”，“懒得写生命周期”,

• 没有CI测试验证代码是否内存安全：他没有看，直接忽略了这一条

他还说：“我不会关闭该issue”。但是接下来他做了什么呢？ closed this as completed

他真的是很守信用的人，说不关就不关

实际上，他是提交了一个删除了#[allow(unused)]的commit之后才关闭的issue，这恐怕就是他说的 “我会将此issue挂起, 在有所谓的"优化"的准备时拿来参考.”

他的修改和我说的东西，完全，没有任何关系。但是可能这就是他认为的问题所在吧？他是精致艺术品的创作者，而我只是一个云程序员

我的视频下，他回复道：像你这种什么都没做出来, 只是学会了一点rust皮毛的人, 只是知道了大量概念的人, 只是觉得多数人即正义的人, 并没有实现过和创造过什么真正的作品来. 但我有一个完整的艺术品供自己欣赏.

接下来我提交了#15，和这个issue一样并不面向于作者，而是面向于其他看到这个项目的人，详细罗列了代码的问题

这次他是这样回复的: “我欢迎你无限攻击我, 也欢迎所有人来观看新世纪人类行为鉴赏.
毕竟这个仓库已经没人来看了, 也没人来开发, 我就把该issue保持open状态. 你一定还会回复或添加新issue继续攻击我, 我对你表示欢迎态度.”

这次他又说保持open状态。确实，这个issue直到被delete前一刻，都是open的。而他对我的“攻击”的欢迎态度是，让我无法再对这个项目添加issue或者回复信息。我也是第一次知道github可以拉黑某个人。

对于他删除我issue的原因，我认为作者认为只有哦对他提出意见。意思就是说所有提出意见的人全都是我的小号。于是，我在github多了一堆“小号”，在B站又多了一堆“小号”。

既然他在github上传了源代码，既然他为他的项目出视频宣传，那就不会只有我一个人看到他的源代码，对他的源代码提出意见

他对一群我以前不认，他们也不认识我的人，说了些什么？

• ​我知道你是异月的小号，你一定会开各种小号来无限攻击我的，为了避免后续，我会把你的账号拉黑屏蔽，希望你好自为之

• ​(reopen#12)把话说干净就好了，我只是看不惯他的语气

• 我看得出你的态度有所悔改(close#12)

• ​我相信你, 真的相信你, 但我真的很想笑而已, 自顾自笑一下而已, 别在意我哈哈哈哈

我就不更多列举了

之后，我搜集了一些信息，就制作了视频

为什么要出视频

其实，到目前为止的所有，我就觉得没什么。他代码写的不行啊，不听建议啊，态度恶劣啊，都没什么。但是他做出了一件值得让我花大量时间去制作一期视频的事，花费大量时间写这个issue补充细节的事。

控评

他的bilibili视频下的评论区，非常干净，几乎全是赞美，很明显嘛，他有在精心维护评论区，对于他不喜欢的他可以删除，或者举报。

甚至我的视频下的评论区，他都要用举报帮我管理，他怎么这么好

而github，更是简单的很。怎么说，这位作者也是很高明的，掐头去尾只开放#12，#10没人知道，#15已经删掉。评论里认个错，诶，他就是对的了。

不合心意的评论，删。不和心意的issue，删。

我呢，因为#12里恶劣的语气啊，现在已经github都无法正常使用，被标记了呢。所以现在#10到#12都是无法打开的状态。

好像舆论的风向已经导向了他，毕竟这是他的地盘，他可以随意控制这里的言论的。

我承认我语气恶劣，我认为这来自于看见他过度包装的项目内里却无比腐败的反差。

为何如此痛恨控评

去查找，分析一场事件的全过程，是很麻烦的，往往也少有人愿意这样做。所以，在可以被看到的地方发布的信息，就可以作为评判事件的根据…吗？

可以被看到的信息，是可以被引导的。而控评，就是起这个作用。

在卯年刚开始不久，我经历了一场非常精彩的舆论引导。

白嫖一款开源游戏，有错吗？这不重要，他说我是只知道testfight的白嫖狗，那我就只能是了呗。不管我说什么，在土皇帝面前，都会变成“已撤回群成员的一条消息”。

稍加引导，我，是群乐子。再稍加引导，我又化身盒战士扬言把群主开了？我说没说过不重要，他骗人干什么？

这都不重要，重要的是我辜负了他们的期待啊。要是我再随便做点什么，那群乐子人会更高兴的。

不过倒是很感谢他们，让我不再把时间浪费在写一个没用的编译器上，写出来顶多自娱自乐，看似它的出现解决了一个大难题实则除了我没人用过。

以上的故事可以当做我编的，随便说说而已

为何还要继续下去

我的视频很好地起到了引流的作用…也让很多人参与进来了，最后结果到底怎么样，我也不是很在乎吧，大不了空中飞人。但是我觉得让不明经过的各位了解一下过程，还是有必要的。

最近在吃药，因为这件事情绪非常不稳定，不过加大用量还是有效的，不过我觉得加大用量治标不治本。

函数callhere与期望不符

let a;
let f() {
    let a = 1;
    let inner() {
        log(a);
    }
    inner();
}

f.call_here(());

期望输出uninit，实际输出1

建议砍掉 除了 加减乘除 以外所有的数值运算优先级.

建议删掉 除了 加减乘除 以外所有的数值运算优先级 的定义,改为这类情况必须加括号.
实际使用的时候记不得,要回来翻语法文档,并且 多种不同语言的优先级不一样, 会看错.

希望这个建议能帮到你. 如果你觉得这个建议没用.请直接关掉本issues.

`mod+`语法, 定义一个相对路径开头

mod+ xx> dir;
mod @dir/yy> modname

clippy pass

该issue的创生宣告了一次战争的尾声.

我想我会拒绝clippy的4格缩进意见, 但之后仍需启用clippy检查并重构部分语句.

我承认我的缩进问题, 我之后会认真参考rustfmt和clippy的建议. 另外, 给出建议时希望不要像异月一样开口就骂人, 而是把建议的原因简单写明, 我会认真参考这些建议.

高三生，为keylang及其作者送上美好的祝福！

我不明白为什么有些人戾气那么重（
可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧（？）

总之作者加油喵！

语法支持：移动值到属性中

期望以下的功能：

let a = {};
let c = {};
c.a = 1;
a.x = c;
// 期望一个将c移动到a.x中的功能，不是复制

这个啥用？有web和sql 的例子吗

这个啥用？有web和sql 的例子吗

祝福这个项目，加油。

我第一次做toylang的时候也才14岁多点，当时我做的很烂，不仅是antlr实现，语法还只有一个js的子集。

我觉得你的决心和毅力非常宝贵。这个项目其实完成度很高了，希望你能不被动摇，吸取良性的建议，无视恶性的诋毁，把这个项目做下去。

祝福你。

编程语言开放社区（PLOC）

@Bylx666 PLOC是国内的语言开发者的一个社区。
https://gitee.com/ploc-org
https://www.ploc.org.cn
key-lang是一个很有意思的语言，可以考虑加入PLOC一起成长。

示例中条件语句`if`无法成功执行

按照文档

let a = 5;
if a > 4 {
  // 成功打印
  log("a确实大于4")
}

错误如截图：

加上;后则可以成功执行

let a = 5;
if a > 4 {
  // 成功打印
  log("a确实大于4")
};

保持初心，你值得称赞

不要理会一些充满恶意、嫉妒的闲言碎语
坚持下去，未来肯定会大有所为！