Listas de diferencias en programación funcional

La pregunta ¿Qué hay de nuevo en estructuras de datos puramente funcionales desde Okasaki? , y la respuesta épica de jbapple, mencionó el uso de listas de diferencias en la programación funcional (en oposición a la programación lógica), que es algo que me ha interesado recientemente. Esto me llevó a encontrar la implementación de la lista de diferencias para Haskell. Tengo dos preguntas (perdóname / corrígeme si debo hacer dos preguntas diferentes en StackExchange).

La simple pregunta es, ¿alguien conoce la consideración académica de las listas de diferencias en la programación funcional y / o implementaciones además de la de la biblioteca Haskell? La respuesta de jbapple no dio una cita para las listas de diferencias (las listas de diferencias en la programación lógica existen en la tradición y en un par de fuentes que tengo Around Here Somewhere (TM)). Antes de encontrar la implementación de Haskell, no sabía que la idea había saltado de la lógica a la programación funcional. Por supuesto, las listas de diferencias de Haskell son una especie de uso natural de las funciones de orden superior y funcionan de manera bastante diferente a las de la programación lógica, pero la interfaz es ciertamente similar.

Lo más interesante (y mucho más difuso) sobre lo que quería preguntar es si el límite superior asintótico reclamado para la biblioteca de la lista de diferencias de Haskell mencionada anteriormente parece correcto / plausible. Mi confusión puede deberse a que me falta algo obvio sobre el razonamiento de complejidad con pereza, pero los límites reclamados solo tienen sentido para mí si la sustitución sobre una estructura de datos grande (o formación de cierre, o búsqueda variable, o algo ) siempre lleva tiempo constante. ¿O es la "captura" simplemente que no hay límite en el tiempo de ejecución para "cabeza" y "cola" precisamente porque esas operaciones pueden tener que pasar por un montón arbitrario de cálculos / sustituciones diferidos?

¿O es la "captura" simplemente que no hay límite en el tiempo de ejecución para "cabeza" y "cola" precisamente porque esas operaciones pueden tener que pasar por un montón arbitrario de cálculos / sustituciones diferidos?

Creo que eso es más o menos correcto. Sin embargo, los DL solo tienen operaciones de construcción rápidas, por lo que el arado es , donde m es el número de operaciones utilizadas para construir el DL.$\Theta(m)$$m$

La siguiente versión desfuncionalizada de algunas de las operaciones esenciales requiere pereza para , pero de lo contrario debería ser una forma directa de comprender los límites de complejidad que se reclaman en el original .$O(1)$ fromList

{-# LANGUAGE NoMonomorphismRestriction #-}

data DL a = Id
          | Cons a
          | Compose (DL a) (DL a)

fromList [] = Id
fromList (x:xs) = Compose (Cons x) (fromList xs)

toList x = help x []
    where help Id r = r
          help (Cons a) r = a:r
          help (Compose f g) r = help f $ help g r

empty = Id

singleton = Cons

cons x = append (singleton x)

append = Compose

snoc xs x = append xs (singleton x)

$\Theta(n)$headtail[a] -> [a]toList

Sí, los límites dependen de la suposición de que la composición de la función lleva tiempo constante. Básicamente, si tiene una lista de unión:

datatype 'a join = Nil | Cons of 'a * 'a join | Join of 'a join * 'a join

$O(n)$