Здравствуйте, thesz, Вы писали:
T>Да брось ты! T>При написании кода с глубоким заглядыванием наподобие нижеприведённого:
... T>Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки.
1. А где (EMul b (EConst c), EConst a) -> ?
Вот тебе баг и язык тебе никак не помог — ибо прекрасно компилится без этой ветки, в которой выход на вторую половину ситуаций.
2. Еще косяки:
const1 * var1 * var2 * var3 * const2 — оптимизация возможна, но не будет произведена.
const1 * (var1 * const2) — оптимизация невозможна, но будет произведена.
В общем, подобной задачкой я занимался в своей жизни неоднократно, приведённый код никуда не годится, ибо, при обработке арифметических и логических выражений не следует использовать бинарные AST, тут нужен банальный список одноуровневых аргументов.
3. Почему izzero и иже с ним проверяется после EConst? (просто любопытно)
4. На системе типов С++ прекрасно делается на частичной специализации.
Букв будет гораздо больше, в основном всвязи с тем, что в С++ шаблонность типов и ф-ий явно аннотировать надо, а в Хаскеле всё шаблонное по-умолчанию.
T>Или вот другой пример: T>
T>-------------------------------------------------------------------------------
T>-- Balin's pipelined sum acc.
T>balinF :: Maybe i -> Maybe i -> Maybe i -> (Maybe i,Maybe (i,i))
T>balinF oldAcc input loopback = (newAcc,output)
T> where
T> (newAcc,output) = case (oldAcc,input,loopback) of
T> (acc,Just inp,Just lb) -> (acc,Just (inp,lb))
T> (Just acc,Nothing,Just lb) -> (Nothing,Just (acc,lb))
T> (Just acc,Just inp,Nothing) -> (Nothing,Just (acc,inp))
T> (acc,Nothing,Nothing) -> (acc,Nothing)
T> (_,inp,Nothing) -> (inp,Nothing)
T> (_,_,lb) -> (lb,Nothing)
T>
T>Сумматор имени Влада Балина aka Gaperton, функция автомата Мили. Что, сможешь сделать такую же таблицу решений? А в такое же количество строк?
Можно саму постановку задачи или пример использования этого кода?
В любом случае, уже сейчас видно, что основную логику в сравнимое кол-во строк впихнуть можно.
В хаскеле не спец, так что еще вопросы:
— что за Just?
— откуда в этой задаче ожидается Maybe/Nothing?
T>Я не понял твоего абзаца практически совсем. T>Он не несёт никакой информации. Что за наука? Что за шапкозакидательство? Бред какой-то.
Ты хочешь сказать, что не слышал о существовании науки о качестве и дисциплины "управление качеством"? Фига се "бред"... В общем, спорить пока не имеет смысла, повторюсь лишь, что заявления, типа "ЯП такой-то сам по себе обеспечивает качество ПО" — это в раздел юмора сносить можно. Любой ЯП не в состоянии обеспечить более 1-2-х _нефункциональных_ требований. Гораздо больше нефункциональных требований способны обеспечить готовые библиотеки и фреймворки, а это уже как-то с языком постольку-поскольку связано. А уж про функциональные требования и ЯП в одном предложении упоминать — оксюморон, кроме случаев разработки повторно используемых библиотек под этот самый ЯП.
T>Да,я использую примерно 10-15% от всех возможностей Хаскеля. Языковых возможностей, конечно. T>Сдались мне эти 100%.
Вот и я про то, что "я пользуюсь 10 лет, и ничего" меня не сильно убеждают на фоне простыни в трекере. Если использовать как основной язык в крупных проектах, то рано или поздно код крылом заденет практически 100% конструкций языка. Взять тот же Решарпер — трудно с ходу придумать ситуацию, в которой он слажает, но в более-менее крупных проектах находится сразу куча таких мест "сами по себе".
T>>>Алгоритмы надо выжимать, не железку. V>>А уже открыт другой способ выжимания?
T>Я не понял вопроса. T>Если ты выжимаешь алгоритмы, то что ты про железки-то говоришь? Если ты выжимаешь железку, то мне как-то дальше неинтересно.
Та блин, а как еще можно "выжимать железку", не вскрывая проца, кроме как через алгоритмы и структуры данных?
T>То, что тебе пришлось работать с уже готовым алгоритмом, что не соптимизируешь, так это беда, а не повод для гордости.
Во-первых, немного еще оптимизируется в основном за счёт выкидывания лишнего из длинных списков аргументов ф-ий. Сами вычисления оптимизировать там практически не куда (кроме явного указания float вместо умолчательного double в нескольких десятках мест). Если же ты уверен, что знаешь, как оптимизировать сам принцип кодирования сигнала — то немедленно сообщи на сайт... ибо speex на сегодня — один из наилучших по показателям кач-во/процессорные_тики. Там эхоподавитель еще сыроват (отдельный необязательный модуль), но кодировщик весьма неплох.
T>Для плавающей запятой это получается порядка 500 операций. Или ~3000 тактов. Параллелить смысла не имеет. Без распараллеливания Хаскель отстанет.
Ты не понял, параллелить единичный кодек смысла не имеет, разумеется. Мне было интересно сравнить одновременный запуск сотен кодеков. Учитывая, что входные данные подаются фиксированными порциями, эту "одновременность" можно сделать и в одном треде в цикле, в любом случае не имеет смысла делать больше тредов, чем ядер железки.
T>Я справился быстрее, чем за пару выходных. Но медленней, чем мне бы хотелось. И узнал о реализации speex больше, чем это нужно здоровому человеку. Ну, и ладно.
Быстрее чем за пару выходных портировал и заставил работать все 3 режима кодека? Коллега, тебе пора начать бороться за крупнейшие гранты какие-нить, а не тратить время в форумах на нас, убогих. В любом случае этот код стоит выложить на сайте.
T>Функции длиной в 500-700 строк это не хорошо.
Это из-за ориентации на embedded и С, а он, в отличие от С++, инлайнинг и linked-time generation не умеет. В любом случае, эти строки — весьма просты, т.к. содержат практически одни вычисления.
T>Хаскель взял под козырёк и пошёл выполнять.
Не Хаскель, так другой, не принципиально. Случится смешная и грустная одновременно ситуация, когда ФП языки, худшие чем Хаскель, станут более популярны "по техническим причинам".
Re[20]: Каким отладчиком пользовались разработчики Kx System
T>esimp (EMul a b) = case (esimp a, esimp b) of
T> (EConst a,EMul (EConst b) c) -> esimp $ EMul (EConst $ a*b) c
T> (EConst a,EMul b (EConst c)) -> esimp $ EMul (EConst $ a*c) b
T> (a,b)
T> | iszero a -> ezero
T> | iszero b -> ezero
T> | isone a -> b
T> | isone b -> a
T> | otherwise -> EMul a b
T>
V>>>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?) T>>Я тоже. Но я не видел его ни в какой другой среде. G>А IntelliJ Idea ты видел?
T>>esimp (EMul a b) = case (esimp a, esimp b) of
T>> (EConst a,EMul (EConst b) c) -> esimp $ EMul (EConst $ a*b) c
T>> (EConst a,EMul b (EConst c)) -> esimp $ EMul (EConst $ a*c) b
T>> (a,b)
T>> | iszero a -> ezero
T>> | iszero b -> ezero
T>> | isone a -> b
T>> | isone b -> a
T>> | otherwise -> EMul a b
T>>
T>>Да брось ты! T>>При написании кода с глубоким заглядыванием наподобие нижеприведённого: V>... T>>Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки.
V>1. А где (EMul b (EConst c), EConst a) -> ? V>Вот тебе баг и язык тебе никак не помог — ибо прекрасно компилится без этой ветки, в которой выход на вторую половину ситуаций.
Это не баг.
Она не обрабатывается в оптимизирующем смысле этого слова, но она обрабатывается вообще, как одна из ситуаций.
AFAIR, esimp применялся после дифференцирования и я пришёл к выводу, что оно и так работает неплохо — всё, что надо упрощалось и группировалось.
V>2. Еще косяки: V>const1 * var1 * var2 * var3 * const2 — оптимизация возможна, но не будет произведена.
У меня этого случая не встречалось. Я думал о решении, пришёл к выводу, что надо упорядочивать пары.
V>const1 * (var1 * const2) — оптимизация невозможна, но будет произведена.
Почему это она невозможна?
V>В общем, подобной задачкой я занимался в своей жизни неоднократно, приведённый код никуда не годится, ибо, при обработке арифметических и логических выражений не следует использовать бинарные AST, тут нужен банальный список одноуровневых аргументов.
Я и такой вариант рассматривал. Зависит. Да тот же gcc в пример привести. Там ушли с n-арных сложений-умножений на бинарные. Для упрощения.
Просто я планировал сделать генератор оптимизаторов, для двоичного дерева он удобней.
V>3. Почему izzero и иже с ним проверяется после EConst? (просто любопытно)
Так показалось удобней.
V>4. На системе типов С++ прекрасно делается на частичной специализации. V>Букв будет гораздо больше, в основном всвязи с тем, что в С++ шаблонность типов и ф-ий явно аннотировать надо, а в Хаскеле всё шаблонное по-умолчанию.
ЧТД.
T>>Или вот другой пример: T>>
T>>-------------------------------------------------------------------------------
T>>-- Balin's pipelined sum acc.
T>>balinF :: Maybe i -> Maybe i -> Maybe i -> (Maybe i,Maybe (i,i))
T>>balinF oldAcc input loopback = (newAcc,output)
T>> where
T>> (newAcc,output) = case (oldAcc,input,loopback) of
T>> (acc,Just inp,Just lb) -> (acc,Just (inp,lb))
T>> (Just acc,Nothing,Just lb) -> (Nothing,Just (acc,lb))
T>> (Just acc,Just inp,Nothing) -> (Nothing,Just (acc,inp))
T>> (acc,Nothing,Nothing) -> (acc,Nothing)
T>> (_,inp,Nothing) -> (inp,Nothing)
T>> (_,_,lb) -> (lb,Nothing)
T>>
T>>Сумматор имени Влада Балина aka Gaperton, функция автомата Мили. Что, сможешь сделать такую же таблицу решений? А в такое же количество строк?
V>Можно саму постановку задачи или пример использования этого кода?
Эта штука ставится перед конвейеризованным сумматором и выполняет роль накапливания суммы. На вход её может (Maybe i) придти число — очередной элемент суммируемого ряда. На вход "loopback" тоже может (Maybe i) придти число — очередная сумма. На выход она должна поставлять пары чисел на сложение, если таковая пара может быть образована.
Соответственно, она изредка (Maybe i) держит что-то в своём аккумуляторе oldAcc — если не удалось образовать пары на сложение.
Да. balinF отрабатывает потактово. newAcc этого такта придёт в oldAcc следующего.
V>В любом случае, уже сейчас видно, что основную логику в сравнимое кол-во строк впихнуть можно.
Даже бесконечно большее число строк будет сравнимо.
Здесь тебя спасают nullable types.
Если ты попробуешь без них, только на значениях, то будет гораздо интересней.
V>В хаскеле не спец, так что еще вопросы: V>- что за Just? V>- откуда в этой задаче ожидается Maybe/Nothing?
data Maybe a = Nothing | Just a
Maybe позникает из-за возможного отсутствия любого элемента.
T>>Я не понял твоего абзаца практически совсем. T>>Он не несёт никакой информации. Что за наука? Что за шапкозакидательство? Бред какой-то.
V>Ты хочешь сказать, что не слышал о существовании науки о качестве и дисциплины "управление качеством"?
Как называется эта "наука о качестве"?
V>Фига се "бред"... В общем, спорить пока не имеет смысла, повторюсь лишь, что заявления, типа "ЯП такой-то сам по себе обеспечивает качество ПО" — это в раздел юмора сносить можно. Любой ЯП не в состоянии обеспечить более 1-2-х _нефункциональных_ требований.
Про теорию типов ты не слышал, так?
T>>Да,я использую примерно 10-15% от всех возможностей Хаскеля. Языковых возможностей, конечно. T>>Сдались мне эти 100%. V>Вот и я про то, что "я пользуюсь 10 лет, и ничего" меня не сильно убеждают на фоне простыни в трекере. Если использовать как основной язык в крупных проектах, то рано или поздно код крылом заденет практически 100% конструкций языка. Взять тот же Решарпер — трудно с ходу придумать ситуацию, в которой он слажает, но в более-менее крупных проектах находится сразу куча таких мест "сами по себе".
Стиль кодирования? Нет?
T>>То, что тебе пришлось работать с уже готовым алгоритмом, что не соптимизируешь, так это беда, а не повод для гордости. V>Во-первых, немного еще оптимизируется в основном за счёт выкидывания лишнего из длинных списков аргументов ф-ий. Сами вычисления оптимизировать там практически не куда (кроме явного указания float вместо умолчательного double в нескольких десятках мест). Если же ты уверен, что знаешь, как оптимизировать сам принцип кодирования сигнала — то немедленно сообщи на сайт... ибо speex на сегодня — один из наилучших по показателям кач-во/процессорные_тики. Там эхоподавитель еще сыроват (отдельный необязательный модуль), но кодировщик весьма неплох.
Я знаю, как соптимизировать параллельный запуск многих speex одновременно.
T>>Для плавающей запятой это получается порядка 500 операций. Или ~3000 тактов. Параллелить смысла не имеет. Без распараллеливания Хаскель отстанет. V>Ты не понял, параллелить единичный кодек смысла не имеет, разумеется. Мне было интересно сравнить одновременный запуск сотен кодеков. Учитывая, что входные данные подаются фиксированными порциями, эту "одновременность" можно сделать и в одном треде в цикле, в любом случае не имеет смысла делать больше тредов, чем ядер железки.
Заставите-таки. Займусь-таки.
Посмотрим, короче.
T>>Я справился быстрее, чем за пару выходных. Но медленней, чем мне бы хотелось. И узнал о реализации speex больше, чем это нужно здоровому человеку. Ну, и ладно. V>Быстрее чем за пару выходных портировал и заставил работать все 3 режима кодека?
Быстрее, чем пару выходных я поняд, что оптимизировать на Хаскеле там нечего.
V>Коллега, тебе пора начать бороться за крупнейшие гранты какие-нить, а не тратить время в форумах на нас, убогих. В любом случае этот код стоит выложить на сайте.
Это не код. Это соображения.
T>>Функции длиной в 500-700 строк это не хорошо. T>>Хаскель взял под козырёк и пошёл выполнять. V>Не Хаскель, так другой, не принципиально. Случится смешная и грустная одновременно ситуация, когда ФП языки, худшие чем Хаскель, станут более популярны "по техническим причинам".
"Avoid success at all costs" anyone?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Каким отладчиком пользовались разработчики Kx System
T>>Да брось ты! T>>При написании кода с глубоким заглядыванием наподобие нижеприведённого: V>... T>>Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки. V>1. А где (EMul b (EConst c), EConst a) -> ? V>Вот тебе баг и язык тебе никак не помог — ибо прекрасно компилится без этой ветки, в которой выход на вторую половину ситуаций.
Вдогонку.
Смотри, сколько ты всего обнаружил!
Смог ли бы ты обнаружить столько же всего в коде на плюсах, размазанному по нескольким файлам?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Каким отладчиком пользовались разработчики Kx System
Здравствуйте, thesz, Вы писали:
V>>>>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?) T>>>Я тоже. Но я не видел его ни в какой другой среде. G>>А IntelliJ Idea ты видел?
T>Нет, конечно.
G>>http://www.jetbrains.com/idea/features/code_assistance.html
T>Это те же олухи, что и MPS?
Да, они самые Те же олухи, что и ReSharper и TeamCity
Однако я придрался к утверждению, что "нормального context-sensitive intellicense я не видел его ни в какой другой среде". Ну не видел — значит не видел.. Но в Идее он как раз есть, один из самых умных, AFAIK.
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Ayreon — Out Of The White Hole
Re[23]: Каким отладчиком пользовались разработчики Kx System
T>>Это те же олухи, что и MPS? G>Да, они самые Те же олухи, что и ReSharper и TeamCity G>Однако я придрался к утверждению, что "нормального context-sensitive intellicense я не видел его ни в какой другой среде". Ну не видел — значит не видел.. Но в Идее он как раз есть, один из самых умных, AFAIK.
Она не бесплатная и для Java, поэтому ничего сказать не могу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[23]: Каким отладчиком пользовались разработчики Kx System
G>>>http://www.jetbrains.com/idea/features/code_assistance.html T>>Это те же олухи, что и MPS? G>Да, они самые Те же олухи, что и ReSharper и TeamCity G>Однако я придрался к утверждению, что "нормального context-sensitive intellicense я не видел его ни в какой другой среде". G>Ну не видел — значит не видел.. Но в Идее он как раз есть, один из самых умных, AFAIK.
Сходил к коллегам, осведомился про IDEA. Специально спросил насчёт intellisense. Получил ответ в смысле "интеллисенс у них нормальный, как у всех."
Подозрительно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Каким отладчиком пользовались разработчики Kx System
Здравствуйте, thesz, Вы писали:
T>Смотри, сколько ты всего обнаружил! T>Смог ли бы ты обнаружить столько же всего в коде на плюсах, размазанному по нескольким файлам?
Ты што мы говорим? По 3-5 тыс code-review строк в день не хочешь?
Разве лишние угловые и фигурные скобки заслонят логику? Если стоит задача реализовать (или проверить) инварианты, то абсолютно пофиг на каком языке, их кол-во и характер от этого не изменится. Человек же не строками кода мыслит, а "понятиями", соотв. пропускная способность и ограничивается не строками, а скоростью переваривания понятий.
Конкретно в твоём оформление первые 10 сек мешало отсутствие пробела после запятой, что не позволяло автоматически визуально структурировать текст, приходилось вчитываться, т.е. пользоваться не только мозжечком (отделённые пробелами конструкции составляли одно целое, а через запятую без пробелов — делимое).
Re[22]: Каким отладчиком пользовались разработчики Kx System
Здравствуйте, thesz, Вы писали:
T>Это не баг. T>Она не обрабатывается в оптимизирующем смысле этого слова, но она обрабатывается вообще, как одна из ситуаций.
Тю блин, ты же мне класс задач показал, не так ли? Пофиг, что в конкретно этом месте забытый матч не фатален, просто ошибки логики ЯП пока не научились ловить.
V>>2. Еще косяки: V>>const1 * var1 * var2 * var3 * const2 — оптимизация возможна, но не будет произведена.
T>У меня этого случая не встречалось. Я думал о решении, пришёл к выводу, что надо упорядочивать пары.
Не надо, надо в один список класть одноранговые операции, т.е. и EDiv тоже.
Если в твой код добавить EDiv и все на прямом паттерн матчинге сделать — это вообще макраме будет. В противовес этому код перебора списка с выхватыванием всех констант значительно покороче выйдет.
V>>const1 * (var1 * const2) — оптимизация невозможна, но будет произведена. T>Почему это она невозможна?
Потому что числовые типы могут быть различными для аргументов, и от порядка вычислений может зависеть результат (мы же пока конечным кол-вом бит в типах располагаем). В общем, скобки явно определяют последовательность операций и их игнорировать нельзя.
V>>В общем, подобной задачкой я занимался в своей жизни неоднократно, приведённый код никуда не годится, ибо, при обработке арифметических и логических выражений не следует использовать бинарные AST, тут нужен банальный список одноуровневых аргументов.
T>Я и такой вариант рассматривал. Зависит. Да тот же gcc в пример привести. Там ушли с n-арных сложений-умножений на бинарные. Для упрощения.
Ес-но, там же линкер теперь linked-time codogeneration делает, и граф операций у него на узлах без ограничения арности, да еще в linked-time гораздо больше известно о возможной константности значений.
T>Просто я планировал сделать генератор оптимизаторов, для двоичного дерева он удобней.
Для двоичного дерева потребуется многократный вызов подобного оптимизатора, пока все возможные узлы не "схлопнутся" (и то, далеко стоящие не схлопнутся), и для определения конца этого процесса придётся тащить дополнительный флаг. При использовании же N-арного дерева с явным расположением узлов одного логического уровня на одном уровне дерева потребуется лишь однократный вызов для полной оптимизации всех возможных ситуаций. Более того, для указанного выше ньюанса со скобками тебе бы пришлось вводить доп. тип узла AST в бинарном дереве.
T>Даже бесконечно большее число строк будет сравнимо.
Еще раз, что есть Just в том коде? (Я действительно хочу привести на паре языков реализацию аналога).
V>>В хаскеле не спец, так что еще вопросы: V>>- что за Just? V>>- откуда в этой задаче ожидается Maybe/Nothing?
T>
T>data Maybe a = Nothing | Just a
T>
T>Maybe позникает из-за возможного отсутствия любого элемента.
Maybe понятен, непонятен Just. Почему не так:
data Maybe a = Nothing | a
И что есть Just(a, b)?
T>Как называется эта "наука о качестве"?
Тебя смущает слово "наука"?
T>Про теорию типов ты не слышал, так?
В посление годы слышал слишком много, но ты, похоже, не понял разницы в ыункциональных и неыункциональных требованиях.
T>Стиль кодирования? Нет?
Нет.
T>"Avoid success at all costs" anyone?
Наоборот, разделение труда, т.к. уже есть большие готовые прикладные платформы.
Re[23]: Каким отладчиком пользовались разработчики Kx System
T>>Это не баг. T>>Она не обрабатывается в оптимизирующем смысле этого слова, но она обрабатывается вообще, как одна из ситуаций. V>Тю блин, ты же мне класс задач показал, не так ли? Пофиг, что в конкретно этом месте забытый матч не фатален, просто ошибки логики ЯП пока не научились ловить.
Про классический пример, когда вывод типов ML показывает на зацикливание, ты тоже не видел.
Система типов ЯП — это логика. Правильная система типов исправляет ошибки логики.
Более того, правильная система типов может регулировать нефункциональные требования наподобие сложности отдельных операций.
Прикольно?
V>>>2. Еще косяки: V>>>const1 * var1 * var2 * var3 * const2 — оптимизация возможна, но не будет произведена. T>>У меня этого случая не встречалось. Я думал о решении, пришёл к выводу, что надо упорядочивать пары. V>Не надо, надо в один список класть одноранговые операции, т.е. и EDiv тоже. V>Если в твой код добавить EDiv и все на прямом паттерн матчинге сделать — это вообще макраме будет. В противовес этому код перебора списка с выхватыванием всех констант значительно покороче выйдет.
Вот именно поэтому и не надо EDiv. Надо EInv (1/x) и ENeg (-x). Это из алгебры, там на этом собаку съели.
V>>>const1 * (var1 * const2) — оптимизация невозможна, но будет произведена. T>>Почему это она невозможна? V>Потому что числовые типы могут быть различными для аргументов, и от порядка вычислений может зависеть результат (мы же пока конечным кол-вом бит в типах располагаем). В общем, скобки явно определяют последовательность операций и их игнорировать нельзя.
Это ты уже о чём-то своём.
V>>>В общем, подобной задачкой я занимался в своей жизни неоднократно, приведённый код никуда не годится, ибо, при обработке арифметических и логических выражений не следует использовать бинарные AST, тут нужен банальный список одноуровневых аргументов. T>>Я и такой вариант рассматривал. Зависит. Да тот же gcc в пример привести. Там ушли с n-арных сложений-умножений на бинарные. Для упрощения. V>Ес-но, там же линкер теперь linked-time codogeneration делает, и граф операций у него на узлах без ограничения арности, да еще в linked-time гораздо больше известно о возможной константности значений.
Это ты тоже о чём-то своём. Кодогенерация, как самый простой этап, остался на RTL. Все оптимизации работают на TreeSSA, который бинарный для сложения и умножения.
linked-time кодогенерация это из будущего. Оно только в SVN.
Как-то странно говорить о багах в ghc и упоминать незаконченные возможности gcc.
T>>Просто я планировал сделать генератор оптимизаторов, для двоичного дерева он удобней. V>Для двоичного дерева потребуется многократный вызов подобного оптимизатора, пока все возможные узлы не "схлопнутся" (и то, далеко стоящие не схлопнутся), и для определения конца этого процесса придётся тащить дополнительный флаг. При использовании же N-арного дерева с явным расположением узлов одного логического уровня на одном уровне дерева потребуется лишь однократный вызов для полной оптимизации всех возможных ситуаций. Более того, для указанного выше ньюанса со скобками тебе бы пришлось вводить доп. тип узла AST в бинарном дереве.
Опыт оптимизации говорит о том, что ты неправильно мыслишь.
Но это твои личные проблемы.
T>>Даже бесконечно большее число строк будет сравнимо. V>Еще раз, что есть Just в том коде? (Я действительно хочу привести на паре языков реализацию аналога).
Я привёл определение Maybe. Могу привести ещё раз:
data Maybe a = Nothing | Just a
Справа от знака равенства Just a означает создание значения типа Maybe a, слева от знака равенства — сравнение значения типа Maybe a с образцом Just a. Если пришло значение Just x на образец Just a, то a в выражении справа от знака равенства будет равен x.
let f (Just a) = a+10
f (Just 11)
21
f Nothing
*ошибка сравнения с образцом*
(задумался над очевидным фактом незнания тобой алгебраических типов.)
V>>>В хаскеле не спец, так что еще вопросы: V>>>- что за Just? V>>>- откуда в этой задаче ожидается Maybe/Nothing?
T>>
T>>data Maybe a = Nothing | Just a
T>>
T>>Maybe позникает из-за возможного отсутствия любого элемента.
V>Maybe понятен, непонятен Just. Почему не так: V>
V>data Maybe a = Nothing | a
V>
Потому, что нельзя. Как мы отличим a, который Maybe a, от a, который, допустим, List a?
V>И что есть Just(a, b)?
:t Just 10
Just 10 :: Maybe Int
:t Just "Hello"
Just "Hello" :: Maybe String
:t Just (10,"Hello")
Just (10,"Hello") :: Maybe (Int,String)
(,) — пара, тупл или тапл (tuple).
:t (,)
(,) :: (a,b)
Пара независимо полиморфна по обеим аргументам.
T>>Как называется эта "наука о качестве"? V>Тебя смущает слово "наука"?
Да. У науки, обычно, бывает название.
T>>Про теорию типов ты не слышал, так? V>В посление годы слышал слишком много, но ты, похоже, не понял разницы в ыункциональных и неыункциональных требованиях.
Признаюсь честно, всеё разницы я вижу только в приставке "не".
Я даже слов таких не знаю.
T>>Стиль кодирования? Нет? V>Нет.
Почему?
T>>"Avoid success at all costs" anyone? V>Наоборот, разделение труда, т.к. уже есть большие готовые прикладные платформы.
Ты уж извини, но когда Хаскель станет успешным, им станешь пользоваться ты. Меня это беспокоит. Ты очень странный.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[23]: Каким отладчиком пользовались разработчики Kx System
T>>Смотри, сколько ты всего обнаружил! T>>Смог ли бы ты обнаружить столько же всего в коде на плюсах, размазанному по нескольким файлам? V>Ты што мы говорим? По 3-5 тыс code-review строк в день не хочешь? V>Разве лишние угловые и фигурные скобки заслонят логику? Если стоит задача реализовать (или проверить) инварианты, то абсолютно пофиг на каком языке, их кол-во и характер от этого не изменится. Человек же не строками кода мыслит, а "понятиями", соотв. пропускная способность и ограничивается не строками, а скоростью переваривания понятий.
Информации. Не понятий, а информации.
Это основное отличие.
См. метрику Хальстеда.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Каким отладчиком пользовались разработчики Kx System
T>-------------------------------------------------------------------------------
T>-- Balin's pipelined sum acc.
T>
T>balinF :: Maybe i -> Maybe i -> Maybe i -> (Maybe i,Maybe (i,i))
T>balinF oldAcc input loopback = (newAcc,output)
T> where
T> (newAcc,output) = case (oldAcc,input,loopback) of
T> (acc,Just inp,Just lb) -> (acc,Just (inp,lb))
T> (Just acc,Nothing,Just lb) -> (Nothing,Just (acc,lb))
T> (Just acc,Just inp,Nothing) -> (Nothing,Just (acc,inp))
T> (acc,Nothing,Nothing) -> (acc,Nothing)
T> (_,inp,Nothing) -> (inp,Nothing)
T> (_,_,lb) -> (lb,Nothing)
T>Сумматор имени Влада Балина aka Gaperton, функция автомата Мили. T>Что, сможешь сделать такую же таблицу решений? А в такое же количество строк?
Безотносительно к теме пользования отладчиками, не стало бы понятнее, что делает эта фунция, если ее переписать вот так?
balinF' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
balinF' oldAcc input loopback = case (oldAcc, input, loopback) of
(Just a, Just n, Just l) -> (Just a, Just (n, l))
(Just a, Just n, Nothing) -> (Nothing, Just (a, n))
(Just a, Nothing, Just l) -> (Nothing, Just (a, l))
(Nothing, Just n, Just l) -> (Nothing, Just (n, l))
(Just a, Nothing, Nothing) -> (Just a, Nothing)
(Nothing, Just n, Nothing) -> (Just n, Nothing)
(Nothing, Nothing, Just l) -> (Just l, Nothing)
(Nothing, Nothing, Nothing) -> (Nothing, Nothing)
Или так?
balinF'' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
balinF'' a b c = case (mapMaybe id [a,b,c]) of
[x,y,z] -> (Just x, Just (y, z))
[x,y] -> (Nothing, Just (x, y))
[x] -> (Just x, Nothing)
[] -> (Nothing, Nothing)
I might be wrong...
Re[21]: Каким отладчиком пользовались разработчики Kx System
B>Безотносительно к теме пользования отладчиками, не стало бы понятнее, что делает эта фунция, если ее переписать вот так? B>
B>balinF' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
B>balinF' oldAcc input loopback = case (oldAcc, input, loopback) of
B> (Just a, Just n, Just l) -> (Just a, Just (n, l))
B> (Just a, Just n, Nothing) -> (Nothing, Just (a, n))
B> (Just a, Nothing, Just l) -> (Nothing, Just (a, l))
B> (Nothing, Just n, Just l) -> (Nothing, Just (n, l))
B> (Just a, Nothing, Nothing) -> (Just a, Nothing)
B> (Nothing, Just n, Nothing) -> (Just n, Nothing)
B> (Nothing, Nothing, Just l) -> (Just l, Nothing)
B> (Nothing, Nothing, Nothing) -> (Nothing, Nothing)
B>
Длинней. Понятней, но длинней.
B>Или так? B>
B>balinF'' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
B>balinF'' a b c = case (mapMaybe id [a,b,c]) of
B> [x,y,z] -> (Just x, Just (y, z))
B> [x,y] -> (Nothing, Just (x, y))
B> [x] -> (Just x, Nothing)
B> [] -> (Nothing, Nothing)
B>
Это происходит "в железе", там списков нет. Но на совсем верхнем уровне можно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: Каким отладчиком пользовались разработчики Kx System
Здравствуйте, thesz, Вы писали:
T>Сходил к коллегам, осведомился про IDEA. Специально спросил насчёт intellisense. Получил ответ в смысле "интеллисенс у них нормальный, как у всех." T>Подозрительно.
Эти же ребята сделали Решарпер, так что могу осмысленно говорить лишь про него. Польза отнего не только и не столько в intellisense, сколько в тех хинтах, где он предлагает выполнить некое действие. Как пример — просто объявляю некое приватное поле, а потом alt+enter дважды, чтобы мне инициализацию этого поля встявили в конструктор, и потом сделали геттер на него. И таких действий у него, скажем прямо, немало. Так что, некая "говорливость" кода неплохо компенсируют подбные тулзы.
Re[24]: Каким отладчиком пользовались разработчики Kx System
Здравствуйте, thesz, Вы писали:
T>Сходил к коллегам, осведомился про IDEA. Специально спросил насчёт intellisense. Получил ответ в смысле "интеллисенс у них нормальный, как у всех."
Видимо, вопроса не поняли. Или IDEA пользоваться не умеют.
Sapienti sat!
Re[25]: Каким отладчиком пользовались разработчики Kx System
T>>Сходил к коллегам, осведомился про IDEA. Специально спросил насчёт intellisense. Получил ответ в смысле "интеллисенс у них нормальный, как у всех." C>Видимо, вопроса не поняли. Или IDEA пользоваться не умеют.
Когда я написал вот этот параграф выше, мне было некоторое время интересно, что же коллективный разум RSDN придумает.
Коллективный разум RSDN не подкачал. Он не пропустил это мимо своего внимания, это раз. И он показал свой обычный высокий уровень аргументации, это два.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Те же олухи, что и ReSharper и TeamCity 
