Beyond Inheritance.. psycmatching

Some meta-thoughts: According to David Weinberger, everything is miscellaneous.

This long lecture (you don't need to watch it now) and probably even longer book essentially states that we needed to have neat hierarchical ordering of things in the physical world, just because you have to put your things somewhere. In the electronic world, not only you can put things everywhere (by a hyperlink or whatever), you also might not want one person to define that order for you, if for you a different order is more useful. Riding this train of thought, our method inheritance is better than no logic at all, but it is still doomed to fail in some circumstances when we want to match method against certain characteristics, not caring about hierarchy at all. You can consider this a theoretical background to why psycmatch() is more appropriate than abbrev().

Think of the following a bit as a sort of multiple inheritance.

Some special cases can either be solved by having seperate types or by a matching relationship:

Consider the fictive variable _photo_JPEG_dog as a derivate of _photo_dog. The JPEG refinement fits the _photo, but not the _dog. Still there is a logic in them being a match. By not looking at inheritance only from the front, we can get to subtler forms of derivation than inheritance.

This sort of matching also applies to some other special cases we have in the protocol, like _failure_unsuccessful_delivery_disconnect wanting to be matchable by something like _failure_delivery (no matter whether they were unsuccessful or _invalid, _disconnect or _port_connect).

It also models the case of service linking, where we currently allow substrings of methods to be subscribed to, like subscribing _mail to receive anything that has to do with _mail.

psycmatch() Implementation

Possible implementations for psycmatch('_failure_delivery', '_failure_unsuccessful_delivery_disconnect')

• In a rapid prototyping language: Split by _ then step through the elements of the right argument and increment the left one whenever a match takes place. If all elements on the left have been matched return true.
• In a low-level language: use two nested strchr() loops and a strcmp() as in http://www.psyc.eu/examples/psycmatch.c

This method extends the existing abbrev() practice for strict inheritance. Consider that these matching operations can generally be optimised at parsing time should your architecture allow that. psyced should do that, but doesn't yet.

Inherited, typed, related or matching

Some definitions.

Inheritance: When a keyword matches an other keyword strictly from the beginning, and no part is missing. _balloon_red_99 inherits from _balloon_red.

Match: When a keyword matches an other keyword according to the method described above, like _failure_unsuccessful_delivery_disconnect matches _delivery.

Type: When keywords share a common family at their beginnings. This does not have to be limited to just one element, for example _photo_JPEG_other_significant and _photo_JPEG_hifi_other_significant share the same type _photo_JPEG, which is itself of the type _photo, but in a more refined way.

Connection: Keywords are connected when they end in a common substring, as in _list_uniform_members and _list_action_speak_members. See also Talk:List for a possible application.

Relationship: Keywords are related when they share any common element, like _mail.

In the case of _nick_local, maybe renamed to _text_nick, the new match technique would require a possibility to distinguish different levels of inheritance for the purpose of assigning different semantics. For instance type inheritance could be constrained to indeed match at the first word, so whenever psycmatch() returns > 1, there is a match of other semantic meaning.

Matching cookbook

Here comes a psyctext template, or an application requesting a variable _photo_pet. What do you do?

1. First you try to return it an exact match called _photo_pet.
2. Then you try to return it a derivate, like _photo_pet_greyscale
3. No luck? Now you try to find a match like _photo_JPEG_pet or even _compressed_photo_pet
4. Still no luck? Try to look for a possible type conversion, like how to render an _avatar into a _photo.

In the case of _compressed_photo_pet, this would imply a change of type requiring a conversion, too. This can be used to request universal type conversions intentionally (like any type can somehow be converted to a string, but you don't want to put that in the list of type conversions as it would be too greedy).

See how unlikely it gets that you will ever need the psycmatch() function. By far most accesses to variables are exact match accesses^((s)).

Ambivalence resolution

What if there are more then one match to step 2 or later of the recipe above?

The answer is simple: If you are given more than one match, either the sender has messed up, or it indeed doesn't matter.

Since simplicity in implementation is a goal in PSYC development, detection of ambivalence is considered unnecessary. Just use the first match you come across. If the result is not as the sender intended, it is her own fault. Paying too much attention is a waste of programming effort and there is no gratifying solution anyhow.