Would an ENV scheme be more appropriate than global natives?

[rgchris]

Currently ENV access is managed through three global natives: GET-ENV, SET-ENV, and LIST-ENV:

get-env "HOME"
get-env "REQUEST_URI"
list-env
set-env "FOO" "Bar"

Using a kind-of Rebolish principle of 'fewer built-in niche verbs,' perhaps it might be more appropriate to isolate these functions to a dedicated URL scheme:

read ENV:HOME
read ENV:REQUEST_URI
read ENV:?all
write ENV:FOO "Bar"

There are a few advantages to this:

• ENV becomes more of a conceptual space than a collection of specific super-verbs,
• the existing super-verbs can be removed from the global namespace,
• the ENV scheme could be constrained by SECURE,
• the literal syntax can easily be found in a search,
• the scheme can be expanded to address some specific cases:

  read ENV:?cgi
  read ENV:?filter=HTTP_*
  

---

A very basic scheme built on top of the existing verbs for testing:

sys/make-scheme [
    name: 'env
    actor: [
        read: func [port] [
            get-env find/case/match/tail port/spec/ref "ENV:"
        ]

        write: func [port value] [
            set-env find/case/match/tail port/spec/ref "ENV:" value
        ]
    ]
]

read ENV:HOME

[Oldes]

I have nothing against using such a scheme, but I think it is not good to remove the fast way, how to receive environmental variables.
See this result:

>> profile [[get-env "APPDATA"][get-env 'APPDATA][read ENV:APPDATA]]

Running 3 code blocks 10 times.
----------------------------------------------------------------------------------
Time               | Evals  | S.made | S.expa | Memory      | Code
1.0x (7μs)         | 1      | 2      | 0      | 64          | [get-env 'APPDATA]
1.1x (8μs)         | 1      | 2      | 0      | 64          | [get-env "APPDATA"]
6.7x (47μs)        | 291    | 18     | 1      | 1304        | [read ENV:APPDATA]
----------------------------------------------------------------------------------

You may say, that in many cases use of these variable is rare, but there are also cases, where you want fast access, like in CGI.
In CGI environmental variables are used to pass all the request info. See this code: #74 (comment)

[rgchris]

If the scheme was implemented natively, I believe you would get comparable speeds. That would be the end goal, my scheme here is just proof-of-concept and usable in transition.

[Oldes]

You would get slightly better speed, but not comparable. There still will be needed the parsing of the url, port creation, dispatching only to call the function like get-env (in it's native form).

[Oldes]

But I can imagine, that you could have opened env port and use some action like pick to get results... I can imagine that it could be used to get multiple results in one request as well... but that is not what is in your proposition;)

[rgchris]

No, but such an operation would be similar conceptually/semantically.

Also, the CGI implementation read ENV:?cgi would be a special op that would only be called once (bear in mind, I'm spitballing the actual syntax of the URL scheme)

[Oldes]

If someone want to create a native env scheme, using the clipboard scheme as a template may be good start.

Or maybe better to see initial implementation of the MIDI scheme (because there must be more changes in other files as well).

[rgchris]

An alternate syntax:

read env:key=HOME
read env:key=REQUEST_URI
read env:list=all
read env:list=cgi
read env:filter=HTTP_*