@dodo2012
var b map<int, slice<map<string, map<string, slice<string>>>>>
var b [map int, [slice [map string, [map string, [slice string]]]]]

相比之下，我还是觉得比<T>的方式清晰一些。

@codehz hhhhhhh 站在巨人的肩膀上

XyKey 纯本地，跨平台

@Leigg 这些不是我现在关注的。
我关注的是如何用尽可能少的语法表达逻辑，还能用怎样少的字符组成功能完备的编程语言，还应该降低读写负担，尽可能把注意力留出来解决问题。
简单性、可读性、可理解性是设计目标（当然，因人而已，挑战旧习惯从来不是容易的事情，也不是每个人都会喜欢我的路线）。
现在只能依赖目标语言，这些能力都受目标语言影响。以后到 llvm，才有条件考虑自身的特性。

@hourann 谢谢你的建议，我去看了，的确有意思

@ClarkAbe emmmmm。。。go 里面也一堆<-，解脱个啥

@GM 嗯，数的没错，的确是 1，2，3，一堆关键字，实在是太多了，都快比我手指都多了，太难记了。

@marcong95
1. // 和 %% 在语言里也没其它用途，没有语法冲突，就索性把 root 和 log 功能都加上了。都是转成库函数来运行，其实不用操作符也可以不用。只是有个 ** ，不加上我有点强迫症。
2. 其实现在的语法去掉类型也是完全能放在动态语言上跑的，的确是挺好玩的。目前我是因为自己写项目要用，就一直折腾下来，以后有空可以捣鼓下动态类型和 shell。

@dwcz
1. 这是编程语言，只不过它现在还只能依赖输出到其它语言来运行，所以还不能去解释自己的内存、版本管理等等东西，这些现在还只能视目标语言的环境来使用。不然编译到 js 的 ts 就不是编程语言了吗，还有 kotlin 之于 js 和 jvm ？
只能说它现在还不是一个独立运行的编程语言。
2. 我不清楚你说的抽象汇总是怎么回事，至少你得提一个具体的案例，才能说明你的观点。
3. 本身 if then else 的结构代码块就是用{}表达，没理由不用 if else 就分不清楚，结构都一样。我反而觉得噪音更少了。
4. 检查异常的结构也是传统的 try catch finally 结构，仅仅省了几个字，功能都一致，这跟 java c#的处理方式有何不同？意思是你觉得这种方案不好，更倾向于 go 的 error value 还是 rust 的 result<T>？

@no1xsyzy
6. 目前是因为我在用那些语言，写这个语言能帮助我做一些共通的工作，工作场景所需，老是要做一些多平台的东西。
主要目标其实也不是多语言，反而是在尝试多语言输出的过程中能学到很多每个语言共通和精妙的东西（当然了不包含函数式，纯函数式也不太需要这种蹩脚的命令式设计）。
算是给自己积累经验，以后输出成 llvm 才能真正脱胎换骨吧（虽然我经常咕，不过没放弃过什么项目）

@no1xsyzy
5. 很好，这给了我灵感，的确是需要一个操作实现 yield 功能，最合适的操作符就是 @ <- value。这样就不能用原来的方案实现 continue 和 break 了，感官不好。
现在我用不带箭头的方式表示这俩操作。
..@ continue
@.. break
比原来的方案好上不少，已经更新了，感谢你的建议。
6. 本身 Lite 也只是旧时代命令式语言的现代精简版，再强也比不上函数式的骚气，这点无论如何都不敢妄自菲薄。
Lite 现在只是类似 ts 对于 js 这样的存在，是个大型语法糖+盐。但也不局限这样，现在支持输出到 c#、go、ts，也有能力输出到 swift、java，实际上就是抽取了很多语言共有的东西，接近通用语言，能简化很多目前我跨平台开发工作。
既然是拥有自己独特的语法和能力，就是独立的语言，能不能做什么，就靠后面编译器和运行时有多强大，靠持续迭代去改进了，计划几年内输出到 llvm。

@no1xsyzy
5. -> @ 和 -> 感觉没有改进特别大。还不如 ~@ 作 break， -@ 作 continue。
6. 你这语法是啥，Type 是泛型吗。
Lite 的泛型语法跟 C#同类型，没 Haskell 那么逆天的类型系统。
apply 函数只能做到 apply<T1,T2>形式的，所以推导能力目前也就只能到这里了。以后支持省略泛型标记的时候再做这方面加强吧。

@no1xsyzy
5. 这道填空题不成立，<- 是一个操作概念，并没有设计成 @就得有个什么对应，函数就得有个什么对应。函数是(->)，跟<- 也对应不起来。<- @ 跟 <- value 才有对应的概念。不如你说说这地方该怎么设计，我可以参考下。
6. 你可能不熟悉 c#，不是加一个 var 就搞定了自动推导功能。
arr = {1,2,3,4,5}
arr = {1}
翻译成 c#是
var arr = new list<int>(){1,2,3,4,5};
arr = new list<int>(){1};
这里应该不难看懂，把自动推导就理解成 var 就太。。。了。
typescript 翻译完 js 还没有类型了，这不影响 typescript 强大。

@lepig 谢谢，编译器前端门槛不高，借助 antlr( https://www.antlr.org/)这样的工具就很好实现，后端比较难，你也可以试一下。
唯一觉得不容易做的没有多少利益的情况下坚持投入个几年时间到上面，还继续投入下去。

@mggis0or1 跟 dsl 差别挺大，通用编程，跟 C# 的语法复杂度差不多，基本无缝互操作，这个规模不太算是 dsl。

@Niphor 对啊，难得讨论了回技术。一开始是以 go 为基础，现在差别挺大的，Lite 的语法需要看过文档学习后才能感觉到舒畅。

@no1xsyzy 双拼的确是非常快的，以前我在少数派工作的时候他们就大力推过，不过那时没有一个跨平台好用的双拼输入法，最终还是没坚持下去。
现在我年纪大了，脑子转的很慢，写个代码要思前想后考虑很多，码字速度已经没拖脑子后腿了，追求不来速度（滑稽
说真，要不你 fork 一份把操作符改成关键词试试玩玩，或者你觉得可以用什么关键词，发一份给我，我改个双模式，不影响编译。

@no1xsyzy 编译器实现了自动推导，输出到 C# 也得用 var 吧，为什么不用啊，写 C# 不用 var 吗？ 233333

@no1xsyzy
1. 总之现在你确认 Lite 是静态语言了，any 类型肯定是需要的，推导不能解决一切问题，很多地方还得靠反射和类型判断，Lite 肯定也得支持。
2. 我只说我去除了关键词，没说去掉了 token，不管字母还是符号到编译器都是 token，我喜欢操作符，不喜欢可以自行 fork 改成字母，这不影响 Lite 本身语法精简。
3. lexer 和 parser 用的都是 antlr，用轮子难道有什么问题？敢情现在写个项目还要从汇编开始写吗。开源大轮子比自己写的要好千万倍吧，后端我还准备用 llvm。
4. 老爷子去世我难过了好一阵，刚开始设计 Lite 看了好久 Erlang 的设计，里面的思想的确精辟，我也借鉴了一些。
5. <- 是返回语义，我通过后面的内容判断返回的目标，<- value 是退出函数，<- @ 用来退出循环，这样符合这个语言自己的设计，统一表达规范是我很着重的部分，