The author has participated in a project  where the openness of Tedit and the Grapher played a central role. The project focussed on tools for the support of language development. Together the tools are called the Muir Environment . The most important aspect of the support came from syntax-directed editing. Tedit was used as the textual front end of the syntax-directed editor. It turned out to be possible to program the discipline of syntax-directed editing into Tedit, exclusively by using the programmatic interface of Tedit. The Interlisp source program, which implements Tedit, was never consulted or changed. The openness provided by the hooks of the programmatic interface was central to these efforts.
NoteCards  is a hypertext system on top of Interlisp. In a similar way to Muir, NoteCards is implemented on top of Tedit, Sketch, and the Grapher. The majority of the necessary extensions was done via the hooks and the functional interfaces of these tools. NoteCards is itself an open environment which can be adapted and tailored to the needs of its users . The programmatic interface of NoteCards (more than 100 Interlisp functions) plays an important role if a user wants to add new functionality to the system. However, hooks do not play any role in the programmatic interface of NoteCards. The interface is exclusively made up of functions, which are supposed to be called from the user's extensions to NoteCards.
Despite the importance of the hook mechanism in several Interlisp applications, Interlisp does not treat the mechanism in a systematic manner. There is no standard way to attach functions to hooks. It is common to attach functions to hooks when a tool is instantiated, but the details vary from tool to tool. In all tools, and independent of each other, the hook mechanism is explained at the level of its implementation, although it would have been clearer to introduce it once and for all, as an Interlisp feature.
Advising  is an Interlisp mechanism which is related to the use of hooks. An advice is an addition of a piece of program to a designated function. Any function can be advised; the function does not need to be prepared for the advice, and the source expression of the function does not need to be present. It is necessary to specify how the advice is related to the existing, and perhaps already advised function (before, around, or after the original function, together with the position of the advice relative to already existing advices).
Advising is typically used to repair errors or inconveniences in functions, which are not under direct control of the user. Advising may also be the basis for a programming style, which Sandewall calls insertive programming [19,18]. Following Sandewall, the essence of insertive programming is to consider a program as a skeleton and a number of amendments. An amendment may serve the purpose of attaching a procedure to a hook, but it is realized by patching the program rather than associating a function to a hook. Furthermore, Interlisp uses advising in the implementation of tracing and breakpoints.