Transformacin de Programas Declarativos

1
Transformación de Programas Declarativos

• David San José Alfaro

2
Índice

• Resumen Histórico
• Objetivo
• Transformación de Programas
• Estrategia de Composición
• Fases de la Composición

3
Índice
4
Resumen Histórico

• Los lenguajes de programación declarativos han
  sufrido durante su historia el estar siempre por
  detrás de los lenguajes de programación
  imperativos.
• Estos últimos han sido y son los lenguajes más
  usados por los desarrolladores de aplicaciones,
  dejando la utilización de otros paradigmas de
  programación, como el caso de la programación
  declarativa al ámbito del aprendizaje y la
  investigación universitaria.

5
Resumen Histórico

• Por qué razón son menos usados?
• Desde la aparición de los lenguajes imperativos
  todos los sectores de desarrollo de hardware y
  software se centraron en ellos.
• Siempre se veía a los lenguajes declarativos como
  algo más matemático que mecánico.

6
Resumen Histórico

• Y todo esto, a pesar de que los lenguajes
  declarativos mantienen estructuras muy semejantes
  a las que utiliza nuestro propio cerebro para
  tratar datos, expresiones, etc, que sus
  semejantes imperativos.
• Basta con ver las múltiples variantes del
  Append en su uso.

7
Resumen Histórico

• Debe ser, por tanto, muy poderosa la razón por la
  que se dejó de lado este tipo de lenguajes. Y así
  es.
• La traba más importante de los lenguajes
  declarativos, es su alto coste operacional.
• Cierto es que parte de esta debilidad deriva del
  hecho de que la construcción de computadores ha
  facilitado desde siempre la programación
  imperativa, pero esto no constituye al arreglar
  el problema.

8
Resumen Histórico

• Veamos un ejemplo. Vamos a realizar la unión de
  tres listas con el programa Prolog.
• Lo más fácil para la obtención de la solución,
  pasa por crear un programa que llame al programa
  append 2 veces, a la que llamaremos
  doubleappend.
• Así pues
• doubleappend(A,B,C,S)-append(A,B,E),
  append(E,C,S).

9
Resumen Histórico

• Lo que a primera vista parecía la solución mas
  sencilla se transforma en un problema cuando
  vemos que su coste operacional es del orden de
  O(2AB) en vez de O(AB) que esperábamos.
• Afortunadamente(en este caso), vemos que la
  solución es sencilla(no siempre ocurre así) y
  bastaría con cambiar el programa doubleappend
  por el siguiente.

10
Resumen Histórico

• El nuevo cuerpo del programa será
• doubleappend(,A,B,S)-append(A,B,S).
• doubleappend(HT,A,B,HS)-
• doubleappend(T,A,B,S).
• Se puede ver como el programador se lo ha tenido
  que currar ? para obtener el programa en su
  versión más óptima. Y ahí es donde entramos
  nosotros.

11
Resumen Histórico

• Lo que intentamos encontrar es un programa que
  acepte como entrada la primera versión de
  doubleappend(la que expresivamente parece la
  más correcta).
• Y que el programa, por si solo, sea capaz de
  encontrar la versión más eficiente posible del
  código original sin que el programador deba
  inmiscuirse demasiado(utópicamente nada) en el
  proceso de obtención del nuevo cuerpo del
  programa doubleappend.

12
Resumen Histórico

• Así pues, un área de investigación todavía
  abierta es la que busca dotar a los lenguajes
  integrados de una mayor eficiencia.
• Esto pasa por la mejora de los mecanismos
  operacionales de base, pero también por el
  desarrollo de técnicas y herramientas que ayuden
  al programador a manipular y optimizar sus
  programas.
• Una de esas técnicas es la transformación
  automática de programas.

13
Resumen Histórico

• Dado un programa P una técnica de transformación
  de programas consiste en construir un nuevo
  programa P' que computa los mismos resultados que
  el programa original P pero mejorando alguna de
  las propiedades de éste.
• El aumento en la eficiencia de los programas es
  uno de los objetivos más perseguidos por la
  transformación de programas.

14
Resumen Histórico

• Recopilando, para solucionar el excesivo coste
  operacional, tenemos 2 alternativas
• Una consistiría en empezar a construir
  computadoras específicamente declarativas, pero
  esto resulta costoso en exceso.
• Y la segunda y más viable, que consistiría en la
  transformación de programas declarativos, que
  manteniendo intacta su semántica se ejecutaran
  más rápido que sus homólogos no transformados,
  hasta acercarse a las cotas de rendimiento de los
  programas imperativos.

15
Objetivo

• El objetivo que trataremos de buscar será el
  estudio de una o varias estrategias de
  transformación de programas declarativos.
• La realización de los mismos se llevará a cabo
  para el lenguaje declarativo lógico-funcional
  Curry(que vimos ayer y que incorpora un mecanismo
  operacional híbrido que permite integrar tanto el
  narrowing necesario como la residuación), y para
  el entorno de aplicación Synth(que veremos ahora).

16
Transformación de Programas Estrategia de
Composición

• La base de la Transformación se basa en la
  aplicación de unas Reglas, según unas Estrategias
  existentes.
• La aplicación de un estrategia, como pueden ser
  Composición o Tupling, genera una secuencia de
  programas equivalentes obtenidos de los
  precedentes por uso de las reglas básicas de
  transformación como son el Plegado, Desplegado,
  Abstracción, etc.
• Por tanto, una Estrategía es la concatenación
  ordenada de varias Reglas de Transformación con
  unos fines específicos.

17
Transformación de Programas Fases de la
Composición

• Como ejemplo de Estrategia de Transformación
  vamos a ver la Composición.
• Las reglas que aplicaremos durante la
  transformación de programas declarativos basada
  en la Composición serán
• Introducción de una definición(también llamada
  Fase de Obtención del Eureka)
• Desplegado
• Normalización
• Plegado

18
Transformación de Programas Problema de Fibonacci

• El problema en cuestión será el de la Serie de
  Fibonacci(el de los conejitos ?), basada en los
  números de Peanno.
• El programa en Curry quedaría
• fib z s z
• fib (s z) s z
• fib (s (s A)) Suma ((fib (s A)), (fib A))
• Empezamos con el proceso de Transformación

19
Fase de Introducción de una Definición o Eureka

• Introducción de una definición
• Sea (R0,...,Rk),Kgt0 una secuencia de
  transformación.
• Permite la obtención de cualquier programa Rk1
  por adición a Rk de una nueva regla (regla de
  definición o eureka) de la forma
  , donde f es un nuevo símbolo funcional no
  perteneciente a la secuencia R0,...,Rk y
  .
• Nos queda por tanto una nueva regla
• 4. newL A ((fib (s A)) , (fib A))

20
Fase de Desplegado

• El desplegado de un programa declarativo se
  entiende en general como el proceso en virtud del
  cual una regla (o cláusula) del mismo es
  sustituida por un nuevo conjunto de reglas
  obtenidas a partir de la original, sobre la que
  se realiza uno (o varios) pasos de ejecución
  simbólica.
• Este tipo de ejecución se refiere a un tipo de
  evaluación donde, en ausencia de datos reales, se
  ejecutan llamadas simbólicas.

21
Fase de Desplegado

• Por tanto, la idea básica de toda operación de
  desplegado consiste en efectuar esta clase de
  evaluación simbólica.
• Pero ya no sobre un objetivo, sino sobre el
  cuerpo (o la parte derecha de la cabeza) de una
  regla del programa.

22
Fase de Desplegado

• Así pues, según el tipo de paradigma declarativo
  que estemos considerando (lógico puro, funcional
  puro o lógico-funcional) se trabaja con un
  mecanismo operacional diferente (resolución SLD,
  reescritura o narrowing, respectivamente) sobre
  el que basar la computación simbólica e
  implementar el desplegado.

23
Fase de Desplegado

• Veamos el desplegado sobre la regla o Eureka
  generado. Desplegamos R4
• 4. newL A ((fib (s A)) , (fib A))
• Obtenemos las reglas R5 y R6
• 5. newL z ((s z) , (fib z))
• 6. newL (s A) ( Suma ( (fib (s A)),(fib(A)) )
  , (fib (s A)) )
• Ahora sería necesario ver si es posible realizar
  alguna normalización a las nuevas reglas
  generadas en el proceso de desplegado.

24
Fase de Normalización

• Realmente, la normalización es un caso particular
  del propio desplegado, pero así queda más claro.
• La normalización es necesaria en los casos en que
  podamos sustituir el valor de una función,
  obtenida en el desplegado, por un valor constante
  de forma directa.
• Normalizando la regla R5(que por tanto quedará
  eliminada), obtenemos R7, donde se produce la
  sustitución fib z ? s z
• 7. newL z ((s z) , (s z))

25
Fase de Plegado

• La regla de plegado junto con la de desplegado
  constituyen el núcleo de todo sistema de
  transformación.
• Aunque sólo de aquellos sistemas de
  transformación basados en la contracción o
  expansión de subexpresiones dentro de un programa
  usando las definiciones del mismo.
• Existen otros sistemas de transformación basados
  en otras ideas que no veremos.

26
Fase de Plegado

• Aunque con algunas matizaciones, en general, la
  transformación de plegado de un programa
  declarativo se considera la operación inversa de
  la transformación de desplegado.
• Es decir, se espera que un paso de desplegado
  seguido del paso de plegado correspondiente (y
  viceversa) devuelva el programa inicial (o
  prácticamente el mismo).
• Sin embargo, es necesario hacer algunas
  puntualizaciones respecto a este hecho.

27
Fase de Plegado

• Para conseguir el efecto comentado de
  inversibilidad o reversibilidad total, es
  necesario exigir, como mínimo, que todas las
  reglas involucradas en una transformación de
  plegado pertenezcan al mismo programa.
• Además se necesita poder plegar un conjunto de
  reglas simultáneamente para obtener una única
  regla transformada.

28
Fase de Plegado

• Vemos que esta última condición es justo la
  contraria a la que se verifica en el desplegado
  (donde una sola regla se despliega originando un
  conjunto de reglas desplegadas).
• Estas condiciones no son siempre requeridas a
  la hora de definir algunos tipos de plegado, lo
  que da lugar a distintas variantes de esta
  operación que poseen una capacidad desigual con
  respecto a su potencial para la optimización de
  programas.

29
Fase de Plegado

• En términos generales, si el desplegado de una
  regla (cláusula) en un programa funcional
  (lógico) reemplaza una llamada a función (átomo)
  por su respectiva definición o parte
  derecha(aplicando la correspondiente
  sustitución), ENTONCES a la inversa el plegado
  reemplaza un cierto fragmento de código por la
  llamada a función (átomo) apropiada.

30
Fase de Plegado

• Veamos el plegado en nuestro programa
• El plegado se realizará en todas aquellas reglas
  que posean en el cuerpo la parte derecha del
  Eureka, es decir, el subtérmino ((fib(s A)),(fib
  A)).
• En este caso son las reglas R6 y R3 las que
  plegaremos usando el eureka R4

4. newL A ((fib (s A)),(fib A)) 6. newL (s A)
( Suma ( (fib (s A)),(fib(A)) ) , (fib (s A)) )
4. newL A ((fib (s A)),(fib A)) 3. fib (s
(s A)) ( Suma ((fib (s A)), (fib A)) )
31
Fin Fase de Plegado

• El resultado son las Reglas R8 y R9
• 8. newL (s A) ( Suma ( newL A ) , (fib (s
  A)) )
• 9. fib (s (s A)) ( Suma ( newL A ) )
• Así queda terminado el proceso de transformación,
  pues ya se han hecho la Obtención del Eureka, el
  Desplegado, la Normalización y el Plegado.
• Eliminamos aquellas reglas sobrantes (R3, R6 y
  R5) nos queda el nuevo programa completo.

32
Fin Fase de Plegado

• Las reglas del nuevo programa de Fibonacci, una
  vez transformado, serían
• 1. fib z s z
• 2. fib (s z) s z
• 4. newL A ((fib (s A)) , (fib A)) -----------gt
  (Eureka)
• 7. newL 0 ((s z) , (s z)) ---------gt
  (Normalización)
• 8. newL (s A) ( Suma ( newL A ) , (fib (s A)) )
  -gt(F)
• 9. fib (s (s A)) ( Suma ( newL A )
  ----------------gt(F)

33
Fin Fase de Plegado

• Antes de continuar, cabe señalar que el proceso
  de plegado es menos dependiente no ya sólo del
  paradigma declarativo que estemos considerando
  (lógico puro, funcional puro o lógico-funcional)
  sino también del mecanismo operacional asociado a
  las computaciones (resolución SLD, reescritura o
  narrowing, respectivamente).
• Por eso, se suelen estudiar los distintos casos
  de Plegado en función de su reversibilidad y no
  en función de los distintos mecanismos asociados
  a las distintas computaciones posibles.

34
Otros Ejemplos

• La Estrategia de Composición es útil en aquellos
  casos donde una función consume a otra. Veamos
  otro ejemplo
• Ej. Supongamos que queremos un programa Curry que
  tome como entrada un árbol binario y queremos que
  nos devuelva el mismo árbol pero en orden
  simétrico.

35
Otros Ejemplos

• Ejemplo

36

• Haciendo cuentas podríamos pensar que el orden de
  complejidad del algoritmo, en el mejor de los
  casos es como mínimo de O(n) o como mucho O(log
  n).
• Pero viendo el ejemplo anterior, qué creéis que
  ocurriría si realizásemos la siguiente llamada al
  programa Sim que obtiene el árbol simétrico a
  uno dado como parámetro?
• Sim(Sim(A))

37
Otros Ejemplos

• Evidentemente el árbol se quedaría como estaba
  inicialmente, pero el tiempo tardado en
  construirlo sería 2 veces la complejidad de
  Sim.
• Este es uno de los problemas que soluciona la
  Estrategia de Composición (recordad, cuando una
  función consume a otra). Otras Estrategias
  solucionan otro tipo de problemas específicos.

38
SYNTH

• Vista la parte teórica, pasamos a ver el programa
  SINTH.
• Synth es un sistema de transformación de
  programas que sigue la aproximación reglas
  estrategias.
• El sistema permite optimizar programas escritos
  en Curry a través de varias Estrategias de
  Transformación de programas como Composición o
  Tupling.

39
SYNTH

• Veamos algunos problemas con sus resultados
  obtenidos en órdenes de complejidad.
• Obtener la Lista de los Factoriales de un numero,
  tiene O(n2) y a través del algoritmo de Tupling
  obtenemos un programa optimizado de orden lineal.
• Uno de los programas donde mejores resultados se
  han obtenido es el de Fibonacci, que posee O(2n)
  y a través de la Composición y de el Algoritmo de
  Formación de Tuplas o Tupling se consigue bajar
  la complejidad hasta nada menos que orden Lineal.

40
Conclusiones

• Comparado con las aproximaciones anteriores en el
  campo de la programación lógico funcional, los
  avances realizados con este tipo de
  estrategias(Composición, Formación de Tuplas,
  etc) son muy esperanzadores e incitan a seguir
  trabajando y evolucionando este proyecto en el
  que aun nos encontramos.

41
Conclusiones

• En concreto, el proyecto que actualmente se está
  desarrollando es la optimización de la Estrategia
  de Formación de Tuplas, aunque existen muchas
  vías pendientes que introducir a SYNTH como
  Fuzzyficación, Obtención de órdenes de
  complejidad de los algoritmos introducidos, etc.