> На самом деле в HW на Си объяснить всю цепочку от printf до сисколла сможет не каждый

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

>> Qi. Это набор макросов к CL? Подмена readtable или еще чего-то?

Другой парсер (ридтейбл) для того же компилятора и рантайма.

Напоминает Си++^WМодулу-3 :)

> Что конструкторы/дестукторы будет в каждой функции из трех строк дергать ядро своими new/delete?

Лолчто?

> Или cast вообще не нужен? Если не нужен, то как реализовать паттерн наподобие ациклического визитора?

1. Просто визитор реализуется без динамик_каст

2. Ациклический визитор вместо статического объявления незавершенного класса юзает динамик_каст. Ахренеть как умно.

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

не знал. но мне это и не надо — достаточно 2-3 бит.

Достаточных 2-3 бита в 32-битном SBCL будут помещены в регистр ;)

1. молча не оторвет у меня 2-3 бита на тайптег, и еще вдобавок разное количество бит в зависимости от опций компиляции :-)

А как на счёт размеров типов? Если у тебя платформа в принципе не поддерживает атомарных 32-битных машинных слов, то все предположения об оптимальности исполнения окажутся неправильными.

2. молча не добавит нафиг мне *здесь* не нужную проверку на переполнение (и затем оперирование длинными числами, как питон)

Объявляй (safety 0) и тип результата.

> Спрятать все потенциальные бесконечности в неведомую е***ую х**** под названием «свободно становящая последовательность» — это лишь уход от проблемы, а не ее решение.

они там не прячутся, во всяком случае я не вижу в этом необходимости

> А как на счёт размеров типов? Если у тебя платформа в принципе не поддерживает атомарных 32-битных машинных слов, то все предположения об оптимальности исполнения окажутся неправильными.

значит будут 32-битные двойные слова

атомарность не нужна — у меня все в 1 поток

> Объявляй (safety 0) и тип результата.

это вы с zubok умные, я love5an убеждал меня, что по-другому (32 бита) нельзя, и глянь — у него код

(declaim (optimize (speed 3) (space 0) (safety 0) (debug 0)))

http://www.linux.org.ru/jump-message.jsp?msgid=4254952&cid=4256112

s/я love5an/а love5an/

>Лолчто?

Тот не смеяться, а плакать надо от убогости данного поделия.

>Просто визитор реализуется без динамик_каст

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

> я требую доступ к shl, add без проверки переполнения, которые есть в железе уже 40-50 лет.

Это не имеет никакого отношения к собственно исключениям.

> Новый код ломает старый код. Это губит весь дух полиморфизма т.к полиморфизм затевался именно для избегания подобных вещей.

Думаю что не ломает. Т.н. expression problem решается на C# без перекомпиляции (не знаю, решается ли на яве) — а там примерно та же проблема.

На с++ для повторения 1 в 1 не хватает стирания типов, но думаю можно руками сделать. Было бы поучительно.

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

Вообще-то, я надеюсь, что лисп будет обгонять Си++ на таком тесте с исключениями. Мне интересно получить подтверждение. Для этого нужно просто переписать плюсовый код и поставить его в равные условия с лисповым. Я прав?

> Для этого нужно просто переписать плюсовый код и поставить его в равные условия с лисповым. Я прав?

нет, перепиши лисповый код, чтобы он не тормозил

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

Там нет речи о бесконечных множествах и не может идти. Видимо, ты неправильно определение понял. Бесконечные множества есть в других определениях в-венных чисел, например, через сечение Дедекинда. Это когда каждое в-венное число представляется, как рассечение множества рациональных чисел на два.

кстати, если это поможет скорости, переменную х можно перенести из глобальных в функцию мейн (в лиспе)

и вообще — я открыт к такого рода предложениям

> 1. От какой проблемы?

От проблемы актуальной бесконечности в теории множеств. man парадокс Рассела.

2. Чем «бесконечное множество точек» _принципиально_ лучше?

Не понял вопроса. Где речь вообще про точки была? Мы уже про геометрию говорим?

> они там не прячутся, во всяком случае я не вижу в этом необходимости

Жаль, очень жаль.

> Там нет речи о бесконечных множествах и не может идти.

?

Как ты можешь определить произвольное вещественное число конечным образом/процессом/...? Ведь множество конечных последовательностей из N всего лишь счетно.

> От проблемы актуальной бесконечности в теории множеств. man парадокс Рассела.

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

правильнее было бы сказать «не избавились»

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

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

> Новый код ломает старый код. Это губит весь дух полиморфизма т.к полиморфизм затевался именно для избегания подобных вещей.

я выступлю немного за тебя:

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

и от себя:

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

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

Визитор - это костыль для эмуляции частного случая мультиметода, где одним из параметров выступает иерархия сущностей, а вторым - иерархия методов обработки этих сущностей. Я его привел чтобы не объяснять лишний раз зачем вообще нужны мультиметоды. Диспетчеризация по двухмерной vtbl займет O(1), а если попытаться как-то сэкономить память на NULL-ах, то получится наверно что-то около O(log N).

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

сдаётся мне, что это счётное множество, соответственно оно меньше континуума

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

Немножко вот тут есть: http://sbcl-internals.cliki.net/index

Спасибо!

Кто-нибудь использует CMUCL? и зачем?

А покажите эти ваши лисповые мультиметоды, чисто ради интереса может я попытаюсь их реализовать =)

[code=lisp] (defgeneric beat (drum stick) (:documentation «Produce a sound by hitting the given drum with the given stick.»))

(defmethod beat ((drum snare-drum) (stick wooden-drumstick)) ...) (defmethod beat ((drum snare-drum) (stick brush)) ...) (defmethod beat ((drum snare-drum) (stick soft-mallet)) ...) (defmethod beat ((drum tom-tom) (stick wooden-drumstick)) ...) (defmethod beat ((drum tom-tom) (stick brush)) ...) (defmethod beat ((drum tom-tom) (stick soft-mallet)) ...) [/code]

Спасибо =)

А чем это отличается от статической перегрузки функций кроме того, что делается в рантайме?

>>Да вот на схеме вроде бы можно всегда писать в чистом ФП-стиле и быть уверенным что из-за исчерпания стека оно никогда не вылетит. На CL если алгоритм по сути не рекурсивный и для его реализации не подходит конструкция типа map или reduce, то лучше цикл нарисовать.

это не так.

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

>А чем это отличается от статической перегрузки функций кроме того, что делается в рантайме?

Для статической перегрузки нужно чтобы статический тип барабана и палочек был известен внутри функции вызывающей beat. Для этого нужно заинклудить все барабаны и все палочки в единицу компиляции где вызывается beat и сделать все функции вызывающие beat шаблонными и зависимыми от типов drum и stick. Так пишут только @#даки.

> Видимо, ты неправильно определение понял.

Да, верно. Я понял как раз как сечение Дедекинда.

От проблемы актуальной бесконечности в теории множеств. man парадокс Рассела.

Не вижу прямой связи. Каким боком определение числа и числового континиума связано парадоксом включения множества в самого себя?

Где речь вообще про точки была?

Разумеется имел в виду числа. «Точки» - это тлетворное влияние топологии.

связано с парадоксом

Узнаю старину лора

ВОТ ТЕПЕРЬ ЛОР ТОТ!

>А в чем смысл притягивать за уши рекурсию если задача сводится к какому-нибудь книжному итеративному алгоритму

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

>при использовании минимизируется использование состояния, т.е. нет лишних деталей.

Состояние состоянию рознь. Если ты деструктивно меняешь какую-то совместно используемую структуру то сразу имеешь минус реентерабельность и минус потокобезопасность. А локальные счетчики и аккумуляторы на надежность не влияют.

что плохого?

Ранняя «пессимизация».

>> CL - это не ФП.

нет. чего не хватает до статуса «есть ФП»?

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

> Не вижу прямой связи. Каким боком определение числа и числового континиума связано парадоксом включения множества в самого себя?

Историческим.

Да, Qi — это сильно мутировавший CL. Настолько изменившийся в результате мутации, что некоторые принимают его за отдельный язык.

>> нет. чего не хватает до статуса «есть ФП»?

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

TCO тут вторично. Вот clojue считается ФП или нет? А в нем ведь нет TCO. (а оператор recur из clojure в CL можно реализовать макросом поверх tagbody & go). Зато есть, например, иммутабельные структуры данных.

В этом смысле C++ ближе к ГМО.

>А в нем ведь нет TCO.

Мне recur даже больше понравился, чем хвостовая рекурсия. И делает тоже самое и читабельные и не надо думать (и знать) про TCO. Когда в стандарте языка предписываются всякие оптимизации это уже от лукавого.

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

Когда в стандарте языка предписываются всякие оптимизации это уже от лукавого.

Согласен. Правильно было бы, вместо указывания TCO в стандартах, во всех учебниках по C++ (и некоторым другим языкам) большими красными буквами писать «НЕ ИСПОЛЬЗУЙТЕ РЕКУРСИЮ В ЭТОМ ЯЗЫКЕ!!!!111».

Т.е. проблема более не актуальна?

>я love5an убеждал меня, что по-другому (32 бита) нельзя

Сдвиг без каких-то проверок (как в приведенных выше дампах) возможен только потому, что целый тип маркируется нулями в младших 2-х битах числа. Поэтому можно спокойно двигать влево, не боясь, что младшие биты «засорят» результат и не боясь, что наличие этих tags как-то замедлят операции. А вот сдвиг вправо, например, засорит результат, поэтому биты эти стирают потом при помощи AND. 32-битное число все-равно интерпретируется как 29-битное. Чтобы увидеть это, достаточно в код добавить logand с каким-то числом. В ассемблерном коде для (logand x 256) мы увидим AND EAX, 1024, например. Такие дела.