Talk:Abstract Wikipedia/Reserved ZIDs

Talk about reserved ZIDs here. The update was here: Abstract Wikipedia/Updates/2020-11-25 --DVrandecic (WMF) (talk) 23:07, 25 November 2020 (UTC)

Reserve a range

I'd recommend having some sections of the first 10,000 reserved as "namespaces", eg that the (presumably mostly empty) range of 2000-2999 all be for a certain kind of basic ZID. --Yair rand (talk) 23:16, 25 November 2020 (UTC)

@Yair rand: to clarify, to see if I understand correctly: not all of the first 10,000 should be reserved, but merely e.g. 2000-2999, and we should have the other numbers be assigned through the normal community process? So the first object created by the community could still be Z1, but when we get to Z1999, the community process would be jumping to Z3000 instead? --DVrandecic (WMF) (talk) 01:28, 3 December 2020 (UTC)

@DVrandecic (WMF): No, sorry, I meant that eg all of the first 10,000 would be reserved, but eg Z2000-Z2999 would within that group be specially reserved for a certain type (a fairly broad category of fundamentals, at least) of reserved ZID, Z3000-Z3999 for another type, etc. Rather than, when assigning spots from the reserved section, assigning them all in direct sequential order. (There's probably a proper term for that kind of sectioning, like how HTTP statuses 400-499 are for client errors etc, but I can't think of the word.) --Yair rand (talk) 10:05, 8 December 2020 (UTC)

Why do we need a specific range of integers?

Couldn't this be managed by another prefix, such as

• "ZT" for types and functions (types are functions if we consider they all have a constructor); "ZB" for their builtin implementation, "ZV" for values/instances (like "ZV0" for False, "ZV1" for True);
• Or by reserving negative values such as "Z-1" for Object, "Z-2" for Persistant object?

Note that in terms of semantic and natural languages, and more generally about all concepts of human knowledge, there's NO real distinction between a class and an instance: each instance can become a class when refined, and like Javascript we should not distinguish them with the later need to create hierarchies of "meta-meta-abstractions", which can become extremely fuzzy (this attempt has been mùade in Wikidata and has caused more confusion than being really useful and productive, creating many unnecessary distinctions. All that matters is just that every object is a class. it has its own "static" properties that inherited by all their "instances" (when they are created) or "subclasses". What really counts then is the fact that an object-class can be derived/instanciated or not. If not, it is then a "final" class that cannot be instanciated/subclassed/derived, and that can then be used as an instance (or value). So in Wikifunctions, everything can be a class, and so can be a constructor (i.e. technically a function): an instance/value however is normally never taking any parameter, and evaluating that "function" without parameter can then return itself (this terminates the evaluation). This object/class/constructor/function/value V can still have properties, notably it can have methods such as "V.tostring : (out string)" which can return a representation as a default text, or "V.totext : (in string langcode, out string)" for another representation in a given language specific by a BCP47 code.

Note that in this representation, a "function" is the name of a n-ary relation not really distinguishing input and output; so "evaluating" a function consists in returning an enumerator of a set of n-uplet made of inputs and outputs; the evaluator will just see if the "function" returns an empty enumerator (failure: no such n-uplet exists) or a single n-uplet (unique solution: classic function). An "implementation" would be code that can resolve this enumerator by binding variables of the n-uplet to solutions that are part of the =relation represented by this "function". This would allow making the system act like Prolog for IA, with a single "function" like "sum" which represents the set of valid n-uplets like (3,2,5) or (3,2,7,12) because 3+2=5 or 3+2+12; this allows a truely functional model (to make it complete, the representation of runtime errors/exceptions (with information/properties in the exception) is that they are an additional parameter (or member of the n-uplet); and pseudo-functions like "random()" are in fact relations "random : (oldstate, newstate, returnvalue)" which are purely functional : note that there may not exist any implementation of builtin capable of "solving" the problem with all possible variables members of the n-uplet left unbound, so technically a function is not necessarily solvable in all direction, as long as it does not havea builtin capable of defining a behavior for a specific subset of variables; as well a function may be evaluated with all variables of its n-uplet bound: the returned enumerator would return either this single n-uplet itself if the relation is true/satisfied, or an empty enumerator if this is false, or more n-uplets of there are multiple solutions, possibilly an infinite number; this also allows defining tests! The evaluator much just check the the first item of the enumerator to see if it is empty, or returns just one n-uplet, or returns more (assuming this number could be infinite, it will first try be resolving enumerators that have the smallest finite set of solutions).

So an interesting Z-object to define would be the "empty set" (a singleton of it unique own type, with ZID=Z0, which has no properties, the equivalent of nil/null in databases, or the last "trail" element of an ordered list or any enumeratable set). This is in fact the most basic Zobject to have, and it should preexist before any other Z-object. It is not instanciable/derivable (attempting to do that would return itself). The evaluator of Wikifunction knows that when it reaches that object, it has terminated an evaluation and must "backtrail" to explore other open parent sets/enumerators: the evaluator uses the same rule: evaluation stops when "calling" a object returns itself and this is the case for calling "empty set" which as a generic type with no parameter.

-- verdy_p (talk) 02:24, 26 November 2020 (UTC)

There's a lot to unpack here!

Regarding the several levels of instantiation, this seems correct in Wikidata, but in programming it seems that most research and experience suggests that it doesn't really go further than four levels. That's also where OMG's UML stops. Further reading through the current programming language literature, it even seems that the four levels of UML might be excessive. Our current function model hopes to get away with three levels, where the third level is just a recursion to the second level. That would make things even simpler (and that would be very similar to how Smalltalk has been doing things).

Things look very different if instead of a class-based system one goes for a prototype-based system, as in JavaScript. In that case it is much easier to have a good model that supports many, many levels. But given that the whole focus of Wikifunctions is on functions and not on rich classes and objects, I really would prefer a simple object model, and put most of the intelligence into the functions. I think that this would allow for a more scalable collaborative creation of the catalog.

(On the other hand, as Scheme has shown, one could implement basically a class or prototype system on top of the current system, so it's not like it would become impossible. I guess, really, we'll see how things will develop over time.)

Regarding Relations, yes, I agree with you that this would make a much more powerful system. And I tried to build the thing as relations instead of functions, but I ran into two and a half major issues:

First, implementing relations seems much more difficult. Being able to turn every argument into inputs or outputs leads, it seems, in order to have efficient implementations, into systems where we need to provide implementations for almost all possible combinations. I mean, it would be very powerful, but implementing arithmetic relations in an efficient way to support unification seems daunting.

Second, having a UX that supports relations seems much more difficult than using functions. When we use functions, you can select a function, and then you need to fill every argument, and the whole system is guided by the types of the arguments and values. With relations, again, a UX seems more daunting, because there seems to be much less guidance that could be provided.

The half-issue is that, over the years, it seems that variables are a major issue when trying to get people to do programming, and a something like "x=x+1" seems to be highly confusing. The current function model allows to completely forego variables. Now, that's a choice (which is why I list it as a half-issue), but you cannot write relations without variables. This ties together with the second point: functions lend to a UX that can provide a lot of guidance, and that does not rely on variables.

Coming back to the original point, I hope to retain a flat universal numbering space and not introduce typing into it. If we put meaning into names, we end up with all kind of possible maintenance issues, like what happens when these things diverge etc. --DVrandecic (WMF) (talk) 01:53, 3 December 2020 (UTC)

Spreading out numbers

I think I want to advise a bit against “crowding” a lot of special IDs in the same tight numeric range, as the current proposal seems to do to some extent (1-15 only has one unassigned number). On Wikidata, several “core” data model properties have “higher” IDs (for historic reasons) – consider located in the administrative territorial entity (P131), date of birth (P569)/date of death (P570), or even sibling (P3373) – and I think this helps to memorize them. --Lucas Werkmeister (talk) 22:29, 29 November 2020 (UTC)

An issue to be considered is having a standard library will make ZObjects more portable.--GZWDer (talk) 22:38, 29 November 2020 (UTC)

@Lucas Werkmeister: That's a great point, and would speak for a larger, more relaxed space of numbers. --DVrandecic (WMF) (talk) 01:57, 3 December 2020 (UTC)

@GZWDer: The issue of portability should be dealt with a different way, I think. I am thinking of the way XML is dealing with Namespaces. Speak, if you are using a different installation of Wikilambda, you shouldn't be using Z1 again, but maybe Y1? (No, we don't have anything to support that right now). Thoughts? --DVrandecic (WMF) (talk) 01:57, 3 December 2020 (UTC)