¿Qué lenguaje de programación práctico y no teórico no tiene palabras clave reservadas?

22

He estado buscando un lenguaje de programación práctico que no tenga palabras clave reservadas, pero no he tenido suerte de encontrarlo.

Estoy trabajando en un lenguaje de programación para mi propia edificación y entretenimiento y aún no he necesitado incluir ninguna palabra clave, eso es lo que me llevó a mi búsqueda y la pregunta:

No creo que la conveniencia para el escritor del compilador sea importante para el usuario final del lenguaje. Las computadoras son lo suficientemente potentes hoy en día como para poder inferir significados del contexto. No más de lo que un escritor necesita etiquetar sustantivos, verbos y demás al escribir una novela, ¿por qué un programador debe etiquetar funciones y variables con function x() {}o set x = 1o var x = 1etc; ¿Cuándo puedo inferir del contexto de las declaraciones que es una declaración de función o una invocación o que una etiqueta es una asignación a un valor o una referencia a ese valor de etiquetas?

Aquí hay un ejemplo concreto de lo que está haciendo mi analizador actual, sin necesidad de palabras clave reservadas para admitir cosas comunes que normalmente tendrían un montón de ruido como funco functiono deco no.

Declaración de funciones

sum3(a,b,c) -> a + b + c.

Invocación de funciones

x = sum3(1,2,3).

Función anónima llamada x

x = (a,b,c) -> a + b + c.
y = x(1,2,3).

Me gustaría saber por qué las palabras clave son tan importantes para un lenguaje de programación exitoso.

theory languages

8

Forth es bastante práctico y no tiene palabras clave.

— SK-logic

44

@JamesAnderson, no, son solo palabras, igual que todas las otras palabras. No tiene ningún significado especial en absoluto.

— SK-logic

77

¿Los operadores y la puntuación cuentan como "palabra clave"? en caso afirmativo, entonces no puede existir un lenguaje, ya que no se puede definir la sintaxis.

— Emilio Garavaglia

2

@ SK-logic: generalmente. Pero, ¿qué son los "identificadores" si aún no se tokeniza? Dado que un token es "cualquier picadura reconocible", "int", "myvalue" y "+" no son diferentes, antes de que se haya dado una regla de sintaxis. Si "+" no está definido como operador, puede ser solo un nombre para algo como cualquier otra cadena de caracteres unicode. Los operadores, desde un punto de vista de sintaxis pura, no son más que "palabras clave de un solo carácter".

— Emilio Garavaglia

2

En este contexto, ¿qué es una palabra clave? ¿Es un identificador que tiene un significado especial para el compilador? ¿Es un identificador que el programador no debería usar como variable o algo así? ¿Cuenta como sin palabras clave si las palabras clave tienen que ser designadas especialmente? (Hace mucho tiempo vi un sistema ALGOL donde las palabras clave necesitaban ser citadas para ser palabras clave.)

— David Thornley

12

MUMPS tiene mucho éxito, se usa ampliamente en seguros y atención médica y no tiene palabras reservadas. Diría que ayudan en términos de escribir código más claro, pero no son estrictamente necesarios. APL es otro ejemplo. APL ve uso para guiones únicos en la industria nuclear, entre otros. J , un miembro de la familia APL también carece de palabras clave.

Las palabras clave ayudan a los escritores de compiladores a implementar el análisis más fácilmente. APL es famoso por su asociación correcta. También ayudan a reforzar las convenciones y mejorar la legibilidad. APL no es conocido por ser enormemente legible para la mayoría.

— Ingeniero mundial
fuente

2

+1 para "Las palabras clave ayudan a los escritores de compiladores a implementar el análisis más fácilmente". Creo que eso es todo. Las palabras clave se inventaron para reducir la cantidad de contexto que un analizador tiene que mantener en la memoria, cuando el compilador completo más su conjunto de trabajo tenía que caber en una docena de KB de RAM.

— Jörg W Mittag

2

¡Es más fácil escribir un analizador para APL que casi cualquier otro idioma! Considere que la primera implementación de un intérprete APL se realizó utilizando transistores y diodos.

— James Anderson

2

Creo que la razón principal de las palabras clave es facilitar que los humanos analicen el idioma más fácilmente. Las computadoras estarían más felices si el lenguaje consistiera enteramente en números y patrones de bits como su código de máquina.

— James Anderson

66

Lo que le falta a APL en las palabras clave, lo compensa con creces al requerir su propia fuente.

— Blrfl

@Blrfl Ese es el punto de J, K y Q. Todos son, en un grado u otro, APL en ASCII.

— Ingeniero mundial

9

Un lenguaje bien conocido sin palabras clave es Lisp. Lo más parecido a las palabras clave son las llamadas formas especiales (su número puede variar entre dialectos) que reciben un trato especial del intérprete. Aparte de eso, no se pueden distinguir de las funciones regulares en términos de cómo se usan, con la excepción de que no se pueden redefinir (al menos en Lisps estoy familiarizado).

Esto da como resultado una sintaxis simple (pero muy pesada), y es una de las cosas que permitió a Lisp tener un sistema macro tan poderoso. Por otro lado, a menudo se dice que Lisp es difícil de leer. APL y MUMPS, aún más, he visto a ambos descritos como a medio camino de Brainf * ck. Las palabras clave ayudan en este departamento y también hacen que la lectura del código sea más fácil para nosotros los humanos.

Por lo tanto, no diría que se requieren palabras clave para un idioma exitoso, pero seguramente ayudan a que un idioma tenga éxito.

— scrwtp
fuente

1

IIRC Lisp NO tiene palabras clave. Las formas especiales deben ser tratadas especialmente por el compilador, pero sus nombres son símbolos regulares.

— Jan Hudec

2

Las palabras clave son una característica de la sintaxis, que Lisp tampoco tiene. No creo que tenga sentido hablar de palabras clave en Lisp, de verdad.

— Jörg W Mittag

2

Estoy de acuerdo con Jörg. Creo que se puede hablar de palabras clave cuando un idioma tiene tokens que deben definirse explícitamente como especiales para distinguirse de los tokens con una estructura similar. Diferentes fichas conducen a diferentes árboles de sintaxis. Por ejemplo, ifen C sería un identificador válido si no se definiera como especial (una palabra clave). Esto significa que ifno es un identificador y if = 10da un error de sintaxis. Si no me equivoco, la sintaxis mínima de Lisp no distingue defunentre f, x, yy +en (defun f (x y) (+ x y)).

— Giorgio

@Giorgio notablemente if es un nombre de variable válido en Common Lisp (y otros Lisp-2) (defparameter if nil)no romperá nada y se puede usar en formas como(unless if (setf if t))

— tobyodavies

En la misma nota, sin embargo, (defun if ...)fallará. Tomó notas de los comentarios en cuenta y editó la respuesta. Estoy de acuerdo en que los formularios especiales no son palabras clave en el mismo nivel que en C, por ejemplo, todavía son lo más parecido que tiene Lisp.

— scrwtp

8

TCL no tiene palabras clave, y de hecho solo 12 reglas de sintaxis. Si bien no es tan popular como lo era antes, tiene su nicho con el esperado y está integrado en ECAD y enrutadores, por lo que sin duda es algo práctico para mí.

También creo que puede mostrar por qué muchos idiomas no siguen esta ruta. Sí, es perfectamente posible escribir un analizador TCL (posiblemente más fácil que muchos otros idiomas), sin embargo, no puede escribir una gramática BNF muy útil para el idioma y muchas personas parecen tener problemas para aprender el idioma. Sospecho que esto se debe al menos en parte a la falta de palabras clave.

— jk.
fuente

2

Tcl es muy similar a Lisp a este respecto, excepto que en lugar de "todo es una lista" tiene "todo es una cadena". Una lista es solo una cadena con espacios en blanco y una llamada a procedimiento es solo una lista cuyo primer elemento se interpreta como el nombre de un procedimiento y el resto se interpreta como sus argumentos. Eso es esencialmente una Expresión S de Lisp.

— Jörg W Mittag

sí, ambos usan la notación polaca y son homo-icónicos, por lo que tienen una semántica bastante similar

— jk.

5

Las computadoras son lo suficientemente potentes hoy en día para poder inferir significados del contexto.

¿Esto significa que quieres una gramática que no esté libre de contexto? Buena suerte.

No se trata de ser poderoso o no. Existen reglas eternas e inmutables sobre los idiomas: las matemáticas. Esto, y el hecho de que un lenguaje de programación debería ser sintácticamente fácil hará que los CFG gobiernen en las próximas décadas.

Por cierto, en Haskell como sintaxis, solo escribes algo como

f x y = (x+1)*(y-1)

para definir una función Pero observe que la "palabra clave" en este caso es el '='. Si te lo pierdes, cosas terribles sucederán en el analizador.

Pero este es un punto en el que estoy de acuerdo con usted, lo encuentro mucho más intuitivo que todas las palabras clave def, dcl, fun, fn, function o what-not que introducen funciones en otros idiomas.

Sin embargo, esta gramática se puede escribir en LALR antiguo (1), aquí no se infiere ningún significado del contexto.

— Ingo
fuente

1

+1 para abordar esta afirmación (las computadoras son lo suficientemente potentes hoy en día como para poder inferir significados del contexto). Creo que la razón por la cual se prefieren las gramáticas de CFG es que permiten que la estructura del programa se defina inductivamente. No veo por qué a uno le gustaría cambiar esto incluso en 100 años, ¿tal vez me falta imaginación?

— Giorgio

2

Los CFG están bastante muertos, y habían estado muertos durante décadas. JavaScript dentro de HTML, incluso cadenas de formato C dentro de C, incluso comentarios anidados en, por ejemplo, OCaml: todo esto no está libre de contexto. Y, ¿por qué querrías restringirte a un formalismo elegido tan arbitrario, ahora, en una era de PEG y GLR?

— SK-logic

1

@Ingo, sí, tienes razón, una elección incorrecta de un ejemplo. Me refería a gramáticas mixtas y extensibles (es decir, de alto orden), que no son CFG.

— SK-logic

2

@ SK-logic: no sé de dónde sacaste la información de que los CFG están bastante muertos. He estado hablando con un antiguo colega mío que ha enseñado la construcción de compiladores durante los últimos 20 años y los CFG parecen estar lejos de estar muertos.

— Giorgio

1

@Ingo: Hasta donde recuerdo, los aspectos no relacionados con la FQ se manejan luego analizando el árbol de análisis semánticamente. Por ejemplo, { int x = 0; x = "HELLO"; }debería producir un árbol de análisis, pero cuando el compilador busca x en la segunda asignación, ve que se ha declarado como int y emite un error de tipo. Por lo tanto, el programa se rechaza incluso si su estructura CF es correcta.

— Giorgio

4

Hasta donde sé, Smalltalk es el idioma que tiene menos palabras clave (si no cuento idiomas como Brainfuck). Palabras clave son Smalltalk true, false, nil, self, supery thisContext.

He diseñado un idioma, inspirado en smalltalk, que no tenía palabras clave. Pero después de un tiempo de usarlo, terminé agregando algunas palabras clave, principalmente para el azúcar sintáctico.

Entonces, mi opinión es que el lenguaje sin palabras clave es posible, pero no es muy práctico y esa es la razón por la cual todos los idiomas populares tienen palabras clave.

— del-boy
fuente

Si Smalltalk tenía soporte para mensajes envía con un receptor implícita, por lo menos true, falsey nilse podría definir como métodos en ese receptor implícito, y, dadas las capacidades de reflexión, los otros tres, probablemente, también.

— Jörg W Mittag

1

Esas no son palabras clave, son pseudovariables. "Pseudo" porque true, falsey nilson valores bien conocidos suministrados por el entorno y self, supery thisContextson variables que no puede establecer pero cuyos valores cambian como resultado de la ejecución.

— Frank Shearar

3

Parece que está trabajando bajo una suposición falsa, que las palabras clave están ahí para facilitar las cosas al compilador. Si bien facilitan las cosas para el compilador, tienen un beneficio mucho más importante: facilitan las cosas para la persona que lee el código .

Sí, podría mirar un montón de contexto y descubrir que está viendo una declaración de función o una declaración de variable, pero dependiendo del contexto y de la complejidad del código involucrado, eso podría tomar mucho tiempo para descubrir . O bien, podría tener una palabra clave útil como función o var , y sabrá de inmediato lo que está viendo.

Sí, hacen que el código sea más complicado de escribir , pero teniendo en cuenta que los programas pasan mucho más tiempo en mantenimiento que en producción, y que su código se lee, depura y mantiene mucho más de lo que se crea, tratando de diseñar su lenguaje para hacer que sea fácil de escribir en lugar de fácil de leer es un caso clásico de optimización prematura dañina.

Además, no desdeñe los conceptos que facilitan el trabajo del compilador. Cuanto más fácil sea analizar, más rápido se compilará su código, lo que significa que los ciclos de edición-construcción-depuración se vuelven más rápidos, lo que significa que su productividad aumenta.

Cuando tiene una base de código grande y compleja, eso puede suponer una diferencia no trivial en la productividad. Por ejemplo, donde trabajo tenemos un programa en el trabajo que tiene alrededor de 4 millones de líneas de Delphi. Tenemos otro módulo que tiene aproximadamente 300,000 líneas de C ++. Ambos toman aproximadamente el mismo tiempo para compilar. (Aproximadamente 3 minutos.) ¡Si tuviéramos 4 millones de líneas de C ++, podría tomar una hora construirlo!

— Mason Wheeler
fuente

Todos los puntos excelentes. +1

si cada sustantivo, verbo, adverbio y adjetivo en una novela fuera etiquetado como tal, ¡sería más DIFÍCIL leerlo más fácilmente!

@JarrodRoberson: Claro que sí, pero el código no es una novela. Los lenguajes naturales son muy diferentes de los lenguajes de programación. El lenguaje natural se entiende intuitivamente, mientras que un lenguaje de programación tiene una semántica formal. Las técnicas utilizadas para leerlo y comprender su significado son muy diferentes, y es un error tratar de igualar los dos como lo hace.

— Mason Wheeler

Dije el escritor del compilador que es diferente del compilador . Los compiladores se vuelven más rápidos en hardware más rápido, los escritores de compiladores son humanos, ¡no nos adherimos a la Ley de Moore!

Las bases de códigos con las que tiendo a trabajar son órdenes de magnitud más largas que las novelas, la mayoría son> 1,000,000+ líneas de código, ¡la mayoría de las novelas más largas son <2,000,000 palabras ! Y al igual que las novelas, los humanos los leen, ¡en realidad se dedica más tiempo a leer el código que a escribirlo! Dada una base de código que tiene> 10 años y más de 1,000,000 de líneas, la cantidad de veces que los desarrolladores la leen durante más de 10 años eclipsa el tiempo que llevó crear en primer lugar.

2

Hay algunos ejemplos raros.

APL usa solo símbolos, ¡pero muchos de ellos! Necesita un teclado especial para usar el idioma.

Ver este artículo de Wikipedia

CORAL 66: tenía palabras clave, pero solo las reconocía si se citaban con comillas simples.

PL / 1 también tenía palabras clave, pero también podría usarlas como nombres de variables o procedimientos.

En general, su pregunta es un poco como preguntar "¿por qué los idiomas hablados tienen palabras?".

— James Anderson
fuente

Solo para agregar que si te gusta el aspecto de APL pero no quieres comprar un nuevo teclado, entonces J es justo lo que necesitas .

— AakashM

0

La razón principal es que es más fácil de analizar tanto para humanos como para computadoras. La desambiguación de un lenguaje complejo sin palabras clave requeriría muchos símbolos como sintaxis, y sería enorme e innecesariamente confuso. Es mucho más fácil de leer functionque $!{}. Y el contexto no resuelve todas las ambigüedades.

— DeadMG
fuente

1

Creo que la palabra clave en su respuesta es compleja , un lenguaje suficientemente diseñado debe ser simple , no complejo .

1

@Jarrod Roberson: Leonardo da Vinci: "La simplicidad es la máxima sofisticación", Antoine de Saint Exupéry: "Parece que la perfección no se alcanza cuando no hay nada más que agregar, sino cuando no hay nada más que quitar".

— Giorgio

1

@Jarrod: Todos los lenguajes de computadora significativamente expresivos son complejos.

— DeadMG

1

@DeadMG: El esquema es muy simple y al mismo tiempo muy expresivo. Desafortunadamente, hasta donde yo sé, carece de una biblioteca estandarizada.

— Giorgio

Erlang es muy expresivo y no es sintáctico complejo. Creo que todos los lenguajes funcionales terminan siendo más expresivos con palabras clave menos reservadas.