Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shorthand for "pattern matching" on an object parameter #119

Open
copumpkin opened this issue Mar 3, 2016 · 9 comments
Open

Shorthand for "pattern matching" on an object parameter #119

copumpkin opened this issue Mar 3, 2016 · 9 comments
Labels

Comments

@copumpkin
Copy link

One thing I really miss when writing jsonnet after writing Nix for a while is the ability to deconstruct an object being passed in as a parameter. For example:

{ a, b, c }: a + b + c

is a one-parameter lambda (arguably the only sort that matters!) that expects the caller to pass it a dict with those three keys in it. You can also set defaults and match on the aggregate.

Would it be possible to get something similar in jsonnet?

@sparkprime
Copy link
Member

So you're not really asking to omit the function keyword, right? You're asking for a way to write the following in half as much space:

local func(T)
    local a = T.a, b = T.b, c = T.c;
    a + b + c;
func({ a: 1, b: 2, c: 3 })

One thing I've realized recently is that people want to use functions a lot more than expected. And in the design they are pretty rudimentary (compared to other languages), with not much sugar to encourage conciseness.

I did for a while flirt with the idea of allowing func{ a: 1, b: 2, c: 3 } as in Lua. But in Jsonnet that makes it quite hard to see whether func is indeed a func or in fact an object being extended. So I think the parens have to stay.

One option is to add something like Python named variables and kwargs

local func(a, b, c)
    a + b + c;
func(a=1, b=2, c=3)
func(**{ a: 1, b: 2, c: 3 })

"Borrow from Python" has been a good default in other areas.

@sparkprime
Copy link
Member

@oconnorr as the word "nix" was mentioned

@oconnorr
Copy link
Contributor

oconnorr commented Mar 7, 2016

I think pattern matching is a great thing, but there are some design choices to be made.

Nix has a moderately complex syntax for pattern matching on tuples

{ foo({ a, b }) = a + b }

Does foo require an object whose set of fields is exactly a and b, or does it always slice an accept any object with at least a and b fields? Nix supports both with special syntax for the second case.

Is the binding lazy so that even if the parameter doesn't have one of the fields, if that field is never used in the computation then maybe that is okay?

Nix also has this ? syntax in the pattern which fills in fields with default values in case the parameter is missing the named field.

@copumpkin
Copy link
Author

@sparkprime yeah, not looking to omit the fairly heavyweight function keyword (although I would love that too 😄). I'm fine with the python splat operator, but with the considerations @oconnorr raises. The only thing I could see us losing from treating it as a splat, rather than an explicit dict, is the sort of thing we do fairly often which is to peel a couple of arguments (possibly with defaults) out of a dict being passed in, but also passing the dict through wholesale to another call.

@sparkprime
Copy link
Member

How do you do that (peel off and pass the whole dict through) in Nix?

@copumpkin
Copy link
Author

oh, sorry.

{
  foo = { bar, baz, ... }@foo: doSomethingWith [ bar baz ] (someOtherFunction foo);
}

@benley
Copy link
Contributor

benley commented Mar 31, 2016

Relatedly, I would love to be able to do things like this:

local (x, y, z) = std.split("foo bar bas", " ")

@sparkprime
Copy link
Member

Is this addressed by #164 ? I know it's not exactly what you asked for but it covers the obvious use case.

@copumpkin
Copy link
Author

I love the default arguments you've added, but is there a splat operator today? With splatting I think it's pretty close to what I'm talking about, but probably wouldn't cover @benley's use case.

sbarzowski added a commit to sbarzowski/jsonnet that referenced this issue Jun 10, 2024
…y) (google#119)

Faster comparisons and IMO cleaner feeling overall.
It doesn't affect behaviour in any way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants