Здравствуй
T>>>Есть у меня подозрение, что примитивный Лисп на ОКамле будет написан где-то между ужином и отходом ко сну. А>> Не надо "примитивный". Надо "эффективный". Интерпретатор то минимального Лиспа любой дурак за час напишет.
T>Ну уж анализ-то кода на камле со сравнениями с образцом писать проще, чем на лиспе с CARами да CDRами.
Как будто в Лиспах нет pattern matching-а. Есть, и погибче даже, чем в OCaml.
T>А если подтянуть GADT из Хаскеля...
Посмотри на эту реализацию ML на Лиспе — там более эффективное решение, чем GADT применяется.
T>>>Тогда как примитивный ОКамл на Лиспе потребует гораздо больше работы. А>> Не гораздо. Два-три часа максимум. Конкретнее — чуть больше тысячи строк кода с комментариями выходит.
T>А это будет "примитивный" или "эффективный" вариант?
Примитивный, но эффективный (потому что всё же компилятор).
T>Где бы на это посмотреть?
Была уже ссылка на одну такую реализацию.
А>> Он слишком жирным стал в последнее время.
T>Потому, что в нём много удобных вещей.
Меня смущает необходимость пихать "удобные вещи" в минимальное ядро языка. Мне более интересен подход, когда "удобные вещи" легко и непринуждённо добавляются к языку средствами самого языка, но без ущерба эффективности. А то, что минимальный Хаскелль стал таким жирным, несколько отпугивает желающих его реализовать.
T>А нельзя ли показать, как это можно сделать с помощью TH? У меня это в голове не укладывается.
T>Вот пакеты кодогенерации: T>http://hackage.haskell.org/packages/archive/pkg-list.html#cat:code%20generation
T>С их помощью я понимаю, как сделать. Как сделать с помощью TH, мне непонятно.
Кодогенерация + макра TH для подстановки этого самого сгенерённого кода во время компиляции.
T>Так отошли от него.
С YHC до сих пор носятся.
T>Мой любимый аргумент: как много новых языков пишут на каком-либо ФЯ в последнее время?
T>На Хаскеле всё больше, на Лиспе с окамлом всё меньше.
А на Java ещё больше, чем на всём остальном, вместе взятом. Это не показатель.
А>> Ну почему же? Фундаментальность — понятие строгое.
T>А нельзя ли его привести?
Несколько позже — сейчас с гарантией облажаюсь.
T>Техника безопасности при работе с компьютером отличается по объёму от техники безопасности ведения боевых действий.
Потому для меня идеалом является с одной стороны сколь угодно гибкая система, позволяющая делать сколь угодно опасные расширения, а с другой стороны, вся эта гибкость должна быть доступна только тем, кому она реально нужна. А остальным они должны предоставлять типобезопасный, верифицируемый, bondage'n'discipline интерфейс к своим сложным фичам.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>А можно более человеческий вариант получить? В том смысле, чтобы не дописывать, а сразу скомпилировать и запустить?
Здравствуйте, Аноним, Вы писали:
DM>> Но без практики это лишь слова. А> Ок, давай практику. Сделай на OCaml..
Кто кому что продает? Если я сделаю что-то на окамле, это про лисп ничего не докажет, кроме, может быть, его бесполезности.
A> аналог макры ast:visit из MBase. То есть, рекурсивный обход ADT без явной рекурсии.
А можно пример?
DM>> Я готов уверовать в его силу, если увижу на нем реализацию вышеупомянутой ВМ,
А> Вышеупомянутая VM не имеет практической ценности.
Ценность в практичном подтверждении слов. Отсутствие решения уж точно не имеет ценности.
А> Интереснее было бы на более практичном примере сравнить. Только всё равно не спортивно — компилятор с интерпретатором пытаться сравнивать.
А в каком месте интерпретатор? Вроде всю дорогу про компиляторы лиспа речь шла, про эффективность получаемых решений..
Здравствуйте, Аноним, Вы писали:
DM>>2. Как то, что на Лиспе можно сделать вывод типов для некоего внешнего языка, поможет в ускорении ВМ, написанной на самом Лиспе, если тормозит именно он?
А> Уф, нашел таки наконец тот пример, который искал: А> http://www.cliki.net/TypeL
Features that will be implemented in feature releases:
1. Algebraic types and pattern matching.
2. Detailed error reporting.
3. Code optimization based on type information and static analysis.
Кажется, это контрпример. В нем нифига не реализовано.
Re[18]: Как написать виртуальную машину на LISP
От:
Аноним
Дата:
12.08.09 14:21
Оценка:
Здравствуйте, D. Mon, Вы писали:
DM>Кто кому что продает? Если я сделаю что-то на окамле, это про лисп ничего не докажет, кроме, может быть, его бесполезности.
Всё дело в том, что ты этого на OCaml не сделаешь. Не получится. Вообще. Не пустит он к себе в потроха, даже если CamlP4 использовать, до определения ADT добраться не дадут, чтоб макру правильно развернуть.
A>> аналог макры ast:visit из MBase. То есть, рекурсивный обход ADT без явной рекурсии.
DM>А можно пример?
Там простые примеры использования есть.
А>> Вышеупомянутая VM не имеет практической ценности.
DM>Ценность в практичном подтверждении слов. Отсутствие решения уж точно не имеет ценности.
Мотивация не очень-то мотивирующая. Посмотрим, если найду время прочитать спек на VM, тогда и реализовать её особого труда не составит.
DM>А в каком месте интерпретатор? Вроде всю дорогу про компиляторы лиспа речь шла, про эффективность получаемых решений..
Я как раз про то, что реализация на Лиспе — компилятор, а на C++ и ML — интерпретаторы.
Здравствуйте, Аноним, Вы писали:
А>Здравствуй
T>>Ну уж анализ-то кода на камле со сравнениями с образцом писать проще, чем на лиспе с CARами да CDRами. А> Как будто в Лиспах нет pattern matching-а. Есть, и погибче даже, чем в OCaml.
"Погибче" не означает "поудобней". А также это не означает "побезопасней".
Здесь присутствуют два бывших Лисповика, vshabanov и lomeo, оба покинули его и из-за невозможности нормального сравнения с образцом в том числе.
T>>А если подтянуть GADT из Хаскеля... А> Посмотри на эту реализацию ML на Лиспе — там более эффективное решение, чем GADT применяется.
Где эта реализация, на которую надо посмотреть?
T>>>>Тогда как примитивный ОКамл на Лиспе потребует гораздо больше работы. А>>> Не гораздо. Два-три часа максимум. Конкретнее — чуть больше тысячи строк кода с комментариями выходит. T>>А это будет "примитивный" или "эффективный" вариант? А> Примитивный, но эффективный (потому что всё же компилятор).
Похоже, что Lisp используется, как RTL в gcc.
А если мы ML в gcc странслируем, получится эффективней, или примитивней?
T>>Где бы на это посмотреть? А> Была уже ссылка на одну такую реализацию.
Здесь не было. Где было-то?
А>>> Он слишком жирным стал в последнее время. T>>Потому, что в нём много удобных вещей. А> Меня смущает необходимость пихать "удобные вещи" в минимальное ядро языка. Мне более интересен подход, когда "удобные вещи" легко и непринуждённо добавляются к языку средствами самого языка, но без ущерба эффективности. А то, что минимальный Хаскелль стал таким жирным, несколько отпугивает желающих его реализовать.
Перечисли, пожалуйста, "удобные вещи", которые можно быстро добавить в Лисп и тяжело добавить в программу на Хаскеле. Если не сложно, то укажите альтернативные варианты и оцените их трудоемкость по написанию и использованию.
T>>А нельзя ли показать, как это можно сделать с помощью TH? У меня это в голове не укладывается. T>>Вот пакеты кодогенерации: T>>http://hackage.haskell.org/packages/archive/pkg-list.html#cat:code%20generation T>>С их помощью я понимаю, как сделать. Как сделать с помощью TH, мне непонятно. А> Кодогенерация + макра TH для подстановки этого самого сгенерённого кода во время компиляции.
Я не очень понимаю на словах.
Нельзя ли кода кусочек?
T>>Так отошли от него. А> С YHC до сих пор носятся.
Как-то слабо.
T>>Мой любимый аргумент: как много новых языков пишут на каком-либо ФЯ в последнее время? T>>На Хаскеле всё больше, на Лиспе с окамлом всё меньше. А> А на Java ещё больше, чем на всём остальном, вместе взятом. Это не показатель.
Но не языков.
Поэтому и показатель, что языки сейчас делают на Хаскеле.
Видимо, это оптимум, sweet spot. И быстро, и безопасно.
T>>Техника безопасности при работе с компьютером отличается по объёму от техники безопасности ведения боевых действий. А> Потому для меня идеалом является с одной стороны сколь угодно гибкая система, позволяющая делать сколь угодно опасные расширения, а с другой стороны, вся эта гибкость должна быть доступна только тем, кому она реально нужна. А остальным они должны предоставлять типобезопасный, верифицируемый, bondage'n'discipline интерфейс к своим сложным фичам.
Вот именно. Здесь Хаскель рулит. Хочешь — добавляй свою фичу и поддерживай её. А всем остальным она будет видна в типобезопасном виде.
Поэтому вопрос: software transactional memory для лиспа есть?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, thesz, Вы писали:
T>>Ну уж анализ-то кода на камле со сравнениями с образцом писать проще, чем на лиспе с CARами да CDRами.
TBG>Пример паттерн-матчинга в статье, кстати, есть.
И им удобно пользоваться? Компилятор поможет, если структура сравниваемых значений изменилась?
Это очень важные вопросы.
Но я повторяюсь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Как написать виртуальную машину на LISP
От:
Аноним
Дата:
12.08.09 14:27
Оценка:
Здравствуйте, D. Mon, Вы писали:
DM>Кажется, это контрпример. В нем нифига не реализовано.
А на фига для данной задачи всё остальное (ADT всякие, и т.д.)? Надо только малость похинтовать компилятор, чтоб с машинными целыми работал. А для этого и такой простой метод сгодится.
Re[14]: Как написать виртуальную машину на LISP
От:
Аноним
Дата:
12.08.09 14:36
Оценка:
Здравствуйте, thesz, Вы писали:
А>> Как будто в Лиспах нет pattern matching-а. Есть, и погибче даже, чем в OCaml.
T>"Погибче" не означает "поудобней". А также это не означает "побезопасней".
Про безопасность соглашусь. Но за безопасность приходится платить жестокостью системы типов. А удобство — это уже дело субъективное.
T>Здесь присутствуют два бывших Лисповика, vshabanov и lomeo, оба покинули его и из-за невозможности нормального сравнения с образцом в том числе.
Интересно было бы послушать, чего именно им не хватило.
T>Где эта реализация, на которую надо посмотреть?
Ранее в этой теме была ссылка.
А>> Примитивный, но эффективный (потому что всё же компилятор).
T>Похоже, что Lisp используется, как RTL в gcc.
Не совсем. RTL низкоуровневый и фиксированный. А Лисп можно специализировать под промежуточное представление для весьма сложных языков.
T>А если мы ML в gcc странслируем, получится эффективней, или примитивней?
Сложнее получится. И он не будет embedded.
T>Здесь не было. Где было-то?
Было-было.
T>Перечисли, пожалуйста, "удобные вещи", которые можно быстро добавить в Лисп и тяжело добавить в программу на Хаскеле.
Ну, например, систему типов. Как, например, в Qi II. Да, да, в Хаскелле уже есть одна, знаю. А я вот другую хочу. Как мне её поменять, не меняя языка?
Или, например, Пролог встроить хочу. Чтоб эффективно в WAM компилировался.
T> Если не сложно, то укажите альтернативные варианты и оцените их трудоемкость по написанию и использованию.
Альтернативный вариант — Template Haskell. Но у него свои сложности и ограничения есть. И я не уверен, что там всё в порядке с интроспекцией определений типов — давно в последний раз с ним играл.
T>Я не очень понимаю на словах.
T>Нельзя ли кода кусочек?
Ок, завтра пришлю простенький Лисп, сделанный на TH.
А>> А на Java ещё больше, чем на всём остальном, вместе взятом. Это не показатель.
T>Но не языков.
Именно языков. Из свежачка, например — Guru.
T>Видимо, это оптимум, sweet spot. И быстро, и безопасно.
Соглашусь, что это оптимум по скорости разработки и безопасности. Лисп — оптимум по скорости разработки и эффективности результата.
T>Вот именно. Здесь Хаскель рулит. Хочешь — добавляй свою фичу и поддерживай её.
А я не хочу. Меня не тянет копаться в разжиревших чрезмерно за последние годы потрохах GHC. И уж тем более поддерживать каждую нужную мне фичу вечно. Я хочу фичи добавлять точно так же, как пишутся библиотеки. И не трогать компилятор языка.
T>Поэтому вопрос: software transactional memory для лиспа есть?
turtle@turtle:~/scm-controlled/turtle/icfpcontest/icfpcontest-2009/speedcon$ g++ orbitvm.cpp
orbitvm.cpp:4:20: error: stdafx.h: No such file or directory
orbitvm.cpp:6:21: error: windows.h: No such file or directory
orbitvm.cpp:24: ошибка: ‘DWORD’ не является именем типа
orbitvm.cpp: In constructor ‘VM::VM()’:
orbitvm.cpp:36: ошибка: нет декларации ‘prg’ в этой области видимости
orbitvm.cpp: In member function ‘bool VM::load_program(const char*)’:
orbitvm.cpp:42: ошибка: нет декларации ‘HANDLE’ в этой области видимости
orbitvm.cpp:42: ошибка: expected `;' before ‘h’
orbitvm.cpp:43: ошибка: нет декларации ‘h’ в этой области видимости
orbitvm.cpp:43: ошибка: нет декларации ‘INVALID_HANDLE_VALUE’ в этой области видимости
orbitvm.cpp:44: ошибка: нет декларации ‘DWORD’ в этой области видимости
orbitvm.cpp:44: ошибка: expected `;' before ‘sz’
orbitvm.cpp:45: ошибка: нет декларации ‘sz’ в этой области видимости
Здравствуйте, Аноним, Вы писали:
A> аналог макры ast:visit из MBase. То есть, рекурсивный обход ADT без явной рекурсии. А> Всё дело в том, что ты этого на OCaml не сделаешь. Не получится. Вообще. Не пустит он к себе в потроха, даже если CamlP4 использовать, до определения ADT добраться не дадут, чтоб макру правильно развернуть.
Из этого примера смысл ast:visit в МЛ ускользает — чем плох обычный рекурсивный обход дерева? В нем гораздо больше свободы действий плюс гарантия полноты матчинга и проверка корректности (проверяет ли ast:visit типы аргументов или хотя бы их число?), а текста немного, т.к. есть нормальный синтаксис.
DM>>А в каком месте интерпретатор? Вроде всю дорогу про компиляторы лиспа речь шла, про эффективность получаемых решений..
А> Я как раз про то, что реализация на Лиспе — компилятор, а на C++ и ML — интерпретаторы.
А, это да. Вот и интересно увидеть всю хваленую эффективность. А то пока что не видно.
Здравствуйте, Аноним, Вы писали:
A>Что позволяет любую сгенерённую во время компиляции конструкцию использовать тут же для определения следующих конструкций.
Это милая фича, не более того. Хитрые зависимости внутри одного модуля плодить совершенно не обязательно. В r6rs scheme, емнип, ввели стадии компиляции и эту фичу порезали — и ничего.
А> И тогда у нас будет два разных языка. Никак не взаимодействующих.
Это не так. Если исходный язык компилируется средствами, скажем, .net в дотнетные сборки, то сам компилятор вполне сможет потом пользоваться скомпилированным кодом. Ну или скомпилированный код компилятором. Взаимодействие между кодом на разных языках — оно метапрограммированию все-таки ортогонально.
А> Совсем не те же. Любой метаязык заведомо превосходит любой не-метаязык. Даже если первый — это Форт, а второй — Haskell (без TH).
Никто не спорит, что метапрограммирование — это хорошая штука. В этой ветке мы сомневаемся в том, что метаязыки имеют какое-то волшебное преимущество при реализации компиляторов или интерпретаторов.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, thesz, Вы писали:
T>>И им удобно пользоваться? Компилятор поможет, если структура сравниваемых значений изменилась?
TBG>Вполне удобно. Если специфицирушь тип — поможет.
Связать полиморфные типы компилятор может?
А вот такое:
data Z
data S n
data Vec a len where
Empty :: Vec Z
Cons :: a -> Vec a n -> Vec a (S n)
safeHead :: Vec a (S n) -> a
safeHead (Cons a _) = a
-- ошибкой будет safeHead Empty.
Неужто тоже может?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Если я сделаю что-то на окамле, это про лисп ничего не докажет, кроме, может быть, его бесполезности. 
