A Review of CLIM Presentation Types (Draft 5)

The Common Lisp Interface Manager specification, version 2 (CLIM 2) defines an architecture for an implementation-generic type system -- essentially. a type system orthogonal to the underlying Common Lisp Object System (CLOS) -- as namely, in the presentation types architecture defined in CLIM 2.

There might be a question that may occur, as in an inquisitively rhetorical manner, as to why the CLIM 2 presentation types system is defined in a manner essentially orthogonal CLOS, moreover independent of CLOS? One might speculate: At the time when CLIM 2 was developed as a specification, moreover at that time in the evolution of the Common Lisp software programming language, perhaps CLOS may not then have been regarded a it being a mature object system, sufficient for CLOS to be more thoroughly, if not singularly adopted for application in CLIM? Considering the development of the Metaobject Protocol (MOP) for CLOS implementation, in a sense of historic tiimelines, perhaps the development of the MOP specification and its subsequent publication -- that, as in The Art of the Metaobject Protocol (AMOP), also in the MOP implementation codified as PCL -- perhaps that may have served to lend more of a sense of codebase maturity for adoption of the CLOS specification.

Alternately, considering the syntax of CLIM 2 presentation type identities, perhaps a singularly CLOS-oriented architecture might not seem sufficient, without it being integrated with any number of implementation-specific details, as to the  nature of the implementation of the fundamental type system in any single Common Lisp implementation.

Inasmuch as CLIM may be furthermore adapted, if not centrally revised for alignment with CLOS and MOP, but of course such adaptations should be accompanied with some substantial documentation, as towards existing forms and adapted forms, and rationale, etc.

Reviewing a small number of albeit superficial qualities of the design of the CLIM presentation types system, one may arrive at any small number of observations. Towards developing an abstract model of CLIM, this article will make note of the following observations:

• CLIM 2 specifies behaviors for definitions of presentation type, presentation generic functions, and presentation methods
• The type identity of a presentation type may be specified with a syntax analogous to the syntax of conventional Common Lisp type specifiers.
• An orthogonal observation: Some implementation-specific features may be developed in an implementation of CLIM, such that for dispatching in selection of any one or more CLIM type specifiers, for any single value, a manner of "Presentation type matching algorithm" may be developed in extending directly of an implementation's underlying type system, as towards a concept of implementation-specific optimization in implementations of CLIM
• Prospectively, as may be correlated to the previous observation, a CLOS method specializer type may be developed -- albeit, in an implementation-specific manner -- for purpose of specializing CLOS methods onto ordinary Common Lisp type specifiers. Such a formal definition may be accompanied with a thorough description of  how the matching algorithm would be applied, in the implementation, for any single range of Common Lisp union, intersection, numeric, sequence, or other type specifiers. Towards a practical observation, perhaps it may be be a relatively straightforward endeavor, to develop such an extension onto CMU Common Lisp (CMUCL), or the highly specialized fork of CMUCL, Steel Bank Common Lisp (SBCL) -- that, as in referencing the ctypes architecture defined in CMUCL, furthermore inherited by SBCL. 
• The conventional `define-presentation-type` macro defined in CLIM 2 allows for definition of a presentation type with a quality of multiple inheritance -- albeit, as would be constrained to the set of presentation types defined in any single application of CLIM2. 
• In searching for an analogy to CLOS, perhaps it might be thought as that the inherits-from property might be viewed as it being analogous to the class-direct-superclasses accessor defined in MOP,  In a broad sense, it may be similar. 
• The CLIM 2 specification does not define any analogous processing for the inherits-from property, in any ways exactly analogous to class-direct-superclasses or the computation of a CLOS class' class precedence list.
• Considering the CLIM 2 presentation types system as a type system, effectively the CLIM 2 presentation types system provides a sort of presentational/interactive layer onto the entire Common Lisp Object System. As such, it might be understood if the CLIM 2 specification does not delve into so many implementation-specific conventions as might be required for defining any manner of inheritance among non-class data types -- e.g. does a hypothetical '(int 32)' extend of a hypothetical '(int 16)', in a "Subclass has a wider field" sense? or vice versa? or not at all? The semantics of such inheritance would be orthogonal to the functional characteristics of any manner of machine-local memory registers.
• Moreover, CLIM 2 does not appear to define any manner of an accessor for the property's value, for any single object or class as may represent a presentation type definition -- that is, to suggest that the information of the presentation type inherits-from property is effectively lost to any portable, implementation-generic forms, when define-presentation-type  is evaluated. That, in itself, could be revised with an implementation-specific adaptation of CLIM such as to store a value evaluated of the  inherits-from property and to provide that value for applications. Such divergences from CLIM2  should likewise be documented as such.
• The CLIM 2 specification defines a presentation type history property for presentation type definitions made with define-presentation-type. 
• This might seem to introduce something of an orthogonal, application-layer property to the fundamental presentation types system in CLIM.  
• In a functional sense, a presentation types history property may be applied within an application, as in regards to input recording for values input via a presentation type's accept method(s). 
• Although perhaps that may seem convenient for development of a CLIM application in any single-application Lisp process, but perhaps this property may be reconsidered as towards a small number of contexts:
• Multiuser computing environments -- if a CLIM application may be applied in a multi-user Common Lisp process, such that the Common Lisp process may serve multiple users simultaneously -- may therefore contain, at any one time, user data from multiple users
• Multiple applications in one process -- as for any single Common Lisp process providing multiple CLIM applications to a single user,
• In either of those instances, the generic presentation type history -- as a property defined of any single presentation type -- might be discarded by the implementation, in lieu of an application-specific and user-specific input recording functionality.
• This, of course, may serve to call a concern towards the broader input recording  mechanisms of CLIM, concerning privacy of user data in any potential applications of CLIM in any Lisp process providing a multi-user or multi-application environment 
• Considering, the parameters-are-types property -- as permitted in applications of define-presentation-type -- perhaps the nature of that property might seem a bit confusing, in some regards -- as to its processing for presentation type definitions made with define-presentation-type.  A small number of questions:
• What specific parameters does the property make reference to, as in  an evaluation of any single define-presentation-type form?
• Is there an example available, if not a single case study as for when those same parameters, in any instance, would not be presentation types?
• Looking ahead to when this article might address qualities of presentation functions and presentation methods, then considering a CLOS-based implementation of each, how would properties of CLOS method dispatching -- inasmuch as in a standard method dispatching, and other method dispatching forms specified in AMOP -- how would may any single manner of method dispatching affect the behaviors of a CLIM presentation method, in applications?

Certainly, the design of CLIM presentation types may permit much more of detailed review, as to further juxtapose CLIM presentation generic functions and presentation methods onto CLOS. 

Perhaps, furthermore, an extensional method dispatching framework may be developed for optimal method dispatching onto presentation methods. 

Presently, the author shall endeavor to review the author's own notes, to this point, in this article of discourse.

• Draft 1: Initial document
• Draft 2: Concerning the inherits-from property for define-presentation-type, making some little more of clarification as towards a juxtaposition onto CLOS
• Draft 3: Adding a note towards an analysis of conventions for method dispatching and, orthogonally, application behaviors in a CLOS/MOP implementation of CLIM presentation methods
• Draft 4: Once again beginning a thesis with regards to UML, SysML, and CLtL2, and CLIM
• Draft 5: Adding "A short listing of I/O forms in CLIM"

Appendix: A short listing of I/O forms in CLIM, indexed by feature

• gestures: stream-read-gesture, stream-unread-gesture
• presentation types: accept / present [Function] -- correspondingly, ... / stream-present, furthermore present-to-string, presentation-replace-input
• commands: read-command
• tokens: read-token / write-token
• strings (input substring replacement): replace-input
• presentation types (input replacement): presentation-replace-input

Appendix: Facilitating discussions of API design decisions, using UML and SysML

Although perhaps it may not represent the most popular of a topic for contemporary discussion, but considering it as a feature of the body of existing work in domains of computing and documentation, the Object Management Group (OMG) specifications for the Metaobject Framework (MOF) and correspondingly, the Unified Modeling Language (UML) and Systems Modeling Language (SysML) metamodels, in each, may be applied for some purposes in illustrating the compositions and behaviors of system elements, as in a system such as of the CLIM 2 specification itself, and in regards to any single implementation of CLIM 2.

Although it may require a substantial design effort -- perhaps, to no clearly popular results moreover -- a metamodel may be defined specifically for modeling of Common Lisp, the Language, 2nd edition (CLtL2) in UML and/or SysML. In a hypothetical extension of such a hypothetical metamodel, a model library may then be developed for describing CLIM2 itself -- in a manner extending of an original mettamodel for CLtL2 -- and a corresponding model library for describing any single implementation of CLIM2.

Alternate to developing a complete metamodel for CLtL2, an approach may be developed for producing an initial UML Profile for CLtL2, such that may extend of the UML and/or SysML metamodels. This approach -- though, to an estimate,, it may seem perhaps more tedious than the direct metamodel approach -- it may serve to allow for that a model developed in an application of the UML Profile could then be applied in any number of existing modeling tools -- such as for generation and analysis of software source forms -- such that any single modeling tool may provide any manner of support for applications of models applying either or both of the UML and/or SysML metaodels.

Not as though the UML Profile approach could not be in any ways tedious in itself, even so much as a simple list structured data type in Common Lisp may require a substantial diagram as to illustrate its complete syntax and possible syntactic variants, in UML. To that effect, the author wishes to make note to albeit an offhand study of some list-structured syntactic forms defined in ASDF,

As one possible benefit of such a work in systems modeling, it may then be relatively easier to present any of a component-oriented view of the behaviors of a CLIM 2 system, in a manner independent of Common Lisp syntax, in applying the resulting UML model library commensurate with documentation. In even more of a hypothetical "Long shot," proverbially: Such an effort in turn, could serve to facilitate a development of a CORBA application model for CLIM2, such that -- lastly -- could be applied in developing an interface onto any single graphical toolkit, in any of the body of existing work in desktop computer interface design, and moreover that could be applied in mobile computing platforms, without any of a specifically platform-centric API.

Of course -- continuing with the ad hoc metaphor -- that would be a long ways to go, to develop a SysML view of CLIM2. Clearly, the popular market may seem to favor much more of any number of immediately stylish applications. Common Lisp not being particularly stylish or immediate, it simply may not "Fit" with "The Modern Market."