ну, блочно-алгольный синтаксис был ещё у ранних версий алгола.

в алгол-68 и алгол-60 было два альтернативных синтаксиса (у алгола-60 — ещё больше).

во втором синтаксисе были скобочки и S-выражения.

mexp.lsp пример трансляции M-выражений, как в ранних лиспах

ранний алгол согласно спецификации имел две формы записи: паскалеподобную и лиспоподобную, со скобочками.

далее модно было такой алгол транслировать либо в лисп, либо в форт. в итоге компилятор алгола на лиспе + REPL который можно подёргать в любой момент, посмотреть, как трансляция отработала, потестировать по отдельным шагам и т.п.

При том, что в C и потомках отказались от удобной концепции «всё есть выражение»

Чем она удобна?

тем, что выражение является first class object. то есть, можно делать выражения, пишущие выражения, читающие выражения, компилирующиеся в выражения. макросы, которые во время компиляции разворачиваются в код или в новый макрос.

Чем она удобна?

меньше дублирования кода, не нужен тернарный оператор. На самом деле C почти следует этой концепции (и во всяких идеоматических C-фрагментах из K&R паримеров хватает) но немножко они не дотянули.

Forth

Отличный язык. Вот только абсолютно нетипизированный — как ассемблер. Есть попытки статической типизации, типа StrongForth — но автор забросил и никто толком не подобрал, есть динамический полуфорт полулисп Factor (но автор, опять-же, сейчас в Apple Swift пилит, хотя тут подобрали проект).

Да и стековая машина, похоже, для современных процессоров — не самая оптимальная штука. Судя, к примеру, по изменению архитектуры VM для lua.

Синтаксис ObjC разработали шизофреники.

Ещё в A68 нет ООП (а в Симуле, которая расширенный алгол-60 — есть). И достаточно неудачно сделано взятие элемента структуры (field of record вместо record.field) что, даже если слепить какое-то ООП из того что есть, будет не только жутко непривычно выглядеть, но и мешать сделать автодополнение в IDE.

ООП какое-то есть и в Ada 83-го года, через address и пакеты как классы и объекты, почти как в cl пакеты. это тоже какое-то ООП, лол. но непривычное. в Ada 2012 выглядит более привычно, Ada 2020 движется в нужном направлении.

да, а в книге про Эль-76 — там есть ООП или нет? там по-моему, такой полиморфизм и ООП как окамле, с сигнатурами и функторами пакетов. только терминология другая для всего этого. то есть ООП более расширяемое, чем Симула/С++/мейнстрим

в книге про Эль-76

Надо будет перечитпть на досуге, давно это было.

Вот только абсолютно нетипизированный — как ассемблер.

Так можно добавить легко.

(но автор, опять-же, сейчас в Apple Swift пилит, хотя тут подобрали проект).

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

Да и стековая машина, похоже, для современных процессоров — не самая оптимальная штука. Судя, к примеру, по изменению архитектуры VM для lua.

Стек в Forth это абстракция, SP-Forth компилируется в сишнопдобный код...

В С подобных языках так тоже можно, но нигде это вроде пока не реализовали. Нужен только доступ к дереву!

Отличный язык. Вот только абсолютно нетипизированный — как ассемблер. Есть попытки статической типизации, типа StrongForth — но автор забросил и никто толком не подобрал, есть динамический полуфорт полулисп Factor (но автор, опять-же, сейчас в Apple Swift пилит, хотя тут подобрали проект).

ну, если посмотреть на PostScript lv 2 и далее level 3 и Display PostScript, оконную систему Sun NeWS.

то там фактически почти что объектно-ориентированный форт. строки хранятся в куче, есть какое-то почти зачаточное ООП на словарях, лол. в Display PostScript попытались допилить его до более полноценного. NeWS выступал сервером оконной системы, который также инстанцировал объекты на таком Display PostScript объектном форте. приложения под NeWS, типа как X11 клиенты — дёргали эти объекты. но при этом в отличие от иксов, не гоняли глифы картинок туда-сюда, а все события выполнялись на сервере. сервер NeWS, оконная система, объектный сервер, сервер приложений Display PostScript объектно-ориентированного.

затем, поскольку это всё жутко тормозило, пытались оптимизировать. выкидывать куски объектов на форте и заменять си реализацией. сначала писали shim, wrappers, кодогенераторы в стиле CORBA. потом плюнули и сделали монолит Xnews, в котором два в одном, и Xlib API можно дёргать из форт-объектов.

потом форт и ООП форт Display PostScript выкинули.

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

потом пришли эффективные менеджеры и похоронили NeWS. остались только иксы и OpenWindows.

.... а вообще, объектно-ориентированные форты не такая уж и редкость.

например, реализация Win32forth под винду содержит примеры хелловордов WinAPI GUI в ООП стиле.

в целом, вполне можно на этом программировать. как обычный си в духе GTK, нужно malloc/free руками писать.

вот Factor уже лучше, да. и GC, и функциональщина с комбинаторами, и объектная модель в духе CLOS. в итоге GUI «композабельный», составимый другой программой. например, см. как там хелп реализован. составляются такие виджеты как объекты, получается почти как compound document.

всё потому что функциональщина более модульна, более составима. далее берём PEG парсер из поставки Factor и пишем свой язычок. например, реализация смоллтока есть в примерах. по-моему и PL/0 алгол какой-то тоже. алгол, впрочем и в форт несложно транслировать.

далее пишем на таком алголе/обероне/модуле и аде свою нетлёнку, всё что угодно. который на самом деле Factor, и можно дёргать за REPL. и вести разработку в образе.

да, у Е. Зуева правильный подход с семантическим деревом.

Форт

добавить легко.

Ну как, StrongForth.f — 70кб + 14 кб OOP.sf. Ещё столько же уйдёт на Хиндли-Миллера, если вывод типов прикрутить. Но да, всё ещё сравнительно компактно.

Стек в Forth это абстракция, SP-Forth компилируется в сишнопдобный код…

Помню был там прикручиваемый компилятор в С. А так — раскрутка небольших инлайнов (которая и в gforth есть, хотя он как раз интерпретатор. Прямого шитого кода, то есть более чем минималистичный, но всё же не прямой машкод). Ну и вершина стека в регистре A.

Ну как, StrongForth.f — 70кб

Ну там смотря как реализовывать.

Помню был там прикручиваемый компилятор в С.

Я не об этом, но вообще можно расшить код если очень хочется. Ничего не мешает.

меньше дублирования кода, не нужен тернарный оператор. На самом деле C почти следует этой концепции (и во всяких идеоматических C-фрагментах из K&R паримеров хватает) но немножко они не дотянули.

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

он там пишет, что выражения с «операцией пробел» — на самом деле алгебра. даже более того, скажу что это моноид в какой-то категории. или нескольких.

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

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

если почитать например Write youself Scheme in 48 hours на хаскеле. то примерно вот это и происходит у А. Столярова, только на С++ препроцессоре вместо хаскеля.

Ну там смотря как реализовывать.

Ну как. В strong.f примерно 25К — это чисто сигнатуры стандартных форт слов в типизированном виде, ещё килобайт 5 — сообщения об ошибках компиляции… В общем делать как Dr. Stephan Becher именно что ANSI Forth, только со строгой статической типизацией, то так на так оно и получится, IMHO.

Или нет?

Скажу просто что вариантов реализации много...

А можно какую нибудь ссылочку кроме Бечеровского СтронгФорта?

У меня таких не имеется.

Нет, я люблю OCaml, но пишут на нем 3.5 фанатика. Тот факт, что 2.5 из них открыли собственные стартапы не делает язык коммерчески успешным.

Ну Jane Street и Facebook давно не стартапы. Фанатиков поболее 3,5, хотя и маловато. Проблема его в том, что не любят его в академической среде, хотя он существенно практичнее того же Хаскеля и Лиспа. По идее он должен был бы прижиться в системах искусственного интеллекта и принятия решений, но что-то пошло не так.

да, у Е. Зуева правильный подход с семантическим деревом.

Семантические интерфейсы языков программирования — Это?

Что прямо весь Facebook? Или несколько гиков в рамках отдельного проекта?

Что-то я не понял. А какие проблемы то?

А есть кто-нибудь из присутствующих, кто его реально использует? Хотелось бы услышать опыт.

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

Не весь, а несколько человек, которые решают свою конкретную задачу. Не нужно передёргивать. Есть штатные сотрудники отдельного подразделения большой корпорации, они пилят на этом языке свою задачу. Есть Jane Street, коммерческая и коммерчески успешная компания, которая свои продукты разрабатывает на OCaml, есть пример написания первого компилятора популярного сейчас языка Rust, был долгое время рендер формул в Википедии на нём написан, теперь вроде бы на JS переписали, есть ещё MLDonkey. В общем, язык-то живой, как и известный многим и горячо нелюбимый у нас Паскаль. Просто на нём не пишут толпы программистов и про него не трындят все подряд.

А вот Dylan действительно мёртв, как и Алгол 68, тут ничего не поделаешь.

Это не так делается. Скобки создаются/удаляются сразу парными.

У этого всего странная логика... Мне трудно редактировать, даже если и привыкну к этому поведению. Да и символов это занимает больше как не крути.

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

После этого вы начинаете мыслить не в терминах скобок, а в терминах блоков кода.

Я не верю что есть человек который мыслит в терминах скобок. Но все равно редактировать неудобно.

Ну, зачем-то вам же захотелось считать скобки.

Но все равно редактировать неудобно.

При использовании структурного подхода к редактированию, о котором говорит ugoday, и при использовании правильного редактора, соответствующего этому подходу, вроде paredit'а, редактировать как раз не просто удобно, а очень удобно. Настолько удобно, что в какой-то момент возникает желание прикрутить paredit и к другим языкам, вроде си. И вот тут начинаются проблемы, поскольку синтаксис у си гораздо менее регулярен и paredit к нему так просто не прикрутишь, а даже если и прикрутишь, пользоваться им в си совсем не так удобно.

Спасибо, анонимус! Ты просто кладезь информации.

Надо начать уже твои посты (а это не первый такой пост, насколько я могу судить), щедро пересыпанные ссылками, сохранять куда-то. А то жалко, ведь потом их на ЛОРе фиг найдёшь, с учётом твоей анонимности.

Для OCaml вопрос так же актуален

Ты че, на окамле пишут софт для ынтерпрайза, не считая уже всяких ресерчевых компиляторов и декомпиляторов

Эх, молодец, как ты правильно все сказал! Дай я тебя в честь этого покатаю на своем волосатом мотороллере!

Ну давай, приезжай к нам в Саратов.

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

Или вообще можно не писать скобки, если прикрутить чудесный parinfer.

Ты чо, в холодильнике живешь? А чо, на хотпоинт-аристон денег не хватило?

На OCaml довольно много компиляторов написано:

https://coq.inria.fr/ https://haxe.org/ https://reasonml.github.io/ http://felix-lang.org/ http://frama-c.com/ это хоть и не компилятор но очень близко, статический анализатор кода.

Кроме Rust еще первые версии F# были тоже были на OCaml.

Спасибо! Ну про F# логично и в том смысле, что это, фактически, диалект OCaml.

Опять было сложно, но я подрочил.

Тут люди на фото поцтеринга и на его код системд дрочат, пора б уже привыкнуть

Интелфикс?

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

Попробуй сам,

Ну, как бы, каждый день пробую, поэтому слегка тебя не понимаю.

Ну что проще то набирается?

(setf variable (+ 2 (* 2 2)))
variable = 2+2*2

if(variable++ < 10) {
    puts("hello world");
}
(if (< (inc variable) 10)
    (format t "hello world~%"))

if(variable++ < 10) {
    puts("hello world");
    variable = 666;
}
(if (< (inc variable) 10)
    (progn
        (format t "hello world~%")
        (setf variable 666)))

В третьем примере progn не нужен.

if(variable++ < 10) {
    puts("hello world");
    variable = 666;
}
(when (< (inc variable) 10)
  (format t "hello world~%")
  (setf variable 666))

Не пишу на лиспе, не знаю как сокращать, но кода все равно больше, взгляд теряется! Я смог когда то привыкнуть к Forth, но к Lisp'у так и не смог, слишком много знаков мешающих читать... Да и писать по моему. Но некоторые видимо могут, но у многих такие же проблемы как и у меня.

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

И сравнивать программы из трех строк смысла мало, надо что-то побольше.

Как меньше если больше? Посчитай символы, лол.

И сравнивать программы из трех строк смысла мало, надо что-то побольше.

Ну тут лисп проиграл))

Ну что поделать, очевидно лисп совершенно не пригоден для написания программ из трех строк!