odenix

> The lookahead here seems easy to me. Arbitrary lookahead can cause problems with syntax highlighters and parser tools. It can also cause performance issues. It’s best avoided if possible....

> No, it's because expressions are not permitted at the module level. But if typed objects could have elements, it would make a lot of sense to allow expressions (elements)...

> Or... should that ambiguity should syntactically be disallowed and should this require that properties are aggregated in notation, This might be a good first (and possibly last) step. Good...

I think the problem is that Truffle 24+ doesn't support older Java versions. I have some ideas on how to support a wider range of Java versions *and* avoid getting...

@zaninime What's blocking the jump is that Pkl supports JDK 17+, whereas GraalVM 24 requires JDK 21+.

I haven't heard an official statement, but Pkl only raised the baseline from 11 to 17 a couple of months ago. Without any changes, Pkl will always stay years behind...

I think there should be a Java language binding, eventually superseding pkl-core, that enables Java users to transparently run the Pkl interpreter as a Java library, native library, or external...

> How would a user on an incompatible Java distribution use the Java library? Does this mean they would need to spawn a sub-process like we do in pkl-go and...

> including the fact that our native library/executable is slower than Pkl run directly on the JVM If we're talking about a regular JVM here (not GraalVM), this indicates that...

I’ll send a PR that fixes both of the bugs reported here.