About the "drifting" answers

[antfu]

I am glad to tell you the overhaul now compiles most of the scripts correctly(the basic examples, draw_trees). :)

However, while I am doing compatibility testing, I found out this line in 算經

https://github.com/antfu/wenyan-overhaul/blob/87d52352b372d70d88f128144b269e3aed612e80/packages/stdlib/lib/%E7%AE%97%E7%B6%93.wy#L46

In the current compiler, it will compile to

    const _ans28 = 引 + 1;
    const _ans29 = 基;
    const _ans30 = 實;
    const _ans31 = 合(_ans29)(_ans30);
    const _ans32 = 造表列(_ans28)(_ans31);

I would say it make sense in some aspect, but it's hard to read and understand without having good knowledge about the compiler internal mechanisms. Which I think should not be advised.

I would suggest changing it to this

https://github.com/antfu/wenyan-overhaul/blob/d01080a3e7d92a78d930d8eadae36902227d5cc5/packages/stdlib/lib/%E7%AE%97%E7%B6%93.wy#L103

The new compiler does not maintain a "drifting" answers list (i forget what's its name in the code), instead, it makes the relationship of variables static during AST generation. (and there is no need for 噫 as well). So I am wondering if we should drop this "non-intuitive" mechanism in the new compiler? Or if there is any reason to have this mechanism please let me know. :)

[LingDong-]

I am glad to tell you the overhaul now compiles most of the scripts correctly(the basic examples, draw_trees). :)

Wow great! So happy to hear!

So I am wondering if we should drop this "non-intuitive" mechanism in the new compiler?

Hmm... I think it is not that unintuitive, it is easy to understand if you think of it as a stack. you push things onto the stack, and use 取 to take things off it.

I agree that the way in the second example is more clear in situations, but maybe it's more like a coding style thing?

Not sure how the new AST generation works, but in your second example, it seems that you're still temporarily saving the result of 加一於「引」. How come it cannot be saved in the first example?

If there're major technical issues I think it's OK to drop it, but otherwise I kinda like the current mechanism :P Maybe point me to the section of the new code so I can take a look?

Thanks a lot!

[antfu]

Here is the result of the new one

In AST, I used nodes { type: "Answer", offset: 0 } to represent current _ans var. 取二以施「造表列」 will be parsed like

 {
      "type": "FunctionCall",
      "function": {
        "type": "Identifier",
        "name": "造表列",
      },
      "args": [
        {
          "type": "Answer",
          "offset": -1
        },
        {
          "type": "Answer",
          "offset": 0
        }
      ],
}

The main idea here is to decide the reference relationship on parsing so the transpiler can focus on transpiring.

If there're major technical issues I think it's OK to drop it,

No, it can be solved with some extra code, no worry. The reason I raise this up is that I see usage in this line of code from all the examples/stdlibs, so I was wondering if this should be considered as an edge case. But yeah, I think stack is the spirit of wenyan-lang, let's have it :)