Gli spazi bianchi negli identificatori sono mai stati idiomatici? [chiuso]

Lo stile C # suggerisce di usare CamelCase negli identificatori per delimitare le parole. La tradizione Lisp suggerisce invece di usare trattini.

È mai esistito un linguaggio di programmazione in cui l'uso degli spazi negli identificatori non era solo consentito, ma un linguaggio comunemente usato quando si impiegano identificatori a più parole?

È possibile avere identificatori con spazi in alcune implementazioni di Scheme , ma non è una pratica ampiamente diffusa. Ecco un esempio:

Petite Chez Scheme Version 8.4
Copyright (c) 1985-2011 Cadence Research Systems

> (define |hey there| 100)
> (define |x y z| 200)
> (list |hey there| |x y z|)
(100 200)

I compilatori FORTRAN hanno ignorato gli spazi così:

   result = value * factor  
   r e s u l t = val ue * fac tor
   result=value*factor`

Erano identici per quanto riguarda il compilatore.

Alcuni dialetti SQL consentono spazi incorporati nei nomi delle colonne ma devono essere circondati da backquotes o da qualche altro delimitatore prima di poter essere utilizzati.

Visual Basic (e VBScript) consentono inoltre spazi bianchi negli identificatori se si circonda l'identificatore con parentesi quadre.

Dim [Hello World]
[Hello World] = 123

Tuttavia, farlo è piuttosto raro.

Conta SQL?

create table "Registered Members" (
    "Full Name" varchar(100),
    "Mailing Address" varchar(100),
    etc...
);

Beh, Whitespace è tutto su ... whitespace:

La maggior parte dei linguaggi di programmazione moderni non considera la sintassi dei caratteri degli spazi bianchi (spazi, tabulazioni e nuove righe), ignorandoli, come se non fossero presenti. Riteniamo che questa sia un'ingiustizia grave per questi membri perfettamente amichevoli del set di caratteri. Dovrebbero essere ignorati, solo perché sono invisibili? Lo spazio bianco è un linguaggio che cerca di ristabilire l'equilibrio. Qualsiasi carattere non bianco viene ignorato; solo gli spazi, le schede e le nuove righe sono considerati sintassi.

Sfortunatamente Markdown non supporta la sua sintassi e non posso mostrarti un po 'di codice, ma Wikipedia ha un esempio di codice amico dell'uomo .

In Algol 68 potresti avere spazio negli identificatori (non ricordo se fossero significativi o meno). Ma le parole chiave sono state contrassegnate da carezze . L'uso dei nomi con lo spazio era idiomatico (almeno intorno a me).

VHDL permette di identificatori con spazi significativi nel loro sfuggito: \foo bar\. Questo permette anche di utilizzare parole chiave come identificativo \and\, qualsiasi carattere \n<42>\e caso sensibilità identificatori ( \Foo\e \foo\sono diverse, mentre Fooe foosono equivalenti, e diverso da entrambi \Foo\e\foo\!). Verilog ha anche identificato gli identificatori con la maggior parte di queste caratteristiche (gli identificatori normali fanno distinzione tra maiuscole e minuscole e la loro fuga inutilmente non crea un altro identificatore), ma non consente spazi in essi. La necessità di identificatori sfuggiti in VHDL e Verilog deriva dal fatto che sono spesso prodotti automaticamente da altre fonti (come lo schema) in cui gli identificatori di solito non hanno le stesse restrizioni del linguaggio di programmazione; AFAIK, non sono usati idiomaticamente in altre circostanze.

Non so se consideri MediaWiki wikitext una lingua, ma i nomi con spazi sono decisamente idiomatici:

==Example==
This example lacks text.
{{Expand section}}

Dove "espandi sezione" è il nome di un modello (http://en.wikipedia.org/wiki/Template:Expand_section)

Immagino che soddisfi i criteri: un linguaggio in cui gli identificatori contengono abitualmente spazi. Non è mai (penso?) Ambiguo perché gli identificatori sono sempre circondati da un sacco di punteggiatura per separarli dal testo wiki grezzo.

Inform 7 è un sistema per lo sviluppo di narrativa interattiva che utilizza una sintassi simile al linguaggio naturale, in cui gli identificatori di più parole sono all'ordine del giorno:

Mr Jones wears a top hat. The crate contains a croquet mallet. 

La limitazione, ovviamente, è che un identificatore non può contenere una parola chiave quando questo sarebbe ambiguo.

Allo stesso modo, gli identificatori con caratteri di sottolineatura in Agda possono essere usati mixfix, il cui esempio più semplice è probabilmente l' if_then_else_operatore:

if_then_else_ : {A : Set} -> Bool -> A -> A -> A
if true  then x else y = x
if false then x else y = y

Scala consente identificatori arbitrari utilizzando i backtick. Il solito uso per questo è invocare Thread.`yield`perché yieldè una parola riservata in Scala. Questo potrebbe essere (ab) usato per avere spazi nei nomi, anche se sarebbe lontano dal codice Scala idiomatico:

val `the answer` = 42
println(`the answer`)

Cavolo, puoi anche avere delle schede negli identificatori:

scala> val `the\tanswer` = 42
the     answer: Int = 42

Suppongo che ciò possa essere plausibilmente idiomatico per il popolo letterato programmatore. Può essere.

F # consente spazi bianchi nei nomi degli identificatori, ma devono essere circondati da doppi backtick. Vedi la risposta a questa domanda: https://stackoverflow.com/questions/6639688/using-keywords-as-identifiers-in-f .

Potresti considerare questo come il caso in Cucumber / Gherkin , in cui i nomi delle funzioni sono effettivamente frasi con gli argomenti incorporati al loro interno.

Come estensione, mi aspetto che questo sia più comune nei piccoli DSL , dove il linguaggio dovrebbe essere amichevole per i non sviluppatori. Ad esempio, molti motori di regole forniscono un'abilità per definire regole con una descrizione di tipo inglese, in cui gli spazi possono essere utilizzati negli identificatori.

FWIW, Tcl consente spazi (e quasi ogni altro carattere) negli identificatori, anche se non è comune sfruttare questa funzionalità. Il motivo principale per cui non viene utilizzato molto spesso è solo che è necessario utilizzare una quotazione corretta. Ad esempio, quanto segue imposta una variabile denominata "il mio nome" su "bob", quindi la stampa

set "my name" "bob"
puts "hello, ${my name}"

OTOH, è molto utile quando si creano variabili in modo dinamico poiché, quando si creano tali variabili, non ci si deve preoccupare di caratteri illegali

Ce ne sono pochi che conosco. Sto lavorando su uno e il linguaggio di programmazione agile . Inform lo fa, ma non è esattamente un linguaggio di programmazione generico.

Se consideri un DSL di test automatizzato una lingua, il framework robot consente spazi nei nomi di parole chiave ed è molto idiomatico. Nel seguente esempio "Say hello" è un nome di parola chiave, "Esempio di test case" è un nome di test case e "$ {first name}" è una variabile:

*** Keywords ***
| Say hello | [Arguments] | ${first name}
| | log | Hello, ${first name}

*** Test Cases ***
| Example test case
| | Say hello | world

Il linguaggio 4D consente spazi bianchi nei nomi e nelle variabili dei metodi. È generalmente disapprovato all'interno della comunità, ma tutti i metodi e le variabili incorporati li usano quando applicabile ( SET MENU ITEM PARAMETERad esempio)

Smalltalk presenta metodi di parole chiave come quelli a:b:c:che coinvolgono spazi bianchi quando invocati. Ad esempio: a: 100 b: 200 c: 300. Questo è un linguaggio standard nella lingua.

Powershell consente spazi nei nomi delle variabili:

PS C:\> ${the var} = 100

PS C:\> ${the var}
100

Ho visto parlare di simili per VB ma in JS questo è usato molto in realtà. È possibile accedere a qualsiasi proprietà di un oggetto in JavaScript e impostarla in forma di stringa con parentesi quadre o semplicemente come stringhe nei valori letterali degli oggetti. I nomi delle proprietà che non seguono le regole di denominazione delle variabili di JS sono inaccessibili tramite. notazione ma sono utili. Ad esempio, potresti voler mappare gli URL in base al comportamento o fare riferimento a un gruppo di persone per nome quando sei sicuro che siano tutti unici. Spesso è molto comodo e facile da leggere:

var peoplesFavoriteThings = {
    "Bob Jones":"kittens",
    "Jane Doe":"chainsaws"
}

for(var name in peoplesFavoriteThings){
    console.log(name + ' likes ' + peoplesFavoriteThings[name] + '.\n');
}

Ciò semplifica anche la ristrutturazione di JSON per facilitarne l'utilizzo senza perdere il fattore oggetto istantaneo quando viene inserito in JS.

Power Query utilizza molto codice generato automaticamente. Immagino che più della metà degli identificatori generati utilizzino spazi bianchi:

let
    Source = Sql.Database(".", "Test"),
    dbo_pvt = Source{[Schema="dbo",Item="pvt"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_pvt, each [VendorID] <= 4),
    #"Removed Columns" = Table.RemoveColumns(#"Filtered Rows",{"Emp1", "Emp2"}),
    #"Grouped Rows" = Table.Group(#"Removed Columns", {"Emp3", "Emp4"}, {{"Count", each List.Sum([Emp5]), type number}})
in
    #"Grouped Rows"

Come puoi vedere, come in molte lingue c'è una sintassi extra per chiarire qual è l'identificatore.

Ma nei luoghi in cui è inequivocabile, non è necessaria alcuna sintassi aggiuntiva:

let
    spaceRecord = [with space = 42, recursive record = @spaceRecord],
    drilldown = spaceRecord[recursive record][recursive record][recursive record][with space]
in
    drilldown   // 42

Se lo si considera come un linguaggio reale, il linguaggio di scripting JMP ( http://www.jmp.com/support/downloads/pdf/jmp_scripting_guide.pdf ). Permette agli identificatori di avere spazi bianchi (per renderli più "leggibili") e più o meno li incoraggia.

Il linguaggio di programmazione o42a che sto attualmente sviluppando supporta nomi di più parole . La lingua non ha parole chiave e i nomi sono generalmente separati da un simbolo. Nel raro caso i due nomi si susseguano, il carattere di sottolineatura viene utilizzato per separarli.

Authorware, il cui linguaggio di scripting era basato su Pascal non orientato agli oggetti, consentiva spazi nei nomi delle variabili, anche se nel tempo le persone hanno scoperto i problemi con il loro utilizzo e si sono allontanate da esso http://books.google.com/books?id= bHC88YignAkC & pg = PA428 & gpl = PA428 .

Modifica: questa risposta ha dimostrato di non essere corretta, vedere i commenti.

Se capisco correttamente la tua domanda, un compilatore non può consentire spazi nel nome dell'identificatore perché potrebbe causare nomi duplicati (a meno che non venga utilizzato un delimitatore). Per esempio:

int my = 0; bool my count = false; int count = 0; if (il mio conte) ...

il termine "mio conteggio" confonde che potrebbe riferirsi alla variabile chiamata "il mio conteggio" o forse lo sviluppatore ha dimenticato di scrivere un operatore di relazione come> tra mio e conteggio.

COBOL ha permesso ai nomi di divisione e ai nomi di sezione di essere separati dallo spazio, ma quelli non sono identificatori e variabili come nella tua domanda.