Half baked idea for a new pair of builtins: builtins.restrictNamespace and builtins.restrictedNamespace (feel free to suggest a different color for the bikeshed). Here's the basic idea:

Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + 1);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in 6. Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + foo);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in an eval error about foo being inaccessible in a restricted namespace. Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + foo);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

hits the builtins.throw case.

Not sure how this would/should interact with builtins.scopedImport.

Motivation for wanting this is that it allows you to restrict the names available to some expression without forcing that expression to be moved into a different file. Good idea, bad idea, thoughts?

Half baked idea for a new pair of builtins: builtins.restrictNamespace and builtins.restrictedNamespace (feel free to suggest a different color for the bikeshed). Here's the basic idea:

Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + 1);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in 6. Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + foo);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in an eval error about foo being inaccessible in a restricted namespace. Evaluating this:

let
  foo = 4;
  bar = x: x + foo;
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

hits the builtins.throw case.

Not sure how this would/should interact with builtins.scopedImport.

Motivation for wanting this is that it allows you to restrict the names available to some expression without forcing that expression to be moved into a different file. Good idea, bad idea, thoughts?

Half baked idea for a new pair of builtins: builtins.restrictNamespace and builtins.restrictedNamespace (feel free to suggest a different color for the bikeshed). Here's the basic idea:

Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + 1);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in 6. Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + foo);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in an eval error about foo being inaccessible in a restricted namespace. Evaluating this:

let
  foo = 4;
  bar = x: x + foo;
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

hits the builtins.throw case.

Not sure how this would/should interact with builtins.scopedImport.

Motivation for wanting this is that it allows you to restrict the names available to some expression (in this case a function, but ideally this'd work for any expression) without forcing that expression to be moved into a different file. Good idea, bad idea, thoughts?

let

   {
      fucking around
    }
    x = 3;
in
 { ... }

let
  scope = _: { foo = 4 };
  bar = (x: x + foo);
in bar 5