namespaces?

[yuuyins]

It seems nickel only has imports just as nix... Are proper modules/namespaces definition and usage/import not in the plans? Guix/Guile has this and it is a boost in usability/organization. In Nix people do hacks to get similar namespace functionality; it is bad usability having to deal with the import/filesystem approach.

[yannham]

Namespaces/modules are not planned currently, but it's not out of the question either.

In one direction, Nickel ought to stay as simple as possible, at least in a simple setting, that is, the actual configuration data: the fact there is a non trivial type system with polymorphism and whatnot is not required knowledge for someone writing a config file. What's important is that they get good error messages when they do something wrong.

On the other hand, a unified and principled way to write and consume libraries could surely pay for the additional complexity.

Just to fuel the discussion, what are e.g. the features your miss from a module system (say, the one of Guix) vs simply using record, imports and destructuring?

[DrRuhe]

I also think a principled and standardized approach for code organization will benefit the developing nickel ecosystem greatly. For example with nix, due to the absence of such an approach, each flake also develops its own organizational scheme. This leads to niche solutions like divnix/std that propose such schemes (which also have to be learned). Ultimately fragmenting the flake ecosystem as flakes only work nicely with specific other organizational schemes.

Generally, any project getting big enough would want to organize the code into multiple files, so code organization libraries would develop anyway. So before the ecosystem has time to fragment, I think nickel should provide a unified approach.

[yannham]

I agree that some standardization is beneficial. To me, there are two facets:

1. Handling non local dependencies (Handle non-local dependencies #329), or how to map a name (such as mysuperlib) to a location - and in fine an expression - on the file system or on the internet. This isn't easy to get right, but I concur that this is just not an option in the medium, even maybe in the short term.
2. A module system in the sense of e.g. OCaml. Having more standardization around what is "something which exports functions and types to be reused elsewhere". Of course the two are usually intertwined but one can coexist without the other: you can write and use modules and module signatures in OCaml inside a single file (and it can be useful!) covering only 2., while JavaScript modules seem to mostly cover 1.

I'm not sure yet if we need 2., because we can do already quite a bit with existing features (although, something that came up recently was exporting a static type, which is not possible currently). If we hope to see the formation of anything that could be called a Nickel ecosystem, we can't avoid 1., yes.