@gullitintanni 虽然发这个帖子有一定的推广存在，但是如果把每篇文章串联起来，你会对“一个编程语言是如何开发的？”有比较清晰的认识，也算是一种教程/科普性质的文章。每次文章出现的 Hulo 和标题代的 Hulo 其实可有可无，换成其他语言也是同理，主要是为了浏览器 SEO ， 因为这类项目的关注度和推广难度真的很难做起来。

@vfs 是的，蛋疼就蛋疼在这里，所以 hulo 需要一堆语法糖去实现这个过程，让用户写起来不需要关注平台的封装，Hulo 会将所有复杂性留在标准库里面，而且也不做编译器内的硬编码，所有的转换都在 .hl 文件里面实现

@vfs 其实最直接的理由就是，著名是开源项目 Kubernetes 中 bash 2.4 % + powershell 0.2% > python 0.0% 而 Hulo 存在的意义就是要让 2.6% 变成 Hulo 。不过这可能是目前的幻想 hhhh

@w568w 感谢支持。除了 V2EX 我在 b 站的时候宣传评论区也存在诸多不解。大部分人的第一印象就是 为什么不直接用 python 、js 等脚本语言写什么批处理，就存在这种刻板印象。不过也还好，质疑的声音越多，我就可以试着表达我的想法和告诉他们为什么需要 Hulo 这样的语言，也能带来更多的曝光度。要开发一个跨平台的批处理编译时真的，复杂度太大了。目标语言的语法一坨又一坨 要统一他们只有各种的语法糖（运算符重载、操作 ast 、comptime 条件编译...）。有时候 bash 用户可能没有 bc 要用 awk ，有时候可能只想用 (( )) ，batch 的延迟展开 这些操作 真的蛋疼

@llsquaer Hulo 现在的定位是批处理脚本的编译时，因为 Hulo 的完成度不是很高，对外宣传的还是比较保守。Hulo 现在能够基础的解释，未来还会为对接上 LLVM ，设计出自己的字节码。至于为什么这么做？因为很多项目都是 bash 、powershell 写的，可以实现一个提升器(lifter) 或者说是 反编译器，将这些语法向 hulo 转换，而 hulo 就能成为这些语言的 IR ，那他能够打包成其他语言，甚至提供 runtime 、native 机制。最终成为批处理脚本的 LLVM

@spritecn 每个语法的设计都有考量的，整体上语法是师从 typescript + rust 的。1. 在接口的定义和实现上抄了 rust 的 impl, 分离具体的实现类和接口之间的耦合，这样可以在任何位置实现，比如说 impl findstr for grep, impl grep for findstr ，不同平台命令可以相互实现。2. comptime 这个语法糖他是一个表达式，可以塞在任何地方，所以他和传统的宏还不太一样，他可以耍无赖的放在函数的参数里面，比如说 echo （ true, comptime { ... }） 至于这要做有什么用，就是后面 hulo 会开发的，hulo 的 comptime 可以操作 ast ，但是不同于传统的编程语言 只能操作包裹的子类节点，hulo 的 comptime 能够直接操作父类，也就是说 经过 comptime { ... } 的执行，外层的 echo 可能被替换成 Write-host ,之所以会这样设计 也是为了跨平台的考量。如果是 go, python 的语法糖压根达不到这样的水平。3. hulo 的命令是基础类型，可以对命令进行组合相互实现，例如 use grep = find & findstr 这样的，有点类似 ts 的类型体操，但是 hulo 的机制更加复杂，因为命令有不同的 options 还需要更细粒度的组合，因此 hulo 还参考了 css 的选择器，支持对命令进行更精细化的提取。总的来说，Hulo 的这些语法糖就是为了统一这些平台的语言设计的。

@xgdgsc 这差的很多吧，Hulo 的目标是编译成 Bash 、Powershell 、VBS 、Batch 统一批处理脚本，作为批处理脚本的中间语言，你可以理解成批处理脚本的 LLVM ，然后在写一个提升器，将 Bash 转化成 Hulo ，就可以实现 Hulo 到其他批处理脚本的转换

@xuanwu Hulo 使用 ANTLR4 生成语法树 https://github.com/hulo-lang/hulo/blob/main/syntax/hulo/parser/grammar/huloParser.g4
使用 ANTLR4 有很高的容错性，一旦语法树解析错误也能继续递归， 这种机制使其在处理不完整或有误的输入时仍能保持一定的解析能力（例如 IDE 中的实时语法检查）

@vfs 因为 bash powershell batch vbs 直接与操作系统捆绑着，他们自带 runtime ，其他语言如 python 、js 都需要安装运行时。而且 bash 在 linux 上面的地位有目共睹，大部分的批处理基本上都用 bash 实现。

@putaozhenhaochi
既然 Windows 都自带 PowerShell 了，为什么还需要 Hulo ？
虽然自带 PowerShell ，但 Hulo 并不冲突。未来可以编写一个 Hulo 代码，翻译成 PowerShell 和 Bash 脚本，让批处理脚本一次编写多端运行。这还需要一个命令转换系统，比如 Write-Host 和 echo 的跨平台抽象。
很少人在 linux 上使用 powershell ，而是使用 bash ，而 hulo 的意义就是作为批处理脚本的 IR 语言。而且 linux 上的 powershell 需要自己安装，不是捆绑在内核中的

由于推流，后续的章节 2-3 天一更

@thinkwei2012 感谢支持。有 lifter （提升器）的开发计划，将 bash, bat-> hulo 然后在用 hulo 去转换，不过这是后话了 目前的目标还是赶紧实现 hulo -> bash / batch 这一侧的为主，等功能都实现差不多了 再实现提升器

@xiaohanyu 目前的目标是 Hulo 能够重写如 nvm(基于 bash), scoop(基于 powershell) 这样的项目，以一种比较现代化语言的方式。

@w568w okok 我有参考过他们，这个比较会在 Hulo 开发完成度比较高的时候在贴出。这几个项目基本上是把命令当函数使唤，本质上和通用编程语言无异，amber 的 unsafe 没什么用，那样设计不能对命令进行代码提示和类型检测，因此 Hulo 的解决方案是直接将命令当成基础数据类型，对 cmd 进行操作，cmd 就是 class 就是 interface ，这点以后会实现。现在的翻译不是最终定稿，我知道需要对变量名进行混淆，混淆器在实现，但是他涉及到 import "time" as t, import { date as d } from "time",这样情况，我始终没法设计出对 import 的最佳实践，只能边发语言边优化，所以现在基本上只能看个大概。

@Damn 哈哈哈，这个我之前看过。虽然要被废了，但是不可否认 Windows10 还有很大市场份额的。不过先发布 VBS 的支持是因为他的语法最接近传统的编程语言，不会像其他批处理脚本一样有各种抽象的概念（比如说 &>, $(), [[]] 等符号满天飞），要设计的地方很多，这周会发布 Hulo 到 Bash 翻译的版本，然后下下周在支持 Batch 。

@bigtear 感谢你的建议，不过目前的计划会先把各平台的批处理脚本都对接完成，然后实现最核心的功能，命令类型，并且实现对命令的代码提示和接收参数的类型检测。虽然自带 Ps ，但是并不冲突，未来可以编写一个 Hulo 代码，翻译成 Powershell 和 Bash 脚本。让批处理脚本一次编写多端运行。不过这还需要一个命令转换系统，比如说 Write-Host 和 echo 的跨平台抽象，这块我后面会实现，已经设计出了语法糖。

@geelaw 哦哦 感谢解释。可能我有点标题党吧，因为一开始的目标也不是只针对 Windows ， 在我的 github 仓库里面，写着是要翻译成 Bash ，Batch ，Powershell 的。然后就是命令了，现在哪怕是最现代化的批处理脚本 Powershell 也很难对市面上的命令进行有效的代码提示，甚至 ps 自己的静态分析就很鸡肋。所以 Hulo 就设计出来了，一款以 cmd 类型为基础数据类型的编程语言，不过这块还没实现，因为要实现的难点在于 命令很复杂，需要一套有效的声明系统，以及不同平台的命令需要实现跨平台封装 相比传统编程语言更加自然，为此我设计了两套还存在于 PPT 中的系统。

@dwu8555 虽然两者语法看起来类似，但是只能翻译成 VBS ，不支持 VB 。VBS 能够直接跑在操作系统不需要安装任何环境，操作系统自带。

@TrackBack 因为翻译成批处理脚本 最重要的就是命令类型比如说 git clone xxx 这种，现有的语言根本不支持这样的语法。所以一个新的语言就诞生了，命令就是最基础的数据类型。不过这块刚构思完，还没来得及实现和介绍