Design da sintaxe - Por que usar parênteses quando nenhum argumento é passado?

Em muitos idiomas, a sintaxe function_name(arg1, arg2, ...)é usada para chamar uma função. Quando queremos chamar a função sem argumentos, devemos fazê-lo function_name().

Acho estranho que um compilador ou intérprete de script exigiria ()detectá-lo com êxito como uma chamada de função. Se uma variável é conhecida como chamadora, por que não function_name;seria suficiente?

Por outro lado, em alguns idiomas, podemos fazer: function_name 'test';ou mesmo function_name 'first' 'second';chamar uma função ou comando.

Acho que os parênteses teriam sido melhores se fossem necessários apenas para declarar a ordem de prioridade e, em outros lugares, eram opcionais. Por exemplo, fazer if expression == true function_name;deve ser tão válido quanto if (expression == true) function_name();.

A coisa mais irritante na minha opinião é fazer 'SOME_STRING'.toLowerCase()quando claramente nenhum argumento é necessário para a função prototype. Por que os designers decidiram contra o mais simples 'SOME_STRING'.lower?

Isenção de responsabilidade: não me interpretem mal, eu amo a sintaxe do tipo C! ;) Só estou perguntando se poderia ser melhor. A exigência ()tem vantagens de desempenho ou facilita a compreensão do código? Estou realmente curioso para saber exatamente qual é o motivo.

Para idiomas que usam funções de primeira classe , é bastante comum que a sintaxe de referência a uma função seja:

a = object.functionName

enquanto o ato de chamar essa função é:

b = object.functionName()

ano exemplo acima, seria referência à função acima (e você poderia chamá-la fazendo isso a()), enquanto bconteria o valor de retorno da função.

Enquanto alguns idiomas podem fazer chamadas de função sem parênteses, pode ficar confuso se eles estão chamando a função ou simplesmente se referindo à função.

De fato, Scala permite isso, embora exista uma convenção a seguir: se o método tiver efeitos colaterais, parênteses devem ser usados ​​de qualquer maneira.

Como escritor de compilador, consideraria conveniente a presença garantida de parênteses; Eu sempre saberia que é uma chamada de método e não precisaria criar uma bifurcação para o caso estranho.

Como programador e leitor de código, a presença de parênteses não deixa dúvidas de que é uma chamada de método, mesmo que nenhum parâmetro seja passado.

A passagem de parâmetros não é a única característica definidora de uma chamada de método. Por que eu trataria um método sem parâmetro diferente de um método que possui parâmetros?

Este é realmente um acaso bastante sutil de escolhas de sintaxe. Vou falar com linguagens funcionais, que são baseadas no cálculo lambda digitado.

Nas referidas linguagens, toda função tem exatamente um argumento . O que geralmente consideramos "múltiplos argumentos" é na verdade um único parâmetro do tipo de produto. Por exemplo, a função que compara dois números inteiros:

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

leva um único par de números inteiros. Os parênteses não indicam os parâmetros da função; eles são usados ​​para combinar o padrão com o argumento. Para convencê-lo de que esse é realmente um argumento, podemos usar as funções projetivas em vez da correspondência de padrões para desconstruir o par:

leq some_pair = some_pair.1 <= some_pair.2

Assim, os parênteses são realmente uma conveniência que permite padronizar a correspondência e salvar algumas digitações. Eles não são necessários.

E uma função que ostensivamente não tem argumentos? Essa função realmente tem domínio Unit. O único membro de Unitgeralmente é escrito como (), é por isso que os parênteses aparecem.

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

Para chamar essa função, teríamos que aplicá-la a um valor do tipo Unit, que deve ser (), para que acabemos escrevendo say_hi ().

Portanto, não existe realmente uma lista de argumentos!

Em Javascript, por exemplo, usar um nome de método sem () retorna a própria função sem executá-la. Dessa forma, você pode, por exemplo, passar a função como argumento para outro método.

Em Java, optou-se por um identificador seguido por () ou (...) significa uma chamada de método, enquanto um identificador sem () se refere a uma variável de membro. Isso pode melhorar a legibilidade, pois você não tem dúvidas se está lidando com um método ou uma variável de membro. De fato, o mesmo nome pode ser usado para um método e uma variável membro, ambos estarão acessíveis com sua respectiva sintaxe.

A sintaxe segue a semântica, então vamos começar pela semântica:

Quais são as maneiras de usar uma função ou método?

Na verdade, existem várias maneiras:

• uma função pode ser chamada, com ou sem argumentos
• uma função pode ser tratada como um valor
• uma função pode ser parcialmente aplicada (criando um fechamento usando pelo menos um argumento a menos e fechando sobre os argumentos passados)

Ter uma sintaxe semelhante para diferentes usos é a melhor maneira de criar uma linguagem ambígua ou, pelo menos, confusa (e temos o suficiente).

Nos idiomas C e C:

• chamar uma função é feito entre parênteses para incluir os argumentos (pode não haver nenhum) como em func()
• tratar uma função como um valor pode ser feito simplesmente usando seu nome como em &func(C criando um ponteiro de função)
• em alguns idiomas, você possui sintaxe abreviada para aplicar parcialmente; Java permite, someVariable::someMethodpor exemplo (limitado ao receptor do método, mas ainda útil)

Observe como cada uso apresenta uma sintaxe diferente, permitindo diferenciá-los facilmente.

Em uma linguagem com efeitos colaterais, é muito útil para a OMI diferenciar entre (em teoria, sem efeito colateral) a leitura de uma variável

variable

e chamar uma função, que pode resultar em efeitos colaterais

launch_nukes()

OTOH, se não houver efeitos colaterais (além dos codificados no sistema de tipos), não há sentido em diferenciar entre ler uma variável e chamar uma função sem argumentos.

Nenhuma das outras respostas tentou abordar a questão: quanta redundância deve haver no design de um idioma? Porque, mesmo que você possa projetar uma linguagem para x = sqrt ydefinir x como raiz quadrada de y, isso não significa que você deva necessariamente.

Em um idioma sem redundância, cada sequência de caracteres significa algo, o que significa que, se você cometer um único erro, não receberá uma mensagem de erro, seu programa fará a coisa errada, o que pode ser algo muito diferente do que você pretendido e muito difícil de depurar. (Como qualquer pessoa que tenha trabalhado com expressões regulares saberá.) Um pouco de redundância é uma coisa boa, pois permite que muitos de seus erros sejam detectados, e quanto mais redundância houver, maior a probabilidade de o diagnóstico ser preciso. Agora, é claro, você pode levar isso muito longe (nenhum de nós quer escrever no COBOL hoje em dia), mas existe um equilíbrio certo.

A redundância também ajuda na legibilidade, porque há mais pistas. O inglês sem redundância seria muito difícil de ler, e o mesmo se aplica às linguagens de programação.

Na maioria dos casos, essas são escolhas sintáticas da gramática do idioma. É útil para a gramática que as várias construções individuais sejam (relativamente) inequívocas quando tomadas em conjunto. (Se houver ambiguidades, como em algumas declarações de C ++, deve haver regras específicas para a resolução.) O compilador não tem latitude para adivinhar; é necessário seguir a especificação do idioma.

O Visual Basic, de várias formas, diferencia entre procedimentos que não retornam um valor e funções.

Os procedimentos devem ser chamados como uma declaração e não exigem parênteses, apenas argumentos separados por vírgula, se houver. As funções devem ser chamadas como parte de uma expressão e requerem os parênteses.

É uma distinção relativamente desnecessária que torna a refatoração manual entre as duas formas mais dolorosa do que precisa ser.

(Por outro lado Visual Basic usa os mesmos parênteses ()para referências matriz como para chamadas de função, de modo que as referências de matriz olhar como chamadas de função. E isso facilita refatoração manual de um array em uma chamada de função! Então, poderíamos ponderar outras línguas usam []'s para referências de matriz, mas discordo ...)

Nas linguagens C e C ++, o conteúdo das variáveis ​​é acessado automaticamente usando seu nome e, se você quiser se referir à própria variável em vez de seu conteúdo, aplica o &operador unário .

Esse tipo de mecanismo também pode ser aplicado aos nomes das funções. O nome da função bruta pode implicar uma chamada de função, enquanto um &operador unário seria usado para se referir à função (ela mesma) como dados. Pessoalmente, gosto da ideia de acessar funções sem argumento sem efeitos colaterais com a mesma sintaxe que as variáveis.

Isso é perfeitamente plausível (assim como outras opções sintáticas para isso).

Consistência e legibilidade.

Se eu descobrir que você chamar a função Xcomo esta: X(arg1, arg2, ...), então eu espero que ele funcione da mesma forma para sem argumentos: X().

Agora, ao mesmo tempo, aprendi que você pode definir a variável como algum símbolo e usá-la assim:

a = 5
b = a
...

Agora, o que eu pensaria quando encontrar isso?

c = X

Seu palpite é tão bom quanto o meu. Em circunstâncias normais, Xé uma variável. Mas se seguíssemos o seu caminho, também poderia ser uma função! Devo lembrar se qual símbolo é mapeado para qual grupo (variáveis ​​/ funções)?

Poderíamos impor restrições artificiais, por exemplo, "Funções começam com letra maiúscula. Variáveis ​​começam com letra minúscula", mas isso não é necessário e torna as coisas mais complicadas, embora às vezes possa ajudar alguns dos objetivos do projeto.

Nota lateral 1: Outras respostas ignoram completamente mais uma coisa: a linguagem pode permitir que você use o mesmo nome para a função e a variável e faça a distinção por contexto. Veja Common Lispcomo um exemplo. Função xe variável xcoexistem perfeitamente.

Side-Nota 2: A resposta aceita nos mostra a sintaxe: object.functionname. Em primeiro lugar, não é universal para idiomas com funções de primeira classe. Em segundo lugar, como programador, eu trataria isso como uma informação adicional: functionnamepertence a um object. Seja objectum objeto, uma classe ou um espaço para nome, não importa muito, mas ele me diz que pertence a algum lugar . Isso significa que você deve adicionar sintaxe artificial object.para cada função global ou criar algumas objectpara armazenar todas as funções globais.

De qualquer forma, você perde a capacidade de ter espaços de nomes separados para funções e variáveis.

Para adicionar às outras respostas, pegue este exemplo C:

void *func_factory(void)
{
        return 0;
}

void *(*ff)(void);

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

Se o operador de chamada fosse opcional, não haveria maneira de distinguir entre a atribuição de função e a chamada de função.

Isso é ainda mais problemático em idiomas que não possuem um sistema de tipos, por exemplo, JavaScript, onde a inferência de tipos não pode ser usada para descobrir o que é e o que não é uma função.