proj-oot-ootAttributes

standard perspectives and attributes:

@meta:

__get __get label = returns the target of the arc labeled label (or should we return a set?) __set __set label value = set the target of the arc (returns new value of a copy of this node with the desired change, copy-on-write) __apply __apply fn = return the result of applying fn to this node __list __list = returns a list of targets of this node (umm, seems a bit redundant?) __arclist __arclist = returns a list of arcs originating from this node (umm, seems a bit redundant?) __label __def __def = function called when __get doesn't find any arcs with the desired label (defaults to (=NOT-FOUND), except for objects, where it defaults to a function that does inheritance) __nonnilish __nonnilish = function called to determine if this value is within type NN

only useful for arcs: __from __to

note: should all of the following be deleted, now that we have __apply which could look for them? i think so..

__in __in x = returns T if something === to x is a target of this node, F otherwise __count __count = returns the # of targets from this node __arc __arc label = returns the arcs labeled label (or should we return a set?) __any __any condition = returns T if there is some target of this node x such that (condition x) returns T __all __all condition = returns T if there is for every target of this node x, (condition x) returns T __map __map fn = maps fn over every target of this node (returns new value of a copy of this node with the desired change, copy-on-write) __foldr, __foldl __tuples __tuples = list of (label, target) for all arcs in __arclist

__undo undo side effects (for transactions) note: can this be unified with inverse?. There should be a type 'undoable'. The compiler should be able to automatically construct an __undo for something composed of __undoable parts. User output is normally not undoable, but debug output does not need to be undone (and so is trivially undoable).

also need a fromtuples constructor and a tuple cons or similar..

note: should __from and __to be __src and __dest? naw.. i'm guessing __to will be typed more than __from..

do we need to add __find? imagine something like

find(isOdd(data)) where data is an arbitrary lazy infinite dict

--

hmm i wonder if __get, __set could be unified with the common HTTP verbs?

GET, PUT, PATCH, DELETE, OPTIONS, HEAD, POST, TRACE, CONNECT

?

should mb also add CREATE

with the HTTP guarantees:

GET, HEAD, OPTIONS, TRACE (?) are "safe", e.g. they don't have side-effects

the safe methods plus PUT, DELETE are idempotent

of course, in addition to these simple formal properties they should also take the usual semantics

--

could also look at HTTP error codes for some ideas about built-in exception types

--

are perspectives like resource types? i doubt it; resource types seem like they "shouldn't" (although there's no rule against it) affect the topology of the results, only their format

if perspectives affected ONLY labels (both edge and node), not connectivity, then i could see it

--

also need cp and serialize and deepcp and mv and alias and lock

---

i guess we should have a 'primitive meta' view that allows you to access the underlying __get and __set, not overridable? but mb this should only be used internally?

---