Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

Post reply on HN
Print view View original

171–180 of 598 posts

Re: Pkl, a Programming Language for Configuration

#171

Post by lijok »

laserlight wrote: post #63
lijok wrote: post #21

Earlier quoted context omitted.

> For example, something like: "this number is be between 1 and 10" means you have to come up with a novel way to add validation, because it isn't built into the language. No need for a novel mechanism - there are plenty of available solutions to add validation to python > imagine telling a Go developer that they need to install Python Pkl doesn't come preinstalled on machines - so you'll have to install it as well >…

> This is the real friction point, but is it a bigger friction point than having to adopt yet another DSL? Yesterday, I created a virtualenv, then ran `pip install`, only to see it fail. I found out that even `pip --version` was failing. I discovered that running `python -m ensurepip --upgrade` would fix pip. It did fix pip, but `pip install` still didn't work properly. I figured out that pip was reporting a differen…

Did you activate the virtual environment?

For all the flak python gets, dependency setup is pretty simple if you're not flailing around aimlessly

  python3.12 -m venv --copies --clear --upgrade-deps ".venv"
  source ".venv/bin/activate"
  python -m pip install --upgrade pip setuptools wheel
  python -m pip install --editable .

Re: Pkl, a Programming Language for Configuration

#172

Post by the_duke »

4ad wrote: post #162
the_duke wrote: post #161

Earlier quoted context omitted.

I really like CUE, but for most use cases I have I would want to embed it in an application, and Go is the only language with support. For it to gain more adoption it really needs a rewrite in a low-level language (C/Rust), so it can be exposed in various languages through an extension/FFI.

Making CUE available as a library for other languages is one of our top priorities. Sadly, I can't provide an ETA at this time, all I can say is that I am personally working on this. Getting feedback from the community about what other languages they'd want supported first would be of massive help, however.

> Getting feedback from the community about what other languages they'd want supported first

Rust and Python would be my top picks.

Re: Pkl, a Programming Language for Configuration

#173

Post by lijok »

IshKebab wrote: post #76
lijok wrote: post #8

Serious question - why not just use python?

Python would be a terrible choice for this. * It's been dragged into static typing kicking and screaming. * You import the whole Python infrastructure/packaging catastrophe. * It's not sandboxed. If you wanted something Python-like you would you Starlark.

Which of these problems outweigh the complexity of onboarding a new language to an organization?

Re: Pkl, a Programming Language for Configuration

#174

Post by pdpi »

jgrahamc wrote: post #107
grashalm wrote: post #79

Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources! https://github.com/oracle/graal/tree/master/truffle Disclaimer: graalvm dev here. Edit: typo

> Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. What now?

As I understand it:

GraalVM is an alternate JDK that can, among other things, do ahead-of-time compilation for Java.

Truffle is a framework for building languages, that sits on top of Graal.

Futamura Projections are a particularly interesting use case for compile-time partial evaluation.

With partial evaluation you have static (known at compile time) arguments to your function, and dynamic (known at runtime) arguments.

When “your function” is an interpreter, and your static arguments are source code, the output is effectively a self-contained compiled binary.

When your function is an interpreter, and the static arguments are the source code for the interpreter itself, that “self-contained compiled binary” is now itself a compiler.

Re: Pkl, a Programming Language for Configuration

#175

Post by ithkuil »

grashalm wrote: post #79

Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources! https://github.com/oracle/graal/tree/master/truffle Disclaimer: graalvm dev here. Edit: typo

Futamura

Re: Pkl, a Programming Language for Configuration

#176

Post by bladehaze »

devmor wrote: post #111
reactordev wrote: post #88

Is this a joke? Why? We have so many usable formats already. Every language can do JSON. What problem does this solve? Or is this another Apple solution to a problem that doesn't exist?

I do not find this particularly interesting because the problem has been solved by several projects already, but this is a programmable configuration file. i.e. you can write code statements and it transpiles down to other formats

I kinda think we haven't solved this yet. Sure, this essentially is to generate a text file from another text file of parameters and code, which becomes our new configuration file.

Then there is need to generate that new configuration file as things getting complicated.

The current approach (of all these current languages, pkl looks like is the same) is to painfully refactor the ones you want to change to a parameter file, i.e. a manual data/code separation and you template that.

It would be nice just say this configuration file is now a template file with A B C fields as parameters, and load it up in our new configuration file for templating with good trackability and performance.

It is also easy to migrate to other languages, as configuration now can turn into code cheaply.

Re: Pkl, a Programming Language for Configuration

#178

Post by steve1977 »

rcarmo wrote: post #137
steve1977 wrote: post #96

Earlier quoted context omitted.

Noticed that as well... I guess not even Apple wants to use it anymore, oh my...

The services teams at Apple are more agnostic than what you’d think.

In the not-eating-our-own-dogfood sense?

Re: Pkl, a Programming Language for Configuration

#179

Post by neongreen »

ratorx wrote: post #142
neongreen wrote: post #121

Earlier quoted context omitted.

There are three (maybe more?) ways things can be Turing-incomplete: 1. You are limited to N evaluation/reduction steps. 2. The language doesn't include primitives like recursion or loops. 3. You can have recursion or loops, but the language makes you somehow prove that your program will terminate. I think (1) would be fine, but I don't know any configuration languages that use this approach. (2) is restrictive/annoyi…

I think 2) seems incorrect. What you can’t have is unbounded loops and recursion. Bounded loops are perfectly fine and I don’t tend to need unbounded ones when programming (with exceptions being infinite loops for handling asynchronous events, which a configuration language doesn’t need to do). Recursion is trickier. I think banning it or simply limiting stack depth seems fairly reasonable? In fact I’m pretty sure mo…

> I don’t see why HTML escaping needs Turing-completeness.

First of all, let's avoid "Turing-completeness" because then we might start arguing about whether a language with unrestricted recursion is or isn't Turing-complete since there are stack depth limits / memory limits / universe will end one day / etc.

I would phrase this question as "why would HTML escaping need unrestricted recursion or loops" -- since in practice config languages either have unrestricted recursion or loops (Nickel), or they don't (CUE, Dhall, Starlark).

For HTML escaping specifically, just having `.map(f)` and `.concat` available (in functional languages), or `for char in string` (in imperative languages), would be enough.

For something like HTML un-escaping, it's already trickier. If you are using recursion, your language needs to understand the concept of the string becoming "smaller" at each step. If you are using loops, `for ... in ...` is not enough anymore.

An even trickier example would be mergesort:

  merge(xs, ys) = ...

  mergeSort(xs) =
    let len   = xs.length
        left  = mergeSort(xs.slice(0, len/2))
        right = mergeSort(xs.slice(len/2, len))
    in merge(left, right)
It might seem obvious that this should terminate, because of course `.slice` will return a smaller array, but the actual termination proof in Agda is already something I wouldn't want in my config language: https://stackoverflow.com/a/22271690/615030>

(Not to mention that this implementation is faulty and will loop at len=1.)

Limiting stack depth at [arbitrary number] -- this is similar to (1). I don't know why configuration languages don't do it, to be honest.

Re: Pkl, a Programming Language for Configuration

#180

Post by baq »

4ad wrote: post #162
the_duke wrote: post #161

Earlier quoted context omitted.

I really like CUE, but for most use cases I have I would want to embed it in an application, and Go is the only language with support. For it to gain more adoption it really needs a rewrite in a low-level language (C/Rust), so it can be exposed in various languages through an extension/FFI.

Making CUE available as a library for other languages is one of our top priorities. Sadly, I can't provide an ETA at this time, all I can say is that I am personally working on this. Getting feedback from the community about what other languages they'd want supported first would be of massive help, however.

C library gets to halfway to everywhere to paraphrase a saying.
Post reply on HN