Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Некоторые «вкусности» Алгол-68

Элегантный синтаксис

        В Алгол-68 (прошу обратить внимание, что Алгол-68 и Алгол-60 — это совершенно разные языки!) есть весьма элегантные конструкции вида «if» — «fi». Очень доходчиво!
if — fi
do — od
case — esac

         Симпатично, но ... А что если нам необходимо закончить некий блок, начинающийся словом «function»? Ему, вероятно, должно соответствовать «noitcnuf»? А пару «operation» должно составить «noitarepo». Это уже похоже на шаманские заклинания. Здесь Алгол-68 и его идея повернулась к нам некрасивым местом. Поэтому от такого стиля лучше отказаться.

         История, сделав виток по спирали, возвратила нам идеи Алгола-68, воплощённые в HTML:
<title> — </title>
<table> — </table>
<p> — </p> и т.д.

         Очень логично. Но громоздко. Языку разметки текста, наверное, простительна такая расточительность в символах. Но языку програмирования лишнее не к лицу. Действительно, если убрать «<» и «>», то смотрится лучше:

if — /if
switch — /switch
for — /for
do — /do
while — /while
class — /class
function — /function

Это смотрится симпатичнее, чем вариант с «end»:

if — end if
do — end do
function — end function

Условный оператор

         В Алгол-68 возможно такое:
a := if a = 0 then b else c fi;
На C это записывается так:
a = (a==0)? b : c;
или:
if (a == 0) a = b; else a = c;
Сейчас такими трюками никого не удивишь. Но они включают фантазию тем, кто придумывает языки. Не знаю, возможно ли такое на Алгол-68 (а это очень даже вероятно — это очень мощный язык), оператор «if» может, по идее, возвращать не только какой-то объект и какое-то значение, но и операции!
a := b if b > 0 then * else + fi c;            // выбор операции * или + в зависимости от b > 0
То же, но на C:
if (a == 0) a = b * c; else a = b + c;
Не правда ли, красивое решение? Хотя и бесполезное: всё тоже самое можно сделать без пижонства.

Уроки провала Алгол-68

         Комитет, занимавшийся выработкой языка, создал язык, чрезвычайно богатый выразительными возможностями. Он же оказался чрезвычайно сложен в реализации. Первые компиляторы появились спустя годы после описания языка. При этом они охватывали лишь часть возможностей языка. Полностью соответствующий стандарту языка компилятор появился лишь десятилетие спустя. О чём это говорит и какие выводы из этого можно сделать?
  • Чем сложнее язык, тем сложнее компилятор. Тем дольше этот компилятор разрабатывается. Тем больших усилий это требует.
  • Сложный язык затрудняет не только написание компилятора, но и изучение самого языка программистами. Чем проще язык, тем больше будет желающих изучить его «за один вечер».
  • Если хотим иметь обозримые сроки создания компилятора, невысокую сложность языка, то нужно уметь выделить главное, от чего нельзя отказаться. Не надо в язык впихивать «невпихуемое».

Что ещё почитать на эту тему

Опубликовано: 2012.09.25, последняя правка: 2015.01.23    03:23

ОценитеОценки посетителей
   ██████████████████ 19 (43.1%)
   █████████ 9 (20.4%)
   ████████████ 12 (27.2%)
   ████ 4 (9.09%)

Отзывы

     2015/04/04 08:27, rst256          # 

Все же ключевым фактором стоит считать именно сложность языка. Вот сайт проекта, новая версия вышла в январе 2015 г.:
http://algol68.sourceforge.net/
размер исходников (преимущественно код на С) ~ 3Mb

     2021/03/27 02:33, Виталий Монастырский          # 

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

Ну ладно, давайте грубо говоря с примером. Реально пользователям удобно иметь и if, и switch, и for, и while, и ещё кучу плюшек со сладостями. Однако разработчикам языка все это нужно реализовывать по всей линии компилятора. Но для компьютера то нужен всего лишь один if и goto...

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

for i=0; i<10; i++ {
что-то там...
}

транслятор это все переводит в наше ядро-чудо:

var i uint
i:0
#back
if i>=10 goto end
что-то там...
i++
if i<10 goto back
#end
Ну вот так как-то...

     2021/04/01 13:03, Александр Коновалов aka Маздайщик          # 

Виталий, возможно, Ваш комментарий был бы более актуален под статьёй «Синтаксический сахар».

Разработка компилятора как транслятора (рассахаривателя) богатого входного языка в бедный промежуточный и генератора кода из промежуточного языка в целевой, в Вашем случае, машинный — хороший подход к проектированию. У меня самого примерно также устроен компилятор Рефала-5λ.

Однако я бы не советовал раскручивать компилятор со столь бедного промежуточного языка. Трансляция блочного if’а и while в код с метками и условными/безусловными переходами довольно проста, и её лучше реализовать сразу — это заметно ускорит разработку.

     2023/11/20 13:37, Деньги на WWWетер          # 

В HTML двойная симметрия конструкций: сперва в пределах самого тега (тег начинается левой угловой скобкой, а заканчивается правой), а затем симметрия в начале и конце конструкции (в начале <тег> и в конце </тег>).

     2024/01/16 16:23, Александр          # 

А есть компиляторы, полностью реализующие популярные языки программирования С++ и SQL ?

     2024/01/16 17:11, Автор сайта          # 

Насчёт C++ точнее всего Вам ответит, наверное, Евгений Александрович Зуев, когда-то разработчик компилятора и представитель страны в международном комитете по стандартизации C++. А вот по поводу SQL даже не знаю, что сказать. По идее стандарт стабилен и невелик в сравнении с C++. Думаю, что полных реализаций немало.

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

●  Устарел ли текст как форма представления программы

●  Русский язык и программирование

●  Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

●  Некоторые «вкусности» Алгол-68

●  «Двухмерный» синтаксис Python

●  Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

●  Должна ли программа быть удобочитаемой?

●  Стиль языка программирования

●  Тексто-графическое представление программы

●●  Разделители

●●  Строки программы

●●  Слева направо или справа налево?

●  Комментарии

●●  Длинные комментарии

●●  Короткие комментарии

●●  Комментарии автоматической генерации документации

●●  Нерабочий код

●●  Помеченные комментарии

●  Нужны ли беззнаковые целые?

●  Шестнадцатиричные и двоичные константы

●  Условные операторы

●  Переключатель

●  Циклы

●●  Продолжение цикла и выход из него

●  Некошерный «goto»

●  Изменение приоритетов операций

●  Операции присвоения и проверки на равенство. Возможно ли одинаковое обозначение?

●  Так ли нужны операции «&&», «||» и «^^»?

●  Постфиксные инкремент и декремент

●  Почему в PHP для конкатенации строк используется «.»?

●  Указатели и ссылки в C++

●●  О неправомерном доступе к памяти через указатели

●  Обработка ошибок

●  Функциональное программирование

●●  Нечистые действия в чистых функциях

●●  О чистоте и нечистоте функций и языков

●●  Макросы — это чистые функции, исполняемые во время компиляции

●●  Хаскелл, детище британских учёных

●●  Измеряем замедление при вызове функций высших порядков

●●  C vs Haskell: сравнение скорости на простом примере

●●  Уникальность имён функций: за и против

●●  Каррирование: для чего и как

●●  О тестах, доказывающих отсутствие ошибок

●  Надёжные программы из ненадёжных компонентов

●●  О многократном резервировании функций

●  Использование памяти

●  Почему динамическое распределение памяти — это плохо

●  Как обеспечить возврат функциями объектов переменной длины?

●●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●●  Массивы переменной длины в C/C++

●●  Размещение объектов в стеке, традиционный подход

●●  Размещение объектов переменной длины с использованием множества стеков

●●  Размещение объектов переменной длины с использованием двух стеков

●●  Реализация двухстековой модели размещения данных

●●  Двухстековая модель: тесты на скорость

●●  Изменение длины объекта в стеке во время исполнения

●●  Размещение объектов переменной длины с использованием одного стека

●  Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

●  Безопасность и размещение объектов переменной длины в стеке

●  Массивы, структуры, типы, классы переменной длины

●  О хранении данных в стеке, вместо заключения

●  Реализация параметрического полиморфизма

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/03/28 13:26 ••• Ivan
Энтузиасты-разработчики компиляторов и их проекты

2024/03/27 19:12 ••• MihalNik
Постфиксные инкремент и декремент

2024/03/22 20:41 ••• void
Раскрутка компилятора

2024/03/20 19:54 ••• kt
О многократном резервировании функций

2024/03/20 13:13 ••• Неслучайный читатель
Надёжные программы из ненадёжных компонентов

2024/03/10 18:33 ••• Бурановский дедушка
Русской операционной системой должна стать ReactOS

2024/03/07 14:16 ••• Неслучайный читатель
«Двухмерный» синтаксис Python

2024/03/03 16:49 ••• Автор сайта
О неправомерном доступе к памяти через указатели

2024/02/28 18:59 ••• Вежливый Лис
Про лебедей, раков и щук

2024/02/24 18:10 ••• Бурановский дедушка
ЕС ЭВМ — это измена, трусость и обман?

2024/02/22 15:57 ••• Автор сайта
Русский язык и программирование

2024/02/19 17:58 ••• Сорок Сороков
О русском языке в программировании

2024/02/16 16:33 ••• Клихальт
Избранные компьютерные анекдоты