Diseño de sintaxis: ¿por qué usar paréntesis cuando no se pasan argumentos?

En muchos idiomas, la sintaxis function_name(arg1, arg2, ...)se usa para llamar a una función. Cuando queremos llamar a la función sin ningún argumento, debemos hacerlo function_name().

Me resulta extraño que un compilador o un intérprete de script requiera ()detectarlo con éxito como una llamada de función. Si se sabe que una variable es invocable, ¿por qué no function_name;sería suficiente?

Por otro lado, en algunos idiomas podemos hacer: function_name 'test';o incluso function_name 'first' 'second';llamar a una función o un comando.

Creo que los paréntesis habrían sido mejores si solo fueran necesarios para declarar el orden de prioridad, y en otros lugares eran opcionales. Por ejemplo, hacer if expression == true function_name;debe ser tan válido como if (expression == true) function_name();.

Lo más molesto en mi opinión es hacerlo 'SOME_STRING'.toLowerCase()cuando claramente la función prototipo no necesita argumentos. ¿Por qué los diseñadores decidieron en contra de lo más simple 'SOME_STRING'.lower?

Descargo de responsabilidad: ¡No me malinterpreten, me encanta la sintaxis tipo C! ;) Solo estoy preguntando si podría ser mejor. ¿El hecho de requerir ()tiene ventajas de rendimiento o facilita la comprensión del código? Tengo mucha curiosidad sobre cuál es exactamente la razón.

Para los lenguajes que usan funciones de primera clase , es bastante común que la sintaxis de referirse a una función sea:

a = object.functionName

mientras que el acto de llamar a esa función es:

b = object.functionName()

aen el ejemplo anterior sería una referencia a la función anterior (y podría llamarla haciendo a()), mientras bque contendría el valor de retorno de la función.

Si bien algunos lenguajes pueden realizar llamadas a funciones sin paréntesis, puede resultar confuso si llaman a la función o simplemente se refieren a la función.

De hecho, Scala permite esto, aunque hay una convención que se sigue: si el método tiene efectos secundarios, los paréntesis deben usarse de todos modos.

Como escritor compilador, la presencia garantizada de paréntesis me parece bastante conveniente; Siempre sabría que es una llamada al método, y no tendría que construir una bifurcación para el caso extraño.

Como programador y lector de código, la presencia de paréntesis no deja dudas de que es una llamada a un método, aunque no se pasan parámetros.

El paso de parámetros no es la única característica definitoria de una llamada a método. ¿Por qué trataría un método sin parámetros diferente de un método que tiene parámetros?

Esto es realmente una casualidad bastante sutil de opciones de sintaxis. Hablaré idiomas funcionales, que se basan en el cálculo lambda escrito.

En dichos idiomas, cada función tiene exactamente un argumento . Lo que a menudo pensamos como "argumentos múltiples" es en realidad un único parámetro del tipo de producto. Entonces, por ejemplo, la función que compara dos enteros:

leq : int * int -> bool
leq (a, b) = a <= b

toma un solo par de enteros. Los paréntesis no denotan los parámetros de la función; se usan para emparejar patrones con el argumento. Para convencerlo de que este es realmente un argumento, podemos usar las funciones proyectivas en lugar de la coincidencia de patrones para deconstruir el par:

leq some_pair = some_pair.1 <= some_pair.2

Por lo tanto, los paréntesis son realmente una conveniencia que nos permite combinar patrones y guardar algunos tipos de escritura. No son obligatorios

¿Qué pasa con una función que aparentemente no tiene argumentos? Tal función en realidad tiene dominio Unit. El miembro único de Unitgeneralmente se escribe como (), por eso aparecen los paréntesis.

say_hi : Unit -> string
say_hi a = "Hi buddy!"

Para llamar a esta función, tendríamos que aplicarla a un valor de tipo Unit, que debe ser (), por lo que terminamos escribiendo say_hi ().

Entonces, ¡realmente no existe una lista de argumentos!

En Javascript, por ejemplo, usar un nombre de método sin () devuelve la función misma sin ejecutarla. De esta manera, por ejemplo, puede pasar la función como argumento a otro método.

En Java, se eligió que un identificador seguido de () o (...) significa una llamada al método, mientras que un identificador sin () se refiere a una variable miembro. Esto podría mejorar la legibilidad, ya que no tiene dudas de si se trata de un método o una variable miembro. De hecho, se puede usar el mismo nombre tanto para un método como para una variable miembro, ambos serán accesibles con su respectiva sintaxis.

La sintaxis sigue la semántica, así que comencemos por la semántica:

¿Cuáles son las formas de usar una función o método?

En realidad, hay varias formas:

• Se puede llamar a una función, con o sin argumentos
• una función puede tratarse como un valor
• una función puede aplicarse parcialmente (creando un cierre tomando al menos un argumento menos y cerrando sobre los argumentos pasados)

Tener una sintaxis similar para diferentes usos es la mejor manera de crear un lenguaje ambiguo o, al menos, uno confuso (y tenemos suficientes de esos).

En C y lenguajes similares a C:

• la llamada a una función se realiza mediante paréntesis para encerrar los argumentos (puede que no haya ninguno) como en func()
• tratar una función como un valor se puede hacer simplemente usando su nombre como en &func(C creando un puntero de función)
• en algunos idiomas, tiene sintaxis abreviada para aplicar parcialmente; Java permite, someVariable::someMethodpor ejemplo (limitado al receptor del método, pero sigue siendo útil)

Observe cómo cada uso presenta una sintaxis diferente, lo que le permite distinguirlos fácilmente.

En un lenguaje con efectos secundarios, la OMI es realmente útil para diferenciar (en teoría, sin efectos secundarios) la lectura de una variable

variable

y llamar a una función, que podría generar efectos secundarios

launch_nukes()

OTOH, si no hay efectos secundarios (aparte de los codificados en el sistema de tipos), entonces no tiene sentido incluso diferenciar entre leer una variable y llamar a una función sin argumentos.

Ninguna de las otras respuestas ha intentado abordar la pregunta: ¿cuánta redundancia debería haber en el diseño de un lenguaje? Porque incluso si puede diseñar un lenguaje que x = sqrt yestablezca x en la raíz cuadrada de y, eso no significa que necesariamente deba hacerlo.

En un lenguaje sin redundancia, cada secuencia de caracteres significa algo, lo que significa que si comete un solo error, no recibirá un mensaje de error, su programa hará lo incorrecto, lo que podría ser algo muy diferente de lo que usted intencionado y muy difícil de depurar. (Como cualquiera que haya trabajado con expresiones regulares lo sabrá). Un poco de redundancia es algo bueno porque permite detectar muchos de sus errores, y cuanto más redundancia haya, más probable es que los diagnósticos sean precisos. Ahora, por supuesto, puede llevar eso demasiado lejos (ninguno de nosotros quiere escribir en COBOL en estos días), pero hay un equilibrio correcto.

La redundancia también ayuda a la legibilidad, porque hay más pistas. El inglés sin redundancia sería muy difícil de leer, y lo mismo ocurre con los lenguajes de programación.

En la mayoría de los casos, estas son elecciones sintácticas de la gramática del lenguaje. Es útil para la gramática que las diversas construcciones individuales sean (relativamente) inequívocas cuando se toman en conjunto. (Si hay ambigüedades, como en algunas declaraciones de C ++, debe haber reglas específicas para la resolución). El compilador no tiene la libertad para adivinar; se requiere seguir la especificación del idioma.

Visual Basic, en varias formas, diferencia entre procedimientos que no devuelven un valor y funciones.

Los procedimientos deben llamarse como una declaración y no requieren parens, solo argumentos separados por comas, si los hay. Las funciones deben llamarse como parte de una expresión y requieren los parens.

Es una distinción relativamente innecesaria que hace que la refactorización manual entre las dos formas sea más dolorosa de lo que debe ser.

(Por otra parte de Visual Basic utiliza los mismos parens ()para las referencias de la matriz como para las llamadas de función, por lo que las referencias de la matriz se parece a las llamadas de función. Y esto facilita la refactorización el manual de una matriz en una llamada de función! Por lo tanto, podríamos considerar otros lenguajes usan []'s para referencias de matriz, pero estoy divagando ...)

En los lenguajes C y C ++, se accede automáticamente al contenido de las variables utilizando su nombre, y si desea hacer referencia a la variable en lugar de su contenido, aplica el &operador unario .

Este tipo de mecanismo también podría aplicarse a los nombres de funciones. El nombre de la función sin procesar podría implicar una llamada a la función, mientras que un &operador unario se usaría para referirse a la función (en sí misma) como datos. Personalmente, me gusta la idea de acceder a funciones sin argumentos sin efectos secundarios con la misma sintaxis que las variables.

Esto es perfectamente plausible (al igual que otras opciones sintácticas para esto).

Consistencia y legibilidad.

Si me entero de que se llama a la función de Xla siguiente manera: X(arg1, arg2, ...), entonces espero que funcione de la misma manera para que no hay argumentos: X().

Ahora, al mismo tiempo, aprendo que puedes definir la variable como un símbolo y usarlo así:

a = 5
b = a
...

Ahora, ¿qué pensaría cuando encuentre esto?

c = X

Tu invitado es tan bueno como el mío. En circunstancias normales, el Xes una variable. Pero si tomáramos su camino, ¡también podría ser una función! ¿Debo recordar si qué símbolo se asigna a qué grupo (variables / funciones)?

Podríamos imponer restricciones artificiales, por ejemplo, "Las funciones comienzan con mayúscula. Las variables comienzan con minúscula", pero eso es innecesario y complica las cosas, aunque a veces puede ayudar a algunos de los objetivos de diseño.

Nota al margen 1: Otras respuestas ignoran por completo una cosa más: el lenguaje puede permitirle usar el mismo nombre para funciones y variables, y distinguir por contexto. Ver Common Lispcomo un ejemplo. Función xy variable xcoexisten perfectamente bien.

Nota lateral 2: La respuesta aceptada nos muestra la sintaxis: object.functionname. En primer lugar, no es universal para los idiomas con funciones de primera clase. En segundo lugar, como programador trataría esto como una información adicional: functionnamepertenece a un object. Si objectes un objeto, una clase o un espacio de nombres no importa mucho, pero me dice que pertenece a algún lado . Esto significa que debe agregar una sintaxis artificial object.para cada función global o crear alguna objectpara contener todas las funciones globales.

Y de cualquier manera, pierde la capacidad de tener espacios de nombres separados para funciones y variables.

Para agregar a las otras respuestas, tome este ejemplo de C:

void *func_factory(void)
{
        return 0;
}

void *(*ff)(void);

void example()
{
        ff = func_factory;
        ff = func_factory();
}

Si el operador de invocación fuera opcional, no habría forma de distinguir entre la asignación de función y la llamada a función.

Esto es aún más problemático en los idiomas que carecen de un sistema de tipos, por ejemplo, JavaScript, donde la inferencia de tipos no se puede utilizar para descubrir qué es y qué no es una función.