O estilo C # sugere o uso de CamelCase em identificadores para delimitar palavras. A tradição do Lisp sugere usar traços em vez disso.
Alguma vez existiu uma linguagem de programação em que o uso de espaços em identificadores não fosse permitido apenas, mas um idioma comumente usado ao empregar identificadores de várias palavras?
É possível ter identificadores com espaços em algumas implementações Scheme , mas não é uma prática amplamente vista . Aqui está um exemplo:
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)
Os compiladores FORTRAN ignoraram os espaços de modo que:
result = value * factor
r e s u l t = val ue * fac tor
result=value*factor'
Foram idênticos no que diz respeito ao compilador.
Alguns dialetos SQL permitem espaços incorporados nos nomes das colunas, mas eles precisam ser cercados por backquotes ou algum outro delimitador antes que possam ser usados.
Visual Basic (e VBScript) também permitem espaços em branco nos identificadores, se você colocar o identificador entre colchetes.
Dim [Hello World]
[Hello World] = 123
No entanto, isso é muito raro.
O SQL conta?
create table "Registered Members" (
"Full Name" varchar(100),
"Mailing Address" varchar(100),
etc...
);
Bem Espaço em branco tem tudo a ver ... espaço em branco:
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.
Infelizmente, o Markdown não suporta a sua sintaxe e não posso mostrar-lhe algum código, mas a Wikipédia tem um amostra de código amigável ao homem .
No Algol 68 você pode ter espaço nos identificadores (não me lembro se eles eram significativos ou não). Mas as palavras-chave foram marcadas por corte . Usar nomes com espaço neles era idiomático (pelo menos ao meu redor).
O VHDL permite identificadores com escape com espaços significativos: \foo bar\ . Isso também permite usar palavras-chave como identificador \and\ , qualquer caractere \n<42>\ e diferenciação de maiúsculas e minúsculas nos identificadores ( \Foo\ e \foo\ são diferentes, enquanto Foo e foo são equivalentes e diferentes de \Foo\ e \foo\ !). O Verilog também possui identificadores com a maioria dessas características (os identificadores normais diferenciam maiúsculas de minúsculas e os que escapam desnecessariamente não criam outro identificador), mas não permitem espaços neles. A necessidade de identificadores com escape em VHDL e Verilog vem do fato de que eles são frequentemente produzidos automaticamente de outras fontes (como esquemática), onde os identificadores geralmente não têm a mesma restrição que na linguagem de programação; AFAIK, eles não são usados de forma idiomática em outras circunstâncias.
Não sei se você considera o MediaWiki wikitext uma linguagem, mas os nomes com espaços são definitivamente idiomáticos:
==Example==
This example lacks text.
{{Expand section}}
Onde "expandir seção" é o nome de um modelo (http://en.wikipedia.org/wiki/Template:Expand_section)
Eu acho que atende aos critérios - uma linguagem em que os identificadores contêm espaços rotineiramente. Nunca é (eu acho?) Ambíguo porque os identificadores são sempre cercados por muita pontuação para separá-los do texto bruto da wiki.
O Inform 7 é um sistema para o desenvolvimento de ficção interativa usando uma sintaxe semelhante à linguagem natural, na qual identificadores de várias palavras são comuns:
Mr Jones wears a top hat. The crate contains a croquet mallet.
A restrição, é claro, é que um identificador não pode conter uma palavra-chave quando isso seria ambíguo.
Na mesma linha, identificadores com sublinhados em Agda podem ser usados como mixfix, o exemplo mais simples de que é provavelmente o operador 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
O Scala permite identificadores arbitrários usando backticks. O uso usual para isso é invocar Thread.'yield' porque yield é uma palavra reservada no Scala. Isso pode ser (ab) usado para ter espaços em nomes, embora isso esteja longe de ser um código Scala idiomático:
val 'the answer' = 42
println('the answer')
Heck, você pode até ter guias nos identificadores:
scala> val 'the\tanswer' = 42
the answer: Int = 42
Eu suponho que isso poderia concebivelmente ser idiomático para o folk letrado de programação. Talvez.
Você pode considerar este o caso em Pepino / Pepino , onde os nomes das funções são efetivamente frases com os argumentos embutidos dentro deles.
Como extensão, eu esperaria que isso fosse mais comum em pequenas DSLs , onde a linguagem é suposta para ser amigável com os desenvolvedores não. Por exemplo, muitos mecanismos de regras fornecem uma habilidade para definir regras com uma descrição em inglês, onde espaços podem ser usados em identificadores.
FWIW, o Tcl permite espaços (e praticamente todos os outros caracteres) em identificadores, embora não seja comum aproveitar esse recurso. A principal razão que não é usada com muita frequência é apenas que você tem que usar a cotação adequada. Por exemplo, o seguinte define uma variável chamada "meu nome" para "bob" e, em seguida, imprime-a
set "my name" "bob"
puts "hello, ${my name}"
OTOH, é muito útil ao construir variáveis dinamicamente, pois ao criar essas variáveis, não é preciso se preocupar com caracteres ilegais
Há poucos que eu conheço. Estou trabalhando em um , e o linguagem de programação ágil . Inform , mas não é exatamente uma linguagem de programação de propósito geral.
Se você considera um idioma de teste DSL automatizado, a estrutura de robô permite espaços em nomes de palavras-chave e é muito idiomática. No exemplo a seguir, "Say hello" é um nome de palavra-chave, "Exemplo de caso de teste" é um nome de caso de teste e "$ {first name}" é uma variável:
*** Keywords ***
| Say hello | [Arguments] | ${first name}
| | log | Hello, ${first name}
*** Test Cases ***
| Example test case
| | Say hello | world
A linguagem 4D permite que o branco espaço nos nomes e variáveis dos métodos. Geralmente é desaprovado dentro da comunidade, mas todos os métodos e variáveis internos os usam quando aplicável ( SET MENU ITEM PARAMETER , por exemplo)
O Smalltalk apresenta métodos de palavras-chave, como a:b:c: , que envolvem espaços em branco quando invocados. Por exemplo: a: 100 b: 200 c: 300 . Este é um idioma padrão na linguagem.
O Powershell permite espaços nos nomes das variáveis:
PS C:\> ${the var} = 100
PS C:\> ${the var}
100
Eu vi menção de similar para VB, mas em JS isso é muito usado na verdade. Qualquer propriedade de um objeto em JavaScript pode ser acessada e definida em forma de string com colchetes ou simplesmente como strings em literais de objeto. Nomes de propriedades que não seguem as regras de nomeação de variáveis do JS são inacessíveis via. notação, mas eles são úteis. Por exemplo, você pode mapear URLs para o comportamento ou fazer referência a um grupo de pessoas pelo nome quando tiver certeza de que são todas exclusivas. Muitas vezes é muito conveniente e fácil de ler:
var peoplesFavoriteThings = {
"Bob Jones":"kittens",
"Jane Doe":"chainsaws"
}
for(var name in peoplesFavoriteThings){
console.log(name + ' likes ' + peoplesFavoriteThings[name] + '.\n');
}
Isso também facilita a reestruturação do JSON para facilitar o uso sem perder o fator de objeto instantâneo ao ser descartado no JS.
Power Query usa muito de código gerado automaticamente. Eu acho que mais da metade dos identificadores gerados usam espaço em branco:
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"
Como você pode ver, como em muitos idiomas, há uma sintaxe extra para diferenciar o identificador.
Mas em lugares onde não é ambíguo, nenhuma sintaxe extra é necessária:
let
spaceRecord = [with space = 42, recursive record = @spaceRecord],
drilldown = spaceRecord[recursive record][recursive record][recursive record][with space]
in
drilldown // 42
A linguagem de programação o42a que estou desenvolvendo atualmente suporta nomes com várias palavras . A linguagem não tem palavras-chave e os nomes são geralmente separados por algum símbolo. No caso raro, os dois nomes seguem um ao outro, o sublinhado é usado para separá-los.
Editar: Esta resposta mostrou-se incorreta, veja os comentários.
Se eu entendi sua pergunta corretamente, um compilador não pode permitir espaço (s) no nome do identificador, pois isso poderia causar nomes duplicados (a menos que um delimitador seja usado). Por exemplo:
int my = 0; bool my count = false; int count = 0; se (minha contagem) ...
o termo 'minha conta' é confuso, ele pode se referir à variável chamada 'minha conta' ou talvez o desenvolvedor tenha esquecido de escrever um operador de relação como > entre o meu e contar.
Os nomes de divisão permitidos e os nomes das seções COBOL podem ser separados por espaço, mas não são identificadores e variáveis como na sua pergunta.