mumuki / mulang

:bamboo: Universal, Multi Language, Multi Paradigm code analyzer
https://mumuki.github.io/mulang
GNU General Public License v3.0
124 stars 9 forks source link

within + count no cuenta llamadas recursivas #345

Open asanzo opened 2 years ago

asanzo commented 2 years ago

En este código:

function a(){ a() }

se cumple la expectativa within 'a' count(calls) == 0 y no debería, porque las calls deberían ser 1. ¿Quizás está relacionado con #334 ?

Es por eso que acá tuvimos que hacer la chanchada de hacer within 'a' count(calls) + count(calls 'a') para que diera el valor verdadero.

(por cierto QUE GROSO que tenga esas expresiones, el EDL es posta increíble) :clap: :clap: :clap:

flbulgarelli commented 2 years ago

(por cierto QUE GROSO que tenga esas expresiones, el EDL es posta increíble) clap clap clap

Gracias :smile:

La respuesta rápida es que no, no es un "bug" (si bien estamos de acuerdo en que no es el el comportamiento más feliz), dado que esto es así por diseño: las expectativas de Mulang siempre empiezan a analizarse en el propio nodo del AST y no en sus descendientes, y por eso cuando usás ciertos predicados (en este caso, estás usando implicitamente el predicado *, es decir, calls *) se excluye automáticamente al identificador usado en el scope (el within o through) de las opciones de búsqueda:

https://github.com/mumuki/mulang/blob/6c04e3e1816eed8925e1bb152b8ac9c03608b02e/src/Language/Mulang/Analyzer/EdlQueryCompiler.hs#L39-L50

En otras palabras, con la implementación actual, el "hack" que propusiste es la forma de implementar este chequeo.

Cambiar este comportamiento es trivial, pero tiene un impacto profundo que podría generar ambigüedad en ciertas expectativas, como por ejemplo:

within `a` declares function

Esto hoy en día se interpreta como si hay una declaración de función dentro del contexto de la declaración de a, lo cual daría falso en function a() {} y verdadero en `function a() { function b() {} } . Eliminando la restricción actual ambas expresiones pasarían a producir expectativas verdaderas. ¿Se podría cambiar esto de una forma más inteligente? Sí, claro, se podría hacer que no considere a la propia expresión sino sólo a su contenido, pero es tricky porque ciertas expectativas tienen sentido sólo cuando se analiza el nodo raíz (ejemplo: las relativas a aridad). En otras palabras, la forma correcta de resolver esto requeriría que cada expectativa, en su definición, incluya información sobre dónde empezar a analizar cuando está contextualizada, lo cual es un refactor grande.