LINUX.ORG.RU

язык мечты


0

1

Добрый вечер!

Теперь всё ясно: Common Lisp - это кал. О чём же теперь мечтать перед сном? Об обратимом препроцессоре? Это можно, но как-то мало. Хочется мечтать о большем. Например, о таком:

1. Одно понятие пространства имён. В "обычных" языках есть пространство имён как namespace, а есть виртуальное пространство имён, которое возникает внутри данного scope. Или пр-во тех имён, которые можно писать после точки, если переменная имеет тип. Обобщить до одного понятия, придать средства управления.

2. Паскаль - порядка 10000 строк в секунду. Хороший мальчик. Синтаксис должен быть простым для компьютера и читаемым для человека. При этом должна быть возможность делать быстрый и компактный код. Поэтому - строгая типизация. Есть тип variant (можно назвать его t для краткости) - он делает Паскаль вполне похожим на лисп по гибкости работы с типами, при условии, что в таком стиле написаны библиотеки.

3. Сборку мусора - в мусорное ведро вместе с JIT. Всё это - разводка на бабло, чтобы покупали новое железо. Вместо этого безопасность дадут декларации работы с памятью: function foo(caption:string):fresh(widgets.form); Что-то мне подсказывает, что весьма простым способом можно с помощью таких деклараций и выводов из них построить работу с памятью без сборщика мусора и с высокой степенью автоматизации (хотя могу ошибаться).

4. Язык должен быть сначала императивным, а потом уже можно строить всё остальное. Для функциональщиков покатит декларация pure. Если в функции f вызываются только чистые функции, то и сама эта функция чиста. Значит, декларацию pure легко проверить на этапе сборки. Соответственно же, декларации const тоже можно проверить (это ещё С умеет делать).

5. Встроенный тип variant. Один, а не 10, как в "некоторых других языках".

6. Макросы не хуже лиспа. А иначе - какой смысл.

7. Конечно же, генерация исполняемого кода в рантайме. Можно через .so, как GCL.

8. Встроенный FFI типа CFFI-GROVEL. Конечно, только С.

9. read-print как в лиспе. Ну и eval к ним (т.е., code=data)

10. Вменяемый синтаксис, но простой. Представление code=data - это промежуточное представление. Для человека оно преобразуется по простым, но гибким правилам. Ну и что-то вроде readtable, как в лиспе. А может,что-то более стройное и менее хакерское.

11. Не ОО. функции, примитивные типы и структуры. И хватит. Вместо ОО - функции как объекты первого класса. ОО должно быть маленькой и лёгкой библиоткой (стиля JavaScript, наверное). CLOS - это пример как делать не надо. Про С++ лучше вообще не говорите.

12. Замыкания... Наверное, состояние в них должно быть явным.

13. Встроенный codewalker.

14. Наверное,кроссплатформенность. Причём, в определении платформы должны содержаться и базовые элементы работы с GUI. Платформа может быть в чём-то неполной (например, не иметь примитивов для работы с файловой системой, eval или compile) и это не должно влиять на общую работоспособность - пусть работает то, что может работать.

Эх, мечты-мечты... Ладно, спокойной ночи.

anonymous


все верно. но только заменить pure на kosher.

// wbr

klalafuda ★☆☆
()

Пиздеть - не мешки ворочать. Сядь и напиши компилятор. Начать можно с чтения SICP'а или Ахо и Ульмана

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

anonymous
()

> 1. ... Обобщить до одного понятия, придать средства управления.

Грабить корованы.

> 2. ... Синтаксис должен быть простым для компьютера и читаемым для человека. При этом должна быть возможность делать быстрый и компактный код.

Грабить корованы.

> 3. Что-то мне подсказывает, что весьма простым способом можно с помощью таких деклараций...

можно грабить корованы

> 4. Язык должен быть сначала императивным, а потом уже можно строить всё остальное.

И грабить корованы.

> 10. Вменяемый синтаксис, но простой. ... по простым, но гибким правилам...

можно грабить корованы

>11. ОО должно быть маленькой и лёгкой библиоткой...

и грабить корованы.

>12. Замыкания...

должны явно грабить корованы.

>14. и это не должно влиять на общую работоспособность - пусть работает то, что может работать.

И грабить корованы.

Короче, когда тебе вдруг начинает казаться что ты чего-то светлое и крутое придумал ты либо (а) изобрел велосипед, либо (б) у тебя громадные проблемы в образовании.

В твоем посте очень много (б) и некоторое количество (а). Плюс засранность мозгов. Короче, учиться, учиться и еще раз учиться.

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

Здесь всё почти полностью гениально. Потому что за основу взят common lisp.

В его скобках скрыта такая красота дизайна, что почти никто и не догадывается. Однако, на него трижды наведена порча. Первая порча - это синтаксис. Вторая - это стандарт, где урезаны многие важные вещи. Третья - это структурированные типы (записи и классы), которые просто ужасны. В итоге, язык больше годится для красивых прототипов, чем для практической работы. В общем-то, похоже, что легче реализовать заново, чем пытаться исправить (при сохранении багосовместимости и сопротивлении сообщества), хотя кое-что исправить можно.

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

Буду ли я сам это делать? Я надеюсь, что не буду, т.к. дело это тяжелое и не особо благодарное. Потому тему и называется - "язык мечты".

den73 забыл пароль

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

>Первая порча - это синтаксиc.

Чего-то я не понимаю, как у языка, основанного на S-выражениях может быть какой-то другой синтаксис? А если на нравятся круглые скобки - покури насчет SET-MACRO-CHATACTER и SET-DISPATCH-MACRO-CHARACTER.

Пойми, что список, дерево и S-выражение - это разные проявления одной сущности. Затем повторяй до полного просветления: "На лиспе я программирую в терминах AST".

ЗЫ: То что главная проблема лиспа - зажравшиеся вендоры, я с тобой согласен.

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

Синтаксис у языка может быть любой. Тому пример - стандартный в лиспе loop. Также см. http://groups.google.com/group/comp.lang.lisp/msg/68b47f7f1fa78759

> Пойми, что список, дерево и S-выражение - это разные проявления одной сущности. Я это понял лет 8 назад. И что? Месяца два назад я понял, что дерьмовый синтаксис лиспа - это одна из причин, почему на нём нет нормального софта. Нет нормального сборщика. Нет нормального gui. Нет нормального средства рефакторинга. Потому что просто практически на нём работать _неудобно_ . И поэтому производительность труда лиспера, на самом деле, _не_так_уж_высока_ , как это утверждается. Хотя, может быть, в силу склада ума лисперов, они не склонны ничего доделывать до конца (у меня тоже есть такая особенность).

Вендоры как раз не являются проблемой лиспа. Есть, например, три (LL)GPL реализация: clisp, ccl и sbcl - обе вполне приличные. И что? Чему это помогло?

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

den73 забыл пароль

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

>три (LL)GPL реализация: clisp, ccl и sbcl - обе вполне приличные

Нравится мне это слово "вполне" ;) Приличия, увы, в них мало.

>дерьмовый синтаксис лиспа

Еще раз спрашиваю, ты что предлагаешь? У XML синтаксис тоже дерьмовый. У ASN.1 еще более дерьмовее. Но есть ли способ простой и элегантный способ описывать деревья?

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

>Потому что просто практически на нём работать _неудобно_ .

А на нем не надо работать _практически_. На нем надо делать DSL'ы. На нем надо делать кодогенераторы. Тогда и задачи GUI и рефакторинга смещаются несколько в другую плоскость.

Сам я пришел к лиспу исключительно, через DSL'ы. Языка, более подходящего этой задаче нет.

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

По твоей логике достаточно одной операционной системы, одного языка программирования, одной аппаратной платформы...

true_admin ★★★★★
()

выглядит ещё страшнее, чем C++

реквестирую draft, и proof-of-concept в виде неоптимизирующего компилятора (или хотя бы транслятора в CL)

// jtootf

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

> Нравится мне это слово "вполне" ;) Приличия, увы, в них мало

Я бы не сказал, что sbcl существенно хуже lispworks. Плохо в нём, пожалуй, только неумение нормально показывать backtrace и отсутствие GUI дебаггера (хотя это - много). A ccl - это в прошлом коммерческая версися. Мне кажется, он лучше sbcl, но он медленнее и в основном только под маками. Хотя я с ним не работал, но сорсы у него более культурные. В sbcl я уже нашёл пару багов и просто корявостей, а в ccl эти места - чистые.

> У XML синтаксис тоже дерьмовый. У ASN.1 еще более дерьмовее. Но есть ли способ простой и элегантный способ описывать деревья?

У XML синтаксис дерьмовее, чем у лиспа, и намного. Что такое ASN и НХТ, я не знаю. Если речь идёт чисто о деревьях, то ничего лучше лиспа не придумать, пожалуй. Но если речь идёт о метапрограммировании, то код - это далеко не "просто деревья". И если оставаться в рамках этого представления, то далеко не уедешь.

> Еще раз спрашиваю, ты что предлагаешь?

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

> на нем не надо работать _практически_. На нем надо делать DSL'ы.

А что, язык с понятиями "переменная", "функция", "условный оператор", "тип данных", "массив", "строка", "структура" - это не DSL? Это "специфический язык для задач программирования". Вот этого-то DSL в лиспе, по-нормальному, и нету. И вообще, делать DSL - это практическая работа или это сидение в библиотеке с книгой в руках?

> Тогда и задачи GUI и рефакторинга смещаются несколько в другую плоскость.

В основном, они усложняются, но их никто не отменяет. Либо мы делаем на языке какие-то _задачи_, либо нет. Кодогенераторы можно писать на чём угодно, DSL-и - тоже. Пример - это SWIG, написан на С и может гораздо больше, чем любое известное мне средство, написанное на лиспе. Doxygen может больше, чем любой кодогенератор на лиспе. GWT может больше, чем любой известный мне web-фремворк на лиспе, хотя веб - это сплошняком кодогенерация и DSL. Язык должен быть полноценным и среда его тоже должна быть полноценной. В конце концов, это наша работа и мы делаем её ради результата, а не ради крутых концепций.

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

> реквестирую draft, и proof-of-concept в виде неоптимизирующего компилятора (или хотя бы транслятора в CL)

Я ещё не доделал утилиты для asdf, переносимую backquote и pattern-matching на ней, а также примеры работы из лиспа с fuse. Нужно всё же доделать, для очистки совести, выложить в сеть. А потом переквалифицироваться в печника или сборщика бутылок. А то от таких задач можно свихнуться окончательно.

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

>А то от таких задач можно свихнуться окончательно

если draft будет - с удовольствием помогу в реализации proof-of-concept компилятора; хотя, опять же, само описание "языка" восторга не вызвало

// jtootf

anonymous
()

Лисперы иногда забавляют. Для них важна сама теоретическая возможность сделать средствами языка что угодно, а будет ли это на самом деле сделано и введено в обиход - дело десятое. Сразу видно математиков: если знаешь, как решать задачу, решать её уже не интересно. Блин, вы на грешную землю снисходите иногда! Наберитесь смелости и признайте, что CL - реликт окаменевший, и даже у пресвятых S-выражений есть неостатки, и из полноценных лиспов сейчас есть разве что Clojure, остальные годятся только для гиковского самовыражения и для встраивания, в виде Scheme. Нет, будем спорить до замозабвения: лисп труъ, кто несогласен, тот гондон и быдло.

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

>Лисперы иногда забавляют

совсем недавно в другом тереде ты ругал Haskell :) поделись же вселенской мудростью: какой язык нынче пригоден для использования?

// jtootf

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

> совсем недавно в другом тереде ты ругал Haskell :) поделись же вселенской мудростью: какой язык нынче пригоден для использования?

Не путай, я ругаю не Лисп как идею, а нынешние его реализации.

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

> поделись же вселенской мудростью: какой язык нынче пригоден для использования?

Женский.

anonymous
()
Ответ на: комментарий от ero-sennin

> Не путай, я ругаю не Лисп как идею, а нынешние его реализации.

Вот, я тоже советовал посмотреть на Forth, но эти забавные лисперы могут спорить о любых языках, но только если они -- Lisp. :)

anonymous
()

> 1. Одно понятие пространства имён. В "обычных" языках есть пространство имён как namespace, а есть виртуальное пространство имён, которое возникает внутри данного scope. Или пр-во тех имён, которые можно писать после точки, если переменная имеет тип. Обобщить до одного понятия, придать средства управления.

то есть, иерархическая вложенность разных пространств имён, так? "Пространство имён класса" = "его методы и свойства, с учётом наследования". "Пространство имён функции" = "с учётом замыканий, вложенности данной функции". Что-то вроде вложенных друг в друга контекстов, где символ имеет значение только в пределах заданного контекста. В этом смысле указатели не нужны, если мы можем грамотно управлять видимостью контекстов (с учётом замыканий, продолжений, и т.п.). Указатель -- это половина ссылки, без учёта того, откуда именно она ссылается; ссылка -- это двунаправленная связь, два указателя, вторая половина ссылки позволяет адресовать контекст (не какое-то место внутри, а как всю область целиком). Про "средства управления" -- ну а чем не нравятся ленивые бесконечные списки. Если у нас символ может разыменоваться либо в значение, либо в другой символ, либо в пустой список, и этот пустой список прекращает вычисления (как монады, Maybe в Хаскелле, и т.п.)

> 2. Паскаль - порядка 10000 строк в секунду. Хороший мальчик. Синтаксис должен быть простым для компьютера и читаемым для человека.

Но минус синтаксиса Паскаля -- читать просто, писать напрягает, многословный вельми.

> 3. Сборку мусора - в мусорное ведро вместе с JIT.

сдаётся, изобретаешь велосипед "статический GC". "Декларации и выводы из них" -- да, можно, если тебе хватит статического управления памятью, не в рантайме (то есть, всё управление памятью однозначно понятнов compile-time). Например, WEB в TeX (тот же паскаль, ага). Например, добавить туда ссылки с описанием типов, как в Cyclone. Например, почитать про указатели и ссылки вот здесь http://lib.ru/CTOTOR/XERION/xerion.txt и правила допустимости приведения. Например, додумать ту идею с вложенными контекстами, и "дешевыми и сердитыми" замыканиями, как scope + делегаты в D (где-то в ньюс-группах или в бложике на тему D была идея: берем функцию-делегат с параметрами замыкание, другой делегат. Второй вложенный делегат при вызове на стеке получает адрес своего контекста в "своих переменных", и адрес охватывающего контекста в адресе из стекового фрейма первого делегата. Вот он, контекст, в котором работает замыкание. Там что-то с тонкостями было, поищу ссылку). "Статический GC" -- где он не работает? JIT -- то же самое, относительно оптимизации вызовов методов, а не управления памятью. Беда не в том, что GC "динамический", а в том, что он не управляемый. Поэтому нужно 2-3 РАЗНЫХ алгоритма GC + ручное управление, и чтобы язык подсказывал, какой алгоритм GC лучше всего для этой задачи подходит.

anonymous
()

Блин, занялись бы чем-нибудь практическим... реанимировали Cyclone, допилили tize для Питона...

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

> допилили tize для Питона...

что это?

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

>> допилили tize для Питона...

> что это?

Слабая попытка сделать Питон статически типизированным.

>> реанимировали Cyclone

> а зачем, если есть Хаскелль?

Потому что Хаскель уже есть, а ядер ОС на нем всё еще нет.

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

>Потому что Хаскель уже есть, а ядер ОС на нем всё еще нет

4.2

погугли House Haskell OS, L4.verified

// jtootf

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

>Что такое ASN и НХТ, я не знаю.

Ай-ай-ай. У гугла спроси.

>код - это далеко не "просто деревья".

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

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

>А что, язык с понятиями ... это не DSL?

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

>Пример - это...

SWIG - это DSL, GWT - если ты про Google Web Toolkit - eDSL, Doxygen - кодоанализатор. И тот факт, что они написаны не на лиспе совершенно не умаляет его достоинств. Скорее показывает правильность концепции DSL.

Macil ★★★★★
()

> 4. Язык должен быть сначала императивным, а потом уже можно строить всё остальное. Для функциональщиков покатит декларация pure. Если в функции f вызываются только чистые функции, то и сама эта функция чиста. Значит, декларацию pure легко проверить на этапе сборки. Соответственно же, декларации const тоже можно проверить (это ещё С умеет делать).

что-то подобное Александреску хотел в D2 делать.

> 5. Встроенный тип variant. Один, а не 10, как в "некоторых других языках".

зачем, какой в нем смысл в статическом языке (точнее, только в статическом какой-то смысл и есть). Какой смысл делать в языке то, что можно сделать в библиотеке. Почему это должно быть в языке. Почему это вообще должно быть, чем не хватает auto f = .. и type inference.

> 7. Конечно же, генерация исполняемого кода в рантайме. Можно через .so, как GCL.

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

> 6. Макросы не хуже лиспа. А иначе - какой смысл.

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

> 10. Вменяемый синтаксис, но простой. Представление code=data - это промежуточное представление. Для человека оно преобразуется по простым, но гибким правилам.

like what? Бери http://en.wikipedia.org/wiki/Category:Extensible_syntax_programming_languages

и смотри любой, например, http://en.wikipedia.org/wiki/XL_(programming_language) или http://www.program-transformation.org/Stratego/MetaProgrammingWithConcreteObj...

или http://www.program-transformation.org/Stratego/TheDryadCompiler (и синтаксического сахара понасыпь) . Или http://www.program-transformation.org/Stratego/RhoStratego .

> Для человека оно преобразуется по простым, но гибким правилам.

Опять таки, чем не нравится хаскелль с монадическими комбинаторными парсерами.

> 12. Замыкания... Наверное, состояние в них должно быть явным.

монада состояний, да.

> 13. Встроенный codewalker.

что это за штука? как работает?

А вообще, смысл в таком языке? Какую задачу должен решать? Просто "детище Франкенштейна"?

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

> Первая порча - это синтаксис.

Dylan более читабелен.

> Третья - это структурированные типы (записи и классы), которые просто ужасны

чем?

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

> Чего-то я не понимаю, как у языка, основанного на S-выражениях может быть какой-то другой синтаксис?

да может, какая проблема. Как с выражениями в инфиксной/префиксной записи. Как питоноподобный Dylan. Взять и тупо заменить readtable -- вот и другой синтаксис.

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

> У XML синтаксис тоже дерьмовый. У ASN.1 еще более дерьмовее. Но есть ли способ простой и элегантный способ описывать деревья?

вот у Терри Перенса в ANTLR есть Tree Grammars, например.

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

> Сам я пришел к лиспу исключительно, через DSL'ы. Языка, более подходящего этой задаче нет.

утверждение спорное. А кодогенератор в стиле autotools, безо всякой обратной связи, и нагенерированный код исполняется сам по себе, в виртуальной волшебной среде? Тогда вопросов нет. А если такую среду надо построить, то и Хаскелль с монадами для управления ресурсами и парсинга вполне сгодится. Подходит может быть и лучше.

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

>Потому что Хаскель уже есть, а ядер ОС на нем всё еще нет.

внезапно нашёл ещё одно:

http://www.ninj4.net/kinetic/

оно, конечно, игрушечное; но сам факт что ядро ОС на хаскеле написать не сложней игрушки чего-то да стоит ;)

// jtootf

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

>>Потому что Хаскель уже есть, а ядер ОС на нем всё еще нет

> 4.2

> погугли House Haskell OS, L4.verified

"The L4.verified project is developing a mathematical proof that the seL4 microkernel does exactly what it is intended to do."

"The bottom level of the verification and of the refinement picture is a high-performance C and assembly implementation of the seL4 microkernel. The next level up, the low-level design, is a detailed, executable specification of the intended behaviour of the C implementation. This executable specification is derived automatically from a prototype of the kernel, developed in the seL4 project. The prototype was written in the high-level, functional programming language Haskell."

Где тут ядро на Хаскеле? Спецификация - на Хаскеле.

House - уже гораздо ближе к делу, но игрушка ("demo"). Больше всего напоминает Movitz.

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

> оно, конечно, игрушечное; но сам факт что ядро ОС на хаскеле написать не сложней игрушки чего-то да стоит ;)

Это не "оно", это игрушка. Кстати, какой процент GHC runtime состоит из Си-кода?

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

> Чего-то я не понимаю, как у языка, основанного на S-выражениях может быть какой-то другой синтаксис?

Таунсенд К., Фохт Д.Проектирование и программная реализация экспертных систем на персональных ЭВМ: Пер. с англ. В. А. Кондратенко, С. В. Трубицына. — М.: Финансы и статистика, 1990. — 320 с.

http://www.forth.org.ru/~kp/taunsend.zip

Смотри, например, главу 7 "Обработка списков".

P.S. Распознан тест не очень, но понять, о чём там можно.

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

> Doxygen - кодоанализатор.

просто документацию, не class browser можно сделать и на каком-нибудь Weave + wiki (txt2tags). Например, в MBase есть очень простой weave на лиспе, и ничего, документация составляется.
Code coverage более хитрый, но ЕМНИП, тоже можно: см. http://hydra.nixos.org , там что-то подобное buildbot+codecoverage. Как бы не на функциональщине оно и написано.

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

>Где тут ядро на Хаскеле?

наверное, здесь: http://programatica.cs.pdx.edu/House/

> Спецификация - на Хаскеле.

Проверяемая компилируемая спецификация и ядро -- это single source document. Как doxygen, как wiki.

> но игрушка ("demo").

а это пофиг. Главное, что спецификация L4 проверяемая. И любая ОС по этой спеке, хоть на хаскелле, хоть на D каком-нибудь будет проверяемая. Потом приложения из "игрушечной" Хаскелль ос можно будет перенести на нормальный Pisctaschio, и всё заработает. Или на сертифицированный OK4L.

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

>Где тут ядро на Хаскеле? Спецификация - на Хаскеле

>The prototype was written in the high-level, functional programming language Haskell

прототип. который автоматически траслировался в Isabelle/HOL и верифицировался. где ты тут слово "спецификация" увидел?

>House - уже гораздо ближе к делу, но игрушка ("demo"). Больше всего напоминает Movitz

ну, ты не просил production-level, ты просто констатировал отсутствие. как видишь, это 4.2 - ядра есть, прецедент создан, вывод - Cyclone не нужен. кстати, какие ядра на нём написаны? именно на нём, не на C (который он генерирует)?

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

>Кстати, какой процент GHC runtime состоит из Си-кода?

а это ты троллишь или шлангуешь? ;)

// jtootf

// в комменте про Isabelle/HOL забыл подписаться, но это тоже был я

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

Анонимный брат, ты смешал в кучу 3 проекта.

>Главное, что спецификация L4 проверяемая. И любая ОС по этой спеке, хоть на хаскелле, хоть на D каком-нибудь будет проверяемая.

AFAIU на Хаскеле делается прототип, из прототипа - спецификация. Си-реализация _не генерируется_.

Впрочем, хотя это всё очень интересно, это не делает ОС на Хаскеле реальной.

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

>> Кстати, какой процент GHC runtime состоит из Си-кода?

> а это ты троллишь или шлангуешь? ;)

Это я как бэ намекаю, что мне нужен язык на замену Си, а не на замену Хаскелю (который сам без Си обойтись не может). Троллинг это или шлангование - решай сам :D

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

>Впрочем, хотя это всё очень интересно, это не делает ОС на Хаскеле реальной

но некоторые плюсы ФП в данной области видны, не? уже хотя бы объём этого самого прототипа и простота трансляции в Isabelle/HOL - что даёт ту самую верифицируемость, которую так любит, например, Шапиро; и которой так не хватает (не хватило) в HURD

чего же тебе не хватает? production-level ядра на Haskell?

// jtootf

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

>Смотри, например, главу 7 "Обработка списков".

Те же яйца, только в профиль. Даже в хаскеле с помощью стрелок понятнее.

Macil ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.