Tweag+nix dev update #41

Development
1

Previously in Tweag :eyes:
Next in Tweag

Making Nix solve people’s problems :wrench::toolbox:

Documentation :books:

jupyterWith improvements

Making Nix work reliably everywhere :penguin::apple::window:

Making Nix ubiquitous :rocket:

Blog posts and medias :newspaper:

  • @solene made another Tweag+nix discourse update :writing_hand:t2:

Zürich

Nickel

Version 0.3 has been released! Take a look at the changelog and try it out in the online playground.

:metal:t5: build harder, better, faster, stronger :robot: reproducibler :metal:t6: (ref)

6 Likes
2

To get a feel for how Nix-y Nickel is, I ran through the old Tour of Nix on the Nickel Playground by copying and pasting the starter code and adjusting it from there. First impressions:

  • I like that the string interpolation syntax is different from shell string interpolation syntax
  • I missed having block syntax for let expressions (just) a little bit
  • the error message for a missing terminal in at the end of a let expression just before a record expression was pretty opaque
  • it’s a bit nice not to have to remember ; all over the place. Using commas in records like in lists felt right
  • the Playground editor feels pretty natural and nice!
  • the way that default arguments in function declarations which accept records still take ? instead of the | default = ... syntax for record metadata hurt me even though I prefer the short syntax, because it’s not documented
  • it would be nice to be able to clear the log on the right side in the Playground without refreshing the whole page
  • I got frustrated and walked a way after a while when trying to translate the first exercise involving Nix { ... }. I wasn’t sure how to search for what I wanted to know in the Nickel documentation or on GitHub. I think this probably relates to the open merge semantics questions? At any rate, CUE feels easier to translate to Nix than Nickel does in this instance: using { foo, ... } in an attribute set in a Nix function declarations is like declaring an open struct in CUE. I wish figuring out The Nickel Way™ here felt as easy as it did in the previous exercises (where it was pretty much always trivial)

Thanks @yannham for all your work on Nickel! It was fun and pretty painless to mess around with it via the Playground today. Working on cute little exercises in Nickel was fun, and I think it’ll be great when the Nickel Playground includes some of its own :slight_smile:

PS: I did see that there were already open issues for some of this stuff, but my exploration today was pretty casual. Apologies for not linking any

3 Likes
3

@pxc thanks a lot for your feedback, this is very valuable :slight_smile:

  • I missed having block syntax for let expressions (just) a little bit

Well, me too :sweat_smile: I actually pushed for let-block in Block syntax for let-binding · Issue #494 · tweag/nickel · GitHub, but at the time we took the decision to wait before enlarging the syntax too much.

  • the error message for a missing terminal in at the end of a let expression just before a record expression was pretty opaque

Yes, the parser generator we use requires some effort for pure parsing errors to be useful, and we haven’t always made that effort yet.

  • the way that default arguments in function declarations which accept records still take ? instead of the | default = ... syntax for record metadata hurt me even though I prefer the short syntax, because it’s not documented

This is a good point, which requires an issue! It’s not very consistent. I think the two were implemented at different times, keeping in mind that the syntax should be the same, but also trying to feel natural. I must admit that | default = feels pretty heavy in a pattern matching. On the other hand, I prefer | default for writing contracts, where it is more explicit and in line with the other kind of metadata. I’m not sure yet what’s the best choice (have ? everywhere, have default everywhere, or the current situation but with better doc)

got frustrated and walked a way after a while when trying to translate the first exercise involving Nix { ... } . I wasn’t sure how to search for what I wanted to know in the Nickel documentation or on GitHub. I think this probably relates to the open merge semantics questions? At any rate, CUE feels easier to translate to Nix than Nickel does in this instance: using { foo, ... } in an attribute set in a Nix function declarations is like declaring an open struct in CUE. I wish figuring out The Nickel Way™ here felt as easy as it did in the previous exercises (where it was pretty much always trivial)

Ah, too bad, the documentation must be lacking. But there is exactly the same notion in Nickel, it just uses only two dots ..: you can write fun {foo, ..} => foo + 1, as well as write contracts like let Contract = {foo, ..} to specify that you allow additional fields.

Once again, thanks a lot for trying things out, that’s helping improving.

1 Like
4

It’s just hard to search for ‘dots’ or ellipses! Knowing this though, I’m excited to come back to it and stumble my way through some more Nix to Nickel translations when I’m feeling fresh. :slight_smile: