Standardization of Application-related Data

[mariari]

@Michael

To

2. How should we standardize semantic patterns in applications ?

The summary I take away from this thread so far is that you @vveiln and @mariari don’t want to require resource object data like value and label to be maps as per the RM specs and instead leave this open. That’s fair.

The open question still is: How can some actor (either a professional indexer or me personally sorting through my resources in my local storage) practically inspect resources for the owner information.
Given the above, the next best thing apps will come up with is a check if the field is a map or not and a second check if there are map entries complying with certain standards this app requires.
So we would create de-facto standards requiring value/ label to be maps by doing this in the Juvix applib. This is obviously not elegant, but are you ok with this?

I am not ok with this, all of this is far too premature. The reason is the following:

1. Enforcing them to be maps, means more indirection and complications for understanding programs. We are already mired in artificial complexity that we are trying to strip out and boil it down to the essential complexity. Thus I can see a strategy on how to maybe make this work, but I’ll get to that in point 4.
2. We are having issues even making simple programs, if we are having issues, outside parties will have issues. I don’t think an explosion of programs will be made yet, dedicated programs with dedicated solvers can be made and I believe these are fine first steps.
3. Our understanding of applications is evolving, what may look like a fine idea now, may be a determent and we’d have to strip out later and chose a different strategy for.
4. Even if maps are a backing data structure we chose for Juvix in the short term, we should not encourage users to explicitly use maps. This is error prone as every record access of the map would return a maybe type before it can be used only adding to the annoyance of writing programs (note that the encoding of basic type information isn’t there yet so currently as of v0.2 it’d be worse than that it’d be a massive foot gun). Now I can see it potentially in the lower layer that is automatically translated, I.E. the base layer encodes them to simple maps but the more user friendly library encourages users to use custom data types that have an encoding function that moves it to a map. I’m heavily against doing this now as it only makes more work for Juvix and we don’t have the library up, thus meaning that a series of boilerplate would have to accompany the program, we should first see how the layer above base turns out before making any decisions here.
5. Looking at the long term (note this is not an argument about now nor Juvix), I think there are much better enforcement mechanisms than standards which will have many false positives (I.E. I name a field owner because for my domain an owner is an unrelated concept and is instead a different kind of information. No practical way to deal with this as it’s just about a field in a map…), I.E. if we have a proper model for computation, this can be boiled down to a simple reflective query based on who implements what interfaces (we can get much better information than this).

For example take the above image. Here I have a trait of mine GithubJSON, which states that every implementer ought to accept the message fromJson:. Here I can query for all the users of this, the top left shows this in gui form, the first picture on the right shows how that gui is made, since it’s made with users, we can list all instances who conform to GithubJSON by simply doing the query self users collect: #allInstances, and just like that I have a collection all instances that can accept fromJson:. However this may not be enough, what if fromJson: is common but my interface is not? Well look at the image below!

In that case I just queried for every object in the current image that has fromJson: implemented. Now I can try writing long running programs that work not only on GithubJSON, but I can also experimentally try on anything that accepts a fromJson: message. What if I want to filter it down to a specific controller?

Here we can see that the same filtering mechanism lets us change the scope of the query to the specific range of things I wish to see.

Thus I’d argue a self reflective system that represents information about itself is a better model to go for that lets you splice by field criteria (owner) or confirmed interface acceptance (implements a trait). We can get this by implementing a MOP or Smalltalk Object System ontop of resources. From there, we can actually do sophisticated queries with known techniques as we can look at GT/moose’s rewriting and query system. This is extra powerful as the queries can run on the AST as well, giving us the ability to query for all programs that have certain patterns[1]. I believe this can be realized not in the valueRef nor labelRef, but instead either through kind mapping or from the reference to the logic directly (pending details). In the long run this is the direction I believe we ought to go and can actually realize, boiling things down to solved problems is nice.

[1]

Rewriting Pharo code