C++ Plush compiler (cplush) deprecation

[ashwanidausodia]

Some of the language keywords require whitespace after them. E.g. return 42; should be valid but return42; should be not. Currently Plush parser does not check for this. Allowing you to write code like

varmyvar = 10;
print(myvar);

var throwAwayTheArgument = function(f)
{
  return42;
};

print(throwAwayTheArgument(0));
throwAwayTheArgument(12);

Also it throws error when function name starts with any of the keywords like throw, return, var etc. Here in line throwAwayTheArgument(12);, Paser parses it as throw AwayTheArgument(12); causing an error ERROR: get_field failed, missing field "AwayTheArgument".

[krypt-n]

Is this about the parser written in C++ or the self hosting parser?

[ashwanidausodia]

The one written in C++

[Maaarcocr]

I may be wrong, but we should not have this problem on the self hosted version of Plush.

[krypt-n]

That's why I was asking. The comments in the self hosted version indicate that these cases were explicitily handled.

[ashwanidausodia]

@Maaarcocr @krypt-n I just saw the code. Self hosted parser handles these cases but one written in c++ does not.

[maximecb]

My goal is to deprecate the C++ parser once the Plush package can fully compile itself. Very close to that, but missing some small key ingredients. You could backport fixes from parser.pls to cplush if you like. Otherwise, hopefully within a month or three, we can fully replace the C++ parser.

[ashwanidausodia]

@maximecb There is no point in backporting the changes if it is going to deprecate. We should rather put efforts in making plush parser as capable as cplush. Can we keep this issue open until plush can parse itself.

[maximecb]

Sure. I'll take the opportunity to tell you what the current state of this is:

• I've been working on implementing serialization in the VM so that we can write generated code to test files (see /tests/plush/serialize.pls and /tests/plush/self_parse.pls). Serialization is currently working.

• The serialized/reimported Plush package doesn't quite work because it references functions in runtime.pls, which aren't available to it. I want to spin out the runtime into its own sub-package (lang/plush/0/runtime).

• I would like implement imports relative to the current source file, so that the Plush package (lang/plush/0/package) can import the runtime using a relative path (./runtime).

• I'm thinking that once package serialization and the Plush bootstrap is complete, we could have a ./zeta --compile <package_source> command-line option. This would serialize generated code after it's produced, instead of running packages. We can use this for the Plush package and the runtime, but also to precompile packages and reduce startup time.

[maximecb]

Tagged this for the MVP milestone. Getting rid of the C++ parser is probably something that needs to get done soon-ish, before we promote Zeta more actively, because I think people find it generally confusing that there are two Plush implementations.