¿Por qué no hay más idiomas que admitan comentarios recursivos / anidados? [duplicar]

El problema es que los comentarios recursivos lo obligan a analizar en realidad la sección de comentarios, empujándola fuera del alcance de un lexer normal y posiblemente introduciendo más problemas.

Como actualización: un compilador generalmente tiene varias etapas distintas con diferentes trabajos, y las primeras etapas son el lexer, que obtiene el programa de entrada y lo separa en una secuencia de tokens (cada una de las cuales contiene una palabra clave). identificador o un operador), y el analizador, que estructura esta secuencia de tokens en un árbol de sintaxis abstracta (AST).

Para el alcance de un lexer, recuerde que el lexing normalmente se puede hacer con expresiones regulares. Las estructuras similares a corchetes, como los comentarios recursivos, no pueden analizarse mediante expresiones regulares (ver gramáticas sin contexto), por lo que el lexer tendría que tener mucha complejidad adicional, por ejemplo. tendría que implementarse a través de un analizador de descendencia recursiva.

Además, para C y lenguajes similares (quienes usaron la sintaxis de comentario / ** / más famoso) nunca surgió la necesidad de comentar grandes trozos de código, ya que tenían el preprocesador y los fragmentos de código no utilizados. por

#if 0
....
#endif

que evitó el problema de análisis delegando el problema a un segundo compilador mucho más simple (el preprocesador).

Resumiendo: dado que los comentarios recursivos harían que la compilación sea más complicada, generalmente no está permitida, y solo los idiomas con comentarios de estilo C, pero sin un preprocesador, realmente lo necesitan. El hecho de que Java esté entre ellos es desafortunado, por supuesto.

Editar: Esto no significa que los comentarios recursivos sean imposibles o incluso muy difíciles de hacer. Podría usar un lexer de descenso recursivo o podría tener un preprocesador antes del lexer para filtrar los comentarios. Sin embargo, ambos enfoques tienen un costo considerable en comparación con el modelo estándar (use RE para generar automáticamente el lexer y un EBNF para generar automáticamente el analizador), y la ganancia es bastante pequeña.

Estoy contigo en esto. Cuando trabaja con bases de código grandes y antiguas, entonces están llenas de comentarios sobre hacks, código comentado, y otras cosas sucias, por no mencionar las interfaces de C documentadas en los comentarios /*...*/ . Si necesitas comentar algo de eso, usar /*...*/ comentarios casi nunca es una opción, porque no se anidan.

Tampoco creo que "complicar aún más el compilador" sea una razón, porque en comparación con la complejidad de C ++, el análisis de los comentarios para /* , */ (y quizás // ) debería ser ridículamente fácil. De hecho, me parece recordar que Borland C ++ (en los años 90) ofreció la opción de analizar comentarios anidados, y ese compilador solía ser conocido por su velocidad de iluminación.

Pero el problema con las soluciones no estándar es que no puede usarlas si es posible que tenga que portar su código más adelante. (Y, en C ++, ¿quién descartaría eso alguna vez?)

Entonces estoy de acuerdo en que sería una mejora si se estandarizara.

Mientras tanto, uso // comentarios para comentar fragmentos de código. Afortunadamente, la mayoría de los editores / IDE modernos tienen la opción de aplicar esto a varias líneas a la vez.

He modificado un compilador de C para hacer esto una vez, no fue terriblemente difícil. Todo está cuidado en el escáner léxico, para que no tenga que andar con las entrañas del analizador. En realidad, solo se trata de mantener un seguimiento del nivel de anidamiento e ignorar cualquier cosa dentro de los delimitadores de cadena.

Newspeak tiene comentarios estructurados que pueden anidar. Y tiene una gramática muy simple, por lo que obviamente no es "engañosamente complejo".

Los comentarios que se extienden sobre varias líneas deben ser la excepción, no la regla.

Incluso en C, uso el estilo C ++ // en lugar del estándar /* */ .

Si es absolutamente necesario comentar una gran parte del código, uso la directiva #if 0 preprocesador, que admite el anidamiento.

Esto es recursión:

public void recursion()
{
    recursion();
}

No tengo idea de cómo serían los comentarios recursivos.

Los comentarios anidados, por otro lado, tendrían sentido y, de hecho, ya funcionan hasta cierto punto. Puede anidar comentarios de una sola línea dentro de varios comentarios de línea.

/* No longer use this!
// This is a method.
public void method()
{
}
*/

Apoyar lo que está preguntando, desde el punto de vista del programador, tendría mucho sentido.

/* No longer use this!
// This is a method.
public void method()
{
    /* Disabled!
       doInterestingStuff();
       ...
    */
}
*/

Teniendo en cuenta que los lenguajes de programación son solo herramientas en las que los programadores pueden expresar sus intenciones, apoyar esta intención sería un valor agregado.

No puedo comentar los aspectos técnicos de memoria, pero parece que algunas de las respuestas ya proporcionaron información al respecto.

Una razón es probablemente la compatibilidad con las bases de código existentes; Los lenguajes similares a C suelen hacer todo como C, incluso cosas estúpidas como 031 == 25 (literales octales, ¿quién los ha necesitado?)

Otra razón es más filosófica: un comentario comienza con (por ejemplo) / * y termina con el siguiente * /, y lo que sea que esté entre ellos, no importa en absoluto . Los comentarios anidados también requieren definir una sintaxis para los comentarios.

Por cierto, si ya no necesita ese código de pieza, ¿por qué no lo elimina por completo y lo deja en el VCS para mantener la versión anterior? El código comentado es un olor de código.