5 votos

Gramática libre de contexto + funciones = ?

Si empieza con las reglas para construir una gramática libre de contexto y las amplía permitiendo que los no terminales de la izquierda sean funciones de uno o más argumentos, ¿va eso más allá de la definición de una gramática libre de contexto? Si es así (imagino que sí), ¿de qué clase de gramáticas se trata? ¿Sensible al contexto?

Para aclararnos, supongamos que tenemos la siguiente gramática:

$S \to F(a,b,c)$
$F(x,y,z) \to xyz$

La gramática anterior es equivalente a la siguiente porque x, y y z se sustituyen:

$S \to abc$

Supongamos ahora que aprovechamos la capacidad de la función con la siguiente gramática:

$S \to F(\epsilon)$
$F(x) \to x\ a\ |\ x\ a\ F(x\ b)$

( $\epsilon$ significa cadena vacía)

Esa gramática produce:

a
aba
ababba
ababbabbba
...

Una aplicación práctica de las funciones en una gramática es expresar un lenguaje informático con formato de sangría. Un ejemplo trivial:

statement(indent)
    : indent basic_statement
    | indent header ':' newline statement_list(indent whitespace)
statement_list(indent)
    : statement(indent)*

Esto significa que una sentencia, dada una cadena de indentación, puede ser de una sola línea (por ejemplo, print 'hola') o puede ser un encabezado (por ejemplo, if (x == 5)) seguido de ':', una nueva línea y una o más sentencias hijas de un nivel de indentación mayor.

Tenga en cuenta que statement_list tiene que salir por sí mismo aquí, ya que statement(indent whitespace)* podría producir líneas hijas con sangrías inconsistentes si el espacio en blanco se expande a algo no constante. Llamando a statement_list una vez con la posible variable whitespace, obligamos a todas las sentencias hijas a tener exactamente la misma sangría. Una vez más, las funciones vienen al rescate.

Para ser más específico sobre las reglas del sistema gramatical del que hablo:

  • La parte izquierda de cada regla es un terminal, un no terminal o una declaración de función para cero o más argumentos.
  • Una función de argumentos cero equivale a un no terminal.
  • Los argumentos de una declaración de función deben ser variables individuales (yo he utilizado $x$ , $y$ y $z$ en los ejemplos anteriores).
  • Los argumentos de una "llamada a función" (utilizada en el lado derecho de una regla) pueden contener terminales, no terminales y llamadas a función anidadas.
  • Los argumentos de una llamada a función se expanden antes de pasarlos. Por lo tanto, las funciones en este sistema gramatical no son superiores al primer orden (si estoy utilizando el término correctamente).

Entonces, añadiendo "funciones" a CFG, ¿qué obtengo?

4voto

Sekhat Puntos 2555

Ya que puede pasar funciones no arbitrarias a las funciones, puede codificar las gramáticas de van Winjgaarden (también conocidas como gramáticas de dos niveles) con su formalismo, lo que hace que el análisis sea un problema indecidible.

Una advertencia: no estoy seguro de lo que quiere decir con "los argumentos de una llamada de función se expanden antes de pasar". Si pasa un no recursivo no terminal como argumento, se puede expandir infinitamente.

3voto

Jakub Šturc Puntos 12549

La mayoría de los formalismos gramaticales se eligen para el análisis sintáctico porque admiten implementaciones eficientes como algún tipo de autómata. La implementación de un autómata es deseable porque ofrece límites precisos de la complejidad temporal y espacial de la implementación en función de la longitud de la entrada (n) y de la profundidad de anidamiento de la expresión de entrada (d). Por ejemplo, el GLR de Tomita utiliza un espacio O(d), mientras que el análisis sintáctico de Packrat utiliza un espacio O(n). Para las entradas generadas por humanos, O(d) es efectivamente O(1).

Los límites estrictos y precisos son más importantes en el análisis sintáctico que en la mayoría de las demás áreas, porque suele darse el caso de que el programador que utiliza el analizador sintáctico generado (por ejemplo, la persona que ejecuta "yacc") no entiende el algoritmo de análisis sintáctico, y no podrá saber qué entradas provocarán un comportamiento patológico (en el tiempo o en el espacio) para su gramática. Además, la persona que utiliza el analizador sintáctico (la persona que ejecuta el programa que incluye el código generado por "yacc") es aún menos probable que entienda esto, por lo que si surge un comportamiento patológico, lidiar con él será especialmente difícil. Por lo tanto, es importante tener buenos límites de tiempo y espacio en el peor de los casos, ya que son probablemente todo lo que se puede confiar.

Además, dado que el analizador sintáctico suele ser el primero de una secuencia de operaciones realizadas sobre la entrada, su complejidad temporal/espacial establece un límite inferior a la complejidad temporal/espacial de toda la operación. No conviene utilizar un algoritmo O( $n^3$ ) como interfaz de un analizador sintáctico en tiempo O( $n\log n$ ). Para maximizar la aplicabilidad de su trabajo, los investigadores en análisis sintáctico y lenguajes formales tienden a imponerse límites superiores bastante estrictos.

En este caso está bastante claro que cualquier formalismo que pueda manejar su gramática va a tener una complejidad temporal extremadamente grande en el peor de los casos, por lo que puede valer la pena buscar un formalismo más débil que siga siendo capaz de hacer el trabajo. Yo sugeriría que se buscaran gramáticas booleanas; tienen la misma complejidad temporal y espacial que las GLR, aunque pueden manejar estructuras no libres de contexto. Codificar la sangría en una gramática booleana puede ser un poco complicado, pero el resultado es bastante eficiente. Los analizadores Packrat pueden ser otra opción, pero la complejidad espacial a menudo se convierte en un problema una vez que se intenta escalar a entradas grandes del "mundo real"; esto puede ser insidioso porque no te encuentras con la desagradable sorpresa hasta que ya has invertido mucho trabajo en desarrollar el analizador.

2voto

domotorp Puntos 6851

Sus reglas no me son completamente claras, pero el lenguaje que usa como ejemplo (con ababbabbba) no es un lenguaje libre de contexto, ya que no satisface el lema de bombeo , por lo que puede ir más allá de los idiomas libres de contexto.

2voto

Bruce Puntos 113

Eche un vistazo a los dos siguientes artículos de Engelfriet y Schmidt:

@article{engelfried: autor = {J. Engelfriet y E. M. Schmidt}, title = {{IO} y {OI}. [ ] revista = JCSS, volumen = [ ] año = 1977 }

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X