Цитата

---

что подразумевается под локальными продолжениями и какая связь с циклами? Циклы ведь безо всяких продолжений делаются.

---

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

(define (test n)

  (let ([foo (lambda(a) (if (zero? a) 

                            (raise a)

                            (add1 a)))])

    (with-handlers ([integer? (lambda(exc) (zero? exc))]

                    [boolean? (lambda(exc) exc)])

      (if (> n 1)

          (raise #f)

          (test (foo n))))))

Цитата

---

Если + не переопределен то его вообще должен джит заинлайнить.

---

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

Цитата

---

misha :
2) Написать черновой стандарт kernel языка (с примитивными макросами) в общем виде.
3) Запилить транслятор kernel языка на одном из существующих диалектов Лиспа. Пусть пока будет генерировать только код на ассемблере LLVM.
4) Добавление в стандарт FFI.
5) Пересмотреть черновой стандарт kernel языка.
6) Привести транслятор kernel языка в соответствие с текущим стандартом.
7) Повторение 4 и 5 пунктов до тех пор, пока в этом есть необходимость(см. пункт 8 )
8.) Переписать транслятор на kernel языке.
9) Повторить пункты 5 и 6, 7.
и т.д.

---

Я вижу в таком подходе следующие проблемы:
1) Писать стандарт до реального кода мне кажется пустой затеей, т.к. всего заранее не учтешь, главное иметь общее направление, и предварительный стандарт не избавит от большей части проблем при разработке. Тем более, что стандарт скорее всего будет сильно изменен по результатам предварительного использования языка.
2) Зачем его пилить на динамически-типизированном Лиспе с неотключаемым сборщиком мусора не очень понятно. Что я получу? Макросы, которые мне не пригодятся, т.к. вся система будет переписана на kernel language в последствие? Отсталые и заброшенные байндинги к ЛЛВМ, плюс всю низкоуровневую работу через непрозрачный FFI?

Если я пишу на Сях, то большая часть из того, что я напишу прямиком переезжает в конечный вид системы и переписывать многие вещи в общем совсем не обязательно, их можно просто линковать хоть в динамике (таким, например образом планируется поставлять различные runtime environments + стандартные библиотеки, да и любые другие библиотеки). К тому же, т.к. система типов Си это практически надстройка над системой типов LLVM, то FFI к сишному коду может и должен быть сделан абсолютно прозрачным.

3) Если я использую сишную либу например с реализацией сборщика мусора, хеш таблиц или там веревочных строк, то я могу просто оставить эту библиотеку как есть в kernel language в виде .lib или .so/.dll, в случае же с Лиспом мне придется всё переписывать, т.к. вытащить эти куски из реализации Лиспа не вижу никаких возможностей.

4) Кроме того, разработчиков на Сях найти на порядок проще, а я планирую привлечь кого нибудь к реализации, т.к. своего свободного времени просто не достаточно на такой проект.

Цитата

---

Kergan :
Речь шла о трансляторе, а не о вм же. В этом плане высокоуровневый язык явно лучше сишки - т.к. никакие причины интероперабельности уже не работают и кроме того все равно в любом случае придется переписывать компилятор, т.к. бутстрап. Так что для до-бутстраповой реализации сишка действительно нафиг и не нужна - это все равно будет прототип, так что надо брать ЯП удобный именно для прототипирования. Лисп в том числе подойдет. А сишка будет явно не лучшим выбором. А статическая типизация уж только помешает.

---

Я собственно о компиляторе+ВМ и писал.

Бутстрап-бутстрапом, а переписывать все с нуля на kernel language это плохая идея -- есть сотни уже готовых и проверенных реализаций всего подряд, такие вещи достаточно скомпилировать в LLVM bitcode из Сишечки и использовать их как есть. Потом, возможно, их и стоит переписать, но далеко не первым пунктом.

Да и ещё раз повторюсь: какой прок от высокоуровневого языка, если его возможности не будут использованы практически никак -- какая разница из какого языка дергать LLVM API? Тут даже С++ был бы более предпочтительным, а если байндинги к Окемлу хороши, то он.

Ладно, на чем пишем -- CL, Racket, Haskell, Ocaml, Java, C#, whatever?

Ок. Значит будет CL. Заодно подтяну знание языка.

Цитата

---

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

---

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

Цитата

---

2) Зачем его пилить на динамически-типизированном Лиспе с неотключаемым сборщиком мусора не очень понятно. Что я получу? Макросы, которые мне не пригодятся, т.к. вся система будет переписана на kernel language в последствие? Отсталые и заброшенные байндинги к ЛЛВМ, плюс всю низкоуровневую работу через непрозрачный FFI?

---

Ну макросы тоже могут быть написаны на kernel, ведь никто вам не запрещает реализовать транслятор с kernel на лисп. А байндинги к ЛЛВМ вам на этой стадии вообще не нужны. Вам главное научиться создавать правильный код.

Цитата

---

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

---

Без наличия готовой вм про динамику забудьте.

Цитата

---

3) Если я использую сишную либу например с реализацией сборщика мусора, хеш таблиц или там веревочных строк, то я могу просто оставить эту библиотеку как есть в kernel language в виде .lib или .so/.dll, в случае же с Лиспом мне придется всё переписывать, т.к. вытащить эти куски из реализации Лиспа не вижу никаких возможностей.

---

А вам это и не потребуется.

Цитата

---

4) Кроме того, разработчиков на Сях найти на порядок проще, а я планирую привлечь кого нибудь к реализации, т.к. своего свободного времени просто не достаточно на такой проект.

---

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

Цитата

---

А я и не писал, что это так просто

---

так речь не о том что это просто, а о том, что это невозможно. то есть такую оптимизацию производить запрещено (хоть и не сложно ).

Цитата

---

Если поступите как я предлагаю, то вам не придется дергать LLVM API из лиспа.

---

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

Я тут наткнулся на интересную мысль:

Цитата

---

Цитата

---

Есть еще Nemerle.

---

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

---

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

--

Смотрел недавно ещё раз на язык Julia, и подумал, что в нем есть практически все, что нужно, кроме двух больших различий:
1) В Julia динамическая типизация. Я если честно не понимаю почему они не реализовали статическую? Теперь на динамике они пытаются выжать скорость C++ путем всяких хитрых оптимизаций. Не очень понятно это просто фейл или это осознанное решение, мотивы которого хотелось бы знать.
2) В документации они пишут, что Julia гомоиконна. Тогда зачем было городить синтаксис, чем не устраивали s-exp? Просто прихоть? Или это нашлепка вида макроса чтения, чтобы синтаксис не отпугивал Лиспофобов? Насколько в реальности такая нашлепка необходима (хотя бы в виде тех же Sweet-expressions) для распространения языка за пределы Лисп-комюнити? И чем в реальности отсутствие s-exp осложнит написание макросов, например? В Julia всё выглядит достаточно пристойно.

--

Что-то не ладится у меня с Common Lisp, меня почему-то от него подташнивать начинает, как только начинаю на нем писать. Я просто уже достаточно долго пытаюсь его освоить по-нормальному (с Emacs'ом в нагрузку), но после небольшого перерыва написания на нем постоянно приходится открывать HyperSpec с целью поиска нужной функции в этой адской кипе. Да и байндинги к LLVM'у у него все таки устаревшие -- версия 3.1 не поддерживается.

В общем, остается C++, видимо.

Цитата

---

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

---

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

Цитата

---

Смотрел недавно ещё раз на язык Julia

---

Ну тогда уже mathematica лучше взять - это больше похоже на то, что мы обсуждаем.

Цитата

---

Да и байндинги к LLVM'у у него все таки устаревшие -- версия 3.1 не поддерживается.

---

вот кстати есть какие-то для racket:
https://github.com/shekari/racket-llvm

я не в курсе правда, в каком они состоянии, но примеры там забавные.

а вот даже автор их использует для написания своего компилятора, так что можно посмотреть как оно используется на менее игрушечных задачах, чем в examples:
https://github.com/shekari/tiger

Цитата

---

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

---

Ну я так понимаю можно и "отматывать назад" раскрытие макросов (с помощью дополнительных меток выставляемых при раскрытии макросов) с целью представления более внятного сообщения об ошибке, как например делает какой-нибудь clang по отношению к макросам Си?

Цитата

---

Kergan :
Ну тогда уже mathematica лучше взять - это больше похоже на то, что мы обсуждаем.

---

Посмотрю.

Цитата

---

Kergan :
вот кстати есть какие-то для racket:
https://github.com/shekari/racket-llvm

я не в курсе правда, в каком они состоянии, но примеры там забавные.

а вот даже автор их использует для написания своего компилятора, так что можно посмотреть как оно используется на менее игрушечных задачах, чем в examples:
https://github.com/shekari/tiger

---

Спасибо, попробую Racket.

Мне тут мысль пришла, что возможно Common Lisp это не локомотив распространенности Лиспов, как его пытаются представить, а собственно его тормоз, т.к. отпугивает своей монструозностью, загораживая элегантность и простоту Лиспов вообще. Читал просто SICP, так все примеры реализации там просты и понятны, то же самое на CL будет выглядеть как Си++ на шаблонах.

> Получается, что без S-expr'ов гомоиконность в принципе теряет свои преимущества

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

А та "гомоиконность" о которой обычно говорят (возможность квазицитирования и т.п.) она по факту ничего не дает, потому что в этом смысле любой язык гомоиконен (или его можно сделать гомоиконным малым допиливанием). Все это имеет смысл только в том случае, если есть поддержка со стороны синтаксиса.

Цитата

---

Ну я так понимаю можно и "отматывать назад" раскрытие макросов (с помощью дополнительных меток выставляемых при раскрытии макросов)

---

Не совсем понятно как что отматывать. У нас в макросах могут и сайд-эффекты быть.

Цитата

---

Посмотрю.

---

просто mathematica (ее ЯП всмысле) де-факто и есть диалект лиспа

Цитата

---

Спасибо, попробую Racket.

---

Ежели будете писать на racket готов помочь в написании

Цитата

---

Мне тут мысль пришла, что возможно Common Lisp это не локомотив распространенности Лиспов, как его пытаются представить, а собственно его тормоз, т.к. отпугивает своей монструозностью, загораживая элегантность и простоту Лиспов вообще. Читал просто SICP, так все примеры реализации там просты и понятны, то же самое на CL будет выглядеть как Си++ на шаблонах.

---

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

Цитата

---

Точно. Форт классная штука. Можем ли мы, вообще говоря, считать, что синтаксис Форта это просто другая запись S-выражений? Точнее, что оба варианта записи позволяют записывать иерархическую структуру? Мы же всегда по идее можем переписать sexp в виде обратной польской записи, типа:

---

sexpr в обратную польскую нотацию можем, да, но вот наоборот - не всегда, т.к. могут быть слова с динамическим стек-эффектом.Например можно написать слово, которое суммирует то, что лежит на стеке до тех пор, пока сумма не станет больше 10. И если мы напишем 1 2 3 4 5 6 7 sum>10 то перевести в секспр у нас это не выйдет.

Цитата

---

Присматриваюсь. Пока всё выглядит классно, я даже начал думать, что зря столько времени убил на CL+Emacs.

---

Вообще racket c emacs тоже можно использовать (geiser), но Dr.Racket и так довольно неплоха, да.

Цитата

---

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

---

Готов помочь и в том и в том.

Цитата

---

Почему, к примеру, в Racket не сделать что-нибудь типа #lang cl, не так уж и нужно видимо всё, что CL тащит?

---

Ну тут во-первых да - это просто ненужно. Во-вторых - у CL весьма сильно отличается семантика рантайма. В рамках #lang cl (то есть внутри модуля) ее реализовать нельзя (точнее можно, но по сути мы не сможем реиспользовать уже существующие части рантайма Rakcet, то есть придется практически с нуля реализовать рантайм CL). Короче реализация либо будет неэффективной, либо потребует очень много трудозатрат, либо будет неполной, либо будет плохо вписываться в экосистему Racket (то есть будет висеть в топлевеле, что нехорошо). В общем что называется "овчинка выделки не стоит". Слишком это будет сложно, а необходимости - нет.

> Ещё вопрос про Racket: посмотрел бенчмарки SBCL/Racket и обратил внимание, что Racket медленнее. С чем это связано -- это какие-то внутренние особенности ВМ/рантайма/языка или просто не уделяли столько времени оптимизации как в CMUCL/SBCL?

Ну, во-первых, у Racket не такой уж хороший jit - то есть даже если прикрутить тот же jit от llvm уже будет выигрыш в производительности (и весьма значительный). Во-вторых, в Racket намного более навороченный рантайм - это, естественно, требует определенных накладных расходов. В-третьих, есть какие-то непонятки у меня с производительностью сборки мусора (я не в курсе как конкретно устроен сборщик мусора, но вполне возможно что он иногда тормозит из-за навороченности рантайма в том числе). В-четвертых максимум чем может управлять программист на Racket - это компиляцией в байткод, который очень высокоуровневый (фактически байткод является тем же самым что и full-expanded код, только он закодирован, то есть сделан более компактным). SBCL же предоставляет гораздо более низкоуровневые средства - начиная от деклараций типов и заканчивая генерацией VOP'ов. В результате если сравнивать, скажем так, обычный код (то есть без каких-то хитрых оптимизаций и всего такого), то обычно все идет наравне, а вот если делать жуткие оптимизации то SBCL выигрывает за счет большего потенциала в области этих самых оптимизаций. То есть средств оптимизации больше. Но в этом случае код начинает выглядеть воистину ужасно - проще написать все на плюсах. Будет и понятнее и быстрее. Ну и да, PLT team не уделяет какого-то особого внимания именно скорости работы, они считают что производительность должна быть "достаточной", и в сущности она действительно достаточна для тех задач, где можно применять языки вроде Racket.

Цитата

---

Ещё, правильно ли понимаю, что Typed Racket это динамически типизированный язык, а метки типов служат только для проверки тайп чекером во время компиляции и исполнения?

---

Не во время компиляции даже а во время экспанда. После экспанда (во время которого и происходит тайпчек) получается тот же самый динамический full-expanded код. Единственное что чекер при экспанде заменяет там где может safe операции на их unsafe аналог. Например если вы пытаетесь получить значнеие поля структуры то по дефолту надо проверить, а является ли аргумент инстансом соответствующей структуры. Если типизация статическая, то проверку можно опустить - соответственно операция меняется. Ну или если вы складываете два флоата или фикснума, то в статике точно известно что это будут флоаты или фикснумы и можно сразу заинлайнить нужную операцию, а не вызывать полиморфную, которая сперва проверит тип аргументов, а потом вызовет, что надо. Ну и т.д.
Собственно там даже есть такая кнопочка "optimizations coach" - она подсвечивает все места в которых оптимизация такого рода (с заменой на unsafe-операции) выполнена, либо может быть выполнена (и даются подсказки как сузить тип для ее выполнения).

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

Цитата

---

Kergan :
ЗЫ: да, учитывая, что падает именно на тесте с пробелами, а все остальное отрабатывает нормально, именно в этом ошибка и состоит.

---

Спасибо, помогло.

Цитата

---

Kergan :
ЗЫЫ: старайтесь не использовать all-defined-out

---

Ну это понятно.

--

А в схеме нет простого (return a) или (break a), чтобы из функции выйти? Или надо брать текущее продолжение и его дергать?

Цитата

---

Kergan :
нет, нету.

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

ЗЫ: в 3.5.1 для for-ов сделали кейворд #:break.
ЗЫЫ: вообще понятно, что классический return в схеме просто не имеет смысла - циклы делаются через рекурсию, а сквозь рекурсию return возвращать не умеет.
ЗЫЫЫ: вообще если вам хочется сделать break или return - значит что вы делается что-то неправильно.

---

Ну, если неправильно это значит "не так как у нас принято", то да. Ладно, не суть, я просто не знал, что Racket wanna be pure functional.