panda
panda copied to clipboard
Replace Javassist with ASM
Hi! Sorry to bother you. Are you trying to use ASM instead of Javassist for performance reasons? [ASM is lower level than Javassist (which still uses ASM under the hood anyway) ]
Hi, well, ASM library is just smaller (should be like 200kb instead of 750kb) and doesn't have to compile string based java-like code to generate classes, so it may improve the parse time. Also, the Javassist 3.x is not based on asm library.
Yeah. ASM is more lightweight, powerful and is considered the industry standard, being used to build languages like Kotlin, Scala, Panda :wink: etc.
Kinda, but it requires from user precisely defined target, so it is not as good as javassist to prototype some behaviours. I'm still trying to figure it out how to properly find a balance between generated bytecode and abstraction of this interpreted language 😳
Have you tried desugaring your Panda program? This means you can have all the abstractions you want and the interpreter can handle generating bytecode from the desugared syntax.
EDIT: Desugaring basically means you remove all abstractions and make your language easier to compile/interpret/generate Bytecode etc.
It's not this kind of problem. If I'd like to generate full bytecode for whole app, I could just do that and forget about the problem. It's more about overall design and the way how language works in situations like Java interop, preserving the abstraction for further feature expansion. I'm still not decided in this field and it's why it also irritates me 😶
If you are going with Java interop, what is your main focus? To call Java libraries/API into panda? Or, do you want to call Panda files from Java?
The former is relatively easy, the latter though, you have make sure your bytecode is on point. If you want both, that is, completely smooth interoperability between Java and Panda, it helps to take a look at other languages that have already implemented this ( ex. Kotlin ) for inspiration.
Yeah, I'm pretty sure that I'm the problem in this case due to my indecision. At this moment I don't want to maintain bidirectional support, so the most important thing is to provide smooth backend for Panda to access all of the Java sources. It's something what already works, but the implemention is such a mess because of the legacy and various concepts in the past.
Then, in this case, all you need is a small cleanup. Can’t wait to see the result! 😝
Yeah, me too. It's probably why the development process is such a fun to write with all these different ideas. It's not only just reproducing another language, but it's all about experiencing a new "world" if I can say that. It's hard to disagree if I tell you that in indev phase, parsers where handled by builtin dependency injection api with runtime code generation of callbacks to improve the performance of interpretation xD
parsers where handled by builtin dependency injection api with runtime code generation of callbacks to improve the performance of interpretation xD
O_O That's a lot to take in.
Then again, about the "referencing Java API" bit, are you going for a reflection based referencing or are you implement something like an import
system?
- Reflection can help in easy loading of Java libraries but it will come at the cost of compile time (interpretation time in your case)
- An import system, on the other hand, makes for easy interpretation but will throw an error if the user misses an import.
EDIT : On an unrelated note, you should update the README's panda
code snippet to reflect the current language state (because you did lots of changes by removing the module
keyword and changed the class
keyword to type
).
Panda uses Type
to operate on types. When you reference Java API through import
/export
keyword or any other generation method, the Class
is just mapped to Type
. It's because I didn't want to operate on standard Java classes by default due to the lack of possibility to extend such a structure.
Types are also wrapped into Reference
to support some kind of lazy loading to avoid generating like thousands of types at once. Interpretation time is also problematic because of the way how JVM works, but it's yet another topic.
Yeah, README is kinda a mess (#635), I'm going to update it for beta release.
It seems you have everything figured out!
I'll come back here soon enough to find out how Panda 0.5.0-alpha
looks! All the best! ;)