I should probably call a less-than simply _set_less_than then it's quite obvious from the name what the function is expected to do.
It is, but it's slightly less obvious how the function is used otoh. In this case one could perhaps believe that the lfun sets the `< in the collection itself. To capture both use and form, the name would be _set_order_using_less_than or something similar. I think it's usually enough if the exact form is described in the docs only. If an ordering function always is of a certain form within the domain, then "the ordering function" is just as descriptive as "the less-than ordering function".
I still believe it's better to have a few relatively limited interfaces that include the 90% most used types instead of having a lot that include 100%.
Fine, as long as those 90% include the interesting data types. That means, in my opinion, that e.g. the property of unknown size has to be covered for the sake of pipe queues.
Besides, the interface will probably be extended over time anyway, as all actively used interfaces do. It's a good thing if one tries to think ahead a bit to avoid future incompatible interface changes, but that doesn't mean one has to incorporate all that from the beginning. And making mandatory functions (and trailing arguments) optional rarely leads to serious incompatibilities.
/.../ because the one who made them just had a those algorithms in mind when the type was done.
I'd like to point out that there's no room for such arbitrariness if it works to describe properties through the existence of functions. If the data type has a certain property then it's clearly a mistake to not implement the corresponding function(s), and it's not up to the implementor to choose whether a data structure has a property or not. The intended algorithms are therefore irrelevant; they can rather be used as a check: If an algorithm that is known to work with a certain collection type turns out not to work then there's an error either in the algorithm implementation, in the collection implementation, or in the interface spec.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-11-14 13:18: Subject: More about ADTs
I haven't thought about that yet, besides that it should be something with either a "`" or a "_" first (for the lfuns, that is). ADT.set_order and ADT.get_order seems like reasonable names for the global functions, and then the lfuns would be _set_order and _get_order. Would that do?
The ordering function is a less-than operation and not a three-way comparator (i.e. like strcmp(3)). My reasons for that are:
o It's simpler to make a less-than function. o It's actually not that often one can use the extra information given by a three-way comparator to save calls, at least in binary trees. o It can be slightly less work to do a less-than operation. o The issue of equality is not connected to the order; in a three-way comparator it's easier to make the mistake that it should return 0 only when the operands are equal, and not when they are orderwise unrelated (i.e. the order is partial).
I was thinking about the name _set_comparator or _set_orderer but that was for a 3-way comparator, I should probably call a less-than simply _set_less_than then it's quite obvious from the name what the function is expected to do. A less-than should likely be enough I'll try to dream up a scenario where it wouldn't be.
Not the algorithm itself, only the functions it needs. The algorithms are inherently dependent on the properties of the collections they can work with, and those properties are more than this. I believe that the need by an algorithm for certain functions is an accurate way of expressing which properties it needs(*). Since all the functions are adequately abstracted and don't touch on the implementations in improper ways, it's also an abstract way.
In this view, you're saying that you wish to oversimplify the interface just to be able to make a simple rule that an algorithm that work on one collection will work on all (or on one of a few subsets). The backside is that you then also completely rule out both algorithms and types of collections that can be very useful on various subsets of each other.
Note that you can exploit the looks-like philosophy of the Pike type system to accurately check if a certain collection fits a certain algorithm, since it checks identifier by identifier that the class of the actual argument is compatible with the class of the formal argument.
I still believe it's better to have a few relatively limited interfaces that include the 90% most used types instead of having a lot that include 100%. Otherwise it will end up in a vast number of different types that only works with a few algorithms each because the one who made them just had a those algorithms in mind when the type was done. But you're right that the current way to categorise the ADTs might have been totally wrong and may be a better way to try to look at possible algorithms and try to see what they need and make a few interfaces, one for each type of algorithm, just try to keep it down to four or five interfaces, ten maximum. Still keep the collection, set, map and the others, but declaring most of the methods optional and put the restriction in the interfaces. Let try it out and see what it result in.
/ Peta, jo det är jag