annotate src/expl_rename.sig @ 2219:ff38b3e0cdfd

Add interface to UnionFind.
author Ziv Scully <ziv@mit.edu>
date Mon, 24 Nov 2014 20:41:24 -0500
parents 210fb3dfc483
children
rev   line source
adam@1989 1 (* Copyright (c) 2014, Adam Chlipala
adam@1989 2 * All rights reserved.
adam@1989 3 *
adam@1989 4 * Redistribution and use in source and binary forms, with or without
adam@1989 5 * modification, are permitted provided that the following conditions are met:
adam@1989 6 *
adam@1989 7 * - Redistributions of source code must retain the above copyright notice,
adam@1989 8 * this list of conditions and the following disclaimer.
adam@1989 9 * - Redistributions in binary form must reproduce the above copyright notice,
adam@1989 10 * this list of conditions and the following disclaimer in the documentation
adam@1989 11 * and/or other materials provided with the distribution.
adam@1989 12 * - The names of contributors may not be used to endorse or promote products
adam@1989 13 * derived from this software without specific prior written permission.
adam@1989 14 *
adam@1989 15 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
adam@1989 16 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
adam@1989 17 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
adam@1989 18 * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
adam@1989 19 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
adam@1989 20 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
adam@1989 21 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
adam@1989 22 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
adam@1989 23 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
adam@1989 24 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
adam@1989 25 * POSSIBILITY OF SUCH DAMAGE.
adam@1989 26 *)
adam@1989 27
adam@1989 28 (* To simplify Corify, it helps to apply a particular kind of renaming to functor
adam@1989 29 * bodies, so that nested functors refer only to fresh names. The payoff is that
adam@1989 30 * we can then implement applications of those nested functors by evaluating their
adam@1989 31 * bodies in arbitrary later contexts, even where identifiers defined in the
adam@1989 32 * outer functor body may have been shadowed. *)
adam@1989 33
adam@1989 34 signature EXPL_RENAME = sig
adam@1989 35
adam@1989 36 val rename : {NextId : int,
adam@1989 37 FormalName : string,
adam@1989 38 FormalId : int,
adam@1989 39 Body : Expl.str} -> int * Expl.str
adam@1989 40
adam@1989 41 end