TASK: EEL use external ECMAScript php parser `mck89/peast`

[mhsdesign]

this is based on the assumption that any EEL written is 100% valid ECMAScript but not the other way around, which is fine. (ECMAScript ≈ JavaScript)

as discussed in the may sprint: https://codimd.cloud.sandstorm.de/qtm34AEiSc-DkqzWvUq6Kw the idea is to replace the old generated eel parser with an external ECMAScript parser for php.

This has the benefit that

1. we dont need to rely on a parser generator from 10 years ago (we use this 2012 fork https://github.com/skurfuerst/php-peg and i coulndt find an active branch of the original https://github.com/hafriedlander/php-peg)
2. we get from the parser AST object nodes which are better to handle than the current arrays a. so the php transpiling process becomes more readable
3. we dont need to maintain and test the ECMAScript grammar

I found this library which looks perfect from first sight: https://github.com/mck89/peast we can even parse super modern es2022 and other targets so we are good to go for the future ;)

Steps to archive this goal:

• performance benchmark the current parser and mck89/peast (without php transpilation, just the ast parsing)
  • would be to bad if we find out at the end that the current parser is way faster.
• ...

[mhsdesign]

well i found one case where my thesis is proven wrong:

this is based on the assumption that any EEL written is 100% valid ECMAScript but not the other way around, which is fine.

currently this is valid eel: () => {"key": "value"} and will return the object {"key": "value"} but javascript will interpret the braces as actual function block opening.

to archive the same in javascript one needs to wrap the object declaration in parentheses: () => ({"key": "value"})

However, this can also be considered a bug. In fact, the current eel grammar will allow some other small things that would be of no use and happened accidentally but conflict with the ES standard.

[mhsdesign]

found another catch:

in eel: a valid identifier can contain dashes:

so this is a variable name 😂, and when you append () its a function ${ c6afd34f-d852-459e-9890-3ddf28b84fb2 }

this is not possible in JS

[fcool]

An actively maintained fork of the current php-peg would be: https://github.com/smuuf/php-peg

I used it in several projects, where I needed own DSLs and it never let me down.

That does not mean, that I a have a really strong opinion against replacing it, but at least I'm not convinced that mixing of languages is a "brilliant" idea.

[manuelmeister]

I would 100% vote for an parser that builds up on ecmascript. Otherwise I would remove the mention of javascript in the docs.