amd63
13.03.2013 08:46 Azoth
"Не могу создать"-псто: @komar, ты можешь для нубаса в один абзац написать, почему ты больше окамлишься, чем хаскелишь? // Потому что у нубаса в голове крутится "Шо то — ML, шо это — ML"
Recommended by:
@gelraen: тред о программировании на псаче. Удивительно.
and
@ulidtko
144 comments
recommend
bookmark
subscribe
Разблеклистил.
Потому что хаскель — говно.
Давай по-другому. Ты раньше на чем писал?
Я ожидал абазца в стиле "В окамле можно/мненравится <1,2,3,4,5> а вот в хаскеле так нельзя/неудобно/некрасиво/нелюблю"
вот те конкретные места, которые говно, они же имеют аналог в окамле? эти аналоги — чуть менее говно/вообще не говно, потому что.....?
В окамле мне нравится то, что это быстрый, простой и выразительный, но не тонущий в обосракциях язык. Хаскель же мне напоминает помойку.
Впрочем, тебя действительно ебет то, почему я выбираю окамл, а не хаскель, или же тебе нужен ответ на вопрос «а что мне самом лучше освоить»?
В окамле нихера нету.
в х-е ленивость — сильно усложняет рассуждения о ресурсоёмкости и производительности кода.
в х-е тайпклассы — усложняют раскопки "откуда блядь взялся код, который работает для a + b".
в х-е нет нормальных модулей, которые очень важны для написания среднего/большого софта. (на однострочники не распространяется.)
в х-е обязательно обмазываться несколькими слоями манаток, тогда как в окамле это — только при необходимости и по собственному желанию (у меня, например, часто такое желание есть, но не всегда).
в х-е "чистота" не так уж много гарантирует, а гемора доставляет ощутимо, тогда как в окамле вполне можно писать чистый код с тем же успехом.
типовые извращения х-я — таки извращения в плохом смысле слова. В окамле берут coq, пишут на нём сколь угодно сложную логику работы с типами, экстрактят в окамл, используют.
> в х-е нет нормальных модулей, которые очень важны для написания среднего/большого софта. (на однострочники не распространяется.)
А что с ними?
с однострочниками? — ничего особо, модули там не нужны.
с модулями? — они не умеют в сигнатуры. О какой абстракции можно говорить после всего этого? Далее, нет функторов над модулями. Отдельная история — если тебе надо будет работать одновременно с двумя мапками со строковым ключём, в одной из которых операция сравнения будет case insensitive, например.
Сигнатур? Функторов? Блять, не верю. Были же вроде.
подборка постов замечательная.
а, ёпта. Есть способ не вытаскивать наружу функции и представления типов. Но по сравнению с .mli — отсос.
Загуглил функторы в х-ле, везде пишут про аппликативные функторы. Я запутался в этой вашей терминологии. В х-ле можно ебануть модуль, который можно будет обхуяривать другими типами и значениями и получать специализированные модули?
@komar и @gds как-то сконцентрировались на недостатках х-ля. В /0 шла речь про "лично для тебя красивые/удобные/правильные плюсы окамла", то есть ответ ожидался в противоположном направлении. Не "оно жрёт много солярки, поэтому велосипед", а "приятно с друзьями, ветер в лицо, поэтому не машина" стиль ответа.
Ответьте плиз больше употребляя слово окамл, а то у вас постоянно слово "х-ль" в ответе :(
Блять, нажал не туда.
> в х-е "чистота" не так уж много гарантирует, а гемора доставляет ощутимо, тогда как в окамле вполне можно писать чистый код с тем же успехом.
Все хаскеллисты дрочат на чистоту же.
И не дай Бог заюзать чего-то, что ПОДРЕЗАЕТ КРЫЛЬЯ ОПТИМИЗАТОРУ.
Как всегда у хаскеллистов, такое дрочерство никакого практического смысла не имеет, и в итоге получается #tsfhsf #tsfhse #tsffze #tsfith
нет.
Блять, я нихуя не понимаю, какого ответа ты ждешь.
Ветер в лицо, да. Друзей нету, потому что на нем пишет 35 человек во всем мире. Поэтому не х-ль.
Давай им папир напишем.
Я ждал "В окамле и вот есть, и вот есть, и вот есть — и это всё красота".
Получил "В х-ле и вот есть, и вот есть, и вот есть — и это всё говно".
Я ждал "Окамл, ведь удобно/красиво/правильно, вот смотри:....."
Получил "Окамл, а что ещё? Выхода нет. Ведь в х-ль и усложнён, и гемор, и манатки"
Да ебать тебя в рот.
Ты хочешь, чтобы я по заданному тобой шаблону ответил?
Ты хочешь, чтобы я смотивировал тебя изучать это говно?
в окамле по умолчанию строгий порядок вычислений, что упрощает рассуждения о производительности и ресурсоёмкости кода. (опциональная явная ленивость — в наличии.)
я начинал использовать окамл одновременно с чтением ассемблерного кода, который он генерит, и теперь имею вполне точное представление, что во что компилируется. Из этого я узнал, что цена абстракции в окамле — минимальная, если и есть вообще.
в окамле всегда легко сказать, какой код возьмётся для компиляции данного выражения — например, если написано "a + b", и "+" не переопределяется открытыми модулями (а таких очень мало, почти нет), то я имею гарантию того, что это скомпилируется в одну машинную инструкцию add.
в окамле есть модули с возможностью гибко ограничить структуру сигнатурой. Кроме того, есть функторы (над модулями) — способ создать модуль на основании других модулей. Как пример этого — http://caml.inria.fr/pub/docs/manual-oca...
в окамле есть возможность несложным образом использовать сайдэффекты, что удивительно для функционального языка программирования. Эти сайдэффекты по производительности не хуже дёрганья сишечьки напрямую — например, почти всё из http://caml.inria.fr/pub/docs/manual-oca... — это простые-тупые обёртки над сишными функциями.
в окамле есть подтипизация как на sum types (можно сказать "на индуктивных типах данных"), называется "polymorphic variants", так и на record types, называется "objects".
есть возможность использовать coq для работы с хитрыми типами. Хотя и в х-е это можно, но х-евым эстетам обычно что-то не нравится в результатах экстракции, поэтому они используют агду, которая, на мой взгляд, проигрывает coq'у.
поддерживаются все парадигмы, кроме "логического программирования", в том числе, для особых ценителей, есть грамотное (безопасное и типопроверяемое) ООП. Хотя нахуй оно нужно — не знаю. А вот объекты ( = "записи с подтипизацией") — очень даже нужны.
с другой стороны, не советую окамл в двух случаях:
1. если нужно multicore, но нет возможности асилить message passing / fork / jocaml,
2. если дохуя эстет и не хочешь понимать, что "+" и "+." это разные операции, и в коде должны быть обозначены по-разному.
Я подумал в языке что-то успело понравиться. А не из ненависти к другому языку.
Не писать на языке А только потому, что на языке B всё ещё хуже. Как-то так.
epic
Особенно последнее.
я те шо, академик? Или ты меня таким образом пытаешься оскорбить??77777777
Во, спасибо
3. windows, всё печально, я как-то успел забыть, да жизнь напомнила недавно
да можно там нормально жить, была бы необходимость. Конечно, говноебство, но шо делать.
Вот у нас здесь хаскеллистов много, понимаешь. Смотри, хаскеллисты. Он тебе спать мешают. хаскеллисты. Я, вот, давай здесь папир напишу, и они все прилетят сюда, и запилят функторы, слышишь? И тебе тогда спать будет хорошо. Давай?
:)
жить то можно, но надо знать как. ты это попробуй объясни "нормальному" виндузятнику как собрать пару биндингов, не твоих
кажется, я начинаю о чём-то смутно догадываться...
это да.
Кстати, недавно подумал, что было бы неплохо составить простую статейку о том, что во что компилируется.
так вперде! Или влом?
Да надо.
Сейчас сходил в camlinternalOO.ml. Ебаный свет, а и не думал, что вся эта хуйня в рантайме творится.
Ты ничего не понимаешь в смысле функциональщины.
Разумеется, смысл функциональщины в том, чтобы написать курсовую, обмазавшись манатками, и при этом 30 раз похвалившись в бложик. И после этого идти писать на крестах.
А этот долбоеб на окамле программы пишет.
с точки зрения использования объектов — мало что из этого в рантайме делается. А если работают с закрытым объектным типом, то вообще method lookup по индексу делается.
Мне тут сейчас сообщили, что функторы не нужны, раз есть тайпклассы.
научи же меня, о великий плюсогуро!
ну да, и обмазываться различными newtype по большой нужде. Можно, было бы желание.
Во, гляди, уже все сделали: http://hackage.haskell.org/packages/arch...
да верю. Лепим тип, заворачиваем в него (конструируем значение на каждый чих), разворачиваем, используем тайпкласс-машинерию для всей работы. Сравни с окамловским подходом.
@kb, ты нормально комментарий написать не мог?
ОП, разъебань этого мудака для конструктивной дискуссии.
doen
Ну вот гляди.
Объясняю я человеку, что вот, есть окамл, и в нем есть функторы. Что, вот, берем мы функтор Map, хуячим туда функцию для сравнения и тип для данных. И заебись. А он мне говорит, дескать, нахуй все это надо, когда есть тайпклассы? Вот берем мы, допустим, тип строки, определяем для него инстанс Ord и суем его в х-льную хуйню для Map’ов. И заебись.
Можно написать реализацию слева на окамле, справа на х-ле, и будет видно — где больше этого "заебись".
Там нихуя не будет видно. Как мы уже установили, видно будет тогда, когда нам понадобятся две мапы с разной сравнивающей функцией.
Осталось придумать задачку, где без этого никуда, и реализовать на двух языках.
Только нахуй все это надо?
я думал у вас тут с @kb сейчас конструктивной дискуссии будет. а он молчит.
может я просто не понимаю, что такое функторы в окамле? В хаскеле это тайпкласс Functor с операцией fmap.
со мной дискуссия о подобных темах обычно односторонняя (т.к. знаний у меня мало), потому уж конструктивной ждать не стоит.
Да, не понимаешь.
точно не то. В окамле функторы — такие высокоуровневые модули, которые берут модули как аргументы и возвращают модуль-результат. Там выше дал ссылку на Map.Make — вот оно. Даёшь модуль с типом и сравнением на этом типе, а Map.Make возвращает модуль для работы с avl tree, где ключ имеет указанный нами тип, а сравнения при работе с деревом осуществляются нашей функцией сравнения.
Кстати, во что функторное говно потом комплируется?
интуиция подсказывает, что при создании функтора создаётся что-то вроде записи, содержащей значения модуля-результата, а его использование — в module_record[index_of_value].
Functors are “functions” from structures to structures.
If you keep the signature of the input structure and the signature of the output structure constant,
you are free to change the implementation details without affecting any of the modules that use it.
Functors allow you to write code that will work irrespective of the implementation of the given structure,
and produces a structure containing functions that we are free to modify, but only have to change in one location, that of the functor.
http://caml.inria.fr/cgi-bin/hump.en.cgi... ← ох лол.
ты бы ещё говно мамонта раскопал.
http://web.archive.org/web/2005101905284... http://www.lri.fr/%7Esignoles/ocamldefun... ПАЦАНЫ КАЧЯЕМ
> ты бы ещё говно мамонта раскопал
> OCaml
смешная шутка!
казалось бы: зачем нам нужен параметрический полиморфизм.
лучше будем вместо типов параметризовать модули!
тут недостаточно параметризовать тип типом, нужно как минимум параметризовывать тип значением ( == зависимые типы).
make_map :: (k → Ordering) → Map k v
опять же, на этом примере не вижу необходимости.
м, блджад, у функции сравнения два аргумента, ну вы понели.
А ты сможешь /50 и /51 ?
а потом кто-нибудь будет использовать Map k v, созданный на string и compare_string_case_insensitive при работе с простыми string (с обычной функцией сравнения), и с известным результатом.
ты можешь инстанциировать вот этот модуль Map с двумя разными функциями сравнения — и получить два разных типа Map?
что тебя убережёт от использования Map с compare_string_case_insensitive в местах, где ты хотел использовать другой Map? у обоих типов ведь будет одинаковая сигнатура, я правильно понимаю?
получу два разных _модуля_ Map. Убережёт то, что Map_string.t 'a <> Map_string_insensitive.t 'a (для любого типа значений 'a). Типы разные.
но публичный интерфейс (сигнатура) у них одинаковый, так ведь?
или сигнатур будет две, параметризованных функцией сравнения вместе с модулем?
в общем, вопрос: я могу писать код, который без изменений будет работать с обоими получившимися типами, или нет?
ну, конкретно любой абстрактный алгоритм, которому похуй на детали реализации и подробное упорядочивание в этих мапах, которому просто нужны ключи и значения.
сигнатура отличается, так как в ней тип, представляющий дерево, получается разным.
Код, работающий с любым деревом, написать можно. Для этого код надо завернуть в функтор, берущий нужный модуль как параметр. Или, если работа предстоит несложная, то можно передать в этот абстрактный алгоритм просто нужные функции, например:
# module M = Map.Make(String);;
module M :
[skipped]
# let f find str map = find (str ^ str) map;;
val f : (string → 'a → 'b) → string → 'a → 'b = <fun>
# f M.find "asd" (M.add "asdasd" 123 M.empty);;
- : int = 123
#
что-то я всё равно не догоняю, что ты дальше будешь делать. В х-ле ведь сравнение определено для типов значений (пофиг ключи сравнивать или value). То есть, если ты хочешь создать мапу, у которой ключи будут сравниваться case-insensitive, тебе нужно параметризирвовать тип ключа, вместо String объявив его
newtype ICString = ICString { unICString :: String }
и определив для него `instance Ordering ICString`.
Если же необходим такой Map, в который при складывании значений String они будут потом сравниваться через case-insensitive, то тебе необходимо как-то переопределить функцию `put` (или как она называется, `insert`?) и все остальные функции, принимающие String, чтоб они его превращали в ICString.
Или я чего-то не понял?
Прочитал этот комментарий в обсуждении того, зачем тапиру такой длинный член. Задумался.
"толпы быдла долбятся в стену не видя двери — для них выпиливают люк" (с)
не понял, разверни.
какой-то бред с новыми корявыми сущьностями для решения частной проблемы, когда можно просто взять тайпклассы.
тайпклассы — какой-то бред с новыми корявыми сущностями для решения частной проблемы, когда можно просто взять модули.
ты какой-то неосилятор плюсов.
не "какой-то", а вполне сознательный неосилятор плюсов, если ты про язык погромирования.
нет бессознательный.
т.е. подолбиться любишь, но плюсы неосилил. поэтому долбишься всякой левой хуйнёй.
не люблю я никуда долбиться, тебе показахлось.
мне кажется что это тебе кажется что тебе показалось.
</thread>. Неконструктивно.
прости, но здесь ты не прав
Я предложил конструктивно в /48-/49-/50-/51 и что мне ответил @komar? Он ответил /52. Хотите конструктивно — сконструируйте. А то вы говорите на разных языках. Одни говорят на окамле, другие говорят на хаскеле — и блять искренне удивляются, почему нет понимания между участниками.
Хотя лично я замечательнй ответ о прелестях окамла получил ещё в твоём /22 и можно было закрывать тему после /39. Но в /40 пришёл @komar и решил тему "В окамле и вот есть, и вот есть, и вот есть — и это всё красота" превратить в чатик с топиком "бросание друг в друга говном". Хотя любому участнику дискуссии понятно, что для решения конкретной задачи следует использовать тот инструмент, который наиболее удобен для решения этой конкретной задачи. Короче, [РЕШЕНО]
поиск значения по типу — коряво. Типы — штука, нужная для ограничения кода с целью добавления статических гарантий. Довешивать на типы ещё и "поиск инстанса (значения)" — бред.
Так и оказывается: в случае, когда нужно на один тип навесить более одного значения (пример — разные сравнения для строк), начинается кривизна, пляски с newtype и подобным, только чтобы наебать тот корявый функционал "резолвинга инстансов".
да я вроде особо не бросался говном, если чо. А на неконструктив от @rtsome отвечать как-то лень. Что-то делаю не так?
> Типы — штука, нужная для ограничения
о, ещё один статиканутый уебан. откуда вы лезете блеать? что, до сих пор не видели словосочетания "type level programming" штоле?
>на один тип навесить более одного значения (пример — разные сравнения для строк
для самых тупых цитирую википедию: ...determines the possible values for that type; the operations that can be done on values of that type...
неудивительно что для подобного наёба системы типов приходится как-то извращаться.
пиздец мне припекает от вашей с комаром статиканутости.
Я все ответы на вопрос из /0 получил. Если кто-то в виде бонуса не поленится ещё сконструировать пример с этими злополучными "одновременно с двумя мапками со строковым ключём, в одной из которых операция сравнения будет case insensitive" из которого будет ОЧЕВИДНО, как безблагодатно будут вынуждены ипстись хаскелисты по сравнению с окамлобогами — то это токмо на пользу дела и в посрамление @rtsome
ОЧЕВИДНО что "ОЧЕВИДНО" всем сразу не будет.
ничего этот твой «поиск инстанса» не бред; ты забываешь, что абсолютно всё с типами во времени компиляции ты не сможешь сделать, и в той или иной форме придёшь к рантаймным типам.
ньютайпы для альтернативных инстансов — да, не решение; но мое мнение здесь такое, что нужно изначально правильно параметризовать свой тип. Алсо, всегда можно забить хуй на статические гарантии™ и заюзать smart constructor, как я уже показывал итт.
Ну как же. Если в спор "Молоток или микроскоп" заслать две картинки — одну про "микробы смотреть" другую про "гвоздь забивать", то всем будет очевидно, для чего какой инструмент нужен.
от «более одного значения на тип» я тоже прихуел, но он имел ввиду другое: что типа один статический тип может содержать значения разных РАНТАЙМНЫХ типов. Например, когда в плюсах наследование с vtable, имеем раздельно статический тип переменной и раздельно рантаймное RTTI-«значение», асоциированное с каждым конкретным инстансом, и разное для разных наследников статического типа, и описывающее *рантаймный* тип каждого конкретного инстанса.
ебать я нагородил блджад
"Давайте конструктивно"-гет
рантаймность — это другая плоскость, но сказано было "засунуть два типа в один", да.
там максимум что получится показать — это что хачкель не будет СРАТЬ ОШИБКАМИ, если ты в аргумент типа «регистроНЕчувствительный мап» засунешь регистрочувствительный, сорт оф типа того
работать будет (и даже не выглядеть говном), но вынудит ПИСАТЬ ТЕСТЫ, видимо.
"type level programming" не нужно, слишком много неявного там творится. Конечно, кому как, но мне обычно нужно, чтобы написанный код явно отражал то, что именно он делает.
> the operations that can be done on values of that type...
ну вот, есть как минимум две разные операции сравнения. Тут у нас консенсус.
а если припекает — ну, что ж поделаешь. Извени...
Ты сконструируй и покажи. А "там, наверное, получится только ...., видимо" это как-то слабенько, слабенько. От тебя-то я большего ожидал :(
мне лень, прости; просто попиздоболить без пруфов охота
> ты забываешь, что абсолютно всё с типами во времени компиляции ты не сможешь сделать
в системах с высокоуровневыми типами, типа coq, вполне так всё могу сделать, и многого не будет видно в рантайме.
про "параметризовать свой тип" — как это будет для примера с разными сравнениями строк? Не понимаю.
я имел ввиду НЕ другое. Уточню, что я имел ввиду. По _типу_ String ищется инстанс Ord String, из этого инстанса берётся _значение_ — функция упорядочивания строк.
Фактически, тайпклассы — это способ брать значение по типу.
То есть, по данному типу можно найти 0..1 значение (0 — инстанса нет, 1 — инстанс есть). Проблема начинается, когда хотим, чтобы всё, что завязано на Ord, брало нестандартное значение для данного типа — например, функцию сравнения строк без учёта регистра.
нет, "засунуть два типа в один" я не говорил.
>слишком много неявного
define явно
ну и это говорит человек фапающий на camlp4
>у нас консенсус.
не было такого
>в системах с высокоуровневыми типами, типа coq,
мышление уровня golden hammer
в хачкеле более чем выразительная система типов для твоей задачи
лол, я не фапаю на camlp4. Вообще. Синтаксические расширения считаю говном.
откуда блядь ты знаешь мои задачи???
ну то что ты тут рассказываешь про хешмап
это не моя задача, это пример того, где в х-е будет некрасиво, а в окамле — красиво.
http://www.haskell.org/haskellwiki/Wrapp...
я принципиально убеждён, что «многого» ты таки не сможешь убрать из рантайма. Это интуиция уровня «нельзя написать вебсервер, вычисляющий ответы на запросы ещё во время компиляции». Понимаешь?
Мы можем специализировать многие функции, статически ограничивая их аргументы; но с «внешними», неизбежно рантаймными данными (think: user input, disk, network IO) такие фокусы не сработают.
Скажем, можешь в Coq написать структуру данных вида коллекции чисел (ну как обыкновенный список интов) — которая заполнится юзером на манер do { input := fromUser; theCollection.append(input); } while (input != 0); — и которая сможет гарантировать безопасное индексирование с проверкой границ *не в рантайме*?
я ОЧЕНЬ удивлюсь, если сможешь. По-моему, это принципиально недостижимо.
это то же самое, но другими словами. Можно сказать, что по типу берётся значение некого абстрактного дескриптора рантаймного типа (который уже содержит в себе актуальную функцию сравнения)
>нельзя написать вебсервер, вычисляющий ответы на запросы ещё во время компиляции
но ведь можно же!
смогу-смогу. Суть: количество элементов пихается в тип (получается тип, зависящий от значения), и дальше при любой работе с этой структурой данных мне надо будет предоставлять пруф того, что 0 <= i < count. Если я буду работать с коллекцией в пределах coq, у меня известно, откуда берутся индексы (например, делаю цикл i = от 0 до count-1 — там легко доказать это ограничение на i), и везде я смогу построить пруфы. Далее, при экстракции (в окамл, в х-ь) "количество элементов" будет стёрто из типа, все пруфы будут стёрты систематическим образом, и будет просто код вида
let rec get i lst =
match lst with
| [] → assert false
| [h :: t] → if i = 0 then h else get (i — 1) t
заметь assert false — до этой ветки выполнение не дойдёт.
Если же окажется, что индекс элемента, который хочу взять, доставляют снаружи — тут конечно, придётся проверить его в рантайме. Но это достаточно сделать один раз, потом проверки не нужны.
> Если я буду работать с коллекцией в пределах coq, у меня известно, откуда берутся индексы
в пределах Coq ты можешь сделать ввод списка от юзера через цикл while как я показал?
для наглядности, что я прошу:
>>> theList = []
>>> while True:
... x = int(input())
... if x == 0:
... break
... else:
... theList.append(x)
...
3
5
9
0
>>> theList
[3, 5, 9]
Заметь, здесь нет цикла i = 0..count-1. Здесь цикл while, условие завершения которого зависит от юзерского ввода.
да, это я смогу сделать. Возьму свою наколенную манатку для ввода-вывода (ввод-вывод делается средствами окамла, coq-код при экстракции это использует), дальше всё как в х-е.
Разве что один coq-специфичный момент: нужно доказать завершимость этой функции. Однако, добавив в эту функцию работу со счётчиком "сколько максимум элементов читать", и вызывая функцию со счётчиком, равным 10^100, можно не беспокоиться о завершимости.
> Если же окажется, что индекс элемента, который хочу взять, доставляют снаружи — тут конечно, придётся проверить его в рантайме. Но это достаточно сделать один раз, потом проверки не нужны.
нуууу окей, близко, но всё равно не совсем то. Я добиваюсь признания того, что ВНЕ ЗАВИСИМОСТИ от крутости спектра статических проверок сколь угодно хорошей системы типов полезные программы (то есть, взаимодействующие с внешним миром) без рантаймных аналогов статических проверок не обойдутся. Принципиально. Это как отец Тьюринг, non-termination и святой дух.
покажи плиз
смотря что считать "статическими проверками". _Какие-то_ проверки — по-любому будут. Без них (без использования инструкций условного перехода процессором) только неинтересное можно сделать.
И типы тут не при чём — всё в типах не записать, они не для того нужны. (а для чего — уже говорил в этом итт треде.)
достаточно будет coq-кода, или реализацию манатки (окамловское) тоже показывать? Дело в том, что я её для продакшона писал, а оттуда выносить код как-то нехорошо.
да обыкновенные статические проверки. Проверка совпадения количества аргументов у функции, к примеру. Обычное ведь дело, так? Даже в последнем ссаном говне мамонта делается во время компиляции.
А если функция создана/импортирована/сгенерирована/загружена из какого-нибудь .gir [1] в рантайме?..
[1]: https://git.gnome.org/browse/gobject-int...
вот как быть с такой хуйней в статической системе типов? не писать же, блядь, в конце концов
data GIRFunction = GIRFunction String [GIRType] Ptr — name, params, body
data GIRType = Int | Bool | String | Array [GIRType] | ...
... и потом везде, где её надо запустить, втыкать какой-нибудь evalFunction с оборачиванием параметров в соответствующие конструкторы значения GIRType... не забывая рантаймные проверки соответствия типов и количества параметров нашей сладкой GIRFunction. И вот как здесь обойтись исключительно статическими проверками? Никак. Только в рантайме.
ну, типа, если там BIND @ RETURN, то я и так пойму
А я заебись тогда.
ты вообще дедфуд
Это же комар, хуле ты хотел.
Как мне показалось, @gds вообще о том же // или хз, за тредом не слежу.
о чём же?
Да точно так же, как и с длинной массива (насколько я понял), вообще принципиальной разницы не вижу. В чем проблема доказать, что при каком-то кол-ве аргументов k у считанной (пусть в рантайме) функции, ты никогда не вызовешь над ней eval, передав ей неравное k кол-во аргументов?
хотя бы в том, что во время построения доказательства значение k неизвестно?
Достаточно ограничить любым наперед заданным (например, size_t).
и это убережет меня от передачи трех аргументов функции, принимающей еще-неизвестно-сколько?
как?
я в упор не понимаю, как это возможно.
Что неизвестно? Известно, что k будет интеджером, например. Так вот зачем знать точное значение k, чтоб иметь возможность доказывать, что оно останется тем же, что и массив аргументов? Тебе достаточно будет просто вставить где-то проверку на равенство (Len(arts) == k), и компилятор будет в состоянии все понять (правда, это все мои мокрые фантазии, сам я не пробовал)
спокуха, покажу код, поглядишь, что там возможно, а что нет.
http://gds.psto.net/tsiezf
Друзья, как я уже упомянул в /90 тему можно было закрывать после /39.
Но теперь, когда вы столько наговорили, я напоследок вот что скажу:
Вот посмотрите, как я в /104 пристаю к @ulidtko а он говорит "мне лень"
И тут я совершенно по другому поводу нагуглил один сайт, и там можно сделать именно то, о чём я влажно фантазировал в /49
Итак, господа — взгляните и содрогнитесь — http://langref.org/haskell+ocaml/solved
Всё уже придумано до нас!
Ну и какую полезную информацию можно извлечь из этой хуйни?
Ну вот гляди. Ты написал в /48 текст в стиле "берём, хуячим, и заебись". А вместо этого идёшь по ссылке — и так за тебя взяли, захуячили и заебись.
Только по ссылке — наглядно и с пруфами, а вы тут без пруфов 100 камментов заслали, не понимая друг друга. Потом что так всегда: когда споришь без пруфов, то споришь о словах и их неодинаковом понимании. Нахуй так жить, посоны?
Друх, из этой хуйни я смог узнать только то, что в окамле стдлибы нету.
Отличные комментарии были в #tsfgse/7 и #tsfgse/22
Я про /7 и /22 и не спорю, я очень рад, что @gds сюда заглянул и подробно расписал.
я содрогнулся. Какой ебанат их учил писать на окамле? Кроме того, если нужно решение не низкоуровневое, то есть "батарейки", где многие вещи решаются в пару строк, а не в те простыни.