% This is LLNCS.DEM the demonstration file of
% the LaTeX macro package from Springer-Verlag
% for Lecture Notes in Computer Science,
% version 2.4 for LaTeX2e as of 16. April 2010
%
\documentclass{llncs}
%
\usepackage{makeidx}  % allows for indexgeneration
\usepackage[pdftex]{graphicx}
%
\begin{document}
%
\mainmatter              % start of the contributions
%
\title{An OCL Map Type\thanks{%
      Copyright \copyright 2019 for this paper by its authors.
      Use permitted under Creative Commons License Attribution
      4.0 International (CC BY 4.0).}}
%
\titlerunning{An OCL Map Type}  % abbreviated title (for running head)
%                                     also used for the TOC unless
%                                     \toctitle is used
%
\author{Edward D. Willink}
%
\authorrunning{Edward Willink} % abbreviated author list (for running head)
%
%%%% list of authors for the TOC (use if author list has to be modified)
\tocauthor{Edward Willink}
%
\institute{Willink Transformations Ltd, Reading, England,\\
\email{ed\_at\_willink.me.uk}}


\maketitle              % typeset the title of the contribution
Lightning presentation at the 19th International Workshop in OCL and Textual Modeling, September 16, 2019, Munich, Germany.
%
\pagebreak
%
\section{An OCL Map Type - E.D.Willink}
OCL's family of \verb$Collection$ types is well known, but a \verb$Map(K,V)$ type is missing. Some distinguished authors have suggested that the deficiency can be remedied by a \verb$Set(Tuple(K, V))$, but this is clearly misguided since a \verb$Set(Tuple)$ can have many different-valued entries for the same key, whereas a map can only have one value per key.

The Java Map type is very familiar and might perhaps inspire an equally familiar library type for OCL, but this too is misguided since a Java Map is mutable while an OCL \verb$Map$ should be immutable.

The ordered \verb$Collection$s are therefore a better source of inspiration. The following have obvious functionality:

\verb$=$, \verb$<>$, \verb$isEmpty()$, \verb$notEmpty()$, \verb$size()$.

New \verb$keys()$ and \verb$values()$ operations can access the two halves of the map. 

Similarly obvious functionality with respect to the keys can be provided  by:

\verb$excludes(k)$, \verb$excludesAll(c)$, \verb$excluding(k)$,

\verb$excludingAll(c)$, \verb$includes(k)$, \verb$includesAll(c)$

Further emulation of ordered Collections suggests that \verb$at(k)$ accesses the map at index \verb$k$. \verb$including(k,v)$ creates a new map with an additional or replacement \verb$k<-v$ binding. It returns \verb$null$ for a null value and \verb$invalid$ for a missing value.

Richer support can be provided by:

\verb$excludesMap(m)$, \verb$excludesValue(v$), \verb$excludingMap(m)$,

\verb$includesMap(m)$, \verb$includesValue(v$), \verb$includingMap(m)$

Construction of a \verb$Map$ literal can re-use the \verb$Tuple$ literal syntax in conjunction with a new binding operator \verb$<-$. Thus a map literal with two entries for two value to key bindings my be created by:

\verb$Map{k1<-v1, k2<-v2}$

The above facilities were prototyped in Eclipse OCL 2015-06. They provide an adequate ability to use a \verb$Map$ but prove very inefficient for Map construction since creating a Map with \verb$N$ entries requires progressive construction of \verb$N-1$ intermediate maps; the execution performance is therefore at best quadratic. The Eclipse OCL 2019-03 release therefore extends the create/operation \verb$Map$ functionality with iteration support.

A \verb$Map$ is treated as a set of keys each with a bound co-value. All the standard \verb$Collection$ iterations apply to \verb$Map$s using the set of keys as the iteration domain. Additionally a co-iterator may be bound to the iterator to avoid the need to invoke \verb$at(k)$ to obtain the value of each key. Thus a map can be checked to ensure that each \verb$v$ bound to its \verb$k$ iterator is equal to the squared value of the iterator.

\verb$let c : Map(Integer, Real)$ \verb$= ...$ \verb$in c->forAll(k<-v | v = k*k)$

A new \verb$collectBy$ iterator, that may be used on \verb$Collection$s or \verb$Map$s, supports creation of a \verb$Map$ by collecting an expression value for each iterator key. A map from ten integer values to their squares may be built by:

\verb$Sequence{1..10}->collectBy(k | k*k)$

Future work might generalize \verb$k<-v$ from special purpose punctuation to an expression operator. The downside of this generalization is the cost/complexity of a new \verb$Entry(K,V)$ type for the new expression result and of course many new operations to allow an \verb$Entry$ type to be used sensibly. The upside is that the \verb$collectBy$ body may use let variables and may compute both key and value. A map that binds an integer value  to its string value could be built by: 

\verb$Sequence{1..10}->collectBy(k | k.toString()<-k)$ 

A consequence of permitting both key and value to be computed, is that, in general, uniqueness of the key values cannot be guaranteed. To avoid non-deterministic loss of colliding values, the \verb$Map$ parameterization would need to be a multimap: \verb$Map(K,Bag(V))$. 

\end{document}