Были ли пробелы в идентификаторах когда-либо идиоматическими? [закрыто]

Стиль C # предлагает использовать CamelCase в идентификаторах для разделения слов. Традиция Лиспа предлагает использовать вместо него тире.

Существовал ли когда-либо язык программирования, где использование пробелов в идентификаторах было не только разрешено, но и широко использовалось при использовании многословных идентификаторов?

В некоторых реализациях Scheme могут быть идентификаторы с пробелами , но это не очень распространенная практика. Вот пример:

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)

Компиляторы FORTRAN игнорировали пробелы так:

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

Были идентичны в том, что касается компилятора.

Некоторые диалекты SQL допускают использование встроенных пробелов в именах столбцов, но перед использованием они должны быть заключены в кавычки или какой-либо другой разделитель.

Visual Basic (и VBScript) также допускают пробелы в идентификаторах, если вы окружаете идентификатор квадратными скобками.

Dim [Hello World]
[Hello World] = 123

Однако это происходит довольно редко.

SQL считается?

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

Ну, пробел это все о ... пробел:

Большинство современных языков программирования не учитывают синтаксис пробельных символов (пробелы, символы табуляции и новые строки), игнорируя их, как если бы их не было. Мы считаем это грубой несправедливостью по отношению к этим совершенно дружественным членам набора символов. Должны ли они игнорироваться только потому, что они невидимы? Пробелы - это язык, который стремится исправить баланс. Любые непробельные символы игнорируются; только пробелы, символы табуляции и перевода строки считаются синтаксисом.

К сожалению, Markdown не поддерживает его синтаксис, и я не могу показать вам некоторый код, но в Википедии есть пример кода, удобного для человека .

В Алголе 68 у вас может быть место в идентификаторах (я не помню, были ли они значимыми или нет). Но ключевые слова были помечены обрезкой . Использование имен с пробелом в них было идиоматичным (по крайней мере, вокруг меня).

VHDL позволяет спасся идентификаторы со значительными пробелами в них: \foo bar\. Это позволяет также использовать ключевые слова в качестве идентификатора \and\, любой символ \n<42>\и регистр чувствительности в идентификаторах ( \Foo\и \foo\отличаются, в то время как Fooи fooэквивалентны, и отличаются от любого \Foo\и\foo\!). В Verilog также есть идентификаторы с пробелами с большинством этих характеристик (обычные идентификаторы чувствительны к регистру, и их выход без необходимости не создает другого идентификатора), но не допускает пробелов в них. Потребность в экранированных идентификаторах в VHDL и Verilog проистекает из того факта, что они часто создаются автоматически из других источников (например, схем), где идентификаторы обычно не имеют того же ограничения, что и в языке программирования; AFAIK, они не используются в других обстоятельствах.

Я не знаю, считаете ли вы MediaWiki wikitext языком, но имена с пробелами определенно идиоматичны:

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

Где «развернуть раздел» - это имя шаблона (http://en.wikipedia.org/wiki/Template:Expand_section)

Я предполагаю, что это соответствует критериям - язык, где идентификаторы обычно содержат пробелы. Это никогда (я думаю?) Неоднозначно, потому что идентификаторы всегда окружены множеством знаков препинания, чтобы отделить их от необработанного вики-текста.

Inform 7 - это система для разработки интерактивной художественной литературы с использованием синтаксиса, подобного естественному языку, в котором многословные идентификаторы являются обычным явлением:

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

Ограничение, конечно, заключается в том, что идентификатор не может содержать ключевое слово, когда это будет неоднозначным.

Аналогичным образом, идентификаторы с подчеркиванием в Agda могут быть использованы mixfix, простейшим примером которого, вероятно, является 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 позволяет произвольные идентификаторы с помощью обратных галочек. Обычно это используется для вызова, Thread.`yield`потому что yieldэто зарезервированное слово в Scala. Это может быть (ab) иметь пробелы в именах, хотя это будет далеко от идиоматического кода Scala:

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

Черт возьми, вы даже можете иметь вкладки в идентификаторах:

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

Я предполагаю , что это может предположительно быть идиоматическим для грамотного программирования народа. Может быть.

F # допускает пробелы в именах идентификаторов, но они должны быть заключены в двойные обратные галочки. Посмотрите ответ на этот вопрос: https://stackoverflow.com/questions/6639688/using-keywords-as-identifiers-in-f .

Вы можете подумать, что это имеет место в Cucumber / Gherkin , где имена функций фактически являются предложениями со встроенными в них аргументами.

Как расширение, я ожидал бы, что это будет более распространено в крошечных DSL , где язык должен быть дружественным для не разработчиков. Например, многие механизмы правил предоставляют возможность определять правила с англоязычным описанием, где пробелы могут использоваться в идентификаторах.

FWIW, Tcl допускает использование пробелов (и почти всех других символов) в идентификаторах, хотя использование этой функции не является распространенным явлением. Основная причина, по которой он не используется очень часто, заключается в том, что вы должны использовать правильное цитирование. Например, следующий код устанавливает переменную с именем «my name» в «bob», а затем печатает ее

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

ОТО, это очень полезно при динамическом построении переменных, так как при создании таких переменных не нужно беспокоиться о недопустимых символах

Есть несколько, о которых я знаю. Я работаю над одним и гибким языком программирования . Inform делает, но это не совсем язык программирования общего назначения.

Если вы считаете, что автоматизированное тестирование DSL является языком, среда роботов допускает пробелы в именах ключевых слов, и это очень идиоматично. В следующем примере «Say hello» - это имя ключевого слова, «Example test case» - это имя теста, а «$ {first name}» - переменная:

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

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

Язык 4D допускает пробелы в именах методов и переменных. Как правило, он не одобряется в сообществе, но все встроенные методы и переменные используют их, когда это применимо ( SET MENU ITEM PARAMETERнапример,)

В Smalltalk есть ключевые методы, такие как a:b:c:пробелы, которые вызываются при вызове. Например: a: 100 b: 200 c: 300. Это стандартная идиома в языке.

Powershell допускает пробелы в именах переменных:

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

PS C:\> ${the var}
100

Я видел упоминание о подобном для VB, но в JS это часто используется. Любое свойство объекта в JavaScript может быть доступно и задано в виде строки в квадратных скобках или просто в виде строк в литералах объекта. Имена свойств, которые не следуют правилам именования переменных JS, недоступны через. обозначения, но они удобны. Например, вы можете сопоставить URL-адреса с поведением или ссылаться на группу людей по имени, когда вы уверены, что все они уникальны. Это часто очень удобно и легко читается:

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

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

Это также упрощает реструктуризацию JSON для простоты использования без потери фактора мгновенного объекта при падении в JS.

Power Query использует много автоматически сгенерированного кода. Я предполагаю, что более половины сгенерированных идентификаторов используют пробелы:

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"

Как вы можете видеть, как и во многих языках, существует дополнительный синтаксис для устранения неоднозначности идентификатора.

Но там, где это однозначно, дополнительный синтаксис не требуется:

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

Если вы считаете его реальным языком, языком сценариев JMP ( http://www.jmp.com/support/downloads/pdf/jmp_scripting_guide.pdf ). Это позволяет идентификаторам иметь пробелы (чтобы сделать их более «читаемыми») и более или менее поощряет такие.

Язык программирования o42a, который я сейчас разрабатываю, поддерживает имена из нескольких слов . В языке вообще нет ключевых слов, а имена обычно разделяются каким-то символом. В редком случае два имени следуют друг за другом, подчеркивание используется для их разделения.

Authorware, чей язык сценариев основан на не объектно-ориентированном Pascal, допускал пробелы в именах переменных, хотя со временем люди обнаруживали проблемы с их использованием и уходили от него http://books.google.com/books?id= bHC88YignAkC & pg = PA428 & lpg = PA428 .

Изменить: Этот ответ был показан как неправильный, см. Комментарии.

Если я правильно понимаю ваш вопрос, компилятор не может разрешить использование пробелов в имени идентификатора, поскольку это может привести к дублированию имен (если только не используется разделитель). Например:

int my = 0; bool my count = false; int count = 0; если (мой граф) ...

Термин «мой счет» сбивает с толку, он может относиться либо к переменной, называемой «мой счет», либо, возможно, разработчик забыл написать оператор отношения, такой как> между my и count.

COBOL позволяет разделять имена разделов и разделов пробелами, но это не идентификаторы и переменные, как в вашем вопросе.