Syntax for proposed extensible attrset

Development
1

I wasn’t sure how to split this off as a separate conversation so I apologize for threadjacking…

I’m probably missing something obvious but why is the proposal for new nix syntax using < and > instead of { and }? I know that’s really the smallest part of the proposed change, but it does make the language feel more alien to me that way.

Thanks

1 Like
2

Yeah, not very good. This is to make Nix3 (and this will require nix version bump!) backward compatible. The other proposal was to do {{ and }}, and you may propose anything else except { and } - those are reserved for regular attribute sets.

3

Just curious: why not use whatever_key_word { } like the recursive set rec { } ?

4

It’s fine but it also requires an operator for module combo. Will it be +?

let moduleCombo = module { ... } + module { ... };

Modules form a monoid, so + is reasonable here. But is clear overload of addition operator. Why do we have different operator for lists then? Haskell has changed to <> for monoid composition. Maybe we should do like that?

let moduleCombo = module { ... } <> module { ... };

But then we also have to define what will be module { ... } <> { ... }.

Compare to proposed by Eelco, which overload function application and forbids any other attribute sets of being merged:

let moduleCombo = < ... > < ... >;
5

It’s fine but it also requires an operator for module combo. Will it be +?

Does it actually require it? it could use an interface similar to
__functor.

Actually I somehow feel most of the proposal can be implemented in plain
nix right now.

The only thing I think we miss for this is ways to associate (and query)
arbitrary metadata to an attrset key, including one that is not
associated with a value. With this I think everything proposed can be
done with __functor-based magic.

And I don’t think adding metadata and a builtin to an attrset key
actually requires a major version bump, if the metadata syntax is chosen
to be backwards-compatible?

Also, I feel that doing things this way makes the language more powerful
and opens up more possibilities than hardcoding merge etc. in the
extensible attrsets.

Now, maybe I’m missing a point :slight_smile:

6

The only thing I think we miss for this is ways to associate (and query)
arbitrary metadata to an attrset key, including one that is not
associated with a value. With this I think everything proposed can be
done with __functor-based magic.

Actually thinking about it again (and having seen shlevy’s nixcon talk
for metadata):

We don’t actually need a syntax for defining or reading metadata, we can
just standardize on metadata.[attrname].[metadataname]

However, the feature we do need is late-binding of variables. In an
extensible attrset I want { a = 1; b = a; } to not be resolved
immediately. So this would need late-bound variables. For instance, the
above attrset could be expanded to { a = {...}: 1; b = {a, ...}: a; }.

All of this could be made manually, but nix-provided tooling would be
really helpful. However, I do think a late { a = 1; b = a; } (or
whatever other name) would be a really important first step, because no
one wants to write one function per attribute. Then special syntax for
setting the metadata.

I guess my idea is this one: If we can make smaller primitives, then
they can be used in more places than we would even expect.

(oh, also I’d love metadata for function arguments, but this one is not
going to be solved by adding metadata.[attrname].[metadataname]…
unless we turn all functions into attrsets with __functor… food for
thought)

7

Thanks for all the comments!

8

Everyone talks about this proposal, new syntax, etc. But where is the proposal itself??

2 Likes
9
2 Likes