¿Por qué los lenguajes de programación no permiten espacios en los identificadores?

https://stackoverflow.com/questions/1805030

05-07-2019
|

Pregunta

Esto puede parecer una pregunta tonta, pero aún no sé la respuesta.

¿Por qué los lenguajes de programación no permiten espacios en los nombres (por ejemplo, nombres de métodos)?

Entiendo que es para facilitar (permitir) el análisis, y en algún momento sería imposible analizar nada si se permitieran espacios.

Hoy en día estamos tan acostumbrados a ello que la norma no es ver espacios.

Por ejemplo:

 object.saveData( data );
 object.save_data( data )
 object.SaveData( data );
 [object saveData:data];

etc.

Podría escribirse como:

 object.save data( data )  // looks ugly, but that's the "nature" way.

Si es solo para análisis, supongo que el identificador podría estar entre . y (, por supuesto, los lenguajes de procedimiento no podrían usarlo porque hay no '.' pero OO do ..

Me pregunto si el análisis es la razón única , y si lo es, qué tan importante es (supongo que será y será imposible hacerlo de otra manera, a menos que todo el lenguaje de programación diseñadores solo ... olvida la opción)

EDIT

Estoy de acuerdo con los identificadores en general (como el ejemplo de Fortran) es una mala idea. Reduciendo a los idiomas OO y específicamente a los métodos, no veo (no quiero decir que no haya) una razón por la que debería ser así. Después de todo el . y el primer ( se pueden usar.

Y olvida el método saveData , considera este:

key.ToString().StartsWith("TextBox")

como:

key.to string().starts with("textbox");

Solución

Antes de que el intérprete o compilador pueda construir un árbol de análisis, debe realizar un análisis léxico, convirtiendo el flujo de caracteres en un flujo de tokens. Considere cómo desearía el siguiente análisis:

a = 1.2423 / (4343.23 * 2332.2);

Y cómo funcionaría tu regla anterior. Es difícil saber cómo lexificarlo sin entender el significado de los tokens. Sería muy difícil construir un analizador que hiciera la lexificación al mismo tiempo.

Otros consejos

Se debe a que dosul d makepa rsing suc hcode reallydif ficult.

Utilicé una implementación de ALGOL (c. 1978) que (extremadamente molesto) requirió una cita de lo que ahora se conoce como palabras reservadas , y espacios permitidos en los identificadores:

  "proc" filter = ("proc" ("int") "bool" p, "list" l) "list":
     "if" l "is" "nil" "then" "nil"
     "elif" p(hd(l)) "then" cons(hd(l), filter(p,tl(l)))
     "else" filter(p, tl(l))
     "fi";

Además, FORTRAN (la forma en mayúscula significa F77 o anterior), era más o menos insensible a los espacios. Así que esto podría ser escrito:

  799 S = FLO AT F (I A+I B+I C) / 2 . 0
      A  R E  A = SQ R T ( S *(S - F L O ATF(IA)) * (S - FLOATF(IB)) *
     +     (S - F LOA TF (I C)))

que era sintácticamente idéntico a

  799 S = FLOATF (IA + IB + IC) / 2.0
      AREA = SQRT( S * (S - FLOATF(IA)) * (S - FLOATF(IB)) *
     +     (S - FLOATF(IC)))

Con ese tipo de historial de abuso, ¿por qué es difícil analizar a los humanos? No digamos que complicar el análisis de la computadora.

Sí, es el análisis, tanto humano como informático. Es más fácil de leer y analizar si puedes asumir con seguridad que el espacio en blanco no importa. De lo contrario, puede tener declaraciones potencialmente ambiguas, declaraciones en las que no está claro cómo van las cosas juntas, declaraciones que son difíciles de leer, etc.

Tal cambio haría un lenguaje ambiguo en el mejor de los casos. Por ejemplo, en un lenguaje similar a C99:

if not foo(int x) {
    ...
}

es equivalente a:

Una definición de función de foo que devuelve un valor de tipo ifnot :
```
ifnot foo(int x) {
    ...
}
```
Una llamada a una función llamada notfoo con una variable llamada intx :
```
if notfoo(intx) {
    ...
}
```
Una llamada negada a una función llamada foo (con no de C99 que significa ! ):
```
if not foo(intx) {
    ...
}
```

Esto es solo una pequeña muestra de las ambigüedades con las que podría encontrarse.

Actualización: Me di cuenta de que, obviamente, en un lenguaje similar a C99, la condición de una declaración si se incluiría entre paréntesis. La puntuación adicional puede ayudar con las ambigüedades si decide ignorar los espacios en blanco, pero su idioma terminará teniendo una gran cantidad de puntuación adicional en cualquier lugar donde normalmente usaría espacios en blanco.

Consulte el generalización de sobrecarga para C ++ 2000 de Stroustrup.

Se nos permitió colocar espacios en los nombres de archivo en la década de 1960 y las computadoras todavía no los manejamos muy bien (todo lo que se solía romper, la mayoría de las cosas, ahora son solo algunas cosas: pero todavía se rompen).

Simplemente no podemos esperar otros 50 años antes de que nuestro código vuelva a funcionar. :-)

(Y lo que todos los demás dijeron, por supuesto. En inglés, usamos espacios y puntuación para separar las palabras. Lo mismo se aplica a los lenguajes informáticos, excepto que los analizadores informáticos definen "palabras" en un sentido ligeramente diferente)

El uso del espacio como parte de un identificador hace que el análisis sea realmente turbio (¿es un espacio sintáctico o un identificador?), pero el mismo tipo de lectura natural " el comportamiento se logra con argumentos de palabras clave. object.save (data: something, atomically: true)

Hay algunos idiomas que permiten espacios en los identificadores. El hecho de que casi todos los idiomas limitan el conjunto de caracteres en los identificadores es porque el análisis es más fácil y la mayoría de los programadores están acostumbrados al estilo compacto sin espacios en blanco.

No creo que haya una razón real.

El lenguaje TikZ para crear gráficos en LaTeX permite espacios en blanco en los nombres de los parámetros (también conocidos como 'claves'). Por ejemplo, ves cosas como

\shade[
  top color=yellow!70,
  bottom color=red!70,
  shading angle={45},
]

En esta configuración restringida de una lista de pares clave-valor separados por comas, no hay dificultad de análisis. De hecho, creo que es mucho más fácil de leer que las alternativas como topColor , top_color o topcolor .

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow