fix issue #406, and add escape new line support.

[pigpigyyy]

When coding with MS, some statement may become too long, add support for \ to escape a new line in the line break will help separating codes into multiple lines. Fix issue #406 along with this PR.

[leafo]

I would prefer not to have backslash for breaking lines.

• If there's a need to break lines it's typically around an binary operator, which means a linebreak could be allowed without introducing ambiguity
• Backslash is already an operator in MoonScript, I do not like the idea of it taking on a new purpose. (Note: I am aware of its purpose in strings, but I consider sting character syntax to be a nested sub language)

I think we should collect common instances where a break is desired, and look a the line and think about how operator parsing can be changed.

[pigpigyyy]

You're right. Explist could handle line break by itself. But backslash can be used after function name or used to write lines start with operator.

some_long_named_function_call_one \
  some_long_named_function_call_two \
    some_long_named_function_call_three 123

->
  a = 1 \
    + 2 \
    + 3 \
    + 4

  a, b \
  , c, d \
  , e, f

->
  -- currently, inserting `White` rule before `Exp` in the ExpList and ExpListLow
  -- can support this syntax, but `InvokeArgs` rule behavior will be affected.
  a, b,
  c, d,
  e, f

[leafo]

Here is how I recommend writing your examples using currently valid code to avoid overloading the \ operator.

from

some_long_named_function_call_one \
  some_long_named_function_call_two \
    some_long_named_function_call_three 123

to

some_long_named_function_call_one(
  some_long_named_function_call_two(
    some_long_named_function_call_three 123
  )
)

(I know this doesn't have the same feel, but I believe that newlines for function invocation starts to introduce enough ambiguity where I feel the developer should just start being explicit, or don't write such long lines, it's part of the reason why you currently can't invoke a function with a newline and an indent.)

from

  a = 1 \
    + 2 \
    + 3 \
    + 4

to

  a = 1 +
    2 +
    3 +
    4

from

  f a, b \
  , c, d \
  , e, f

to

  f a, b,
    c, d,
    e, f

(the fact that we currently can't use , and newline with return statements is probably an oversight)

[Sod-Almighty]

Today, I discovered Moonscript. I thought to myself "hey, that looks neat, but before I invest hours and hours of my time into learning and using it, maybe I should check it's still being maintained."

So what I'm seeing here is, the project maintainers are either dead or don't care about the project anymore. Issues go completely ignored for literally more than a year. Doesn't really inspire confidence in this buggy garbage, frankly.

[leafo]

Today, I discovered Moonscript. I thought to myself "hey, that looks neat, but before I invest hours and hours of my time into learning and using it, maybe I should check it's still being maintained."

So what I'm seeing here is, the project maintainers are either dead or don't care about the project anymore. Issues go completely ignored for literally more than a year. Doesn't really inspire confidence in this buggy garbage, frankly.

Don't be a jerk or you'll be banned from our GitHub page.

MoonScript is very stable, and does not require any substantial changes at this time.

[Sod-Almighty]

Stable? I count a dozen bugs in the first two pages of the issue tracker alone.

[leafo]

Stable? I count a dozen bugs in the first two pages of the issue tracker alone.

@Sod-Almighty All software of any complexity is going to have bugs and feature requests. There's nothing critical outstanding that prevents the usage of the software as described in the documentation.

[Sod-Almighty]

So the fact that the compiler apparently crashes when given certain pieces of valid code is not critical?

Sure, all software has bugs. It's not the presence of bugs that concerns me. Rather, it is the fact that these bug reports have been completely ignored for almost two years. Not only aren't you fixing them, but there are also a dozen ignored pull requests, so you're not letting other people fix them either.

When defects, support requests and submitted fixes are ignored for years, what reasonable conclusion could I possibly come to other than "the project is dead"?

[leafo]

@Sod-Almighty I just want you to keep in mind, with a programming language project a lot of changes are both subjective and can have wide reaching impacts outside of their intended effect on things like how code is structured internally, changes to performance, conflicts with changes I might have planned, and unintended side-effects to parsing due to changes in precedence/ambiguity. Because of this, my stance on developing this project is to be incredibly conservative about changes that may affect those things. I have many large scale projects that depend on MoonScript and it's more important to me that those projects continue to work as intended instead of trying to introduce changes here that may cause breaks. I'm sorry the pace of development here doesn't match whatever gave you your expectations.

Admittedly, as you have noticed, I tend to leave requests and issues open. It's a lot of work to go through them and there are good ideas in there. One day if a particular area is tackled then an issue can be officially closed or used in some way. In the meantime, I don't see it any harm to leaving them there as a reminder of things that could be worked on.

So the fact that the compiler apparently crashes when given certain pieces of valid code is not critical?

Practically speaking, not really. In the most common invocation, compiler exits regardless whether is completes it's job or not. It can have a successful run with compiled code, or it can fail to compile due to a malformed or ambiguous input. Generally we should have helpful error messages and account for all kinds of invalid inputs, but if a particular rare input causes a runtime exception it is not the end of the world as these types of errors are recoverable in a dynamic language like Lua.

To circle back to your original complaint about this project being "dead": The phrase "dead" with regards to software projects is kinda subjective. I think you're implying that if something is "dead" it shouldn't be used, and using that as an opportunity to be unnecessarily aggressive and rude by throwing harsh statements like "buggy garbage." I honestly don't really know what you are trying to accomplish with your original post, other than potentially trying to feel better about yourself by insulting the work of others.

I acknowledge that pace of development has not published any substantial updates in quite some time, but I do not consider it dead because 1. It is accomplishing the goal it intended to accomplish and 2. This project supports possibly a million lines of MoonScript code in various critical projects that I'm very still actively developing.

Hope that helps

Note: I'm locking this issue because this discussion is off-topic