> On Jan 8, 2020, at 4:25 PM, Mike Schinkel <m...@newclarity.net> wrote: > >> On Jan 8, 2020, at 11:10 AM, Robert Hickman <robehick...@gmail.com> wrote: >> >> My suggestion was not a preprocessor, but what others have said >> already, a 'shim' that goes between the parser/lexer and bytecode >> generation which allows user code to inspect and modify the AST. This >> idea is not unusual and Python for example can do this. The idea is >> the basis of macro systems in Lisps, and Rust has a very nice >> implementation of it from what I've seen in passing. The system should >> be fully aware of the syntax, scoping, namespaces etc, the lack of >> which is the problem with C preprocessor for example. >> >> With regards to how JAI does this: >> >> https://www.youtube.com/watch?v=UTqZNujQOlA >> https://www.youtube.com/watch?v=59lKAlb6cRg&list=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO&index=20&t=0s > > Nice!
I replied prematurely. OMG, JAI's ability to run code at _compile time_ is incredible, and exactly the kind of thing would solve the concerns about dynamic instantiation of constants. It would also solve a large class of performance concerns, way beyond just dynamic instantiation of constants, as well as allow us to implement really robust error checking assertions into our libraries. Which makes me wonder the following: AFAIK PHP opcodes are not something a developer can handle; they are only handled by PHP itself. IOW — correct me if I am wrong — but PHP _cannot_ generate an OpCode file to disk that can be named and later loaded by a different PHP app? The only thing similar to this is PHAR, which AFAIK is not OpCode, right? If not, how about we discuss about creating a full API to allow developers to compile to OpCode files and then load and run them? In addition to exploring this run PHP code to generate OpCode before the page load actually runs? -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
