Objective Caml - Пятница, 27 апреля 2012

Objective Caml

ocaml@conference.jabber.ru

Пятница, 27 апреля 2012< ^ >

Конфигурация комнаты

Участники комнаты

GMT+4
[00:33:01] tilarids вошёл(а) в комнату
[00:33:38] tilarids вышел(а) из комнаты
[00:33:59] tilarids вошёл(а) в комнату
[00:53:56] gds вышел(а) из комнаты
[00:59:07] shaggie вошёл(а) в комнату
[00:59:08] shaggie вышел(а) из комнаты
[01:14:52] tilarids вышел(а) из комнаты
[01:25:58] Kakadu вышел(а) из комнаты
[01:43:46] Typhon вышел(а) из комнаты
[01:51:45] ftrvxmtrx вышел(а) из комнаты
[01:52:13] ftrvxmtrx вошёл(а) в комнату
[02:10:13] bobry вышел(а) из комнаты
[02:49:20] f[x] вышел(а) из комнаты
[09:35:58] bobry вошёл(а) в комнату
[10:04:05] bobry вышел(а) из комнаты
[10:53:00] ermine вошёл(а) в комнату
[10:59:54] ftrvxmtrx вошёл(а) в комнату
[11:24:17] dlebedev8 вошёл(а) в комнату
[11:29:45] Kakadu вошёл(а) в комнату
[11:51:41] ftrvxmtrx вышел(а) из комнаты
[11:52:09] ftrvxmtrx вошёл(а) в комнату
[11:53:34] Sun][ вошёл(а) в комнату
[11:54:16] ftrvxmtrx вышел(а) из комнаты
[11:55:09] ftrvxmtrx вошёл(а) в комнату
[11:58:12] gds вошёл(а) в комнату
[12:36:28] dlebedev8 вышел(а) из комнаты
[12:45:19] ftrvxmtrx вышел(а) из комнаты
[12:46:11] ftrvxmtrx вошёл(а) в комнату
[12:49:48] ftrvxmtrx вышел(а) из комнаты
[12:50:11] tilarids вошёл(а) в комнату
[12:50:49] ftrvxmtrx вошёл(а) в комнату
[12:53:30] ftrvxmtrx вышел(а) из комнаты
[12:54:25] ftrvxmtrx вошёл(а) в комнату
[13:14:12] ftrvxmtrx вышел(а) из комнаты
[13:15:05] ftrvxmtrx вошёл(а) в комнату
[13:20:16] ftrvxmtrx вышел(а) из комнаты
[13:21:11] ftrvxmtrx вошёл(а) в комнату
[13:21:52] dzhon вошёл(а) в комнату
[13:35:03] <klapaucius> bobry: солгал. Балодя ответил на его вопрос, при этом я с ним полностью согласен. Ленивость по-умолчанию лучше потому, что строгость можно вывести автоматически, а ленивость - нельзя.
[13:37:03] <gds> сраные теории без практических применений.  Почему же тогда, если можно вывести, нигде в практически-важных случаях она не выводится, и приходится утыкивать х-евую программу аннотациями строгости, как какашку спичками?
[13:41:04] <klapaucius> gds: Ну, это преувеличение. Утыкивание имеет место быть - факт. только большая часть этих аннотаций строгости бесполезны. Одни из них и так выведены, а другие не дают наблюдаемых эффектов. Людей запугали вот они и начинают ставить аннотации не понимая что они делают на самом деле. Кроме того, автоматический вывод может стать лучше, а ручной - нет. тут ситуация как с управлением памятью - ручное управление нужно, но в экстремальных случаях.
[13:45:31] <klapaucius> Большая часть проблем с ленивостью происходит от того, что программист не понимает как работает ленивость и ожидает от программы на ленивом языке поведения программы на строгом. Эта проблема - реальная, но не техническая, а образовательная.
[13:45:56] <Kakadu> т.е. "руки кривые"?
[13:46:18] <Kakadu> Боброму так и ответили....
[13:48:14] <klapaucius> Ну нет, почему сразу "кривые"? Просто для того, чтоб пользоваться чем-то - надо уметь этим пользоваться. Проблема в данно случае в том, что что-то выглядит как то, чем человек пользоваться умеет, но является тем, чем человек пользоваться не умеет.
[13:49:47] shaggie вошёл(а) в комнату
[14:19:11] komar вышел(а) из комнаты: Replaced by new connection
[14:19:11] komar вошёл(а) в комнату
[14:20:53] ftrvxmtrx вышел(а) из комнаты
[14:21:05] ftrvxmtrx вошёл(а) в комнату
[14:24:21] tilarids вышел(а) из комнаты
[14:34:59] Typhon вошёл(а) в комнату
[14:40:03] Sun][ вышел(а) из комнаты
[14:42:58] bobry вошёл(а) в комнату
[14:43:43] <bobry> klapaucius: может я пропустил или не так понял — что именно мне ответили? желательно цитату
[14:45:31] <klapaucius> [18:47:20] <балодя> в общем, аннотации ленивости -- полностью ручной процесс, зато аннотации строгости вот можно большей частью свалить на компилятор
[14:48:15] <bobry> ок — видимо действительно пропустил; а аргументация выше напоминает мне аналогичную ситуацию в мире js, когда фанатики начинают обвинять возмущающихся убогостью дизайна в неосиляторстве
[14:48:29] <bobry> "надо уметь этим пользоваться"
[14:49:17] <klapaucius> Разница тут простая: в одном случае дизайн убогий, а в другом - наоборот - хороший.
[14:50:23] <bobry> "хорошесть" как минимум сомнительна
[14:50:44] <klapaucius> Понятное дело, что убогий дизайн всегда именно так и защищают. Из этого однако не следует, что уметь чем-то пользоваться не нужно.
[14:51:01] <bobry> не следует конечно
[14:51:44] <bobry> мне все таки интересно почему "lazy by default" несмотря на большую вероятность ошибки и необходимость "уметь этим пользоваться" считается удачным решением?
[14:52:53] <klapaucius> Во-первых, "большая вероятность ошибки" будет для программиста на ML, который пишет на хаскеле, а не для программиста на хаскеле, который пишет на хаскеле.
[14:53:29] <bobry> для любого кто еще не набил шишек и не "научился этим пользоваться"
[14:53:35] <klapaucius> Одна из причин почему решение удачное - указал балодя.
[14:54:41] <Typhon> пример практический
[14:54:48] <Typhon> где они автоматически выводятся то?
[14:54:53] <klapaucius> bobry: проблема тут, как  я пытался выше объяснить не столько в опыте работы с хаскелем, сколько в опыте работы со строгими зяыками. если бы вторые были в меньшинстве программисты бы в них устраивали лики и не понимали бы почему там все так странно работает.
[14:55:16] <klapaucius> Typhon: автоматически они выводятся в GHC.
[14:56:21] <Typhon> почему у bobry не вывелись?
[14:56:35] <Typhon> мне это напоминает фразу торвальдса "Theory and practice sometimes clash. And when that happens, theory loses. Every single time."
[14:57:23] <Typhon> типа, когда факториал считать, ghc справляется, а когда реалворлд приложение, не особо сложно, судя по словам bobry, причём, нужно восклицательными знаками вооружаться
[14:57:37] <klapaucius> Typhon: потому, что не должны были выводится "вывод строгости" не означает, программа, написанная на ленивом языке начинает работать так, как на строгом. Иначе какой смысл вообще на ленивом языке писать?
[14:57:52] <Typhon> и судя по презентациям типа "high performance haskell" это не единичный случай
[14:58:01] <bobry> Typhon: про восклицательные знаки уже выше была ремарка — неосилил я, и от неосиляторства начал панически ! ставить
[14:58:13] <bobry> klapaucius: про смысл во многом и вопрос
[14:58:14] <Typhon> "Иначе какой смысл вообще на ленивом языке писать?" — my point, exactly
[14:58:19] <bobry> лол
[14:58:22] <klapaucius> Typhon: И как бы восклицательный знак помог ему прочесть документацию библиотеки, которую он использовал?
[14:58:53] <bobry> klapaucius: ее использовал мой коллега — я только дебажил
[15:00:07] <Typhon> если у нас строгое по умолчанию, то когда было бы нужно, программист поставил бы аннотацию ленивости. здесь же по умолчанию ленивое, и предполагается (?) что компилятор сам должен вывести строгость тут. чего не происходит
[15:00:37] <klapaucius> Программировать на ленивом языке имеет смысл, если хочется иметь возможность собирать код из мелких компонентов. т.е. ради модульности и повторного использования.
[15:01:05] <bobry> как это связано с ленивостью? я что-то не улавливаю
[15:01:08] <bobry> может лучше на примере?
[15:01:46] <klapaucius> Typhon: Компилятор не может изменять семантику кода. Код работает как написано, а не так как программисту хотелось бы, чтоб он работал. Прочитать мысли программиста анализатор строгости не может.
[15:01:49] <Kakadu> я тоже не улавливаю
[15:02:13] <Typhon> """зато аннотации строгости вот можно большей частью свалить на компилятор"""
[15:03:12] <klapaucius> Typhon: Да. Но программа на ленивом языке все равно будет работать как программа на ленивом языке. Строгость будет выведена для оптимизации, семантику она не поменяет.
[15:04:44] <Typhon> тогда пойнт балоди про "строгость by default vs ленивость by default" не особо в кассу, кмк. семантически то чем выгоднее ленивость?
[15:05:39] <klapaucius> Ну а зачем программисты всякие итераторы используют? Чтоб им невыгоднее было?
[15:07:03] <Typhon> итераторы — это не ленивость by default же
[15:07:32] <klapaucius> Ну, т.е. зачем ленивость не бай дефолт - понятно?
[15:07:45] <Kakadu> и вообще, причем тут итераторы? Вы про С++ные итераторы или про какие?
[15:08:11] <Typhon> ну у нас тут вроде тёрка про то, что управляемая ленивость, вместе со строгостью по умолчанию — годная тема, а наоборот — педальная
[15:08:47] <klapaucius> Про любые. Цель у них у всех одинаковая - посволить собрать что-то более сложное из менее сложных деталей.
[15:09:46] <klapaucius> Typhon: Ну тогда в чем проблема с тезисом Балоди?
[15:10:26] <Kakadu> я непонимаю причем тут декомпозиция к ленивости
[15:11:12] <klapaucius> Typhon: В одном случае компилятор программисту помогает - в другом нет. Следующий плюс - можно управлять строгостью вычисления ленивого кода извне, а ленивым строгий код неинтрузивно не сделать.
[15:12:24] <Kakadu> Как  понимаю что балодя хочет сказать, что Аннотации сделать из ленивого кода строгий компилятор сможет без внесения багов, а наоборот --- не сможет даже теоритически
[15:13:21] <Kakadu> Но тогда получается, что ghc делает при компиляции деленивизацию, что неверно
[15:14:14] <klapaucius> То, что ручная аннотация делает "деленивизацию" - тоже неверное утверждение.
[15:16:27] Sun][ вошёл(а) в комнату
[15:16:52] ftrvxmtrx вышел(а) из комнаты
[15:17:34] dzhon вышел(а) из комнаты
[15:17:47] <klapaucius> А с декомпозицией все просто. Можем мы написать or на базе fold в строгом языке? нет, функция будет не коротко-замыкаемая и будет делать лишнюю работу - придется писать функцию с нуля. Можно сделать в строгом языке any из or и map? - нет, функция потребует двойного прохода и лишней работы - придется писать функцию с нуля.
[15:17:47] ftrvxmtrx вошёл(а) в комнату
[15:19:41] <Typhon> >>> any = functools.partial(reduce, operator.or_)
>>> any([True, False, False, True])
True
[15:19:43] <Typhon> питон
[15:20:16] <klapaucius> Потому программисты и используют итераторы. Но итераторы не решают всех проблем и ухудшают асимптотику - они вычисляют одно и то же по несколько раз. Приходится прикручивать к ним мемоизацию. С этого момента проблем будет как минимум столько же, сколько и от ленивости, но компилятор нам ничем не поможет, да и  реализация всего этого в строгом по умолчанию языке обычно костыльная и тормозная.
[15:21:39] <Kakadu> что вычислет по несколько раз? есть ли ещё элементы?
[15:21:46] <gds> > Можем мы написать or на базе fold в строгом языке?
можем элементарно.  См. http://docs.camlcity.org/docs/godisrc/batteries-1.4.1.tar.gz/batteries-1.4.1/src/batReturn.mli
[15:24:12] <klapaucius> gds: ну, за счет всяких ретурн-континьюэйшенов можно делать короткозамкнутые версии, но все это приведет к замусориванию кода и прочему. Никто же не спортит, что через тернии все можно сделать, хочется-то делать не через тернии.
[15:24:51] <gds> мемоизацию делать -- та же фигня, что и с ленивостью, те же опасности -- опасность забыть голову списка/потока в памяти.  Если опасность не приведёт к тяжким последствиям, то пофиг, мемоизация или ленивость, и пофиг, ленивое или строгое оно.  Если приведёт -- то тоже пофиг, те же проблемы (только в строгих языках можно кое-что получше гарантировать про "незаседание в памяти").  Профита от лени не вижу вообще.
[15:26:00] <gds> klapaucius: какие нафиг тернии, ты о чём, всё тупо там.  Зато ресурсная семантика кода -- очевиднее некуда, при BatReturn, не надо думать о "прелестях" лентяйки.
[15:28:08] <klapaucius> В простом случае ресурсная семантика проще простого в обеих случаях. В сложных - ресурсная семантика опять таки будет сложной в обеих случаях. С тем, что проблемы в строгих языках решать программисты привыкли лучше - я не спорю, я как раз об этом и говорю.
[15:29:46] <klapaucius> Если же профита от ленивости не видно - никто не заставляет Хаскелем пользоваться. Для тех кому видно профит - ленивость ключевая фича хаскеля. Без нее он никому не нужен - чем он будет отличатся от остальных языков?
[15:30:16] <gds> типа, он единственный ленивый язык в мире.
[15:31:35] <klapaucius> Ну, есть аж еще целый один, в названии кторого букв, наврное больше, чем у него пользователей и который собирается становится реализацией хаскеля. А когда-то еще и третий был, да весь вышел.
[15:32:13] <gds> про ресурсы -- вроде таки есть разница.  Если делаем or через fold по списку, который вычисляется "по ходу дела", то получаем, что 1. память забивается по мере выполнения or -- лол же, 2. может случиться какая-то ошибка.  В случае, когда список уже вычислен, этого не будет, и мы уверены, что операция or -- максимум O(длинасписка) обращений к памяти, сама or памяти не требует, судить о ней проще.
[15:32:57] <klapaucius> Сделать приемлимую по производительности реализацию ленивого языка - серьезный труд, никогда их много не будет. В этом как раз самый большой недостаток ленивости и заключается.
[15:33:58] <gds> ещё от пользователей требуется труд, и для чего -- для того самого анализа строгости, который будет когда-то потом, когда построят коммунизм.
[15:37:15] <klapaucius> gds: труд от пользователя требуется в основном для преодоления собственного опыта пользователя. В большинстве таких случаев анализ строгости не поможет. потому что семантика ленивого языка останется семантикой ленивого языка.
[15:39:49] tilarids вошёл(а) в комнату
[15:43:47] <klapaucius> Поэтому я и говорил, что сложность - не техническая. Улучшением анализатора строгости она не решается. Человек который привык писать на, допустим ML начинает с того, что пишет программу на ML в синтаксисе хаскеля. Ожидает он того, что программа эта и будет работать, как программа на ML. Хуже всего то, что в некоторых случаях примерно так и будет (примерно, потому что разницу можно заметить и на простых примерах) - это только укрепляет программиста в заблуждении, что ничего особенного нет - все как раньше. Разумеется в "практически значимых случаях" программа на ML в хаскелном синтаксисе не работает нормально. Иначе и быть не может. И да, это тоже существенный недостаток ленивости, как и любой другой фичи, которая не встречается в большинстве языков.
[16:02:08] komar вышел(а) из комнаты: Replaced by new connection
[16:02:08] komar вошёл(а) в комнату
[16:07:05] <tilarids> други, а подскажите, можно ли как-нибудь к емаксу(или окамлевому топлевелу) прикрутить интерактивный хелп по окамлевским модулям? Может, я чего-то не знаю и все этим пользуются?
[16:07:11] <tilarids> очень не хватает после питоновского топлевела
[16:10:10] <gds> tilarids: смотря какой хелп нужен.  Если посмотреть тип или комментарий (ocamldoc'овский), то typerex рулит.  Если что-то типа "все функции модуля" -- $ ocamlfind ocamlbrowser -all
[16:10:43] <bobry> только это не совсем интерактивный хелп
[16:13:11] f[x] вошёл(а) в комнату
[16:14:28] <tilarids> сейчас попробуем
[16:21:51] <tilarids> странно, но или я не понимаю, как использовать ocamlbrowser, или он у меня не стартует
[16:21:57] <tilarids> + он же на tk?
[16:22:42] <gds> окошко появляется?
[16:23:04] <gds> да, он на tk, а именно, labltk, такая окамловская библиотека.
[16:25:01] ftrvxmtrx вышел(а) из комнаты
[16:25:54] ftrvxmtrx вошёл(а) в комнату
[16:27:35] <tilarids> нет, не появляется окошко
[16:27:59] <Kakadu> из консольки запусти. посмотри что скажет
[16:28:20] <Kakadu> у нас Sun][ уже должен быть экспертом по камлобразеру
[16:28:57] <tilarids> http://paste.in.ua/4206/ - хвост стрейса
[16:29:04] <tilarids> в консольку ничего не пишет
[16:29:43] <Kakadu> прикольно
[16:35:17] <gds> tilarids: трейс, вроде, ниачом.  А камло штатным образом поставил?
[16:36:06] <f[x]> потому что чайлда не трейснул
[16:36:09] <f[x]> strace -f -ttT
[16:38:33] <gds> tilarids: а без трейса в stdout/stderr что-то пишет?
[16:39:32] <gds> если чо, ocamlbrowser у меня работал всегда и везде, даже на винде в 2004г.
[16:41:07] dzhon вошёл(а) в комнату
[16:44:07] <tilarids> gds, без трейса ничего не пишет
[16:46:05] <tilarids> typerex ок, только цвета нужно подобрать для консоли
[16:46:35] <gds> tilarids: ocamlfind стоит?  а работает?  tk-либы стоят?  какие-нибудь тестовые программы компилируются?  просто команда ocamlbrowser работает?
[16:47:11] <gds> tilarids: есть там у них в customize варианты выбора цвета.  Если хочешь без расцветки вообще (так, как мне нравится) -- есть заклинание для ~/.emacs
[16:47:23] <gds> тьфуты, варианты выбора схемы цветов.
[17:01:41] <tilarids> сам окамль с батарейками стоит, ocamlfind работает, все компилируется. Браузер не работает, но он и не нужен, меня вполне устроит typerex
[17:01:49] <tilarids> он умеет help и умеет автокомплит
[17:02:14] <tilarids> есть заклинание, которое убирает вырвиглазную расцветку тултипом и автокомплитных окошек?
[17:04:47] <gds> tilarids:
(setq font-lock-global-modes '(not typerex-mode))
(setq ocp-syntax-coloring nil)
[17:05:07] ftrvxmtrx вышел(а) из комнаты
[17:05:57] ftrvxmtrx вошёл(а) в комнату
[17:10:26] <tilarids> не, мне сам syntax coloring нравится. Не нравится в тултипах цвета
[17:25:09] ftrvxmtrx вышел(а) из комнаты
[17:25:47] ftrvxmtrx вошёл(а) в комнату
[17:31:06] dzhon вышел(а) из комнаты: Replaced by new connection
[17:31:16] dzhon вошёл(а) в комнату
[17:33:42] <gds> тогда, если через customize не получается (в том числе, выбрать схему раскраски) -- пиши авторам.
[17:34:58] ftrvxmtrx вышел(а) из комнаты
[17:36:13] ftrvxmtrx вошёл(а) в комнату
[17:36:54] ftrvxmtrx вышел(а) из комнаты
[17:37:50] ftrvxmtrx вошёл(а) в комнату
[17:41:15] ftrvxmtrx вышел(а) из комнаты
[17:42:12] ftrvxmtrx вошёл(а) в комнату
[17:43:47] ftrvxmtrx вышел(а) из комнаты
[17:45:03] ftrvxmtrx вошёл(а) в комнату
[17:46:50] ftrvxmtrx вышел(а) из комнаты
[17:47:25] <tilarids> я сам поковыряю еще
[17:47:43] ftrvxmtrx вошёл(а) в комнату
[17:47:47] <tilarids> в общем - спасибо, хелп именно такой, как хотелось. Надоело по 30 вкладок открытыми держать
[17:48:56] dzhon вышел(а) из комнаты
[17:51:33] ftrvxmtrx вышел(а) из комнаты
[17:51:52] <gds> ых, а у меня в coq за каждый присест по 10 вкладок открывается.  один раз решил почистить вкладки за неделю-две, порядка сотни закрыл на эту тему.  но там не такие вещи, которые можно в {typerex,ocamlbrowser}-подобном ide найти, те вещи ищу в coqide напрямую.
[17:52:21] ftrvxmtrx вошёл(а) в комнату
[17:52:55] ftrvxmtrx вышел(а) из комнаты
[17:53:48] ftrvxmtrx вошёл(а) в комнату
[17:54:50] ftrvxmtrx вышел(а) из комнаты
[17:55:45] ftrvxmtrx вошёл(а) в комнату
[17:57:01] ftrvxmtrx вышел(а) из комнаты
[17:57:46] ftrvxmtrx вошёл(а) в комнату
[17:58:52] ftrvxmtrx вышел(а) из комнаты
[17:59:46] ftrvxmtrx вошёл(а) в комнату
[18:03:11] Sun][ вышел(а) из комнаты
[18:06:14] <bobry> coqer :)
[18:32:36] Typhon вышел(а) из комнаты
[18:33:11] Typhon вошёл(а) в комнату
[18:33:12] Typhon вышел(а) из комнаты
[18:35:11] bobry вышел(а) из комнаты
[18:59:09] ftrvxmtrx вышел(а) из комнаты
[19:06:09] ftrvxmtrx вошёл(а) в комнату
[19:09:05] ftrvxmtrx вышел(а) из комнаты
[19:09:32] ftrvxmtrx вошёл(а) в комнату
[19:11:19] ftrvxmtrx вышел(а) из комнаты
[19:11:46] ftrvxmtrx вошёл(а) в комнату
[19:15:07] ftrvxmtrx вышел(а) из комнаты
[19:15:34] ftrvxmtrx вошёл(а) в комнату
[19:16:08] <Kakadu> Господа, положим передо мной список чисел: набор байткодов для некоторой виртуальной машины. Мне надо интерпретатор этого. Какой подход правильный: мэчить список чисел влоб и походу исполнять, или предварительно перегнать в какой-нить культурный тип данных
[19:16:10] <Kakadu> ?
[19:17:00] ftrvxmtrx вышел(а) из комнаты
[19:17:27] ftrvxmtrx вошёл(а) в комнату
[19:18:23] ftrvxmtrx вышел(а) из комнаты
[19:19:22] <gds> Kakadu: смотря какие требования к исполнению кода и какие силы готов затратить на это.
[19:19:58] <Kakadu> Это демонстрационная программа для простой виртуальной машины под лозунгом "Окамл круче С++"
[19:20:14] ftrvxmtrx вошёл(а) в комнату
[19:20:58] ftrvxmtrx вышел(а) из комнаты
[19:21:34] ftrvxmtrx вошёл(а) в комнату
[19:23:14] <gds> давай чуть больше конкретики, а то есть несколько подходов, все разные, даже не знаю, что посоветовать.
[19:27:12] ftrvxmtrx вышел(а) из комнаты
[19:27:24] ftrvxmtrx вошёл(а) в комнату
[19:28:03] ftrvxmtrx вышел(а) из комнаты
[19:28:09] ftrvxmtrx вошёл(а) в комнату
[19:28:32] <Kakadu> вернее это программа не для ВМ, а сама ВМ. Есть входной ассемблерный язык (где пока есть регистровые mov, add, пару прерываний. но будут ещё команды). Он генерится в код виртуальной машины (которая будет стеково-регистровой). Есть интрепретатор, который.... интерпретирует :-) Вопрос у меня об интерпретаторе: как лучше организовать интерпретацию списка кодов-чисел? можно влоб, но тогда будет матчинг циферок и кое-где (например для mov c двумя аргументами) ещё в правой части снимания аргументов с моего списка-стека. А можно предварительно всё это перегнать в какойнить тип данных
type bytecmd =
  | Mov1 of regI * regI (* move register to register *)
  | Add1 of regI * regI
  | Sub1 of regI * regI
  | Int of interrupt
И его уже кошерно интерпретировать
[19:28:54] ftrvxmtrx вышел(а) из комнаты
[19:29:07] ftrvxmtrx вошёл(а) в комнату
[19:29:36] <Kakadu> понятно, что без скорее всего первый вариант быстрее работает, но  на скорость не фапаю.
[19:29:51] ftrvxmtrx вышел(а) из комнаты
[19:30:07] <Kakadu> s/без//
[19:30:24] ftrvxmtrx вошёл(а) в комнату
[19:31:12] ftrvxmtrx вышел(а) из комнаты
[19:31:22] ftrvxmtrx вошёл(а) в комнату
[19:32:05] ftrvxmtrx вышел(а) из комнаты
[19:32:06] <gds> как я понял, числа -> bytecmd -> интерпретация.  Смотря сколько раз будут выполняться команды, если много -- лучше сразу в bytecmd перегнать.  Если важна память, то интерпретируй напрямую.
Ещё один факт: если брать окамл, то, если выполнять "перегон инструкции в bytecmd -> выполнение инструкции из bytecmd" по сравнению с "выполнение инструкции из циферок" -- принципиальная разница только в засирании minor heap, то есть, практически неощутимая.
[19:32:23] ftrvxmtrx вошёл(а) в комнату
[19:33:37] ftrvxmtrx вышел(а) из комнаты
[19:37:08] ftrvxmtrx вошёл(а) в комнату
[19:37:51] ftrvxmtrx вышел(а) из комнаты
[19:38:42] ftrvxmtrx вошёл(а) в комнату
[19:39:11] ftrvxmtrx вышел(а) из комнаты
[19:40:07] <Kakadu> Ну если я весь код сразу перегоню, то кучу я засру. Но думаю ты ленивые камлёвые streamы имел ввиду
[19:40:26] ftrvxmtrx вошёл(а) в комнату
[19:40:52] <Kakadu> Хотя в будущем ещё планируются всякие jmp по адресам. Так что наверное придется по любому весь код предварительно перегонять
[19:41:38] <Kakadu> Хотя нет, и тут грёбаной ленивости есть место
[19:42:36] <Kakadu> Короче буду сразу весь код в память складывать, будем считать что она резинова
[19:42:53] ftrvxmtrx вышел(а) из комнаты
[19:43:54] ftrvxmtrx вошёл(а) в комнату
[19:45:03] <gds> так вот, я про jmp тоже имел в голове.  но тут от адресной модели зависит.  как вариант, можно к каждому ip привязать опционально проинтерпретированную инструкцию.
конкретно тут ленивость не обязательна, достаточно мутировать содержимое нужного массива.  (эффект похожий, но в мелочах разница есть.)  Но и ленивость можно, тоже прилично будет.
[19:45:59] ftrvxmtrx вышел(а) из комнаты
[19:50:11] <gds> если про камло говорить, то какой-нибудь array (option 'a) будет повеселее в плане памяти, так как None в массиве занимают лишь ячейку массива, но не больше.  А функцию типа "достать инструкцию по адресу" всё равно надо писать (ту, которая при Some x будет давать x, а при None будет смотреть, что за инструкция там).
Кроме того, если есть инструкции без immediate arguments, можно их закешировать в HashSet каком-нибудь, типа hash-consing.
[19:51:23] <Kakadu> массивчик а-ля кэш операций
[19:54:35] <Kakadu> а индексом массива ты что предлагаешь сделать? адрес команды?
[19:57:41] <Kakadu> лучше всего кончено же захакать байткод, введя туда "метки". Тогда не будет прыжков по левым адресам, будут только переходы по меткам. а все куски кода , которые могут исполняться после прыжков, можно узнать за предварительный проход....
[19:58:26] <Kakadu> короче пока рано городить огород. сделаю как-нибудь
[20:00:49] <Kakadu> и ещё наверное с точки зрения trustworthy было бы круто хранить внутри типа bytecode код команды mov в байткодне. привет dependent types я понимаю?
[20:08:04] <gds> индекс -- адрес, да.  Смотри, насколько тебе это удобно.  Для хитрожопого машинного кода, где с середины одной инструкции может начинаться другая -- вполне годно.
Про "внутри типа bytecode код команды mov в байткодне" -- совсем не понял, поясни.  Насколько я понял, просто в байткодовую инструкцию можно добавить дополнительное значение "собственно код mov" (или что угодно), или не?
[20:10:51] <Kakadu> Не, я хочу в _тип_ bytecode это добавить. А то для большого количества операций можно как-нить получить что
сущетвует code такой что : code <> code_of_command (command_of_code code)
[20:12:36] <Kakadu> вероятно, что я пока не доконца понял что из себя представляют зависимые типы. Может чушь несу
[20:13:23] <Kakadu> gds: с массивом идею понял, спасибо
[20:14:48] <gds> это да, получить такое, про code <> .. code, вполне реально.  Либо через тесты (тупо побрутфорсить, типа quickcheck-подобных тестов), что проще, либо через доказательства, что чуть сложнее.  Но тут вроде не столько зависимые типы, сколько доказательства.  Кстати, coq умеет генерить камлокод, и, если потвикать, то приличный.  Мутабельное там через жопу только получается, но конкретно твоя функция "интерпретировать инструкцию" -- вполне чистая.  При желании доказать её корректность -- сможешь вполне.  Даже помог бы с "первым пинком" и с разными мелочами.
[20:18:05] <gds> более того, я в псто писал про atmel'ы, и тема не заглохла (однако, другой работы подкинули), и там мне тоже будет интересно кое-что подоказывать про машинный код (но в перспективе), то есть, я бы поработал на своё будущее.
[20:21:07] shaggie вышел(а) из комнаты
[20:21:24] <Kakadu> надо будет мне в конце мая защитить диплом, и понять, чем я буду заниматься
[20:22:07] <gds> тогда это -- первоочередное.  А дальше уже всякие ВМ.  Как будет желание -- обсудим дальше тему.
[20:23:38] Kakadu даже стыдно стало
[21:54:37] tilarids вышел(а) из комнаты
[22:10:28] bobry вошёл(а) в комнату
[22:50:15] ftrvxmtrx вышел(а) из комнаты
[23:02:04] <bobry> gds: а расскажи чем ты по работке занимаешься, а то меня прям заинтриговала твоя фраза про задачки которые непонятно как решать
[23:05:23] tilarids вошёл(а) в комнату
[23:07:48] f[x] вошёл(а) в комнату
[23:54:56] shaggie вошёл(а) в комнату