回来了

感谢正好十六个人关注，所以我每次把这里当作自己随便写的地方

总之有什么，能干什么已经约定好了，所以以后不管怎么样都能做出来

这个是最后版本的 GeekApk，因为后来计划又有变，很抱歉，貌似没有 GeekApk 了，不过有别的计划，不要转发

这次看了一些《ES6 标准入门》，基本了解了 Promise 和 Generator，也涨知识了

同时也有新的变化，记录在书上。

首先是项目列表，变成了

+ GeekApk
+ ApkPage（它最初叫这个名）
+ HuaJiPhys
+ InScript（Lite 变的）

后来 GeekApk 又没有了（因为被又改名叫 GitApk 的家伙取代了... 和 InScript 取代 Lite 一样）

首先说 InScript（duangsuse 有习惯把本应该记录在笔记上的文字记录在这里

InScript 名来自与 Inspect 和 Script 两词，我想让 Lite 成为一个专门扩展其他语言的 AST 解释器，所以我觉得这个名字比较可以突出它的性质

InScript 开始计划开的坑有

+ Highlights 高亮配置们
+ Ideains IDEA 插件
+ Inside InScript 打算做一个 Android IDE 的
+ instd 因为解释器本身不携带类库... 准确的说是「扩展」类库，因为 InScript 虽然是 OO 的，但是不能创建类，一切依赖「方法覆盖」
+ inspec 类似 RSpec，必须的测试框架
+ ink 包管理器
+ instruct 类 Rake 构建系统，因为 InScript 非常依赖平台原生的类库，而脚本不能而且不需要编译（最多到 AST 格式而已）
+ indoc 一个内联文档的构建工具是必须的

解释器方面打算有 Kotlin 的、ES6 的、C# 的

如果有时间还打算出 Ruby 和 C 的版本，虽然更加没有意义（

另外 Lite 变成 InScript 自然是不会没有任何改变的，实际上改动很大很大

+ 允许为块指定「全局」环境

Lite 比较蹩脚，因为不像 Ruby，有些东西不是方法（全局 LiteBlock 对象）
所以拿这个弥补一下

+ 当前 self

整个解释器（一个线程一个解释器）应该有一个全局的 self，显然 self 应该是一个函数调用的本地参数...
Lite 目前是使用填充 self 符号再调用方法的，考虑将 self 作为真正的参数

+ 无括号调用

学习 Ruby，因为有时候没有参数还要括号很蠢

以前必须这样写

System.gc()

现在不需要括号

+ InterpreterOptions

解释器允许不同的解释模式，如使用 self 填充或本地变量，不支持 @ 处理器等等

+ forIndex

for i = 0 to i >= 100 do i++
  puts(i)

+ TLS errno

线程安全的 Errno，但是我觉得没有必要，现在已经安全了（一个线程一个解释器上下文）

所以确认增加了更好的 StackTrace（增加脚本行号）和 saved exception，因为 InScript 不支持异常

+ Option & Result 值

类似与 Rust，因为我们没有异常系统，必须要有办法处理异常

Rust 拥有 Option 是为了不让所有引用类型都可能为空，Rust 为安全设计，而 Java 和 Kotlin 中引用完全可能是 null，InScript 支持没有意义

Result 方便处理错误，Lite 应该要有类似的东西，不过我觉得实现 Promise 即可替换掉 Result，所以解决方案变了。

using std.Promise

Promise.try(|>
  a = File.read('a.txt'))
.catch(Exception, |>
  # .....
)

Promise 会在 errno 被设置时「捕捉」异常，因为 InScript 是完全的 AST 解释器，Promise.try 对于每一个可能设置 errno 的语句都能进行异常处理（修改块对象）

+ statement processor

就像 ES6 的 decorator 特性一样

using std.Httpd

def Processor_get(path)
  Httpd.add_route(Httpd::Methods::GET, path, self)

@get('/')
def hello_world = "你好，世界！"

Httpd.run host: '127.0.0.1', port: 8080

+ String templating / interpolating

foo = gets
foo_bar = `$foo ${Bar::FOO}`

+ 箭头函数

fn = (a) => puts a

hello = |> puts 'Hello'

+ Hash 支持 [] 语法

a = 1
puts {
  [a]: '2333333'
  WWWwwwwW: a
}.to_s

+ InScript 的新模块化模式：scope、using、inscript.unload

require 'load_scope'

using LoadedScope # 导入作用域环境
# using load_scope.LoadedScope
# using load_scope/LoadedScope # 先 require 再载入

scope main # 默认作用域

puts foooo # 在本地作用域和作用域链上查找

inscript.unload :LoadedScope

+ Tail Call Optimization

InScript 支持尾调用优化，所以可以节省尾递归操作的时间

但是，这不是解释器自动实现的，我懒得做 CFA（控制流分析）

scope Algorithm

fibonacci = inscript.tco do |n, ac?, ac1?|
  ac |= 1
  ac1 |= 1
  return ac2 if n <= 1
  return fibonacci(n - 1, ac1, ac + ac1)

scope main
using Algorithm

fibonacci 2333

+ case 表达式，其实我提过不过没写

然后是 GeekApk，虽然现在可以说已经算是完成设计了，但是很不幸的是我又打算走懒惰道路，让 GitHub 平台托管 GA 了...
和上次的 GeekApkR 有本质区别，上次那个只能算是因为管理太没速度弄的，现在这个是完全不一样的实现

所以改名叫 GitApk，利用 GitHub/GitLab 的功能实现 GeekApk 的功能，而且大多数页面都是静态生成的

将会继续进行设计，目标是覆盖目前 GeekApk 的所有设计

GitLab 和 GitHub 应该都有能力做出 GeekApk 某些无法静态特性的高层抽象，比如 Follow，虽然他们自己是有实现，但 GitApk 打算不把他们的帐号信息直接作为 GitApk 的帐号信息

我最想首先支持的是 Gitea，GitLab 想部署要配置很好的硬件，GitHub 程序可能不开源

Gitea 应该完全有能力做这些抽象（比如收藏应用等
而且非常容易部署，适合 GitApk「生存」于其中

https://try.gitea.io/api/swagger
Gitea swagger API 管理器

GeekApk 也可以先用 Swagger 来写个 API 文档

在完全独立的 GeekApk 和完全依赖 Gitea/Gitlab/Github 的 GitApk 之间我觉得还是选择半独立半静态好
能静态则静态，不能静态则还是使用 GeekApk 服务

（算了还是全部依赖 Gitea 吧（他们的平台大（虽然还是我们自建 Gitea 服务

好处将是上来就有视图，而且更加简单，坏处是不够独立

将更多的事情依赖于 Gitea 上意味着更好的稳定性

验证、星标等就完全是基于 Gitea 的，GeekApk 就只是纯静态的，一切动态处理都交给 Gitea 的后端

😶 是
因为 Java 是强类型，所以 x 大概是数值型
x != x++ 应该是 true 啊

好耶