49

C# style suggests using CamelCase in identifiers to delimit words. Lisp tradition suggests using-dashes-instead.

Has there ever existed a programming language where using spaces in identifiers was not only allowed, but a commonly used idiom when employing multi-word identifiers?

It's possible to have identifiers with spaces in some Scheme implementations, but it's not a widely seen practice. Here's an example:

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)
dharmatech
  • 531
  • 5
  • 12

22 Answers22

78

FORTRAN compilers ignored spaces so:

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

were identical as far as the compiler was concerned.

Some SQL dialects allow embedded spaces in column names but they need to be surrounded by backquotes or some other delimiter before they can be used.

Emily
  • 101
  • 2
29

Visual Basic (and VBScript) also allow whitespace in identifiers if you surround the identifier with square brackets.

Dim [Hello World]
[Hello World] = 123

However, doing so is quite rare.

Eric Lippert
  • 46,558
18

Does SQL count?

create table "Registered Members" (
    "Full Name" varchar(100),
    "Mailing Address" varchar(100),
    etc...
);
Barry Brown
  • 4,095
18

Inform 7 is a system for developing interactive fiction using natural language–like syntax, in which multi-word identifiers are commonplace:

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

The restriction, of course, is that an identifier can’t contain a keyword when this would be ambiguous.

In a similar vein, identifiers with underscores in Agda can be used mixfix, the simplest example of which is probably the if_then_else_ operator:

if_then_else_ : {A : Set} -> Bool -> A -> A -> A
if true  then x else y = x
if false then x else y = y
Jon Purdy
  • 20,597
12

I don't know if you consider MediaWiki wikitext a language, but names with spaces are definitely idiomatic:

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

Where "expand section" is the name of a template (http://en.wikipedia.org/wiki/Template:Expand_section)

I guess it meets the criteria - a language where identifiers routinely contain spaces. It's never (I think?) ambiguous because identifiers are always surrounded by lots of punctuation to separate them from raw wiki text.

12

In Algol 68 you could have space in identifiers (I don't remember if they were significant or not). But keywords were marked by stropping. Using names with space in them was idiomatic (at least around me).

VHDL allows escaped identifiers with significant spaces in them: \foo bar\. This allows also to use keywords as identifier \and\, any character \n<42>\ and case sensitivity in identifiers (\Foo\ and \foo\ are different while Foo and foo are equivalent, and different from either \Foo\ and \foo\!). Verilog also has espaced identifiers with most of these characteristics (normal identifiers are case sensitive and escaping them unnecessarily doesn't make another identifier), but doesn't allow spaces in them. The need from escaped identifiers in VHDL and Verilog come from the fact they are often produced automatically from other sources (such as schematic) where identifiers customarily don't have the same restriction as in programming language; AFAIK, they aren't idiomatically used in other circumstances.

AProgrammer
  • 10,532
  • 1
  • 32
  • 48
11

Well Whitespace is all about... whitespace:

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.

Unfortunately Markdown doesn't support its syntax and I can't show you some code, but Wikipedia has a human friendly code sample.

yannis
  • 39,647
8

Scala allows arbitrary identifiers using backticks. The usual use for this is to invoke Thread.`yield` because yield is a reserved word in Scala. This could be (ab)used to have spaces in names, although that would be far from idiomatic Scala code:

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

Heck, you can even have tabs in identifiers:

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

I suppose this could conceivably be idiomatic for the literate programming folk. Maybe.

Peter C
  • 131
5

You might consider this to be the case in Cucumber/Gherkin, where function names are effectively sentences with the arguments embedded inside them.

As an extension, I would expect this to be more common in tiny DSLs, where the language is supposed to be friendly to non developers. For example, many rules engines provide an abilty to define rules with an english-like description, where spaces can be used in identifiers.

Chris Pitman
  • 3,496
5

F# allows white space in identifier names, but they must be surrounded with double backticks. See the answer to this question: https://stackoverflow.com/questions/6639688/using-keywords-as-identifiers-in-f.

Matt H
  • 2,163
4

FWIW, Tcl allows spaces (and just about every other character) in identifiers, though it's not common to take advantage of this feature. The main reason it's not used very often is just that you have to use proper quoting. For example, the following sets a variable named "my name" to "bob", then prints it

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

OTOH, it's very useful when building variables dynamically since, when creating such variables, one doesn't have to worry about illegal characters

Bryan Oakley
  • 25,479
3

If you consider an automated testing DSL a language, the robot framework allows spaces in keyword names, and it's very idiomatic. In the following example "Say hello" is a keyword name, "Example test case" is a test case name, and "${first name}" is a variable:

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

*** Test Cases ***
| Example test case
| | Say hello | world
Bryan Oakley
  • 25,479
3

There are few I know of. I am working on one, and the lithe programming language. Inform does, but it's not exactly a general purpose programming language.

Telastyn
  • 110,259
1

The 4D language allows white space in method names and variables. It is generally frowned upon within the community, but all built-in methods and variables use them when applicable (SET MENU ITEM PARAMETER, for example)

1

Powershell allows spaces in variable names:

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

PS C:\> ${the var}
100
dharmatech
  • 531
  • 5
  • 12
1

I saw mention of similar for VB but in JS this is used a lot actually. Any property of an object in JavaScript can be accessed and set in string form with square brackets or simply as strings in object literals. Property names that don't follow JS's variable naming rules are inaccessible via . notation but they are handy. For instance, you might want to map URLs to behavior or reference a group of people by name when you're certain they're all unique. It's often very convenient and easy to read:

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

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

This also makes it easy to restructure JSON for ease of use without losing the instant-object factor when dropped into JS.

Erik Reppen
  • 6,281
0

Smalltalk features keyword methods such as a:b:c: which involve whitespace when invoked. E.g.: a: 100 b: 200 c: 300. This is a standard idiom in the language.

dharmatech
  • 531
  • 5
  • 12
0

Power Query uses a lot of automatically generated code. I'd guess more than half of generated identifiers use white space:

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"

As you can see, like in many languages there's extra syntax to disambiguate what the identifier is.

But in places where it's unambiguous, no extra syntax is needed:

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

If you you count it as a real language, JMP scripting language ( http://www.jmp.com/support/downloads/pdf/jmp_scripting_guide.pdf ). It allows identifiers to have whitespace (to make them more "readable") and more or less encourages such.

Jamie
  • 101
-1

The o42a programming language I am currently developing supports a multi-word names. The language has no keywords at all and the names are usually separated with some symbol. In the rare case the two names follow each other, the underscore is used to separate them.

lorus
  • 496
-2

Authorware, whose scripting language was based on non-object-oriented Pascal, allowed spaces in variable names, though over time people discovered the problems with using them and moved away from it http://books.google.com/books?id=bHC88YignAkC&pg=PA428&lpg=PA428 .

-5

Edit: This answer was shown to be not correct, see the comments.

If I understand your question correctly, a compiler can't allow space(s) in identifier name because it could cause duplicate names (unless a delimiter is used). For example:

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

the term 'my count' is confusing it could either refer to the variable called 'my count' or maybe the developer forgot to write a relation operator such as > between my and count.

COBOL allowed division names and section names to be separated by space but those are not identifiers and variables as in your question.

NoChance
  • 12,532