Vietare le funzioni a zero argomenti - quali problemi potrebbe causare in un linguaggio ipotetico?

3

Sto creando un linguaggio di programmazione come hobby, ma ho riscontrato un problema con la progettazione della sua sintassi. Il problema è il conflitto tra la sintassi per definire le funzioni dell'argomento zero e la sintassi per le operazioni di riassegnazione. La sintassi della definizione della funzione è presa da Haskell e assomiglia a questo:

name arguments = expression

Una funzione a zero argomenti avrebbe ovviamente questa forma: name = expression . Tuttavia, ciò pone un problema perché, senza contesto, il programmatore potrebbe confondere tale definizione con un'operazione di riassegnazione (che ha la stessa forma, variable = expression ).

La mia soluzione è semplice: vietare le funzioni con argomenti zero. Più precisamente, tali funzioni assumono ora un singolo valore del tipo di unità come argomento. Questo è ispirato da Scala, in cui funzioni che "non restituiscono nulla", in realtà restituiscono () (di tipo Unit ), che è un tipo con un solo valore possibile che non contiene informazioni utili.

La definizione sarebbe quindi simile a questa:

name () = expression

E una chiamata dovrebbe avere la forma name () - nota che '()' non è un elenco di parametri, ma piuttosto il valore di tipo Unit . La definizione di cui sopra si basa sulla corrispondenza del modello, come () non è il nome dell'argomento, ma l'unica forma che può assumere.

La mia domanda è se una tale decisione progettuale abbia senso teorico e se abbia alcuni effetti negativi pratici ?

    
posta jcora 12.07.2015 - 01:17
fonte

3 risposte

2

Ho deciso di portare a termine questa decisione di progettazione per i seguenti motivi:

  1. Tale convenzione è in realtà più coerente con la natura funzionale della lingua. Tutte le funzioni sono unarie (accetta un singolo argomento) - quelle che accettano più argomenti sono semplicemente al curry , e quelle che accettano "nessuna" (come da questa decisione) in realtà accetta il solo valore () .

  2. Diversi linguaggi funzionali implementano già questa convenzione, come Ocaml ( vedi la sezione Come definire una procedura? ), il che mi ha dato più fiducia che non si tratta solo di un trucco casuale che ho trovato.

  3. La decisione stessa consente di utilizzare l'interessante sintassi della definizione della funzione ispirata da Haskell, poiché l'ambiguità tra la riassegnazione viene rimossa (che è la motivazione originale per la decisione, vedi la domanda).

Quindi la risposta diretta alla domanda è non ha senso teoricamente e ha effetti pratici positivi

    
risposta data 16.07.2015 - 09:30
fonte
4

Certo, questo ha un senso teoricamente. Soprattutto nei linguaggi funzionali, avere una funzione che non richiede input è strano. Anche se ti incoraggerei a impedire che le funzioni senza parametri che dichiarano non le impediscano nel tuo sistema di tipi.

Considera il binding dei parametri. Se hai una funzione unaria e ti colleghi un parametro, avresti una funzione senza parametri anche se non l'hai dichiarata. Avere un caso speciale per aggiungere un parametro fittizio non sembra grandioso (ma forse inevitabile).

L'uso di un operatore di dichiarazione diverso rispetto al segno di uguale sembra essere un'alternativa valida per gestire la potenziale confusione (anche se le funzioni senza parametri avranno un impatto altrove nella lingua).

    
risposta data 12.07.2015 - 02:36
fonte
2

Scala return () really significa semplicemente che dovresti ignorare il valore di ritorno senza significato. Fondamentalmente uguale a void in C, giusto? Ma una funzione che non accetta argomenti può ancora restituire un valore utilizzabile, quindi non sono sicuro di vedere una corrispondenza uno-a-uno nella progettazione.

Forzare le funzioni senza parametri funzionalmente per prendere un parametro di tipo Unit che viene ignorato per definizione, mi sembra davvero innaturale.

Molte lingue sono sopravvissute sovraccaricando l'operatore = .

    
risposta data 12.07.2015 - 02:24
fonte

Leggi altre domande sui tag