Replies: 3 comments
|
Mago is a great project, but parsing is a relatively small part of what Elephc does. Most of the complexity lies in semantic analysis, type checking, ownership and copy-on-write behavior, EIR lowering, the runtime, ABI handling, and native code generation across all supported targets. Elephc also implements a deliberately static subset of PHP together with some compiler-specific extensions. Using Mago would therefore not remove most of the compiler work; it would mainly replace an already working frontend while introducing an adaptation layer between Mago’s representation and Elephc’s compiler pipeline. A stable Rust API in Mago 2.0 would certainly make embedding it safer, but it would not materially change that trade-off. At the moment, I do not see enough benefit to justify rebuilding Elephc’s frontend around it. |
|
Thanks for the response and amazing work man |
|
Thanks a lot. I dream of a day when we will have a game engine written in PHP :D |
Uh oh!
There was an error while loading. Please reload this page.
I am very curious to know why this project doesn't use Mago as its base. I might be missing some context and they may just serve different needs, but it seems like a solid foundation.
In version 2.0, they promised a stable Rust API. Would that enable it to be considered as an option?
All reactions