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

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 backquote o altri delimitatori prima che possano essere utilizzati.

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

Dim [Hello World]
[Hello World] = 123

Tuttavia, farlo è abbastanza raro.

SQL conta?

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

Bene Spazio bianco è tutto su ... spazi bianchi:

Most modern programming languages do not consider white space characters (spaces, tabs and newlines) syntax, ignoring them, as if they weren't there. We consider this to be a gross injustice to these perfectly friendly members of the character set. Should they be ignored, just because they are invisible? Whitespace is a language that seeks to redress the balance. Any non whitespace characters are ignored; only spaces, tabs and newlines are considered syntax.

Sfortunatamente Markdown non supporta la sua sintassi e non posso mostrarti del codice, ma Wikipedia ha un campione di codice amichevole .

In Algol 68 potresti avere spazio negli identificatori (non ricordo se fossero significativi o meno). Ma le parole chiave sono state contrassegnate da stropping . Usare nomi con lo spazio in essi era idiomatico (almeno intorno a me).

VHDL consente identificativi di escape con spazi significativi in essi: \foo bar\ . Ciò consente anche di utilizzare parole chiave come identificatore \and\ , qualsiasi carattere \n<42>\ e maiuscole / minuscole negli identificatori ( \Foo\ e \foo\ sono diversi mentre Foo e foo sono equivalenti e diversi da \Foo\ e \foo\ !). Verilog ha anche espanso gli identificatori con la maggior parte di queste caratteristiche (gli identificatori normali sono case sensitive e sfuggirli inutilmente non fa un altro identificatore), ma non lascia spazio in essi. La necessità degli identificatori di escape in VHDL e Verilog deriva dal fatto che spesso sono prodotti automaticamente da altre fonti (come schematica) dove gli identificatori di solito non hanno la stessa restrizione del linguaggio di programmazione; AFAIK, non sono utilizzati in modo idiomatico 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)

Credo che soddisfi i criteri - una lingua in cui gli identificatori abitualmente contengono spazi. Non è mai (penso?) Ambiguo perché gli identificatori sono sempre circondati da un sacco di segni di punteggiatura per separarli dal testo del wiki.

Inform 7 è un sistema per lo sviluppo di narrativa interattiva usando sintassi simile al linguaggio naturale, in cui gli identificatori di più parole sono comuni:

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

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

Analogamente, gli identificatori con caratteri di sottolineatura in Agda possono essere utilizzati mixfix, l'esempio più semplice di che è probabilmente l'operatore if_then_else_ :

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 usando i backtick. Il solito uso è invocare Thread.'yield' perché yield è una parola riservata in Scala. Questo potrebbe essere (ab) usato per avere spazi nei nomi, anche se questo sarebbe lontano dal codice Scala idiomatico:

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

Diamine, puoi persino avere le schede negli identificatori:

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

Suppongo che questo potrebbe essere concepibile essere idiomatico per la gente che programma la letteratura. Forse.

Potresti considerare ciò come nel Cucumber / Gherkin , dove i nomi delle funzioni sono effettivamente frasi con gli argomenti incorporati al loro interno.

Come estensione, mi aspetto che questo sia più comune nei minuscoli DSL , dove si suppone che la lingua essere amichevole con i non sviluppatori. Ad esempio, molti motori di regole forniscono una capacità di definire regole con una descrizione simile all'inglese, in cui gli spazi possono essere utilizzati negli identificatori.

F # consente lo spazio bianco nei nomi degli identificatori, ma devono essere circondati da doppi apici inversi. Leggi la risposta a questa domanda: link .

FWIW, Tcl consente gli spazi (e quasi tutti gli altri caratteri) negli identificatori, sebbene non sia comune trarre vantaggio da questa funzione. Il motivo principale per cui non viene usato molto spesso è solo che devi usare la citazione corretta. Ad esempio, il seguente 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 dinamicamente poiché, quando si creano tali variabili, non ci si deve preoccupare dei caratteri illegali

Ne sono pochi a conoscenza. Sto lavorando su uno , e lithe linguaggio di programmazione . Inform sì, ma non è esattamente un linguaggio di programmazione generico.

Se consideri una DSL di test automatizzata una lingua, la struttura del robot consente spazi nei nomi di parole chiave ed è molto idiomatica. Nell'esempio seguente "Dì ciao" è un nome di parola chiave, "Esempio di test case" è un nome del 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

La lingua 4D consente il bianco spazio nei nomi e nelle variabili del metodo. È generalmente disapprovato all'interno della comunità, ma tutti i metodi e le variabili incorporati li usano quando applicabile ( SET MENU ITEM PARAMETER , ad esempio)

Smalltalk presenta metodi di parole chiave come a:b:c: che coinvolgono spazi bianchi quando invocati. E.g .: a: 100 b: 200 c: 300 . Questo è un idioma standard nella lingua.

Powershell consente spazi nei nomi di variabili:

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

PS C:\> ${the var}
100

Ho visto parlare di simile 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 letterali degli oggetti. I nomi di proprietà che non seguono le regole di denominazione delle variabili di JS non sono accessibili tramite. notazione ma sono a portata di mano. Ad esempio, potresti voler associare gli URL al comportamento o fare riferimento a un gruppo di persone per nome quando sei certo 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 facilità d'uso senza perdere il fattore istantaneo dell'oggetto quando viene rilasciato in JS.

Power Query utilizza molto del codice generato automaticamente. Immagino che più della metà degli identificatori generati utilizzi lo spazio bianco:

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 disambiguare l'identificatore.

Ma in luoghi in cui non è ambiguo, 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 contate come linguaggio reale, linguaggio di scripting JMP ( link ). Permette agli identificatori di avere spazi bianchi (per renderli più "leggibili") e più o meno incoraggia tali.

Il linguaggio di programmazione o42a attualmente in sviluppo supporta i nomi di più parole . La lingua non ha parole chiave e i nomi di solito sono separati da un simbolo. Nel raro caso i due nomi si susseguono, il trattino basso viene usato per separarli.

Authorware, il cui linguaggio di scripting era basato su Pascal non orientato agli oggetti, consentiva spazi nei nomi di variabili, sebbene col tempo le persone scoprissero i problemi con il loro utilizzo e si allontanassero da esso link .

Modifica: questa risposta è stata mostrata come non corretta, vedere i commenti.

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

int my = 0; bool my count = false; int count = 0; if (my Count) ...

il termine 'mio conteggio' confonde che potrebbe fare riferimento alla variabile chiamata 'mio conteggio' o forse lo sviluppatore ha dimenticato di scrivere un operatore di relazioni come > tra il mio e il conteggio.

COBOL ha permesso di separare i nomi di divisione e i nomi delle sezioni in base allo spazio, ma quelli non sono identificatori e variabili come nella tua domanda.