Rust Implementation

[aspizu]

Hey, I want to try writing a rust implementation. Could you explain the parts of the core?

[holzensp]

Are you talking about language bindings for Rust, or a re-implementation of the language in Rust? If the former; take a look at pkl-swift or pkl-go. If the latter; please ask a few more directed questions.

[holzensp]

@aspizu is saying sensible things. There is a lot more going on than just parsing when you want the data out of a Pkl file. But also, rewriting data from one format to another is exactly Pkl's core strength. I think that if Pkl can't produce your XML format, your format isn't actual XML (but I may be wrong). If it's normal XML, but following a specific schema, I'd also do the rewrite in Pkl. Worst-case, I'd let Pkl generate its standard XML output and XSLT to transform it to the target I want.

[adaflexer]

Thank will start to check everything and consider transforming to YAML /JSON. We have already the generators written in python. It takes input from textx based DSL Files and transforms to Schema based XML File. We want to try and see if we can use PKL and eliminate textx based language.

[aspizu]

Does pkl perform any kind of JIT or compilation?

[holzensp]

It piggy-backs on the JIT facilities of the JVM when run on the JVM. For the binary, it uses GraalVM's AOT compiler to sort out optimisations.

[bioball]

Pkl code itself is also JIT-compiled, thanks to being implemented in Truffle. Truffle (and GraalVM) is some pretty neat technology. Here's a video about Truffle in case you wanted to learn more:

https://www.youtube.com/watch?v=SYg4KO8Z2Ts

[zaxebo1]

@aspizu
pkl is a great configuration language.
And your idea of reimplementing it fully in rust is even-greater.
thousand Github stars to your future repo in advance from my side.

[akdor1154]

I did go looking for a rust implementation, not for any special love for rust, but because what I really want is a wasm implementation I could run in-browser. If the native builds could output a wasm target I'd be over the moon, but it sounds like this could be fiddlier than it sounds?

[aspizu]

A rust implementation would be wonderful as its very easy to compile to WASM, I'm doing it for my other compiler project and its working great.

[odenix]

If you’d like to see a Pkl WASM implementation, make sure to upvote this issue: oracle/graal#3391

[sandstrom]

@holzensp I know it's a large undertaking (but easier today with LLMs), but are there any plans to re-implement pkl in Rust?

When it comes to language bindings, most other programming languages usually have good facilities for writing bindings to either C/C++ or Rust code.

For example, I looked a bit at bindings for Ruby, and it's probably doable, but would have been easier if pkl was written in C/C++ or Rust.

[donbeave]

I have not seen this repository mentioned in the thread, so I wanted to add it here:

• Repository: jdx/pklr
• Release reviewed: v1.3.0
• Description: a pure-Rust Pkl parser and evaluator

This appears to be a real independent implementation, rather than Rust bindings around the official evaluator or a wrapper that shells out to the pkl executable.

The crate contains its own lexer, parser, evaluator, runtime value representation, import resolution, resource access abstraction, and diagnostics. Its primary API evaluates a .pkl module directly into a serde_json::Value, without requiring an external Pkl installation.

What is already implemented

Based on the repository, tests, and changelog, pklr already covers a substantial amount of the language and evaluator:

• lexer, parser, and evaluator written in Rust;
• local, HTTP, and selected package:// imports;
• amends and extends;
• classes, inheritance, super, this, and outer;
• open classes and property modifiers such as hidden, const, and abstract;
• object amendment and late binding;
• type aliases, constrained types, and is/as;
• annotations;
• string interpolation and raw strings;
• lambdas and higher-order collection methods;
• glob imports;
• read() and read?();
• durations, data sizes, NaN, and Infinity;
• output renderer converters;
• parser-only and capability-backed builds;
• rich error diagnostics.

The changelog shows that it is actively being developed and is already used as the default embedded evaluator by hk.

Therefore, calling it only a parser, an early experiment, or a thin partial implementation would be unfair.

Is it a complete Pkl implementation?

My conclusion is:

pklr is a substantial native Rust reimplementation of Pkl's parser and a broad evaluator, but it is not yet a fully Pkl-compatible runtime or a drop-in replacement for the complete official Pkl implementation and toolchain.

There are several reasons I would avoid describing it as “complete.”

Its own ecosystem documentation says compatibility is incomplete

The hk documentation says that pklr may not yet support every Pkl feature and recommends falling back to the official CLI.