Perché non più lingue hanno la possibilità di confrontare un valore con più di un altro valore? [chiuso]

Considera quanto segue:

if(a == b or c)

Nella maggior parte delle lingue, questo dovrebbe essere scritto come:

if(a == b or a == c)

che è leggermente ingombrante e ripete le informazioni.

So che la mia sintassi di esempio sopra è leggermente goffa, ma sono sicuro che ci sono modi migliori per trasmettere l'idea.

Perché non lo offrono più lingue? Esistono problemi di prestazioni o di sintassi?

Il problema della sintassi è che richiede sintassi.

Qualunque sia la sintassi della tua lingua, le persone che usano la lingua devono impararla. Altrimenti corrono il rischio di vedere il codice e di non sapere cosa fa. Quindi è generalmente considerato positivo se una lingua ha una sintassi semplice che gestisce in modo pulito molti casi.

Nel tuo esempio specifico, stai provando a prendere un operatore infix (una funzione che accetta due argomenti ma è scritto Argument1 Operator Argument2) e stai cercando di estenderlo a più argomenti. Ciò non funziona in modo molto chiaro perché l'intero punto degli operatori di infissione, nella misura in cui ce n'è uno, è mettere l'operatore tra i 2 argomenti. L'estensione a (Argument1 Operator Argument2 MagicallyClearSymbol Argument3...)non sembra aggiungere molta chiarezza Equals(Arg1,Arg2,...). In genere, Infix viene utilizzato per emulare convenzioni matematiche con cui le persone hanno familiarità, il che non sarebbe vero per una sintassi alternativa.

Non ci sarebbero particolari problemi di prestazioni associati alla tua idea, a parte il fatto che il parser dovrebbe avere a che fare con una grammatica con un'altra o due regole di produzione, che potrebbe avere un leggero effetto sulla velocità di analisi. Ciò potrebbe fare la differenza per un linguaggio interpretato o compilato JIT, ma probabilmente non è una grande differenza.

Il problema più grande dell'idea è proprio che fare molti casi speciali in una lingua tende a essere una cattiva idea .

Perché non è un problema, e risolverlo porta sostanzialmente zero benefici, ma implementarlo comporta un costo diverso da zero.

Le funzioni esistenti basate sulla portata e tali che praticamente ogni lingua offre possono funzionare perfettamente in questa situazione se si adattano a una dimensione a == b || a == cche non lo taglierà.

Alcune lingue hanno tali caratteristiche. Ad esempio in Perl6 possiamo usare le giunzioni , che sono "sovrapposizioni" di due valori:

if $a == any($b, $c) {
    say "yes";
}

# syntactic sugar for the above
if $a == $b | $c {
    say "yes";
}

Le giunzioni ci consentono di esprimere le operazioni su un insieme di dati in modo abbastanza succinto, in modo simile al modo in cui le operazioni scalari si distribuiscono su raccolte in alcune lingue. Ad esempio usando Python con numpy, il confronto può essere distribuito su tutti i valori:

import numpy as np
2 == np.array([1, 2, 3])
#=> np.array([False, True, False], dtype=np.bool)
(2 == np.array([1, 2, 3])).any()
#=> True

Tuttavia, questo funziona solo per i tipi primitivi selezionati.

Perché le giunzioni sono problematiche? Poiché le operazioni su una giunzione si distribuiscono sui valori contenuti, l'oggetto di giunzione stesso si comporta come un proxy per le chiamate di metodo - qualcosa che pochi sistemi di tipo oltre alla tipizzazione duck possono gestire.

I problemi di sistema di tipo possono essere evitati se tali giunzioni sono consentite solo come sintassi speciale attorno agli operatori di confronto. Ma in questo caso, sono così limitati che non aggiungono un valore sufficiente per essere aggiunti a qualsiasi linguaggio sano. Lo stesso comportamento potrebbe essere espresso utilizzando le operazioni impostate o spiegando manualmente tutti i confronti e la maggior parte delle lingue non crede nell'aggiunta di sintassi ridondante se esiste già una soluzione perfettamente valida.

Nelle lingue con macro, è facile aggiungere qualcosa del genere se non è già lì. Considera la racchetta

(define-syntax-rule (equal-any? a b ...)
  (or (equal? a b) ...))
(equal-any? "a" "b" "a")
> #t

In altre lingue senza metaprogrammazione, forse puoi riformularla come controllo dell'appartenenza set / list forse:

if a ∈ {b, c}

In alcune lingue (popolari) l' ==operatore non è transitivo. Ad esempio in JavaScript 0è uguale a entrambi ''e '0', ma poi ''e '0'non sono uguali a vicenda. Altre di queste stranezze in PHP.

Significa che a == b == caggiungerebbe un'altra ambiguità, perché potrebbe produrre un risultato diverso a seconda che sia interpretato come (a == b) & (a == c)o (a == b) & (a == c) & (b == c).

Nella maggior parte delle lingue, questo dovrebbe essere banalmente raggiungibile scrivendo una Infunzione, quindi perché renderlo parte della lingua attuale?

Linq, per esempio, ha Contains().

Bene, per tutti voi pedanti, ecco la mia implementazione in C #:

public static bool In<T>(this T obj, params T[] values)
{
    for(int i=0; i < values.Length; i++)
    {
        if (object.Equals(obj, values[i]))
            return true;
    }
    return false;
}

"if (a == b o c)" funziona nella maggior parte delle lingue: se a == b o se c non è negativo, nullo o zero.

Lamentarsi del fatto che sia prolisso manca il punto: non dovresti accumulare una dozzina di cose in un condizionale. Se è necessario confrontare un valore con un numero arbitrario di altri valori, creare una subroutine.

Di solito, vuoi mantenere la tua sintassi al minimo e invece consentire a tali costrutti di essere definiti nella lingua stessa.

Ad esempio, in Haskell è possibile convertire qualsiasi funzione con due o più argomenti in un operatore infix usando i backtick. Questo ti permette di scrivere:

if a `elem` [b, c] then ... else ...

dove elemè solo una normale funzione che accetta due argomenti - un valore e un elenco di valori - e verifica se il primo è un elemento del secondo.

Cosa succede se si desidera utilizzare andanziché or? In Haskell, puoi semplicemente utilizzare quanto segue invece di attendere che il fornitore del compilatore implementi una nuova funzionalità:

 if all (== a) [b, c] then ... else ...

Alcune lingue lo offrono - fino a un certo punto.

Forse non come esempio specifico , ma prendi ad esempio una linea Python:

def minmax(min, max):
    def answer(value):
        return max > value > min
    return answer

inbounds = minmax(5, 15)
inbounds(7) ##returns True
inbounds(3) ##returns False
inbounds(18) ##returns False

Quindi, alcune lingue vanno bene con confronti multipli, purché tu lo esprima correttamente.

Sfortunatamente, non funziona come ci si aspetterebbe per un confronto.

>>> def foo(a, b):
...     def answer(value):
...         return value == a or b
...     return answer
... 
>>> tester = foo(2, 4)
>>> tester(3)
4
>>> tester(2)
True
>>> tester(4)
4
>>> 

"Cosa vuoi dire con restituisce True o 4?" - il noleggio dopo di te

Una soluzione in questo caso, almeno con Python, è usarla in modo leggermente diverso:

>>> def bar(a, b):
...     def ans(val):
...             return val == a or val == b
...     return ans
... 
>>> this = bar(4, 10)
>>> this(5)
False
>>> this(4)
True
>>> this(10)
True
>>> this(9)
False
>>> 

EDIT: Quanto segue farebbe anche qualcosa di simile, sempre in Python ...

>>> def bar(a, b):
...     def answer(val):
...             return val in (a, b)
...     return answer
... 
>>> this = bar(3, 5)
>>> this(3)
True
>>> this(4)
False
>>> this(5)
True
>>> 

Quindi, qualunque sia la lingua che stai usando, potrebbe non essere che non puoi farlo, solo che devi prima dare un'occhiata più da vicino a come funziona effettivamente la logica. In genere si tratta solo di sapere cosa stai "chiedendo" alla lingua.

Il metodo indexOf, usato su un array, che quasi tutte le lingue hanno, permette di confrontare un valore con molti altri, quindi immagino che un operatore speciale non abbia molto senso.

In javascript che scriverebbe:

if ( [b, c].indexOf(a) != -1 ) { ....  }

Mi chiedi perché non possiamo farlo: if(a == b or c)

Python lo fa in modo molto efficiente, infatti, in modo più efficiente con set:

if a in set([b, c]):
    then_do_this()

Per i test di appartenenza, 'set' verifica che gli hash dell'elemento siano gli stessi e solo allora confronta per uguaglianza, quindi gli elementi, bec, devono essere hash, altrimenti un elenco confronta direttamente per uguaglianza:

if a in [b, c]:
    then_do_this()

I linguaggi in stile APL ti consentono di confrontare uno scalare con ogni elemento in un vettore in una singola operazione. Questo produce un vettore booleano. Ad esempio, vorrei promuovere spudoratamente la mia calcolatrice apl con funzionalità minime, inca ( interprete online ).

   a<5
5 
   b<4
4 
   c<5
5 
   a=b c
0 1 

Per ridurlo a un singolo valore, possiamo fare un inclusivo o sommando e controllando lo zero.

   0!+/a=b c
1 
   c<6
6 
   0!+/a=b c
0

Quindi, come dicono le altre risposte, il problema è la sintassi. In una certa misura, sono state trovate soluzioni di sintassi , a un costo forse considerevole per l'apprendimento del paradigma dell'array.