自荐一个编程语言： Lite

[Kulics]

• 项目地址： https://github.com/kulics/lite

• 类别：编程语言

• 项目后续更新计划： 语法设计已经稳定（ 1.0-alpha ），后续主要精力将放在编译器实现改进迭代，扩展到更多场景。

• 项目描述： Lite 是一个专注于工程化的开源通用编程语言。

  这门语言的设计目标是简单性、可读性、可理解性。

  通过去除关键字，减少语法特性，统一表达规范，这门语言可以有效降低读写负担，让使用者能够把真正的注意力放在解决问题上。

  目前支持输出到 C#/Go/TypeScript，借助它们的资源，已经可以在非常广泛的场景下使用这门语言。

• 推荐理由：精心设计的语法，易于编写和阅读。可能是目前世界上语法最精简的静态编程语言。

• 示例代码：

Main(->) {
    print("Hello, world!")
    greetings = get_greetings("love lite!")
    greetings @ [index]value {
        ? index == 0 {
            print(value)
        } index == 1 {
            print(value + ", 世界!")
        } _ {
            print(value + ", world!")
        }
    }
}

get_greetings(first str -> result []str) {
    <- first + {"你好", "Hola", "Bonjour",
                "Ciao", "こんにちは", "안녕하세요",
                "Cześć", "Olá", "Здравствуйте",
                "Chào bạn"}
}

[no1xsyzy]

@Kulics 1. 我没有觉得 Lite 能算静态语言，反而我变得觉得 C++ C# go 也不能算——虽然也都不能算动态语言，这两者中间可以有其他的种类。编译期你连对象实例是否拥有某个方法都不能确定，instance.method(params) 会执行哪个代码你都不知道。
2. 请重新看一下 operator 是什么意思。如果你的 ?@!{} 能算操作符，那么 operand 在哪？还是说你的 {} 其实是代码块一类的东西？关键 “字” 不是指字母。操作 “符” 不是指符号。`and` 也可以是操作符，`?` 也可以是关键字（比如 powershell 的 ? % 两个关键字（是内建 “别名”，可以被覆盖））
3. 用轮子的前提是你能够实现一个的时候偷懒，而不是不能的时候跃进。
5. 填空：@ 是循环 <-@ 是退出循环，正如 _____ 是函数，<-value 是退出函数。
#95 不是你推导完一圈又回到 var 到底和不推导有什么区别啊……

[lepig]

还是挺支持楼主的。能写了一个自己的语言确实需要很多的技术储备

[Kulics]

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

[Kulics]

@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 强大。

[no1xsyzy]

@Kulics 5. 你要让人眼能 parse 必然要让相似形状具有相似含义。
不然这神经网络也太复杂了，人脑在无法作出有效预测的情况下会升级神经网络尺寸是没错（虽然实际上工作方式并不是扩大尺寸），但这还是给自己添加负担，越大越慢也越耗能。
既然你把 ->@ 作 continue，不如 -> 作 break
break 只会出现在 @{} 的块里，应该不太会歧义为 Lambda，无论是 syntaxer 还是 人眼
6. 行我明白 var 不是 auto 了，不过你这也不是推导啊，就是个判断。
你没有清楚地说明比如给定
函数 apply: forall (a:Type, b:Type). (a->b)->a->b
函数 format: Str->Num->Str
变量 x: Num
变量 form: Str
如何得知 apply(format(form), x) 的类型是 Str 的。
需要更多指示才能明确是有类型推导的。

[Kulics]

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

[no1xsyzy]

@Kulics 5. 说起来还有一种建议是干脆当作尾递归的语法糖，实际编译成迭代。
就好像 racket let 的第二种形式
<https://docs.racket-lang.org/reference/let.html#%28form._%28%28lib._racket%2Fprivate%2Fletstx-scheme..rkt%29._let%29%29>
它作为一个语句可以具有值，break 时可以带值 break。
所以就是
<-@ continue
<-value 带值 break
6. Type 是指任意类型，a 是任意类型，a 就是一个泛型，b 也同理。
确实 Haskell 的推导很强（最强，全都能推导），不过类型表达能力本身还是 Typed Racket 更强，毕竟 type? 就是 (-> any/c boolean?)
C# 不熟，这么其实说到底你的语言就是 C#、go 的糖+盐。
通过恰当的调味让两者趋于一致，这本身确实是个技术活。但将其描述为一个新语言简直就是在捧杀。

[Kulics]

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

[no1xsyzy]

@Kulics 5. 我也就起到了启发……虽然还是很奇怪但至少没有给我带来 break = continue 既视感了。
6. 本来跨语言的语言就是个伪命题（世界语有多少人用？）。（我总觉得最后又会变成一个 lisp 实现）。

[dwcz]

你这不是编程语言，是编程语言基本语法汇总。更倾向于代码自动生成。编程语言中：内存布局、代码即文档、版本管理、模式抽象、错误和通信的分层处理，这些问题都没涉及。判断语句的设计不好，没有抽象汇总，而且感官上不能直接区分各个分支。代码块都用{}表达，反到分不清了。把检查异常放到正常代码中，不是个好的方案。

[Kulics]

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

[Kulics]

@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>？