Nix expression language capabilities

[Ericson2314]

It just occurred to me that this might be useful, so opening an issue. Various unsafe/effectful constructs like dynamic scope, (including operator overloading), NIX_PATH lookup, reflection, exception catching, etc, are very useful for certain tricks (things that the tagged people have worked, on for example). Yet simultaneously those tricks rely on the code the wrap to not use those same mechanisms to subvert the tricks.

We already have a safe mode, but such things are global and thus unsuited for this usecase. Capabilities on the other hand could work really well. The capabilities are fed to the wrapper, but the wrapper does not in turn feed them to the loaded code.

CC @nbp @copumpkin @fkz

[nbp]

I am not sure to understand what you call capabilities. Can you clarify, maybe with an example?

Various unsafe/effectful constructs like […]

Can you clarify which one is unsafe / effectful? From what I understand, these are only different forms of inputs.

I might agree that some feature such as scopedImports are really dirty hacks made to have a control over the NIX_PATH, and I totally disapprove this feature. Still it is not effectful, as it does not mutate any state. It just change the way some lexical operations are interpreted under the scoped expression.

We already have a safe mode, […]

A safe mode?

[Ericson2314]

Can you clarify, maybe with an example?

It could work like this:

{ overloadCap } @ caps:

builtins.overloadOpWithin caps "<" (l: r: ...) ...scopeOfOverload...

One needs the overload capability in order to use the builtin, which overloads the meaning of "<" within ...scopeOfOverload.... A top-level nix-instantiate command (or equivalent) specifies the set of capabilities to be provided to the give expr-file / expression (should therefore evaluate to a function).

Can you clarify which one is unsafe / effectful?

Sorry, I meant effectful in a formal PL sense---so roughly any sort of non-local or impure construct, not just mutation.

A safe mode?

I've only heard about this in other comments, never used it myself. It prevents builtins.readFile or import from being given non-store-paths, for example.

[nbp]

Can you clarify which one is unsafe / effectful?

Sorry, I meant effectful in a formal PL sense---so roughly any sort of non-local or impure construct, not just mutation.

I do not think loading a file (builtins.readFile) from out-side the Nix store is impure. This is just a source which is defined in a different format. The same applies for builtins.getenv. The only reason why these could be considered unsafe, is if these functions are not memoized.

I do not think exception handling (builtins.tryEval) fits in this unsafe category either, as it does not change the evaluation semantic of the language, it only capture the success of the evaluation of an expression, which otherwise would be handled by the top-level of the interpreter.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[stale[bot]]

I closed this issue due to inactivity. → More info