First release of Nickel (0.1.0)

Announcements
#1

Dear Nix community, I’m excited to announce the first release of Nickel! You can read the announcement blog post for a quick recap of the current capabilities, and to learn about what’s in and what’s coming next.

For this release, we have focused on designing the core language more than anything else. While it is not intended to be used in production yet, we hope to collect feedback and experience to help steer the future of the language in the right direction.

Using Nickel for Nix is, for the moment, quite limited. However, now that the 0.1.0 milestone has passed, this is very much our main focus for the near future: find a robust and ergonomic way of using Nickel as an alternative to write shells, packages, and modules, without disturbing the Nix ecosystem. We’ve already been thinking about it on and off for quite some time, and it poses particular challenges, such as how to leverage the existing Nix ecosystem without being drawn into the same issues we were trying to improve on in the first place.

In the meantime, @garbas , @regnat and I have been fiddling on the side with a hacky direct way to write simple derivations in Nickel: you can find our current lab at nickel-lang.

Let me conclude by quoting the blog post itself:

We are seeking for feedbacks, ideas and opinions. Yours are invaluable: please use Nickel, break it, do cool things we haven’t even imagined, and most importantly, please let us know about it!

22 Likes
#2

Do you think it would be possible (in the future) to remove the requirement of --option allow-import-from-derivation true --impure for it to work?

#3

Right now, @regnat actually did a version where --impure is not needed: Nickel shell by yannham · Pull Request #1 · nickel-lang/nickel-nix · GitHub. As he mentions himself, it’s “absolutely ugly” :slight_smile: but it’s at least demonstrating that it is possible.

Note that nickel-nix is just an experimentation. It’s not fleshed out, we cut corners, and most importantly, this is not what the future of using Nickel for Nix will look like, hopefully. We just sidestepped a lot of fundamental questions to get something working now. The “robust and ergonomic way of using Nickel as an alternative [for Nix]” mentioned as the roadmap will most likely gives us something different, involving a tighter integration of the two systems and languages.

#4

This is a tangent I guess, but have y’all seen UCG (https://ucg.marzhillstudios.com)?

I stumbled on it last year but for some reason I didn’t recognize the similarities at the time.

2 Likes
#5

I haven’t, and at first sight the resemblance is troubling! I’m going to read more about it, but it does seem to have very similar goals, scope and motivations. Really interesting. Thanks for sharing!

#6

I have a more meta question:

Will be there a formal specification of this language, in order to allow alternative implementations?

2 Likes
#7

Yes, We plan to do so at some point, although for now I think the language is not stable enough to seriously start such an enterprise (in particular the merge system part). But we are currently writing down a formal specification of the type system, for example.

Having a specification was a point mentioned in the very first design document, exactly to make it not too hard to have an alternative implementation for the core language. The idea is that you could get light interpreters that just don’t care about types, and maybe contracts. But I suspect the latter may prove harder than initially thought, because contracts can already add default values, force fields to have some values, etc. which makes them conveniently schema-like but also means they impact the end result, and they are not all just checks that you can get rid of freely.

In any case, even without alternative implementations, a specification is important for solid foundations.

2 Likes
#8

I noticed with nickel in doc sections you can do source blocks with highlighting like markdown

This be used to mark the syntax highlighting to be used in a normal multi-line string?

I’d love to have correct highlighting in my nix script blocks :smiley:

buildPhase = ''bash
  echo this is my bash
'';

is there some documentation around doc & %%m? I found %m for multiline but nothing about the other 2

#9

You can find information about doc in the metadata section. This is used to attach documentation to any value. It can be leveraged by the nickel query command (or :q/:query in the REPL, for example try :q array and :q array.map), and later by a doc generator, when it will be available.

doc is to be followed by a string (a “static” string, it can’t be a compound expression, and it can’t have interpolation inside), and support markdown (as, the query command will render markdown natively, and the future doc generator as well).

Using several % in a multi string delimiter is used to write a string with literal %{ } or m%"/%"m inside without having to escape them. If you use n (say, 3) % in the opening delimiter like m%%%", then only the same number of % will be interpreted as interpolation ( %%%{exp}) or a closing delimiter "%%%m. For example:

{ foo | doc m%%"
          Help interpolating zorglubs, as in `m%"%{foo zorglubs}"%m
        "%%m }

$ nickel -f foo.ncl query foo
• documentation: Help interpolating zorglubs, as in m%"%{foo zorglubs}"%m
1 Like
#10
4 Likes
Hosted by Flying Circus.