Les espaces dans les identificateurs ont-ils déjà été idiomatiques? [fermé]

Le style C # suggère d'utiliser CamelCase dans des identifiants pour délimiter des mots. La tradition Lisp suggère d'utiliser plutôt des tirets.

Existe-t-il un langage de programmation où l’utilisation d’espaces dans les identifiants était non seulement autorisée, mais un idiome communément utilisé pour les identifiants à plusieurs mots?

Il est possible d'avoir des identifiants avec des espaces dans certaines implémentations de Scheme , mais ce n'est pas une pratique largement vue. Voici un exemple:

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)

Les compilateurs FORTRAN ont ignoré les espaces afin:

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

Étaient identiques en ce qui concerne le compilateur.

Certains dialectes SQL autorisent les espaces incorporés dans les noms de colonne, mais ils doivent être entourés de guillemets arrières ou d'un autre délimiteur avant de pouvoir être utilisés.

Visual Basic (et VBScript) autorisent également les espaces dans les identificateurs si vous l’entourez de crochets.

Dim [Hello World]
[Hello World] = 123

Cependant, cela est assez rare.

Est-ce que SQL compte?

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

Eh bien Whitespace est tout au sujet ... des espaces:

La plupart des langages de programmation modernes ne prennent pas en compte la syntaxe des caractères d'espaces (espaces, tabulations et nouvelles lignes), en les ignorant, comme s'ils n'y étaient pas. Nous considérons qu'il s'agit d'une injustice flagrante à l'égard de ces membres parfaitement sympathiques du jeu de caractères. Devraient-ils être ignorés, simplement parce qu'ils sont invisibles? Les espaces sont un langage qui cherche à redresser la barre. Tous les caractères non blancs sont ignorés; seuls les espaces, les tabulations et les nouvelles lignes sont considérés comme une syntaxe.

Malheureusement, Markdown ne supporte pas sa syntaxe et je ne peux pas vous montrer de code, mais Wikipedia a un exemple de code convivial .

Dans Algol 68, vous pourriez avoir de la place dans les identifiants (je ne me souviens pas s'ils étaient significatifs ou non). Mais les mots-clés ont été marqués par des arrêts . Utiliser des noms avec de l’espace était idiomatique (du moins autour de moi).

VHDL permet des identifiants échappé avec des espaces importants en eux: \foo bar\. Cela permet également d’utiliser des mots-clés comme identifiant \and\, tout caractère \n<42>\et toute sensibilité à la casse dans les identifiants ( \Foo\et \foo\sont différents tant que Fooet foosont équivalents \Foo\et\foo\!) Verilog a également des identifiants espacés présentant la plupart de ces caractéristiques (les identifiants normaux sont sensibles à la casse et qui les échappent inutilement ne créent pas d'autre identifiant), mais n'autorisent pas les espaces. La nécessité des identificateurs échappés dans VHDL et Verilog provient du fait qu'ils sont souvent générés automatiquement à partir d'autres sources (telles que des schémas) où les identificateurs n'ont généralement pas la même restriction que dans le langage de programmation; Autant que je sache, ils ne sont pas utilisés de manière idiomatique dans d'autres circonstances.

Je ne sais pas si vous considérez MediaWiki wikitext comme un langage, mais les noms avec des espaces sont définitivement idiomatiques:

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

Où "expand section" est le nom d'un modèle (http://en.wikipedia.org/wiki/Template:Expand_section)

Je suppose que cela répond aux critères - un langage dans lequel les identificateurs contiennent régulièrement des espaces. Ce n'est jamais (je pense?) Ambigu, car les identifiants sont toujours entourés de nombreux signes de ponctuation pour les séparer du texte wiki brut.

Inform 7 est un système de développement de fiction interactive utilisant une syntaxe semblable à celle du langage naturel, dans lequel les identificateurs comportant plusieurs mots sont monnaie courante:

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

La restriction, bien sûr, est qu'un identifiant ne peut pas contenir un mot clé lorsque cela serait ambigu.

Dans le même ordre d'idées, les identifiants avec des tirets bas dans Agda peuvent être utilisés avec mixfix, dont l'exemple le plus simple est probablement l' if_then_else_opérateur:

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

Scala autorise des identifiants arbitraires utilisant des backticks. L’utilisation habituelle de cette méthode est d’appeler Thread.`yield`car il yields’agit d’un mot réservé dans Scala. Cela pourrait être (ab) utilisé pour avoir des espaces dans les noms, bien que cela soit loin du code Scala idiomatique:

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

Heck, vous pouvez même avoir des onglets dans les identifiants:

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

Je suppose que cela pourrait en théorie être idiomatiques pour les gens de la programmation littéraire. Peut être.

F # autorise les espaces blancs dans les noms d'identifiant, mais ceux-ci doivent être entourés de doubles backticks. Voir la réponse à cette question: https://stackoverflow.com/questions/6639688/using-keywords-as-identifiers-in-f .

Vous pourriez penser que cela est le cas dans Cucumber / Gherkin , où les noms de fonctions sont en réalité des phrases avec les arguments incorporés à l'intérieur.

En tant qu'extension, je m'attendrais à ce que cela soit plus courant dans les DSL minuscules , où le langage est supposé être convivial pour les non-développeurs. Par exemple, de nombreux moteurs de règles permettent de définir des règles avec une description de type anglais, dans lesquelles des espaces peuvent être utilisés dans des identificateurs.

FWIW, Tcl autorise les espaces (et presque tous les autres caractères) dans les identificateurs, bien qu'il ne soit pas courant de tirer parti de cette fonctionnalité. La principale raison pour laquelle il n'est pas utilisé très souvent est simplement que vous devez utiliser des citations appropriées. Par exemple, ce qui suit définit une variable nommée "mon nom" sur "bob", puis l’imprime

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

OTOH, c'est très utile lors de la création dynamique de variables car, lors de la création de telles variables, il n'est pas nécessaire de s'inquiéter des caractères illégaux.

Il y en a peu que je connaisse. Je travaille sur un , et le langage de programmation souple . Inform le fait, mais ce n'est pas exactement un langage de programmation généraliste.

Si vous considérez un DSL de test automatique comme un langage, le framework de robot laisse des espaces dans les noms de mots-clés, et c'est très idiomatique. Dans l'exemple suivant, "Dites bonjour" est un nom de mot clé, "Exemple de scénario de test" est un nom de scénario de test et "$ {prénom}" est une variable:

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

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

Le langage 4D autorise les espaces dans les noms de méthodes et les variables. Il est généralement mal vu au sein de la communauté, mais toutes les méthodes intégrées et les variables les utilisent le cas échéant ( SET MENU ITEM PARAMETERpar exemple).

Smalltalk propose des méthodes de mots clés telles que celles a:b:c:qui impliquent des espaces quand elles sont appelées. Par exemple: a: 100 b: 200 c: 300. Ceci est un idiome standard dans la langue.

Powershell autorise les espaces dans les noms de variables:

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

PS C:\> ${the var}
100

J'ai vu mention de la même chose pour VB mais dans JS, cela est beaucoup utilisé en fait. Toute propriété d’un objet en JavaScript peut être consultée et définie sous forme de chaîne avec des crochets ou tout simplement en tant que chaînes dans des littéraux d’objet. Les noms de propriété qui ne suivent pas les règles de nommage des variables de JS sont inaccessibles via. notation mais ils sont pratiques. Par exemple, vous pouvez associer des URL à un comportement ou référencer un groupe de personnes par leur nom lorsque vous êtes certain qu'elles sont toutes uniques. C'est souvent très pratique et facile à lire:

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

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

Cela facilite également la restructuration de JSON pour une utilisation plus facile sans perdre le facteur d'objet instantané une fois transféré dans JS.

Power Query utilise beaucoup de code généré automatiquement. Je suppose que plus de la moitié des identifiants générés utilisent des espaces:

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"

Comme vous pouvez le constater, comme dans de nombreuses langues, il existe une syntaxe supplémentaire pour préciser l’identifiant.

Mais là où cela n’est pas ambigu, aucune syntaxe supplémentaire n’est nécessaire:

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

Si vous le considérez comme un langage réel, langage de script JMP ( http://www.jmp.com/support/downloads/pdf/jmp_scripting_guide.pdf ). Il permet aux identificateurs d'avoir des espaces (pour les rendre plus "lisibles") et les encourage plus ou moins.

Le langage de programmation o42a que je suis en train de développer supporte des noms de plusieurs mots . La langue ne contient aucun mot-clé et les noms sont généralement séparés par un symbole. Dans les rares cas où les deux noms se suivent, le soulignement sert à les séparer.

Authorware, dont le langage de script était basé sur un langage Pascal non orienté objet, a autorisé les espaces dans les noms de variables, même si au fil du temps les utilisateurs ont découvert les problèmes liés à leur utilisation et s'en sont éloignés http://books.google.com/books?id= bHC88YignAkC & pg = PA428 & lpg = PA428 .

Edit: Cette réponse s’est avérée incorrecte, voir les commentaires.

Si je comprends bien votre question, un compilateur ne peut pas autoriser d'espace (s) dans le nom de l'identifiant car cela pourrait provoquer des noms en double (sauf si un délimiteur est utilisé). Par exemple:

int my = 0; bool my count = false; int compte = 0; si (mon comte) ...

le terme "mon compte" est confus, il peut faire référence à la variable appelée "mon compte" ou peut-être le développeur a-t-il oublié d'écrire un opérateur de relation tel que> entre mon et compte.

COBOL a autorisé les noms de division et les noms de section à être séparés par un espace, mais il ne s’agit pas d’identifiants ni de variables comme dans votre question.