From (get-env "FOO") to (environment.FOO) to (env.FOO) to $FOO

[hostilefork]

@hostilefork

So if someone put a gun to my head and told me to make it work right now--today--the quickest path would be to make a new ANY-CONTEXT! type in C called an ENVIRONMENT!. The flaky part is that environment variables come from an extension, and so it would be an "extension type" (like a GOB! or VECTOR!), and those are second-class citizens (they don't work in TYPESET! for instance, they're all considered the same CUSTOM! datatype for those purposes).

I resist the temptation to do this, because while it would be nice to write environment.FOO instead of get-env "FOO", most of the uses are in the rebmake code...which needs to work in the bootstrap executable. So no point in making an existing mess with extension types messier.

The flakiness is fading away, and there's little to stop me now from making an ENVIRONMENT! datatype.

It would implement PICK and POKE, and as such be able to do selection of environment variables via TUPLE!.

We have standardized methods now where if you say env.FOO and it doesn't find it, then you get a raised error. So you say try env.FOO and get NULL.

It can be supported in typechecking, though questions about how extension types participate in things like ANY-CONTEXT? are still up in the air.

I think you should be able to do things like:

 >> env.FOO: "demo"

 >> group: bind env '(FOO)
 == (FOO)  ; bound

 >> eval group
 == "demo"

It might not be useful to bind a block of code in general to environment variables--due to the possibility of the environment to expand to contain anything and thus compete with your words of code. But having a COMPOSE variant that binds GROUP!s to the environment could be quite useful, as you could say (FOO) or $(FOO) did environment variables.

You could do an EVAL-IN-ENV construct, that composed a block of code where just instances of $FOO-style things were composed... though that would snapshot the environment variable state before the evaluation. You couldn't pick up modifications as they happened. That would require being able to actually hook the evaluator... which... yes is still on the table.

What To Call It?

I guess calling it just system.environment puts it in a good place, and system is shorthanded to sys so it could be similarly shorthanded as sys.env.

Then if you needed to you could say env: system.environment or e: sys.env or whatever shorthand you thought was appropriate.