LINUX.ORG.RU

Нужен совет по придумыванию синтаксиса

 ,


0

4

Какой из двух вариантов управляющих конструкций вам нравится больше и почему? Сопоставьте как с известными вам различными императивными языками, так и собственными представлениями о гармоничности.

ПЕРВЫЙ:

// циклы с предусловием:

while condition do
    statements
end:while

until condition do
    statements
end:until

// циклы с постусловием:

do
    statements
repeat while condition;

do
    statements
repeat until condition;

// вечный цикл:

do
    statements
repeat forever;

// простой блок кода:

block
    statements
end:block

ВТОРОЙ:


// циклы с предусловием:

while condition loop
    statements
end:while

until condition loop
    statements
end:until

// циклы с постусловием:

loop
    statements
repeat while condition;

loop
    statements
repeat until condition;

// вечный цикл:

loop
    statements
repeat forever;

// простой блок кода:

do
    statements
end:do
★★

Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от AntonI

В качестве ошибкоустойчивости синтаксис максимально контекстнонезависимый? В т.ч. закрытие блоков зависит от типа блока?

Тут контекстнонезависимость скорее не средство достижения цели, а сопутствующий результат.

Вот если взять блоки. У нас привычно есть разные виды скобок, которые группируют синтаксические элементы, такие как скобки при вызове функции или скобки для блока в Си.

В Алголе и Паскале такими скобками были также begin - end.

Однако затем дизайн Паскаля был справедливо признан многословным и неудобным. Его скобки ничего не дают, только отнимают. Отнимают время на набор, но при этом по своей сути это тот же самый блок {}.

Дальше эволюция синтаксиса пришла к тому, чтобы блок для compound statement оформлять неявно, делая его неотъемлемой частью другой синтаксической конструкции. Таким образом возникли function .. end, if ... end, while ... end и так далее. Как в Обероне, Луа и им подобных.

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

А в таком подходе начала у нас разные, а конец — одинаковый.

По этой логике Бейсик в своё время пришел к End If, Ада пришла к end if;, а я пришел к end:if. Теперь логичная картина восстановлена. Каждому собственную виду начала полагается такой же вид конца.

контекстнонезависимый

Что касается непосредственно контекстно-независимости. То, в какой мере, для парсинга грамматики, необходимо знать словарь определённых идентификаторов, пока вопрос открытый. У меня нет тотального предубеждения против контекстно-зависимой грамматики. Если в каких-то случаях то будет иметь смысл оставить, я оставлю.

Пока это затрагивает объявления в сишном стиле, но я еще не брался за их переделку.

Я иногда в сложном коде такое оформляю комментами

Уже: Нужен совет по придумыванию синтаксиса (комментарий)

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 4)
Ответ на: комментарий от AntonI

Я бы тогда вместо begin/end взял бы {}, но приписывал к ним тип блока.

А зачем? Выглядеть это будет как-то так:

while (queue.waitMsg())
{<<event_loop>>
   ...
   ...
}<<event_loop>>

Как по мне, жутко и неудобно.

На практике мы не именуем всё подряд, а держим в уме «Так, вот это конец вон той ветки условий… А здесь конец вон того цикла…» Макировка вида end + название statement-а решает именно это задачу, делать наши вот эти неявные соображения (неявные в Си-подобных языках) — явными.

А затем, когда нечто становится более важным, чем просто «какой-то цикл», а становится «именно вот этим существенным для понимания циклом», то можно дать ему имя:

event_loop:
while queue.waitMsg() do
   ...
   ...
end:event_loop
wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

Опционально. Если блок именован, то его имя должно быть указано при закрытии.

Вообще идея с именованием типа блока при зарытии м.б. и хороша (в техе оно не лишнее), но как это с } совместить красиво я не знаю. А на begin/end лично у меня аллергия.

Кстати про XML - я когда свой велосипед для управления расчетами делал, в качестве ограничения блоков выбрал <>.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Это всё из-за того, что тебя Паскаль когда-то травмировал.)

Не получится это красиво в сишный синтаксис засунуть. Нужно дизайнить синтаксис с нуля, с учётом наличия фичи.

wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

Но фигурные скобки ИМНО объективно лучше читаются чем begin/end

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

<%...%>  (%...%)  [%...%] {%...%} |%...%|

хорошо читаются и парсятся тривиально.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

У Паскаля и Си синтаксис записи control flow почти идентичный.

Вот Паскаль:

if c then
begin
  b1
end
else
begin
  b2
end

Слово then здесь соответствует закрывающей круглой скобке в Си. begin – открывающий фигурной. end – закрывающей фигурной.

wandrien ★★
() автор топика
Ответ на: комментарий от AntonI

Да. Именно поэтому Си удачнее Паскаля.

Если мы даём визуальным знакам на экране вес, это должно быть для чего-то. Баланс фигура - фон. В паскале он не соблюдается.

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

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

Поэтому я использую end:имя.

wandrien ★★
() автор топика
Ответ на: комментарий от AntonI

сделать не так как у всех остальных плохая идея. … Хорошей идеей мне кажется сделать синтаксис максимально похожим на самые популярные ЯП…

Это плохая идея. Так как пользоваться этим языком будет ровно один человек, то лучше брать синтаксис не популярных языков, а тех, которые проще реализовать и поддерживать. А это Лисп, Форт и Ассемблер. При том ассемблероподобный язык в некоторых случаях может быть более читаемый чем Лисп и Форт, хотя и менее лаконичный. Форт - самый лаконичный. Лисп - золотая середина.

Kogrom
()
Ответ на: комментарий от Kogrom

Ребят, я угораю с вашей логики.

«Проще всего реализовывать и поддерживать» -> в пределе даёт вообще не реализовывать и не поддерживать. То есть вообще ничего не делать.

Кастомные проекты делаются не для того, чтобы было «проще», а именно чтобы за***ться.

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

…вообще ничем не ограничивать своё творчество.

Что за странное стремление взять чужую мысль типа Лиспа или Форта и реализовать её будто ты сам это придумал?

Где собственный полёт фантазии?

wandrien ★★
() автор топика

Есть вариант всё-таки пойти по пути Ады и вообще устранить из синтаксиса циклы с пост-условием.

Но с другой стороны, в таком случае и continue придётся делать в стиле Ады, вот так: https://rosettacode.org/wiki/Loops/Continue#Ada

wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

Кастомные проекты делаются не для того, чтобы было «проще»

Я когда делал свои языки, то исходил из практических соображений. Поэтому там важно было «проще». Мне был важен не синтаксис, а способы управления данными. Из этого уже рос синтаксис.

Первый язык должен был быть лаконичным как Питон, без потери читаемости. При этом был со статической типизацией, не требовал ни ручного управления памятью, ни сборщика мусора, и транслировался в C++. На этом языке я сделал несколько программ, которыми пользуюсь. Сейчас у меня есть некоторые идеи по развитию этого ЯП, но пока нет идей как элегантно реализовать.

Второй язык - минимальный интерпретатор со статической типизацией. Там была идея поэксперементировать с компиляцией в оп-код и со всякими проверками ошибок. Практические цели тут тоже были: разобраться с интерпретаторами, сделать простой интерпретатор для мобильного телефона. Нужен был синтаксис, который бы уместился по ширине в узкий экран мобильного, а интерпретатор должен был проследить, чтобы скрипт не подвесил основную работу телефона.

Kogrom
()

Возьми лучше пример с лиспа, а не паскаля. Проверки (while/until) должны быть в теле цикла, а не на границе. Например.

// циклы с предусловием:

loop
    while condition
    statements
end:loop

loop
    until condition
    statements
end:loop

// циклы с постусловием:

loop
    statements
    while condition
end:loop

loop
    statements
    until condition
end:loop

// вечный цикл:

loop
    statements
end:loop

// простой блок кода:

do
    statements
end:do

Ну и условия в любом количестве посреди statements тоже могут быть.

Gentooshnik ★★★★★
()
Ответ на: комментарий от wandrien

конструкция

while i > 0 do
   statement
end:while

не вполне хороша, потому что делает end:while довольно-таки странным придатком и затруднят разбор statement..

то есть начать с того что такое «statemеnt», зачем ему терминатор «end:while».

в паскаль-стайл, statement это: expression | begin (expression ;)* end

в Cи-стайл, соответсвенно: expression | { (expression ;)* }

в обоих случаях - конструкция кратка,удобна. Ничего лишнего

MKuznetsov ★★★★★
()
Ответ на: комментарий от vM

Да, как раз думал об этом, так легче искать условие выхода, особенно в случае внутреннего условия. break_on <cond> или break(<cond>), если не хочется дублировать ключевое слово.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Мне в рамках этого дизайна нужно обеспечить весомость, а не прозрачность синтаксиса. Смотри обсуждения в теме и примеры кода.

break поставить в начале предложения

Это используется в Ада и Руби. Я по размышлении отказался от такого подхода, так как из моего опыта такой код сложнее читать.

wandrien ★★
() автор топика

Ни один вариант не нравится. Предлагаю свой

Бесконечный цикл

loop
 .....
done;

Цикл с предусловием

while foo
loop
 ...
done;

Цикл с постусловием

loop
 ...
done while foo;

Так более ортогонально

Psilocybe ★★★★
()
Ответ на: комментарий от anonymous

Особенно прекрасно в сишном синтаксисе объявление функций.

Мы читаем: int… something… и всё ещё не знаем, что это такое. И вот наконец, ура! Нам встретилась открывающая круглая скобочка! Теперь мы знаем, что это функция, а не переменная.

Другими словами, нашим глазам сначала скормили имя типа, непонятно к чему относящееся. Потом имя самого объявляемого чего-то. Тоже непонятно чего именно. И только после этого нам соизволили объяснить, «что это было за кольцо и что за порошок». Считать это уродство нормальным можно только в силу многолетней привычки, замыленности глаза и стадного инстинкта типа «настоящие программисты пишут на…».

В этом плане паскале- и адоподобные языки куда симпатичнее. И большинство современных языков, унаследовав, например, фигурные скобки от сишных, для определения функций имеют явно задаваемые ключевые слова. В Rust, Go… да даже в попсовом JavaScript это выглядит и читается куда лучше сишной блеванины.

Если что — я люблю Си. А ещё больше я люблю плюсы, это мой кормилец. Что не мешает мне замечать в этих языках очевидных недостатков а кое-где и откровенного уродства.

Так что если ТС хочет создать хорошо читаемый ЯП — могу только пожелать ему успеха. Другое дело, что для того, чтобы ЯП взлетел, читаемость далеко не достаточное условие. И даже к сожалению, далеко не всегда необходимое.

hobbit ★★★★★
()
Ответ на: комментарий от wandrien

Между крайностями «создать совсем новое» и «написать еще один компилятор Си» могут быть промежуточные варианты. Например, втереться в сообщество разработчиков той же Ada и предлагать свои новшества. Другое дело, что там сообщество крайне консервативное в силу достаточно очевидных причин. Ну так есть ещё Free Pascal… :)

hobbit ★★★★★
()
Ответ на: комментарий от AntonI

Но потом я перешел под linux и нашел питон - выяснилось что Гвидо сделал именно то что мне надо, тока лучше чем я.

Если бы этот Гвидо ещё вместо сомнительной идеи ставить семантику в зависимость от отступов сделал явные скобки (даже пофиг, begin-end или {}, хоть какие-нибудь, хоть birth-death), было бы совсем замечательно.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Уже обсуждали это много-много раз. ИМНО отступы не идеальный синтаксис, но у питона есть и другие родовые травмы, например разделение на изменяемые и неизменяемые переменные.

Человек не блоха, ко всему привыкнуть может(с)

AntonI ★★★★★
()