BD
не знаю как устроен мадболге, где можно поизучать, погуглил быстренько, но ненашёл
http://www.lscheffer.com/malbolge_spec.html оф спека вот
Size: a a a
2020 February 02
YS
Надо пристально смотреть на реализацию, но insert может стать мутабельным, если мапа используется линейно.
ну, это очевидные общие слова. я надеялся увидеть про подмену реализаций через rewrite rules, например
AT
ну, это очевидные общие слова. я надеялся увидеть про подмену реализаций через rewrite rules, например
Мы же линейные типы обсуждали - при чём тут rewrite rules?
YS
Мы же линейные типы обсуждали - при чём тут rewrite rules?
переписывать иммутабельный Map на мутабельный Map в случае линейности
C
спасиб, но хочу уточнить, что интерпретатор брайнфака на препроцессорах си не моя работа
YS
переписывать иммутабельный Map на мутабельный Map в случае линейности
без переписывания пользовательского кода
BD
спасиб, но хочу уточнить, что интерпретатор брайнфака на препроцессорах си не моя работа
я понимаю, я про то, что написать хоть что-нибудь на малболге - довольно сложная задача, даже для генераторов
YS
Мы же линейные типы обсуждали - при чём тут rewrite rules?
мы всё ещё обсуждаем линейные типы. а точнее, вот этот тезис: https://t.me/CompilerDev/54653
AT
переписывать иммутабельный Map на мутабельный Map в случае линейности
У rewrite rules в Haskell нет доступа к информации о типах и, соответственно, линейности. Поэтому сначала переписывание, а уже потом линейность в компиляторе.
λ
А! Есть всё-таки ещё борцы за инклюзивность кроме меня! 😄
Но я всё равно глубоко убеждён, что читать молча - предпочтительный режим, особенно, когда речь идёт о чём-то вне твоей сферы знаний. Даже не пытайтесь меня переубедить! 😄
Но я всё равно глубоко убеждён, что читать молча - предпочтительный режим, особенно, когда речь идёт о чём-то вне твоей сферы знаний. Даже не пытайтесь меня переубедить! 😄
ого, какое высокомерие )
AT
Наверное, в Idris 2 со всяким elaborator reflection может быть так как ты хочешь.
AT
ого, какое высокомерие )
Это Вы просто меня пока ещё плохо знаете! 😂
YS
У rewrite rules в Haskell нет доступа к информации о типах и, соответственно, линейности. Поэтому сначала переписывание, а уже потом линейность в компиляторе.
ну, значит, не rewrite rules. или не в текущем виде. просто это первое, что приходит в голову, когда я думаю об оптимизации в компиляторе, ведомой библиотекой
λ
Это Вы просто меня пока ещё плохо знаете! 😂
учту 😂
AT
мы всё ещё обсуждаем линейные типы. а точнее, вот этот тезис: https://t.me/CompilerDev/54653
Хорошо, признаю, что неудачно выразился. Без переписывания кода мало что заработает. Скорее, даже, не то, что хотелось бы. Это вообще если аннотации линейности будут сами выводиться, в чём я сомневаюсь.
AT
ну, значит, не rewrite rules. или не в текущем виде. просто это первое, что приходит в голову, когда я думаю об оптимизации в компиляторе, ведомой библиотекой
Вот "ведомой библиотекой" не будет. Не в обозримом будущем. 😔
YS
Хорошо, признаю, что неудачно выразился. Без переписывания кода мало что заработает. Скорее, даже, не то, что хотелось бы. Это вообще если аннотации линейности будут сами выводиться, в чём я сомневаюсь.
перечитал. это я неправильно тебя истолковал
AT
перечитал. это я неправильно тебя истолковал
Но это значит, что я недостаточно внятно написал. 😊
МБ
Хорошо, признаю, что неудачно выразился. Без переписывания кода мало что заработает. Скорее, даже, не то, что хотелось бы. Это вообще если аннотации линейности будут сами выводиться, в чём я сомневаюсь.
Есть парочка языков - SISAL и SAC (Single Assignment C), в них эта задача была решена довольно давно. Код пишется функциональный, без явной линейности в типах, но компилятор видит, где массивы (или frame-ы в случае SISAL) последовательно thread-ятся, и в этих местах повторно использует память. SISAL в какие-то времена был эффективнее Фортрана.
И алгоритмы эти, вроде не такие уж сложные, чтобы не иметь возможности закодировать их в системе типов. В Haskell же есть стрелка
И алгоритмы эти, вроде не такие уж сложные, чтобы не иметь возможности закодировать их в системе типов. В Haskell же есть стрелка
-o? SPJ рассказывал уже. Проверить, к сожалению, пока не могуAT
Есть парочка языков - SISAL и SAC (Single Assignment C), в них эта задача была решена довольно давно. Код пишется функциональный, без явной линейности в типах, но компилятор видит, где массивы (или frame-ы в случае SISAL) последовательно thread-ятся, и в этих местах повторно использует память. SISAL в какие-то времена был эффективнее Фортрана.
И алгоритмы эти, вроде не такие уж сложные, чтобы не иметь возможности закодировать их в системе типов. В Haskell же есть стрелка
И алгоритмы эти, вроде не такие уж сложные, чтобы не иметь возможности закодировать их в системе типов. В Haskell же есть стрелка
-o? SPJ рассказывал уже. Проверить, к сожалению, пока не могуВ том-то и дело, что линейной стрелки в GHC всё ещё нет. Как только появится - так сразу и заживём! 😃