Perché i linguaggi di programmazione non consentono spazi negli identificatori?

Question

Potrebbe sembrare una domanda stupida, ma non conosco ancora la risposta.

Perché i linguaggi di programmazione non consentono spazi nei nomi (ad esempio i nomi dei metodi)?

Capisco che sia per facilitare (consentire) l'analisi, e ad un certo punto sarebbe impossibile analizzare qualcosa se gli spazi fossero consentiti.

Oggi siamo così abituati che la norma non è quella di vedere gli spazi.

Ad esempio:

 object.saveData( data );
 object.save_data( data )
 object.SaveData( data );
 [object saveData:data];

ecc.

Potrebbe essere scritto come:

 object.save data( data )  // looks ugly, but that's the "nature" way.

Se è solo per l'analisi, immagino che l'identificatore potrebbe essere compreso tra . e ( ovviamente, i linguaggi procedurali non sarebbero in grado di usarlo perché c'è no '.' ma OO lo fa

Mi chiedo se l'analisi sia la unica ragione, e se lo è, quanto sia importante (presumo che sarà e sarà impossibile farlo diversamente, a meno che tutto il linguaggio di programmazione i designer ... dimenticano l'opzione)

Modifica

Sono d'accordo con gli identificatori in generale (come nell'esempio fortran) è una cattiva idea. Restringendo alle lingue OO e in particolare ai metodi, non vedo (non voglio dire che non c'è) un motivo per cui dovrebbe essere così. Dopo tutto è possibile utilizzare . e il primo (.

E dimentica il metodo saveData , considera questo:

key.ToString().StartsWith("TextBox")

come:

key.to string().starts with("textbox");

Answer 1

Prima che l'interprete o il compilatore possano costruire un albero di analisi, deve eseguire un'analisi lessicale, trasformando il flusso di caratteri in un flusso di token. Considera come desideri analizzare il seguente:

a = 1.2423 / (4343.23 * 2332.2);

E come la tua regola sopra funzionerebbe su di essa. Difficile sapere come lessificarlo senza comprendere il significato dei token. Sarebbe davvero difficile costruire un parser che abbia fatto la lessificazione allo stesso tempo.

Answer 2

Sii causa due cose da fare per avere successo davvero.

Answer 3

Ho usato un'implementazione di ALGOL (c. 1978) che & # 8212; estremamente fastidioso & # 8212; citazione obbligatoria di ciò che ora è noto come parole riservate e spazi consentiti negli identificatori:

  "proc" filter = ("proc" ("int") "bool" p, "list" l) "list":
     "if" l "is" "nil" "then" "nil"
     "elif" p(hd(l)) "then" cons(hd(l), filter(p,tl(l)))
     "else" filter(p, tl(l))
     "fi";

Inoltre, FORTRAN (la forma in maiuscolo significa F77 o precedente), era più o meno insensibile agli spazi. Quindi questo potrebbe essere scritto:

  799 S = FLO AT F (I A+I B+I C) / 2 . 0
      A  R E  A = SQ R T ( S *(S - F L O ATF(IA)) * (S - FLOATF(IB)) *
     +     (S - F LOA TF (I C)))

che era sintatticamente identico a

  799 S = FLOATF (IA + IB + IC) / 2.0
      AREA = SQRT( S * (S - FLOATF(IA)) * (S - FLOATF(IB)) *
     +     (S - FLOATF(IC)))

Con quel tipo di storia di abusi, perché rendere difficile l'analisi per gli umani? Per non parlare del complicare l'analisi del computer.

Answer 4

Sì, è l'analisi - sia umana che informatica. È più facile da leggere e da analizzare se si può presumere che gli spazi bianchi non contino. Altrimenti, puoi avere dichiarazioni potenzialmente ambigue, dichiarazioni in cui non è chiaro come vanno le cose insieme, dichiarazioni che sono difficili da leggere, ecc.

Answer 5

Un simile cambiamento comporterebbe un linguaggio ambiguo nel migliore dei casi. Ad esempio, in un linguaggio simile al C99:

if not foo(int x) {
    ...
}

è equivalente a:

1. Una definizione di funzione di foo che restituisce un valore di tipo ifnot :

   ifnot foo(int x) {
       ...
   }
   

2. Una chiamata a una funzione chiamata notfoo con una variabile denominata intx :

   if notfoo(intx) {
       ...
   }
   

3. Una chiamata negata a una funzione chiamata foo (con non di C99 che significa ! ):

   if not foo(intx) {
       ...
   }
   

Questo è solo un piccolo esempio delle ambiguità che potresti incontrare.

Aggiornamento: ho appena notato che, ovviamente, in un linguaggio simile al C99, la condizione di un'istruzione se sarebbe racchiusa tra parentesi. La punteggiatura aggiuntiva può aiutarti con le ambiguità se scegli di ignorare gli spazi bianchi, ma la tua lingua finirà per avere un sacco di punteggiatura extra ovunque avresti normalmente usato lo spazio bianco.

Answer 6

Scopri il classico Generalizing Overloading for C ++ 2000 di Stroustrup.

Answer 7

Ci è stato permesso di rimettere gli spazi nei nomi dei file negli anni '60 e i computer ancora non li gestiscono molto bene (tutto ciò che era solito rompersi, quindi la maggior parte delle cose, ora sono solo alcune cose - ma si rompono ancora).

Non possiamo semplicemente aspettare altri 50 anni prima che il nostro codice funzioni di nuovo. : -)

(E ciò che tutti gli altri hanno detto, ovviamente. In inglese, usiamo spazi e punteggiatura per separare le parole. Lo stesso vale per i linguaggi informatici, tranne per il fatto che i parser di computer definiscono "parole" in un senso leggermente diverso)

Answer 8

L'uso dello spazio come parte di un identificatore rende l'analisi molto oscura (è uno spazio sintattico o un identificatore?), ma lo stesso tipo di "lettura naturale" il comportamento si ottiene con argomenti di parole chiave object.save (data: qualcosa, atomicamente: vero)

Answer 9

Esistono alcune lingue che consentono spazi negli identificatori. Il fatto che quasi tutte le lingue limitano l'insieme di caratteri negli identificatori è perché l'analisi è più semplice e la maggior parte dei programmatori è abituata allo stile compatto senza spazi bianchi.

Non credo che ci sia la vera ragione.

Answer 10

Il linguaggio TikZ per la creazione di grafica in LaTeX consente lo spazio bianco nei nomi dei parametri (noto anche come 'chiavi'). Ad esempio, vedi cose come

\shade[
  top color=yellow!70,
  bottom color=red!70,
  shading angle={45},
]

In questa impostazione limitata di un elenco separato da virgole di coppie chiave-valore, non vi sono difficoltà di analisi. In effetti, penso che sia molto più facile da leggere rispetto alle alternative come topColor , top_color o topcolor .