(Optionally) automated environment via namespaces
See original GitHub issueI find myself calling create
and passing around different env
’s of types in many files, and I’ve only just started really leaning on sanctuary in a large project, and its going to get worse.
I’ve thought about different ways to structure this to prevent the verbosity, but I thought I’d at least vent the radical thought that keeps coming to mind.
What I really want, is an automated env. I don’t want to pass env’s around, I want to define a type and ideally I want sanctuary-def to manage the concatenation for me.
This came up when I was working on sum-type, I wanted to be able to nest union types, and I wasn’t sure if that meant I needed to insert the previously created types into the env of any new types. So to date (I think), that’s exactly what I do. Its technically still pure, it just automatically gives each type a new env that includes the previously defined types. I don’t know if I actually need to do that, but whether or not I do, it at least makes me wonder, why don’t we do this by default?
I don’t want to have to think about order of operations across possibly 100’s of modules.
I want to be able to write $.RecordType({ ... })
and know I can use that type anywhere now.
Now there’s problems, maybe we don’t want some subset of a project to include the environment from another part of a project. I think this is solved in programming languages via a namespace
.
So what if we had $.namespace
// file1
// string -> Array ( Any -> Any ) -> ???
$.namespace('main', function([def, S, SumType]){
$.NullaryType(...)
$.UnaryType(...)
$.RecordType(...)
def(....)
def(....)
SumType(...)
})
//file2
// string -> Array ( Any -> Any ) -> ???
$.namespace('main', function([def]){
$.NullaryType(...)
$.UnaryType(...)
$.RecordType(...)
})
And then in one place, we can initialise that namespace
.
// String -> Array ({ checkTypes: Boolean, env }) -> ???
$.createNamespace('main', [
$.create
,S.create
,SumType.create
])
Just walking through the signatures, $.createNamespace
would accept a namespace name, and a list of functions that receive { checkTypes, env }
, sanctuary-def
would somehow initialize them for us, and manage concatenating the environment behind the scenes. This is very hand wavey! 😄
I’m not sure what $.createNamespace
would return, I have a few ideas. One option, it could return a merged object of whatever each $.namespace
returned, essentially giving us an analogue to modules. Another idea could be to return an interface that gives the caller control over exception handling (whether to throw, or write errors to a stream etc)
This API could let us do cool things, like use different namespaces for testing, or hot paths. Or control execution of code that depends on sanctuary-def types. Now we can toggle env for the entire namespace (across files) in one place. We also don’t need to concern ourselves with concatenating different type arrays, because namespaces would automatically do that for us.
It’s very opinionated, and maybe would be better off as a library, but I don’t know if it would be possible to do this in user-land.
Its a very broad debatable idea, but seems interesting to me. I’d love to hear some criticism!
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top GitHub Comments
I like that revision!
Maybe
$.namespace
could accept args for documentation base urls, and package name prefixes, and the namespace itself could autoprefix type and function names with package prefixes. Potentially we could just provided the hash, or final path of a documentation url per type.That would automatically prefix any documentation urls in that namespace with that base url, and any type with that package prefix.
How about
$.environment
or$.namespace
could also concatenate the bindings with whichever standard/global types/functions exist.