rnd0101
commented
3 years ago Most of the systems develop in the direction of supersystems. So naming and libraries is naturally a supersystem over oFrugar/oMiser. Traditionally programming languages addressed this by having some hierarchical module structures, and even the web has URL (L for locator).
One crazy idea is that obs are very much their meaning (maybe, up to lindies). What if the location of the obs libraries can be associative instead of "address-based" (here the same as RAM versus associative memory/storage)? Then obs can be found by pattern-matching their internals. And names can be given to those patterns.
For example, if one is seeking implementation for commutative group ADT (even without knowing it), then library function for that will be found.
Of course, names and aliases can be given as well, but ob representation can also be quite compact to be an address in itself (not sure about lindies - maybe those can be somehow stored separately?).
Also stored obs can be self-described by having some structure in the beginning, which will need to be stripped of with some simple operation before execution, making obs-storage more self-serving.
So that I see "applying meaning" to more abstract parts (also applicable to those pretty-printing problems and de-lambda) can be a separate layer.
I am not proficient enough in programming oMiser, but I guess there is a way to "decorate" the whole structure with names and then have a procedure to strip those decorations before execution or user them for printing instead (a la literal programming), all in the oMiser. If oMiser is really universal system as I believe it is, it should be possible for it to modify it's code.
Update: I see you have similar ideas in #26 (which I read after I wrote this) regarding structural comparisons and usage of hashes. Of course, the implementation of association addressing can also be hash-based, so approach can be reused for addressing as well as acceleration.
This is a place-holder for some important Computer Science topics that cannot be addressed with oMiser and oFrugal, yet are relevant in how higher-level activities are situated. There is no indication of how one might bridge to these in a fashion that preserves some level of purity and ability to reason about functional bits and the confinement of external dependencies/interactions.
The Naming Conundrum
There is no naming system in the oMiser model of computation. This has been intentional. The lindies are symbolic individuals having utility without any individually-distinct applicative interpretations. Lindies are merely constants. There is some limited intrinsic value using lindy traces as part of verifying an applicative procedure. The intended interpretations for chosen liindies are external, however they are selected for affordance-evocative purposes.
The handling of binding names is an ephemeral arrangement within an oFrugal console session. The binding names are established within a session and there is no carryover to any other session. The oFrugal processor always starts up without any defined binding names. Binding names are not even persistent within a session, since the name can always be reused for a new binding as oFrugal processing of an input stream progresses.
Having persistent storage of obs in libraries of some form requires agreement on how such obs are named. If (also-persistent) scripts may refer to other library-carried/-bound obs, there are new issues around referential integrity and versioning of obs with respect to extensional identity and its preservation. We also don't want to collapse what an ob is versus where it is retained/accessed.
Th notion of persistently stored obs is distinct from the oFrugal ability to merge stored oFrugal scripts into an oFrugal session stream. Even that introduces some naming and access considerations; it is interesting to consider how those might be inter-related in terms of reliable identification. For the most part, this occurs independent of oMiser, with changes to included scripts simply being of utilitarian value in oFrugal operation. With introduction of imperative behaviors and stateful considerations at the Miser level, interplay of considerations may arise with regard to management of dependencies.
When there are means for access to obs located elsewhere, there are important matters with regard to uniqueness of location and determination of the ob itself. It is conceivable that caching of distant obs will be desirable and determination of versioning is especially important there with regard to the integrity of dependence and consistency with respect to any nearby cache.
These are matters of greater significance than the rudimentary oMiser model. It is not expected that they be resolved with either oMiser or oFrugal. Instead, it is desired that any early introductions around namings and persistent identity be established in a manner that does not foreclose extension to higher-level cases hinted at in this issue.
The provision of operations at the Miser level that make programmatic presence of access to and establishment of persistent obs is definitely related to the treatment of computations (#30) and how assignment, continuations, and streaming are dealt with. There is also interaction with accelerators (#29) and the policy there is that accelerators are inherently local, maybe cached, but not conveyed with persistent forms of obs. Distributed presence/situation is a complication that requires more thought before distributed operation on an overall procedure is entertained.
Clearly, these considerations are not anything that oMiser should solve for us. Addressing them with respect to a purely-functional foundation is perhaps useful for insights on the matter, especially on how one can preserve (or better achieve) consistency and the ability to reason about the elaborate schemes of representation and encoding that can be appealed to.
Thoughts about Name Forms
The reliance on extensional identity in oMiser is a powerful feature as well as a serious limitation. It is desirable to appraise the prospect of accelerators for structural equality (#26) as both opportunity and necessity with regard to the enhancement of performance without loss of dependability. Here the question is whether something equivalent can be achieved with regard to persistent obs in (potentially) mutable storage.
It appears that we need to distinguish
what something (an ob) is
where it is/was found
what it is offered for
This last may have to do with some sort of logical attestation that constitutes demonstration of some representation. It might involve investigation of types relative to representations; that may have bearing on the semblance idea (#23, #20).
Attempting to account for all of this at or near the oMiser level is not necessarily practical. It may be worth it to the degree that there is some insight considering computational interpretation, representations/encodings, and higher-level notions, such as (simple) types. I am hopeful, but not that confident.
[to be continued]