La sintassi duplicata per la definizione delle funzioni con nome è una cattiva decisione di progettazione del linguaggio?

Question

La sintassi duplicata per la definizione delle funzioni con nome è una cattiva decisione di progettazione del linguaggio?

#1 da (3 voti)
#2 da (2 voti)
#3 da (2 voti)

9

Sto modellando un linguaggio di programmazione per divertimento, e la sintassi è strongmente influenzata da Scala - in particolare le definizioni di funzione.

Ho riscontrato un problema di progettazione perché la mia lingua non distingue tra funzioni definite tramite la sintassi def (metodi di classe) e funzioni anonime assegnate ai valori (create utilizzando => ) - rimuove le differenze in entrambi implementazione e comportamento .

Il risultato è che le due definizioni seguenti indicano la stessa cosa:

def square(x: Int) = x*x

val square = (x: Int) => x*x

Non c'è motivo per l'ultima forma (assegnazione anonima di funzioni anonime) da utilizzare in qualsiasi situazione normale - è semplicemente possibile usarlo al posto del modulo def .

La sintassi duplicata per la definizione delle funzioni denominate avrebbe danneggiato l'ortogonalità della lingua o qualche altro aspetto del design?

Preferisco questa soluzione perché consente definizioni brevi e intuitive di metodi e funzioni con nome (tramite def ) e brevi definizioni di funzioni anonime (utilizzando => ).

Modifica: Scala fa la differenza tra le due - le funzioni anonime non sono le stesse dei metodi definiti con def in Scala. Le differenze sono relativamente sottili però - vedi i post che ho linkato prima.

language-design scala

posta jcora 21.06.2014 - 01:02

fonte

3 risposte

Leggi altre domande sui tag language-design scala

Fonte originale di '(seme * 9301 + 49297)% 233280' algoritmo casuale? Algoritmi per creare mosaici di immagini - c'è un modo più veloce di questo?

score 3 · Answer 1

Penso che avere due costrutti che significano la stessa cosa ma apparire diversi dovrebbe essere ridotto al minimo in una lingua. Qualsiasi duplicazione aumenta la difficoltà di leggere (e quindi scrivere / modificare il codice in) la tua lingua. Eliminare la all duplicazione è inevitabile in un linguaggio che può creare costrutti arbitrari (ad esempio, l'equivalenza di iterazione contro ricorsione).

Quindi, in questo caso, penso che potrebbe essere progettato meglio qui. Un modo unico per definire le funzioni ha più senso per me. In questo caso, sembra che le due istruzioni scala effettivamente abbiano implicazioni leggermente diverse, che probabilmente non sono di buon design (probabilmente è meglio avere qualcosa di chiaro che indichi quali sono le differenze, come una parola chiave).

In effetti, puoi applicare questo principio non solo alle funzioni con nome, ma anche alla funzione qualsiasi . Perché c'è qualche differenza nella definizione delle funzioni nominate e delle funzioni anonime? In Lima , le funzioni sono sempre definite in questo modo: fn[<arguments>: <statements>] . Se vuoi che sia "named" puoi assegnarlo a una variabile: var x = fn[<arguments: <statements>] , e se vuoi passarlo ad un'altra funzione in modo anonimo: function[fn[<arguments: <statements>]] . Se vuoi che venga issato, rendilo costante const var x = fn[<arguments: <statements>] . La singola forma rende ovvio che significano la stessa cosa.

score 2 · Answer 2

2

Quello che hai postato è valido scala e funziona bene.

Dato che il raddoppio non ha causato problemi con scala (a mia conoscenza), ho intenzione di dire che non sarà un problema nemmeno per la tua lingua.

risposta data 21.06.2014 - 02:45

fonte

score 2 · Answer 3

Ho trovato una differenza fondamentale tra i metodi lambdas e def in Scala - che non sono ancora sicuro se voglio implementarlo. Devo fare ulteriori ricerche su di esso e poi riferirò sulla mia decisione.

Essenzialmente, solo i metodi possono return - e quando la parola chiave viene usata da un lambda, in realtà ritorna dal metodo che comprende.

Come ho detto, non sono sicuro se lo voglio. Ma potrebbe essere una giustificazione sufficiente per questa sintassi. O forse troppo pericoloso perché sottili differenze possono inaspettatamente causare danni.

Dettagli