希望语言精心设计，不急着发布正式版

[rhymecoding]

star, 加油

[dou4cc]

教程页的自适应好怪，请问是怎么设计的？

[zhanzhenzhen]

呵呵，是的，这是我n年前弄的一个东西，叫做site，目标是消除像素，全部用矢量。不过最近由于在弄FutureScript，这个就没有更新，至今只在我的网站中内部使用。

[dou4cc]

正方形审美不适合阅读，求改，移动设备完全看不下去！！

[zhanzhenzhen]

刚用平板看了一下，的确体验不是很好。 这几天在改进架构，没有新增功能，新架构使编译器能够在浏览器中运行，现在可以直接在教程页面运行代码了。 后面我会实现异步，还要让教程页面的编辑器实现彩色。网站的布局也会优化的。

[dou4cc]

0.4.0

plus: a->b->c->a+b+c
#console.log (plus 1 2 3)
console.log ((plus 1) 2) 3

写了个柯里化的plus，却发现注释里的代码报错，要写成下一行，感觉不爽。请问FuS是否打算支持柯里化？

[dou4cc]

建议把js"命令改成函数，这样就可以：

0.4.0

code: "alert()"
js code

或保留eval。

[dou4cc]

也许保留eval更好，因为eval根本封不了，是大自然的规律：

0.4.0

window.eval "alert()"

[zhanzhenzhen]

@dou4cc:

1. 那种柯里化形式其实我觉得只适合参数确定的静态语言，而我们的是动态语言。另外我觉得柯里化本身可读性并不是很好，我想了个或许是更好的办法，但现在不能公布（增加一点神秘感）。我的计划中有几十个将来可能会加入的功能，柯里化的替代品是其中之一。
2. 动态插入JS，这个性能就很差了，但也可以实现，靠fus-ext就可以。以后fus-ext应该会加入非常多的功能，像这个，还有数组、对象的处理，underscore的大多数功能，各种杂七杂八的功能，都可以写在其中。语言本身只应该实现fus-ext实现不了的东西。

[zhanzhenzhen]

当前首要问题还是实现异步。

[dou4cc]

我觉得一段静态JS可以单独成为文件，很好奇为什么需要插入在一大段FuS中。

[dou4cc]

很多人用ES7写出如下代码：

async function fun(){
  let info=await getInfo();
  //此处省略很多代码
  element.value=info;//这里才第一次使用info
  //此处省略很多代码
}

实际上该这么写：

async function fun(){
  let info=getInfo();
  //此处省略很多代码
  info=await info;
  element.value=info;//这里第一次使用info
  //此处省略很多代码
}

否则fun的上下文会被getInfo白白卡很久，而后一种写法很丑。建议FuS把前一种写法编译成后一种。

[zhanzhenzhen]

因为await是阻塞式的，所以不能这样编译，否则要乱套了。异步函数的特征就是用“同步”的语法，同步的特征是什么？就是阻塞式。“异步”指的是从异步函数外部来看，不是从内部来看。

[dou4cc]

逻辑清楚就可以避免混乱。

[dou4cc]

async function的目标是用同步代码实现异步，不考虑Promise的内部实现。但当要进行的异步操作可以并发，却不得不手工写出异步的并发流程：

//request是个向服务器获取数据的函数
async function fun(){
  let [a, b, c]=await* [request('a'), request('b'), request('c')];
  //此处省略很多代码
}

这更该让编译器来做。

[zhanzhenzhen]

await*这种语法我昨天才知道，好像不是ES7的，有人说可以用await Promise.all代替。我们先实现简单的ES7式的异步，复杂的以后看看有没有必要

[dou4cc]

我想再举个例子让zzz体会一下这种支持的必要，及ES7的不合理：

'use strict';

//request是个向服务器拉取数据的函数
async function fun(){
  let urlA;
  let urlB;
  let urlC;
  //此处省略n多行求urlA的耗时代码
  //此处省略n多行求urlB的耗时代码
  //此处省略n多行求urlC的耗时代码
  let [a, b, c]=await* [
    request(urlA),
    request(urlB),
    request(urlC),
  ];
  //此处省略很多代码
}

如上代码白白浪费了可用于请求的计算时间，而唯一的改法很丑：

'use strict';

//request是个向服务器拉取数据的函数
async function fun(){
  let urlA;
  let urlB;
  let urlC;
  //此处省略n多行求urlA的耗时代码
  let a=request(urlA);
  //此处省略n多行求urlB的耗时代码
  let b=request(urlB);
  //此处省略n多行求urlC的耗时代码
  let c=request(urlC);
  a=await a;
  b=await b;
  c=await c;
  //此处省略很多代码
}

[dou4cc]

zzz是回老家过年暂时停更了吗？

[zhanzhenzhen]

没有没有，前天刚做完异步，之所以没有放出来是因为还在弄网站的编辑器，我要让编辑器可以加载underscore和lodash，这样能更好地体验。新版本应该马上就可以放出来。 最近发现Apple的iCloud收邮件很成问题啊，经常不会自动收邮件，hotmail至少还能每15分钟收一次呢。按理说Apple是支持IDLE命令的，真是奇怪。

[zhanzhenzhen]

@dou4cc: 关于你说的异步性能问题，我理解你的意思，就是利用请求的时间来做运算。我前几天想了下，可否使用嵌套方式来解决，在JavaScript中可以写成：

async function fun(){
    let [a,b,c] = await* [
        (async () => {
            //此处省略n多行求urlA的耗时代码
            return await request(urlA);
        })(), (async () => {
            //此处省略n多行求urlB的耗时代码
            return await request(urlB);
        })(), (async () => {
            //此处省略n多行求urlC的耗时代码
            return await request(urlC);
        })()
    ];
    //此处省略很多代码
}

当然，这仍然显得不太好看，这是由于JS的语法所限，改用fus的话就可以用do，并省略return、async，会更好看些。不过上面的代码我没测试过，就提出个概念而已，我对await*也不熟悉，没用过。

其实我觉得用node来做真正阻塞的事情，像是CPU运算，似乎应该避免的，记得国外谁说过。

[dou4cc]

不用黑魔法，不调API，只做数值计算，JS的性能和优化过的C++没有数量级的差别。 有人做过测试：https://www.web-tinker.com/article/20374.html

[dou4cc]

看到教程页编辑器里的示例代码用了FuS自己的Ajax API，请问zzz还想重构那些特性？我觉得JS的fetch已经很好，FuS如果不借助JS的生态，工程会很浩大。

[zhanzhenzhen]

其实也不是很浩大，像lodash这类10000多行的库我不可能去和它硬拼（我个人风格是喜欢创新而不愿意去硬拼），我也不想去弄这么大的规模。这个只是扩展包而已，不强制使用，所以其实也没有脱离JS生态，人们完全可以使用underscore、lodash、request，只是选择的范围更大了而已。也可以既使用fus-ext又使用其他，都没有问题。

其实web的功能是从我n年前的一个项目mate中移植过来的： http://zizisoft.com/mate https://github.com/zhanzhenzhen/mate

但mate使用的技术现在看来不太好，作用于全局，有副作用。所幸在fus里面可以用管道了，所以可以把很多功能都移植过来而不带来副作用。你看看mate的规模，其实也并不大。1000多行而已。但是涉及到方方面面，属于麻雀虽小但五脏俱全的。所以未来的fus-ext和那些著名的类库可以是形成互补。

[zhanzhenzhen]

对了，过几天，就会有更好的编辑器。你有这个疑问其实部分原因是编辑器我还没弄好。

[dou4cc]

fetch是浏览器原生API，完全Promise化。 教程：http://javascript.ruanyifeng.com/bom/ajax.html#toc29

[dou4cc]

用await*写代码不主要是丑，要赋的值离变量太远影响阅读。而且await*层数分多以后代码会横向发展。

[dou4cc]

--真是个神奇的东西，经典语法里它是自减，Haskell里它是单行注释，到FuS里变成了匿名函数。

[zhanzhenzhen]

呵呵。。。

[dou4cc]

建议教程页加缓存，否则每次打开都要Downloading一会儿。

[zhanzhenzhen]

已能用平板正常浏览，但得横屏，竖屏将出现提示信息。

[zhanzhenzhen]

这个issue的标题是关于版本。我想说一下我对semantic version的看法。

我发觉它有个大问题，很可能会导致这个模式将死。这就是，随着dependency数目的增加，可靠性会出现下降，除非完全锁死版本。

这是因为，只要是人，都是会犯错误的。他即使想让1.2.0版和1.1.0版完全兼容，仍然有极小的几率（例如1%）他的代码有bug，导致愿望落空。那么按照此几率，当你所有dependency数目达到100个（包括间接的）之时，你运行npm update后无法正常运行的可能性就超过50%。有解决办法吗？没有，除非所有直接间接的dependency都完全限定版本号。而如果完全限定版本号才更合理，那把版本分解为3个数字就没有意义。

所以，我很想让我所有未来的package都使用一种更为激进的版本策略，就是minor和revision都设为0，只有主版本号有意义。哪怕是修复bug，也要使主版本号加1。只有当修复从前版本的bug时，才可以让minor加1。这个策略的妙处是它和semver兼容。

好处： 数位更短。在semver中，很有可能出现10.12.1，有5位数字。但实际上可能只是第57个版本。哪种更好记？显然是后者。算一下，即使一个月发布一个版本（到了后期不可能这么密集），3位数可以用80年。

当然这个策略过于激进，所以打算n年后第10版发布之后导致版本号数位太多时再使用。

[dou4cc]

@zhanzhenzhen 语言的版本本来就不是按semantic version起的。ECMAScript的版本号只有一个数，C++的版本号是年份。