Здравствуйте, WolfHound, Вы писали:

_>>И так, мне нужен простенький DSL в стиле Basic. Ну там if, for, print, переменные строковые и целочисленные и какие-нибудь доменные функций. Значит я записываю соответствующую грамматику и с помощью bison/flex за пару часов делаю парсер этого языка.
WH>При этом будешь долго разбираться с конфликтами shift/reduce.
WH>А потом пользователи будут получать фееричные сообщения об ошибках.
_>>Далее, в тот же парсер я добавляю обход по АСТ, который банально выводит в файл соответствующий (if в if, for в for и т.п.) C++ код.
WH>И пользователь будет получать ошибки от компилятора С++.
WH>Это ад.

Ну вообще то ошибок C++ то точно не будет, т.к. это кодогенерация, причём простейшая. Но это уже мелочи, а интереснее главное — так я правильно понял, что в общем то единственным отличием вашего продукта от предложенного сценария будет изначальная отлаженность? )

WH>Вероятность того что там будет пролог и все остальные языки которые на слуху равна 100%

Ну если так, то здорово!

Правда у меня есть определённые сомнения, что вы осилите такой объём работ... Но в любом случае буду болеть за вас.

Здравствуйте, alex_public, Вы писали:

_>Ну вообще то ошибок C++ то точно не будет, т.к. это кодогенерация, причём простейшая.
А как на счёт вызова несуществующей функции?
А использование не тех типов?
У тебя про это ни слова.

_>Но это уже мелочи, а интереснее главное — так я правильно понял, что в общем то единственным отличием вашего продукта от предложенного сценария будет изначальная отлаженность? )
Объём работы и качество результата.
Ты просто сильно недооцениваешь объём работы, который нужно проделать, чтобы сделать нормальный компилятор.

_>Правда у меня есть определённые сомнения, что вы осилите такой объём работ... Но в любом случае буду болеть за вас.
А нам и не надо будет.
Всё напишут за нас.

Здравствуйте, WolfHound, Вы писали:

_>>JS же — это по сути один здоровый скрипт (даже если он и во многих файлах), работающий у клиента. Но причём тут он, если мы говорили про серверный Питон? )
WH>Мы говорим про всё решение.
WH>Вот и получается что данные из одного питоновского скрипта пройдя через клиенствий ЖС могут попасть в другой питоновский скрипт.

Естественно могут. Я об этом ещё в самом начале писал. Более того, я указал что есть ещё и второй канал обмена данными, с другой стороны — через БД. Но в любом случае оба эти канала являются не прямыми, а через другой язык, так что непонятно какое это имеет значение в контексте нашей дискуссии.

_>>Ха, т.е. ты не увидел основного в этом инструменте? ))) Там же реализован набор команд: local/run/sudo, put/get, reboot, prompt. Плюс набор модификаторов контекста: lcd/cd, prefix, path, shell_env, hide/show.
WH>Это всё за час делается.
WH>Короче я так и не понял что ты предлагаешь там неделю писать.

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

_>>Гм... Вообще то VB статически типизированный язык. Если же ты подразумеваешь под динамикой в нём наличие типа Variant, то он такой и в C++ (ну с Boost'ом) есть... )))
WH>Современный ВБ.

Ну который с IDispatch начал работать уже такой был. )

_>>Не буду цепляться к лишним строкам на переименовывание (кстати не вижу в нём особого смысла — имена то пускай будет родные, главное чтобы смысл не менялся) — тут и без этого большое раздолье... ))) Сразу возникают вопросы: кто такие "do", "\x" и "->"?
WH>А кто такой "s"? А кто такой "in"? А кто такой ":".
WH>Короче я тоже к буквам цепляться умею.

Хорошо, перефразирую по простому: требовать знание понятия переменной и цикла для вывода набора строк — это нормально, а требовать знания понятия лямбда и монада — это бредово.

_>>Ну так а можно глянуть на пример? ) А то на Питоне или Хаскеле я вообще то и сам могу, а вот на Немерле пока никак. )))
WH>Ох.
WH>

WH>#pragma indent
WH>using System.Console

WH>def test(data)
WH>  foreach (s in data)
WH>    System.Threading.Thread.Sleep(1000)
WH>    WriteLine(s)

WH>test(["один", "два", "три"])
WH>

Воот, Немерле похоже может претендовать на замену Питона, в отличие от Хаскеля. Во всяком случае по лёгкости синтаксиса. Инфраструктуры (кстати, запуск в стиле интерпретатора/jit у вас имеется?) подходящей конечно нет, но это хотя бы решаемо при большом желание.

_>>Проблема как раз в том, что нужен уже mapM_, а не map. ) С кучей разных последствий из этого.
WH>IO нужно только на входе и на выходе.
WH>Так в чём проблема то?

С монадами в Хаскеле вообще куча проблем и это подробно обсуждалось на этом форуме. Если кратко, то код внутри монад лишён множеств преимуществ Хаскеля. Изначально была идея локализовать в них весь "неправильный" код и писать в остальных частях приложения на нормальном красивом Хаскеле. Однако на практике постоянно оказывается, что в реальных приложениях ввод/вывод, состояния и т.п. встречаются на каждом шагу. А кроме этого добавление монады в одном месте обычно "заражает" ею вверх весь стек вызова. В итоге получается, что практически весь код приложения находится внутри монад. А это лишает выбор Хаскеля всякого смысла, потому как монадный код, по сути являющийся реализацией императивного подъязыка, является жалкой и убогой пародией на современные императивные языки. Так что на практике применение Хаскеля оправдано только в очень узкой нише, типа каких-нибудь консольных преобразователей текстовый файлов и т.п., где можно реально локализовать весь ввод/вывод и не нужны состояния. Ну или в академических/демонстрационных проектах. )))

Здравствуйте, WolfHound, Вы писали:

_>>Ну вообще то ошибок C++ то точно не будет, т.к. это кодогенерация, причём простейшая.
WH>А как на счёт вызова несуществующей функции?
WH>А использование не тех типов?
WH>У тебя про это ни слова.

Так это же просто не пройдёт через парсер. Т.е. конечно в случае более сложного языка (хотя сложный DSL — это уже весьма необычно) потребуется внести дополнительные проверки. Но для конкретного этого моего примера (с синтаксисом Basic'a) должно хватить и вообще парсера.

_>>Но это уже мелочи, а интереснее главное — так я правильно понял, что в общем то единственным отличием вашего продукта от предложенного сценария будет изначальная отлаженность? )
WH>Объём работы и качество результата.
WH>Ты просто сильно недооцениваешь объём работы, который нужно проделать, чтобы сделать нормальный компилятор.

Компилятор чего и куда? Скажем продукты типа gcc и ему подобные я даже в кошмарном сне не возьмусь переписывать. А допустим реализовать тот же OpenSCAD я бы взялся без проблем, причём в весьма короткие сроки...

_>>Правда у меня есть определённые сомнения, что вы осилите такой объём работ... Но в любом случае буду болеть за вас.
WH>А нам и не надо будет.
WH>Всё напишут за нас.

Хм, ну посмотрим, посмотрим... Интересно будет взглянуть на вашу бизнес-модель.

Здравствуйте, alex_public, Вы писали:

_>Естественно могут. Я об этом ещё в самом начале писал. Более того, я указал что есть ещё и второй канал обмена данными, с другой стороны — через БД. Но в любом случае оба эти канала являются не прямыми, а через другой язык, так что непонятно какое это имеет значение в контексте нашей дискуссии.
Этот фактор лишь усугубляет последствия.

WH>>Современный ВБ.
_>Ну который с IDispatch начал работать уже такой был. )
IDispatch это уже динамическая типизация.

_>Хорошо, перефразирую по простому: требовать знание понятия переменной и цикла для вывода набора строк — это нормально, а требовать знания понятия лямбда и монада — это бредово.
Это слишком субъективно.

_>Воот, Немерле похоже может претендовать на замену Питона, в отличие от Хаскеля. Во всяком случае по лёгкости синтаксиса. Инфраструктуры (кстати, запуск в стиле интерпретатора/jit у вас имеется?) подходящей конечно нет, но это хотя бы решаемо при большом желание.
Вроде кто-то делал, но мне искать лень.
В любом случае там, на пару часов работы.

_>С монадами в Хаскеле вообще куча проблем и это подробно обсуждалось на этом форуме. Если кратко, то код внутри монад лишён множеств преимуществ Хаскеля.
Так они нужны только для IO.
Зачем тебе IO по всему коду?.

_> Изначально была идея локализовать в них весь "неправильный" код и писать в остальных частях приложения на нормальном красивом Хаскеле.
Правильная идея. Я так даже не на хаскеле пишу.

_>Однако на практике постоянно оказывается, что в реальных приложениях ввод/вывод, состояния и т.п. встречаются на каждом шагу.
У тебя просто императивное смещение сознания.

Здравствуйте, alex_public, Вы писали:

WH>>А как на счёт вызова несуществующей функции?
WH>>А использование не тех типов?
WH>>У тебя про это ни слова.
_>Так это же просто не пройдёт через парсер.
У тебя сильно неверное представление о возможностях парсера.
Парсер не может проверить ни объявление функции, ни объявление переменной, ни тем более соответствие типов.

Или ты хочешь иметь захардкоженый набор функций, один тип и запрет на объявление пользователем своих переменных и функций?

Много цитат ниже. Остается только поразиться, как у таких титанов духа, у которых все пишется за часы, нет ничего. Ни инфраструктуры, ни библиотек, ни решений — ни.че.го. Для любого из языков, начинающихся на N.

1.
_>>Инфраструктуры (кстати, запуск в стиле интерпретатора/jit у вас имеется?) подходящей конечно нет, но это хотя бы решаемо при большом желание.
WH>Вроде кто-то делал, но мне искать лень.
WH>В любом случае там, на пару часов работы.

2.
WH>А нам и не надо будет.
WH>Всё напишут за нас.

3.
WH> Либо есть либо пишется за пару часов.
(хотя это про Хаскель было, но не суть)

4.
WH> Для любого статически типизированного языка такое пишется примерно за день

5.
WH> Все равно не вижу, что там больше одного дня писать.

6.
WH> Это всё за час делается.

7.
WH> Куча реализованных расширяемых языков
вернее
WH> Когда натра будет доведена до релиза, там будет куча разных языков
вернее
_> И вот только сейчас, после долгой дискуссии я смог вытащить из тебя клещами информацию про некую библиотеку языков в Найтре
WH> Ох. Создание оно бывает разным.

Здравствуйте, WolfHound, Вы писали:

_>>Естественно могут. Я об этом ещё в самом начале писал. Более того, я указал что есть ещё и второй канал обмена данными, с другой стороны — через БД. Но в любом случае оба эти канала являются не прямыми, а через другой язык, так что непонятно какое это имеет значение в контексте нашей дискуссии.
WH>Этот фактор лишь усугубляет последствия.

Непонятно. Какие последствия? ) Ты хочешь сказать, что если ты заменишь в этом сценарии Питон на какой-то статически типизированный язык, то что-то в этой картине изменится? )

WH>>>Современный ВБ.
_>>Ну который с IDispatch начал работать уже такой был. )
WH>IDispatch это уже динамическая типизация.

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

_>>С монадами в Хаскеле вообще куча проблем и это подробно обсуждалось на этом форуме. Если кратко, то код внутри монад лишён множеств преимуществ Хаскеля.
WH>Так они нужны только для IO.
WH>Зачем тебе IO по всему коду?.

Потому что в реальных, а не академических приложениях, ввод-вывод и есть по всему коду. Один GUI уже чего стоит и обычно пронизывает всё приложение. И даже если есть модули не связанные с GUI, то скорее всего они что-то пишут в сеть или на диск.

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

_>> Изначально была идея локализовать в них весь "неправильный" код и писать в остальных частях приложения на нормальном красивом Хаскеле.
WH>Правильная идея. Я так даже не на хаскеле пишу.

Правильная идея теоретиков от программирования. )

_>>Однако на практике постоянно оказывается, что в реальных приложениях ввод/вывод, состояния и т.п. встречаются на каждом шагу.
WH>У тебя просто императивное смещение сознания.

Я как раз больше люблю использовать ФП стиль, а не ООП. Кстати говоря, вся STL и большая часть Boost'а именно в таком стиле и написаны. Я против языков с чистым ФП. Причём самое понятие чистоты мне тоже вполне себе нравится. Но его можно вводить не по кривому (как в Хаскеле, в обязательном порядке), а по нормальному (как в D, в виде модификатора). В итоге получаем нормальный мультипарадигменный язык, который обладает всеми полезными возможностями чистых функций, но не навязывает их использование. А в Хаскеле из-за его кривого дизайна нам приходится использоваться нормальную концепцию монад (полезная вещь для некого узкого круга задач) не по их прямому назначению, а для компенсации этой кривизны.

Здравствуйте, WolfHound, Вы писали:

_>>Так это же просто не пройдёт через парсер.
WH>У тебя сильно неверное представление о возможностях парсера.
WH>Парсер не может проверить ни объявление функции, ни объявление переменной, ни тем более соответствие типов.
WH>Или ты хочешь иметь захардкоженый набор функций, один тип и запрет на объявление пользователем своих переменных и функций?

Ты похоже забыл или не знал, что такое классически Basic (а не VB). Там же тип переменной задаётся в её имени. Так что парсер очень даже хорошо со всем разберётся. Ну и да, набор предметных функций у нас зашит в грамматику — на то оно и DSL, а не язык общего назначения. )))

Здравствуйте, alex_public, Вы писали:

_>Непонятно. Какие последствия? ) Ты хочешь сказать, что если ты заменишь в этом сценарии Питон на какой-то статически типизированный язык, то что-то в этой картине изменится? )
Если убрать всю динамику включая жабаскрипт, то всё сильно изменится.

_>Потому что в реальных, а не академических приложениях, ввод-вывод и есть по всему коду. Один GUI уже чего стоит и обычно пронизывает всё приложение. И даже если есть модули не связанные с GUI, то скорее всего они что-то пишут в сеть или на диск.
Ну не знаю.
Мне в большей части кода IO не нужно.

_>Да, и кстати говоря плохие (которые появляются из-за сомнительного дизайна языка, а не из-за реальной потребности в конвейере вычислений) монады в Хаскеле ограничиваются не только вводом-выводом.
Нормальный дизайн.
Просто в "обычных" языках монада IO протянута всегда и везде.

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

WH>>Правильная идея. Я так даже не на хаскеле пишу.
_>Правильная идея теоретиков от программирования. )
Я практик.
В моём коде IO всегда очень сильно локализовано.

_>Я как раз больше люблю использовать ФП стиль, а не ООП. Кстати говоря, вся STL и большая часть Boost'а именно в таком стиле и написаны. Я против языков с чистым ФП. Причём самое понятие чистоты мне тоже вполне себе нравится. Но его можно вводить не по кривому (как в Хаскеле, в обязательном порядке), а по нормальному (как в D, в виде модификатора). В итоге получаем нормальный мультипарадигменный язык, который обладает всеми полезными возможностями чистых функций, но не навязывает их использование.
Так на любом языке можно писать чистые функции.
Хоть на ассемблере.

_>А в Хаскеле из-за его кривого дизайна нам приходится использоваться нормальную концепцию монад (полезная вещь для некого узкого круга задач) не по их прямому назначению, а для компенсации этой кривизны.
В хаскеле куча проблем.
Но организация IO к ним не относится.
Держать IO под контролем хорошо всегда.

Здравствуйте, alex_public, Вы писали:

_>Ты похоже забыл или не знал, что такое классически Basic (а не VB). Там же тип переменной задаётся в её имени. Так что парсер очень даже хорошо со всем разберётся. Ну и да, набор предметных функций у нас зашит в грамматику — на то оно и DSL, а не язык общего назначения. )))
Ох.
Парсер не может проверить, что переменная объявлена.
Парсер не может проверить, что ты присваиваешь переменной выражение правильного типа.
Язык без функций это ад. Больше 20-30 строк кода на нём не написать.

Здравствуйте, WolfHound, Вы писали:

_>>Непонятно. Какие последствия? ) Ты хочешь сказать, что если ты заменишь в этом сценарии Питон на какой-то статически типизированный язык, то что-то в этой картине изменится? )
WH>Если убрать всю динамику включая жабаскрипт, то всё сильно изменится.

Ну вот допустим мы проделаем кучу никчемной (на мой вкус) работы и перепишем клиентскую часть на TypeScript, а серверную на Go. По твоему это что-то улучшит в данной системе? )

_>>Потому что в реальных, а не академических приложениях, ввод-вывод и есть по всему коду. Один GUI уже чего стоит и обычно пронизывает всё приложение. И даже если есть модули не связанные с GUI, то скорее всего они что-то пишут в сеть или на диск.
WH>Ну не знаю.
WH>Мне в большей части кода IO не нужно.

Это значит, что у тебя как раз очень не стандартный код.

_>>Да, и кстати говоря плохие (которые появляются из-за сомнительного дизайна языка, а не из-за реальной потребности в конвейере вычислений) монады в Хаскеле ограничиваются не только вводом-выводом.
WH>Нормальный дизайн.
WH>Просто в "обычных" языках монада IO протянута всегда и везде.

Я же говорю, изначально дело не в монадах. Они являются лишь следствием — кривым лекарством.

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

Ну вот смотри, допустим мы заняты обработкой видео в реальном времени. Если делать это на Хаскеле в каноническом виде (и с красивым кодом), то это будет выглядеть так: выделить буфер для нового кадра, загрузить в него данные, применить набор фильтров (а здесь для каждого фильтра выделяем новый буфер, пишем в него результат и передаём его дальше), выдать результат и перейти к первому шагу (надеясь, что сборщик мусора очистит все эти буферы). Я думаю не надо объяснять, что производительность такого кода будет совершенно убогой? ) В нормальной реализации (скажем на том же C++) мы будем использовать для всех этих операций (и для всех кадров) ровно один буфер. На Хаскеле такое естественно тоже можно реализовать, но тогда там сразу полезет дикая кривизна, уродливый код, монады и т.п.

WH>>>Правильная идея. Я так даже не на хаскеле пишу.
_>>Правильная идея теоретиков от программирования. )
WH>Я практик.
WH>В моём коде IO всегда очень сильно локализовано.

Дело не в локализации, а в соотношение объёмов кода. Если у нас скажем всякие игры с состояниями занимают 1/10 всего кода, то вполне логично, что мы можем пожертвовать удобством (т.к. императивный подъязык, реализуемый монадами, является убожеством по сравнению с нормальными императивными языками) в написание этой 1/10 ради множества преимуществ в написание основной части программы. Только вот подобное соотношение встречается очень редко (чаще всего как раз в академически примерах), а на практике у нас хорошо если не наоборот всё. В итоге мы страдаем при написание большей части приложения, ради невидимых (ощутимых только в малой части кода) преимуществ.

Если же ты говоришь про локализацию IO не в Хаскеле, то это не имеет ничего общего с обсуждаемой темой, т.к. в других языках устройство кода (и набор возможностей языка) у тебя будет одинаковое и в IO и в остальном коде. Ну да, повторюсь ещё раз. Локализация IO в Хаскеле является не причиной, а следствием — вынужденной мерой из-за кривого базового дизайна.

_>>Я как раз больше люблю использовать ФП стиль, а не ООП. Кстати говоря, вся STL и большая часть Boost'а именно в таком стиле и написаны. Я против языков с чистым ФП. Причём самое понятие чистоты мне тоже вполне себе нравится. Но его можно вводить не по кривому (как в Хаскеле, в обязательном порядке), а по нормальному (как в D, в виде модификатора). В итоге получаем нормальный мультипарадигменный язык, который обладает всеми полезными возможностями чистых функций, но не навязывает их использование.
WH>Так на любом языке можно писать чистые функции.
WH>Хоть на ассемблере.

Нет, компилятор должен как минимум знать (а в идеале ещё и проверять, т.е гарантировать — это в D тоже есть) о чистоте этих функций. Тогда он сможет давать этим функциям дополнительные возможности и применять дополнительные оптимизации: ленивое выполнение, кэширование результатов и т.п.

_>>А в Хаскеле из-за его кривого дизайна нам приходится использоваться нормальную концепцию монад (полезная вещь для некого узкого круга задач) не по их прямому назначению, а для компенсации этой кривизны.
WH>В хаскеле куча проблем.
WH>Но организация IO к ним не относится.
WH>Держать IO под контролем хорошо всегда.

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

Здравствуйте, WolfHound, Вы писали:

_>>Ты похоже забыл или не знал, что такое классически Basic (а не VB). Там же тип переменной задаётся в её имени. Так что парсер очень даже хорошо со всем разберётся. Ну и да, набор предметных функций у нас зашит в грамматику — на то оно и DSL, а не язык общего назначения. )))
WH>Ох.
WH>Парсер не может проверить, что переменная объявлена.
WH>Парсер не может проверить, что ты присваиваешь переменной выражение правильного типа.
WH>Язык без функций это ад. Больше 20-30 строк кода на нём не написать.

Вообще то когда-то только так и писали))) Да и сейчас можно найти здоровенные bat файлы. )))

Ну и возвращаясь к основной теме. Я вообще то не спорю, что в общем случае кроме парсера потребуются ещё дополнительные проверки (это конечно же если мы хотим статически типизированный DSL сделать, в случае динамического опять же нет проблем), речь шла про конкретный пример очень простого (но статически типизированного!) DSL с синтаксисом Basic, где возможностей парсера вполне должно хватить. Кстати, в случае конкретного языка я вполне себе представляю как задать эти проверки. А у вас же должен получиться вроде как универсальный инструмент — интересно, как это вы там формализовали их задание?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, LaPerouse, Вы писали:

LP>>Кроме одного случая. Когда динамика используется для интеграции систем друг с другом (на уровне получить из одной системы и передать в другую) при отсутствии всякого метаописания, то есть без возможности автоматически сгенерировать классы.
WH>И когда такое происходит?

Да когда угодно. Например, при работе с веб-апи.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, alex_public, Вы писали:

WH>

WH>import Control.Concurrent;
WH>sleep s = threadDelay  (s * 1000000)

WH>foreach collection fn = mapM_ fn collection

WH>test lines = do
WH>    foreach lines (\x -> do
WH>        sleep 1
WH>        putStrLn x
WH>        )

WH>main = test ["asd", "фвыфыв", "йцууцй", "вапва", "qвапвапzxew"]
WH>

Только вот этот foreach только по названию foreach. На самом деле это map со всеми минусами map-ов и прочих filter-ов (пригодность только для простых случаев, неэффективность и да, многословность).

Здравствуйте, LaPerouse, Вы писали:

LP>Да когда угодно. Например, при работе с веб-апи.
Что мешает описать типы для веб АПИ?

Здравствуйте, alex_public, Вы писали:

_>Ну вот допустим мы проделаем кучу никчемной (на мой вкус) работы и перепишем клиентскую часть на TypeScript, а серверную на Go. По твоему это что-то улучшит в данной системе? )
Не правильный подход.
Нужно переписать всё на чём-то типа NemerleWeb.
Кода будет меньше в разы.
И не будет ресинхронизации между клиентом и сервером.

WH>>Мне в большей части кода IO не нужно.
_>Это значит, что у тебя как раз очень не стандартный код.
Я вообще не могу придумать задачу, где IO будет по всему коду.

_>>>Да, и кстати говоря плохие (которые появляются из-за сомнительного дизайна языка, а не из-за реальной потребности в конвейере вычислений) монады в Хаскеле ограничиваются не только вводом-выводом.
WH>>Нормальный дизайн.
WH>>Просто в "обычных" языках монада IO протянута всегда и везде.
_>Я же говорю, изначально дело не в монадах. Они являются лишь следствием — кривым лекарством.
Ты точно прочитал, на что отвечаешь?

_>>>Например стоит нам захотеть заняться обработкой данных в мутабельном буффере (а по другому вообще не реально работать с потоками, если интересует хотят бы минимальная производительность), то тут же в полный рост вылезает другая никчемная монада... )))
WH>>А в чем там проблема с производительностью?
_>Ну вот смотри, допустим мы заняты обработкой видео в реальном времени.
Мы всё ещё про многопоточность говорим?
Или уже про числодробилки?

_>Если делать это на Хаскеле в каноническом виде (и с красивым кодом), то это будет выглядеть так: выделить буфер для нового кадра, загрузить в него данные, применить набор фильтров (а здесь для каждого фильтра выделяем новый буфер, пишем в него результат и передаём его дальше), выдать результат и перейти к первому шагу (надеясь, что сборщик мусора очистит все эти буферы). Я думаю не надо объяснять, что производительность такого кода будет совершенно убогой? ) В нормальной реализации (скажем на том же C++) мы будем использовать для всех этих операций (и для всех кадров) ровно один буфер. На Хаскеле такое естественно тоже можно реализовать, но тогда там сразу полезет дикая кривизна, уродливый код, монады и т.п.
По описанию тут компилятор должен справиться с оптимизацией.
С виду довольно простой анализ должен показать, что все буферы можно склеить в один.

_>Дело не в локализации, а в соотношение объёмов кода. Если у нас скажем всякие игры с состояниями занимают 1/10 всего кода,
Игры с IO в моём коде занимают 1/10000 если не меньше.

_>Ещё раз, проблема не из-за IO. А из-за требования обязательной чистоты и иммутабельности. Достаточно было сделать эти вещи опциональными и большая часть проблем исчезла бы. Да, это получился бы совсем другой язык, но при этом все базовые возможности можно было бы сохранить.
В том то и дело что нельзя.
Вся крутизна хаскеля проистекает из его чистоты.
Уберёшь чистоту, и хаскель скатится в говно.

Здравствуйте, alex_public, Вы писали:

_>Вообще то когда-то только так и писали))) Да и сейчас можно найти здоровенные bat файлы. )))
Я понимаю, что код и на брейнфаке можно писать. Но зачем?

_>Ну и возвращаясь к основной теме. Я вообще то не спорю, что в общем случае кроме парсера потребуются ещё дополнительные проверки (это конечно же если мы хотим статически типизированный DSL сделать, в случае динамического опять же нет проблем),
Ты только что хотел его в С++ компилировать.

_>речь шла про конкретный пример очень простого (но статически типизированного!) DSL с синтаксисом Basic, где возможностей парсера вполне должно хватить.
Не должно.
Максимум что может бизон это GLR. Те все КС языки.
Проверка объявления переменной не является КС.

_>Кстати, в случае конкретного языка я вполне себе представляю как задать эти проверки.
КС грамматикой задать проверку объявления переменной?
Код в студию.
Если справишься, премия Тьюринга тебе гарантирована.

_>А у вас же должен получиться вроде как универсальный инструмент — интересно, как это вы там формализовали их задание?
Отдельным ДСЛ, который мы сейчас пишем.

Здравствуйте, WolfHound, Вы писали:

_>>Вообще то когда-то только так и писали))) Да и сейчас можно найти здоровенные bat файлы. )))
WH>Я понимаю, что код и на брейнфаке можно писать. Но зачем?

Брейнфак — это шутка. А bat файлы до сих пор кругом. Причём в главной роли и в самых современных инструментах. Вот допустим скачай последний Android SDK — там в главной роли выступает некий android.bat на сотню строк. )))

_>>речь шла про конкретный пример очень простого (но статически типизированного!) DSL с синтаксисом Basic, где возможностей парсера вполне должно хватить.
WH>Не должно.
WH>Максимум что может бизон это GLR. Те все КС языки.
WH>Проверка объявления переменной не является КС.

Ох, да ознакомься ты уже с мат.частью))) Нет в Бейсике никаких объявлений переменных. Да и сам подумай зачем они там, если все переменные глобальные, а тип задаётся в имени.

_>>Кстати, в случае конкретного языка я вполне себе представляю как задать эти проверки.
WH>КС грамматикой задать проверку объявления переменной?
WH>Код в студию.
WH>Если справишься, премия Тьюринга тебе гарантирована.

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

_>>А у вас же должен получиться вроде как универсальный инструмент — интересно, как это вы там формализовали их задание?
WH>Отдельным ДСЛ, который мы сейчас пишем.

Хы, любопытно. Я себе такое не особо представляю, правда это и совсем не моя тема. )))

Здравствуйте, WolfHound, Вы писали:

WH>Не правильный подход.
WH>Нужно переписать всё на чём-то типа NemerleWeb.

А зачем? ) Оно и так работает без всяких проблем. )

WH>Кода будет меньше в разы.

Что-то очень сомнительно. Там и так его и так мало (я же говорил, пара десятков Питон скриптов, на 1-2 экрана каждый). Куда ещё меньше то? )

WH>И не будет ресинхронизации между клиентом и сервером.

а это вообще что? %)

_>>>>Например стоит нам захотеть заняться обработкой данных в мутабельном буффере (а по другому вообще не реально работать с потоками, если интересует хотят бы минимальная производительность), то тут же в полный рост вылезает другая никчемная монада... )))
WH>>>А в чем там проблема с производительностью?
_>>Ну вот смотри, допустим мы заняты обработкой видео в реальном времени.
WH>Мы всё ещё про многопоточность говорим?
WH>Или уже про числодробилки?

Не, я всё время говорил как раз про потоки данных, а не исполнения. Просто неточно сформулировал. Только сейчас перечитал и понял, что можно было понять по другому. )))

_>>Если делать это на Хаскеле в каноническом виде (и с красивым кодом), то это будет выглядеть так: выделить буфер для нового кадра, загрузить в него данные, применить набор фильтров (а здесь для каждого фильтра выделяем новый буфер, пишем в него результат и передаём его дальше), выдать результат и перейти к первому шагу (надеясь, что сборщик мусора очистит все эти буферы). Я думаю не надо объяснять, что производительность такого кода будет совершенно убогой? ) В нормальной реализации (скажем на том же C++) мы будем использовать для всех этих операций (и для всех кадров) ровно один буфер. На Хаскеле такое естественно тоже можно реализовать, но тогда там сразу полезет дикая кривизна, уродливый код, монады и т.п.
WH>По описанию тут компилятор должен справиться с оптимизацией.
WH>С виду довольно простой анализ должен показать, что все буферы можно склеить в один.

Ну попробуй))) Но я тебе сразу скажу, что не справится. Более того, даже если бы и произошло такое чудо, то речь бы шла максимум о склейке буферов разных фильтров, но не об использование одного буфера для всех кадров. Я видел оптимизированную реализацию подобного на Хаскеле (причём написанную не мною, а специалистом по Хаскелю) — кривизна и хитрые хаки на каждом углу. В целом мрак и ужас. В то время как на практически любом другом языке это же пишется элементарно.

_>>Дело не в локализации, а в соотношение объёмов кода. Если у нас скажем всякие игры с состояниями занимают 1/10 всего кода,
WH>Игры с IO в моём коде занимают 1/10000 если не меньше.

Поздравляю) Значит ты относишься к той крайне узкой нише, в которой Хаскель может быть действительно полезен.

_>>Ещё раз, проблема не из-за IO. А из-за требования обязательной чистоты и иммутабельности. Достаточно было сделать эти вещи опциональными и большая часть проблем исчезла бы. Да, это получился бы совсем другой язык, но при этом все базовые возможности можно было бы сохранить.
WH>В том то и дело что нельзя.
WH>Вся крутизна хаскеля проистекает из его чистоты.
WH>Уберёшь чистоту, и хаскель скатится в говно.

Так я и н говорю убирать. Достаточно сделать необязательными.