This is about synergy in a few languages.
(2016)We interrupt this program to note a possible solution for several of these languages here.
I code a really dumb set abstraction in a few languages.
In each version one can add an element to a set and query membership.
Some versions also allow set union.
All these values are immutable.
The particular implementation is inefficient—a linked list of elements; we are concerned about efficiency of abstraction here, not efficient set representation.
Set union is significant here because it requires bringing two element lists together—synergy.
There is another dichotomy:
- A set of values and a set of operators for those values.
- A set of values each carrying ‘methods’ that one can invoke passing another value of the same ‘class’.
I prefer the former for its symmetry.
It has no impact on the syntax.
I am not aware of any fundamental semantics issues raised by this dichotomy
(except that the examples of the latter that I know (such as C++) do not provide creation of new classes at runtime).
My OCaml example is of this form.
- OCaml
-
The module type in OCaml is a class of types that have in common some abstract type called set a value em of that type, and a function from int & set to set, and another function of the same type.
The toy module here is called Set and is accessible only thru the filter of the module type Sett.
A module type is a compile time notion rather like a Java Interface.
It is string enough, I think, to allow for v-tables.
That a value of type set is a list of ints is not available at the call sites.
This code does not use the features referred to by the “O” of “OCaml”.
A more typical synergy app in OCaml.
Then see this!
- Scheme
-
I know of no Scheme except perhaps, Scheme48, that provides efficient synergy.
Given either of the two efficient synergy mechanisms that I am aware of (safe & seals) I propose to explore several object styles for Scheme.
I do not expect a correlation between synergy mechanism and object styles.
- In this version the set is delivered as a pair of functions, one to add, and one to query.
There is no union and thus no required synergy.
It is done by simple closures.
- Here we build on the safe apparatus and deliver a function from four symbols to four ‘methods’.
If s is such a pack then:
- ((s 'add) b) yields the set s∪{x}.
- ((s 'query) x) yields x∈s.
- ((s 'union) t) yields s∪t.
- (s 'badge) yields the badge for s and is both useless and harmless to anyone but those from the set clan who hold it closely.
There is a problem of invoking procedures from untrusted sources.
It may not return or it might return too many times.
I am not confident that my code continues to work correctly in the latter case.
At least in the former case I do not misbehave.
I shall assume for now a function once that takes a procedure and returns another procedure that never returns twice.
I leave for another time whether this needs to be primitive.
- C++
- See this.
Trying to understand this logic
A poor abstraction mechanism
A classic paper by James Morris