Sintassi Design - Perché usare le parentesi quando non vengono passati argomenti?

In molte lingue, la sintassi function_name(arg1, arg2, ...)viene utilizzata per chiamare una funzione. Quando vogliamo chiamare la funzione senza alcun argomento, dobbiamo farlo function_name().

Trovo strano che un compilatore o un interprete di script richiederebbe ()di rilevarlo correttamente come una chiamata di funzione. Se è noto che una variabile è richiamabile, perché non function_name;sarebbe sufficiente?

D'altra parte, in alcune lingue possiamo fare: function_name 'test';o persino function_name 'first' 'second';chiamare una funzione o un comando.

Penso che le parentesi sarebbero state migliori se fossero state necessarie solo per dichiarare l'ordine di priorità, e in altri luoghi fossero facoltativi. Ad esempio, fare if expression == true function_name;dovrebbe essere valido quanto if (expression == true) function_name();.

La cosa più fastidiosa secondo me è fare 'SOME_STRING'.toLowerCase()quando chiaramente la funzione prototipo non richiede argomenti. Perché i progettisti hanno deciso contro il più semplice 'SOME_STRING'.lower?

Disclaimer: non fraintendetemi, adoro la sintassi tipo C! ;) Sto solo chiedendo se potrebbe essere migliore. La richiesta ()ha qualche vantaggio in termini di prestazioni o semplifica la comprensione del codice? Sono davvero curioso di sapere quale sia esattamente il motivo.

Per i linguaggi che utilizzano funzioni di prima classe , è abbastanza comune che la sintassi del riferimento a una funzione sia:

a = object.functionName

mentre l'atto di chiamare quella funzione è:

b = object.functionName()

anell'esempio sopra sarebbe riferimento alla funzione sopra (e potreste chiamarla facendo a()), mentre bconterrebbe il valore di ritorno della funzione.

Mentre alcune lingue possono effettuare chiamate di funzione senza parentesi, può creare confusione se chiamano la funzione o semplicemente si riferiscono alla funzione.

In effetti, Scala lo consente, sebbene segua una convenzione: se il metodo ha effetti collaterali, le parentesi dovrebbero essere comunque utilizzate.

Come scrittore di compilatori, troverei la presenza garantita tra parentesi abbastanza conveniente; Saprei sempre che è una chiamata di metodo e non dovrei creare una biforcazione per il caso dispari.

Come programmatore e lettore di codice, la presenza di parentesi non lascia dubbi sul fatto che si tratti di una chiamata di metodo, anche se non vengono passati parametri.

Il passaggio di parametri non è l'unica caratteristica che definisce una chiamata di metodo. Perché dovrei trattare un metodo senza parametri diverso da un metodo con parametri?

Questo è in realtà un colpo piuttosto sottile di scelte di sintassi. Parlerò con linguaggi funzionali, che si basano sul calcolo lambda digitato.

In tali lingue, ogni funzione ha esattamente un argomento . Ciò che spesso pensiamo come "argomenti multipli" è in realtà un singolo parametro del tipo di prodotto. Quindi, ad esempio, la funzione che confronta due numeri interi:

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

accetta una singola coppia di numeri interi. Le parentesi non indicano i parametri della funzione; sono usati per abbinare lo schema all'argomento. Per convincerti che questo è davvero un argomento, possiamo invece usare le funzioni proiettive invece di pattern matching per decostruire la coppia:

leq some_pair = some_pair.1 <= some_pair.2

Pertanto, le parentesi sono davvero una comodità che ci consente di modellare la corrispondenza e salvare un po 'di battitura. Non sono richiesti

Che dire di una funzione che apparentemente non ha argomenti? Tale funzione ha effettivamente dominio Unit. Il singolo membro di Unitè solitamente scritto come (), quindi è per questo che appaiono le parentesi.

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

Per chiamare questa funzione, dovremmo applicarla a un valore di tipo Unit, che deve essere (), quindi finiamo per scrivere say_hi ().

Quindi, non esiste davvero un elenco di argomenti!

In Javascript, ad esempio, l'utilizzo di un nome metodo senza () restituisce la funzione stessa senza eseguirla. In questo modo, ad esempio, è possibile passare la funzione come argomento a un altro metodo.

In Java è stata fatta la scelta che un identificatore seguito da () o (...) significhi una chiamata di metodo mentre un identificatore senza () fa riferimento a una variabile membro. Ciò potrebbe migliorare la leggibilità, poiché non hai dubbi sul fatto che tu abbia a che fare con un metodo o una variabile membro. In effetti, lo stesso nome può essere utilizzato sia per un metodo che per una variabile membro, entrambi saranno accessibili con la rispettiva sintassi.

La sintassi segue la semantica, quindi partiamo dalla semantica:

Quali sono i modi di usare una funzione o un metodo?

Esistono, in realtà, diversi modi:

• una funzione può essere chiamata, con o senza argomenti
• una funzione può essere trattata come un valore
• una funzione può essere parzialmente applicata (creando una chiusura prendendo almeno un argomento in meno e chiudendo sugli argomenti passati)

Avere una sintassi simile per usi diversi è il modo migliore per creare un linguaggio ambiguo o quantomeno confuso (e ne abbiamo abbastanza di quelli).

In linguaggi C e simil-C:

• la chiamata di una funzione viene effettuata utilizzando le parentesi per racchiudere gli argomenti (potrebbe non essercene nessuno) come in func()
• trattare una funzione come un valore può essere fatto semplicemente usando il suo nome come in &func(C creando un puntatore a funzione)
• in alcune lingue, hai sintassi abbreviate per l'applicazione parziale; Java consente someVariable::someMethodad esempio (limitato al metodo method, ma comunque utile)

Nota come ogni utilizzo presenta una sintassi diversa, che ti consente di distinguerli facilmente.

Nessuna delle altre risposte ha tentato di affrontare la domanda: quanta ridondanza dovrebbe esserci nella progettazione di una lingua? Perché anche se puoi progettare una lingua in modo che x = sqrt yimposta x sulla radice quadrata di y, ciò non significa che dovresti necessariamente.

In una lingua senza ridondanza, ogni sequenza di caratteri significa qualcosa, il che significa che se si commette un singolo errore, non si riceverà un messaggio di errore, il programma farà la cosa sbagliata, che potrebbe essere qualcosa di molto diverso da quello che si previsto e molto difficile da eseguire il debug. (Come saprà chiunque abbia lavorato con le espressioni regolari.) Una piccola ridondanza è una buona cosa perché consente di rilevare molti dei tuoi errori e maggiore è la ridondanza, maggiore è la probabilità che la diagnostica sia accurata. Ora, ovviamente, puoi andare troppo lontano (nessuno di noi vuole scrivere in COBOL in questi giorni), ma c'è un equilibrio giusto.

La ridondanza aiuta anche la leggibilità, perché ci sono più indizi. L'inglese senza ridondanza sarebbe molto difficile da leggere, e lo stesso vale per i linguaggi di programmazione.

In un linguaggio con effetti collaterali, l'IMO è davvero utile per distinguere tra (in teoria effetti collaterali gratuiti) la lettura di una variabile

variable

e chiamando una funzione, che potrebbe comportare effetti collaterali

launch_nukes()

OTOH, se non ci sono effetti collaterali (diversi da quelli codificati nel sistema dei tipi), allora non ha senso distinguere tra leggere una variabile e chiamare una funzione senza argomenti.

Nella maggior parte dei casi, si tratta di scelte sintattiche della grammatica della lingua. È utile che la grammatica per i vari costrutti individuali sia (relativamente) inequivocabile se presi tutti insieme. (Se ci sono ambiguità, come in alcune dichiarazioni C ++, ci devono essere regole specifiche per la risoluzione.) Il compilatore non ha il margine per indovinare; è necessario seguire le specifiche della lingua.

Visual Basic, in varie forme, distingue tra procedure che non restituiscono un valore e funzioni.

Le procedure devono essere chiamate come un'istruzione e non richiedono parentesi, solo eventuali argomenti separati da virgola. Le funzioni devono essere chiamate come parte di un'espressione e richiedono i parentesi.

È una distinzione relativamente non necessaria che rende il refactoring manuale tra le due forme più doloroso di quanto deve essere.

(D'altra parte di Visual Basic utilizza le stesse parentesi ()di riferimenti ad array come per chiamate di funzione, in modo da riferimenti ad array sembrare chiama la funzione. E questo facilita refactoring manuale di un array in una chiamata di funzione! Quindi, potremmo riflettere altre lingue usano []'s per riferimenti di array, ma sto divagando ...)

Nei linguaggi C e C ++ si accede automaticamente al contenuto delle variabili usando il loro nome e se si desidera fare riferimento alla variabile stessa anziché al suo contenuto, si applica l' &operatore unario .

Questo tipo di meccanismo potrebbe essere applicato anche ai nomi delle funzioni. Il nome della funzione non elaborata potrebbe implicare una chiamata di funzione, mentre un &operatore unario verrebbe utilizzato per riferirsi alla funzione (stessa) come dati. Personalmente, mi piace l'idea di accedere alle funzioni senza argomento senza effetti collaterali con la stessa sintassi delle variabili.

Questo è perfettamente plausibile (come lo sono altre scelte sintattiche per questo).

Coerenza e leggibilità.

Se vengo a sapere che si chiama la funzione Xin questo modo: X(arg1, arg2, ...), quindi mi aspetto che funzioni allo stesso modo per nessun argomento: X().

Allo stesso tempo, imparo che puoi definire la variabile come un simbolo e usarla in questo modo:

a = 5
b = a
...

Ora cosa dovrei pensare quando lo trovo?

c = X

La tua ipotesi è buona come la mia. In circostanze normali, Xè una variabile. Ma se dovessimo prendere la tua strada, potrebbe anche essere una funzione! Devo ricordare se quale simbolo è associato a quale gruppo (variabili / funzioni)?

Potremmo imporre vincoli artificiali, ad esempio "Le funzioni iniziano con la lettera maiuscola. Le variabili iniziano con la lettera minuscola", ma ciò è inutile e rende le cose più complicate, anche se a volte potrebbero aiutare alcuni degli obiettivi di progettazione.

Nota a margine 1: Altre risposte ignorano completamente un'altra cosa: il linguaggio potrebbe consentire di utilizzare lo stesso nome sia per la funzione che per la variabile e distinguere per contesto. Vedi Common Lispcome esempio. Funzione xe variabile xcoesistono perfettamente.

Side-note 2: La risposta accettata ci mostra la sintassi: object.functionname. Innanzitutto, non è universale per le lingue con funzioni di prima classe. In secondo luogo, come programmatore lo considererei come un'informazione aggiuntiva: functionnameappartiene a un object. Che objectsi tratti di un oggetto, una classe o uno spazio dei nomi non ha molta importanza, ma mi dice che appartiene da qualche parte . Questo significa che devi aggiungere sintassi artificiale object.per ogni funzione globale o crearne alcune objectper contenere tutte le funzioni globali.

E in entrambi i casi, perdi la possibilità di avere spazi dei nomi separati per funzioni e variabili.

Per aggiungere alle altre risposte, prendi questo esempio C:

void *func_factory(void)
{
        return 0;
}

void *(*ff)(void);

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

Se l'operatore di invocazione fosse facoltativo, non ci sarebbe modo di distinguere tra l'assegnazione della funzione e la chiamata della funzione.

Ciò è ancora più problematico nelle lingue prive di un sistema di tipi, ad esempio JavaScript, in cui l'inferenza del tipo non può essere utilizzata per capire cosa sia e non sia una funzione.