Li Jin

The two problems you mentioned is currently intended. The macro expanded in the middle of a code block, will be treated as a `do` block without an extra variable scoping....

It is a syntax precedence problem. To support syntax like: ```moonscript readFile "example.txt" |> extract language, {} |> parse language |> emit |> render |> print ``` The multiline pipes...

I think it is better to explicitly write the Yuescript statement that affect the rest codes in the same scope, like `global *`, `local *` and backcall statement ` object,...

In the current Yuescript compiler the orignal code: ```moonscript f * a |> b ``` is just seen as: ``` [expression][newline character] [advanced indentation][pipe expression] ``` And there is no...

It's intended behavior in Yuescript. I forced the comment to follow the code indent or an advanced indent. You can find the syntax rules here. https://github.com/pigpigyyy/Yuescript/blob/e66f56215614c4e1995d1e4369b01b0ebc7131b2/src/yuescript/yue_parser.cpp#L842-L846 The mis-indented comments have...

Wow, it is the expected usage for Yue macro functions. Doing code generations or executing some building workflows through Lua during the compile time. The zig code generation seems a...

There are now four valid cases conflicting with binary operators at the start of newlines. ```moonscript do a = value :abc do a = value -1 |> f do a...

Just did some tests, the correct command can be with double quotes. ```sh yue --target=5.1 -s -t "D:\path with spaces\Yue" yue\ ```

I'm currently using a pretty print function taken from Moonscript's library. You can use it as: ```moonscript import "yue" as :p foo = "bar" tb = {1, 2,3, abd: 123}...

added option `yue -c` to reserve some comments before statements, like ```moonscript ---@param a any ---@param b any ---@param c any f = (a, b, c)-> ``` But not sure...