¿Los espacios en blanco en los identificadores alguna vez han sido idiomáticos? [cerrado]

Los compiladores FORTRAN ignoraron los espacios, por lo que:

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

Eran idénticos en lo que se refería al compilador.

Algunos dialectos de SQL permiten espacios incrustados en los nombres de columnas, pero deben estar rodeados por comillas inversas o algún otro delimitador antes de que puedan usarse.

Visual Basic (y VBScript) también permiten espacios en blanco en los identificadores si rodea el identificador entre corchetes.

Dim [Hello World]
[Hello World] = 123

Sin embargo, hacerlo es bastante raro.

¿Cuenta SQL?

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

Bueno, Whitespace se trata de ... espacio en blanco:

  

La mayoría de los lenguajes de programación modernos no consideran la sintaxis de los caracteres de espacios en blanco (espacios, tabulaciones y nuevas líneas), ignorándolos, como si no estuvieran allí. Consideramos que esto es una grave injusticia para estos miembros perfectamente amigables del conjunto de caracteres. ¿Deberían ser ignorados, simplemente porque son invisibles? El espacio en blanco es un lenguaje que busca corregir el equilibrio. Se ignoran los caracteres que no sean espacios en blanco; Sólo los espacios, las pestañas y las nuevas líneas se consideran sintaxis.

Desafortunadamente, Markdown no admite su sintaxis y no puedo mostrarte un código, pero Wikipedia tiene un Ejemplo de código amigable para el hombre .

En Algol 68 podría tener espacio en los identificadores (no recuerdo si fueran significativos o no). Pero las palabras clave se marcaron con stropping . Usar nombres con espacio en ellos fue idiomático (al menos a mi alrededor).

VHDL permite identificadores de escape con espacios significativos en ellos: \foo bar\ . Esto también permite usar palabras clave como identificador \and\ , cualquier carácter \n<42>\ y la sensibilidad a mayúsculas en los identificadores ( \Foo\ y \foo\ son diferentes, mientras que Foo y foo son equivalentes, y son diferentes de \Foo\ y \foo\ !). Verilog también tiene identificadores espaciados con la mayoría de estas características (los identificadores normales distinguen entre mayúsculas y minúsculas y el escape innecesario no crea otro identificador), pero no permite espacios en ellos. La necesidad de identificadores escapados en VHDL y Verilog proviene del hecho de que a menudo se producen automáticamente a partir de otras fuentes (como el esquema) donde los identificadores generalmente no tienen la misma restricción que en el lenguaje de programación; AFAIK, no se utilizan idiomáticamente en otras circunstancias.

No sé si consideras MediaWiki wikitext un lenguaje, pero los nombres con espacios son definitivamente idiomáticos:

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

Donde "expandir sección" es el nombre de una plantilla (http://en.wikipedia.org/wiki/Template:Expand_section)

Supongo que cumple con los criterios, un idioma en el que los identificadores contienen espacios de forma rutinaria. Nunca es (¿creo?) Ambiguo porque los identificadores siempre están rodeados por una gran cantidad de puntuación para separarlos del texto del wiki sin formato.

Inform 7 es un sistema para desarrollar ficción interactiva utilizando una sintaxis similar a un lenguaje natural, en el que los identificadores de varias palabras son comunes:

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

La restricción, por supuesto, es que un identificador no puede contener una palabra clave cuando esto sería ambiguo.

De manera similar, los identificadores con guiones bajos en Agda se pueden usar mixfix, el ejemplo más simple de que es probablemente el 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

Scala permite identificadores arbitrarios utilizando backticks. El uso habitual para esto es invocar Thread.'yield' porque yield es una palabra reservada en Scala. Esto podría ser (ab) tener espacios en los nombres, aunque estaría lejos del código Scala idiomático:

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

Vaya, incluso puedes tener pestañas en los identificadores:

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

Supongo que esto podría posiblemente ser idiomático para la gente de programación alfabetizada. Tal vez.

Puede considerar que este es el caso en Cucumber / Gherkin , donde los nombres de funciones son oraciones con los argumentos incorporados dentro de ellos.

Como extensión, espero que esto sea más común en los pequeños DSLs , donde se supone el idioma ser amigable con los desarrolladores no. Por ejemplo, muchos motores de reglas ofrecen la posibilidad de definir reglas con una descripción similar a la del inglés, donde los espacios se pueden usar en los identificadores.

F # permite espacios en blanco en los nombres de los identificadores, pero deben estar rodeados con dobles comillas invertidas. Consulte la respuesta a esta pregunta: enlace .

FWIW, Tcl permite espacios (y casi todos los demás caracteres) en los identificadores, aunque no es común aprovechar esta función. La razón principal por la que no se usa muy a menudo es simplemente que tiene que usar la cotización adecuada. Por ejemplo, lo siguiente establece una variable llamada "mi nombre" en "bob" y luego la imprime

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

OTOH, es muy útil cuando se crean variables dinámicamente ya que, al crear tales variables, uno no tiene que preocuparse por los caracteres ilegales

Hay pocos que yo sepa. Estoy trabajando en uno y en lenguaje de programación ágil . Inform lo hace, pero no es exactamente un lenguaje de programación de propósito general.

Si considera que un DSL de prueba automatizado es un lenguaje, el robot framework permite espacios en los nombres de palabras clave, y es muy idiomático. En el siguiente ejemplo, "Diga hola" es un nombre de palabra clave, "Ejemplo de caso de prueba" es un nombre de caso de prueba y "$ {primer nombre}" es una variable:

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

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

El lenguaje 4D permite el blanco Espacio en nombres de método y variables. Por lo general, está mal visto dentro de la comunidad, pero todos los métodos y variables incorporados los usan cuando corresponde (por ejemplo, SET MENU ITEM PARAMETER )

Power Query usa mucho de código generado automáticamente. Supongo que más de la mitad de los identificadores generados usan espacios en blanco:

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 puede ver, al igual que en muchos idiomas, hay una sintaxis adicional para desambiguar cuál es el identificador.

Pero en lugares donde no es ambiguo, no se necesita una sintaxis adicional:

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

Smalltalk presenta métodos de palabras clave como a:b:c: que involucran espacios en blanco cuando se invocan. Por ejemplo: a: 100 b: 200 c: 300 . Este es un idioma estándar en el idioma.

Powershell permite espacios en nombres de variables:

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

PS C:\> ${the var}
100

Vi una mención de similar para VB pero en JS esto se usa mucho en realidad. Se puede acceder a cualquier propiedad de un objeto en JavaScript y establecerla en forma de cadena con corchetes o simplemente como cadenas en literales de objetos. Los nombres de propiedades que no siguen las reglas de denominación de variables de JS son inaccesibles a través de. Notación pero son útiles. Por ejemplo, es posible que desee asignar direcciones URL al comportamiento o hacer referencia a un grupo de personas por su nombre cuando esté seguro de que todas son únicas. A menudo es muy conveniente y fácil de leer:

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

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

Esto también facilita la reestructuración de JSON para facilitar su uso sin perder el factor de objeto instantáneo cuando se coloca en JS.

Si lo considera como un lenguaje real, el lenguaje de scripting JMP ( enlace ). Permite que los identificadores tengan espacios en blanco (para hacerlos más "legibles") y más o menos los alienta.

El lenguaje de programación o42a que estoy desarrollando actualmente es compatible con nombres de varias palabras . El idioma no tiene palabras clave y los nombres suelen estar separados por algún símbolo. En el caso raro de que los dos nombres se sigan, el guión bajo se usa para separarlos.

Authorware, cuyo lenguaje de script estaba basado en Pascal no orientado a objetos, permitía espacios con nombres de variables, aunque con el tiempo la gente descubrió los problemas con su uso y se alejó de él enlace .

Editar: esta respuesta se mostró incorrecta, vea los comentarios.

Si entiendo su pregunta correctamente, un compilador no puede permitir espacio (s) en el nombre del identificador porque podría causar nombres duplicados (a menos que se use un delimitador). Por ejemplo:

int my = 0; bool mi cuenta = falso; cuenta int = 0; si (mi cuenta) ...

el término "mi cuenta" confunde que podría referirse a la variable llamada "mi cuenta" o tal vez el desarrollador olvidó escribir un operador de relación como > entre mi y contar.

COBOL permitió que los nombres de división y los nombres de sección estén separados por espacios, pero no son identificadores ni variables como en tu pregunta.