AZ
может таки в LanguageDev?
Size: a a a
2020 December 03
AT
Ресурс, но не ресурс класса, все просто класс его не контролирует значит не управляет им, вырожденые случае вида класс контролирует свою же память предлагаю не рассматривать
Это какая-то демагогия с C++ головного мозга, ИМХО.
AT
может таки в LanguageDev?
Makes sense.
BD
M
Pavel Samolysov
Столкнулся с таким вопросом, хотя это возможно больше про дизайн языков. В расте нет non-type template parameters, назовем это так. В С++ уже очень давно можно передавать значение int/size_t как параметр шаблона. Иногда это очень удобно, например у нас есть матрица и мы можем при компиляции проверить, что она квадратная, определив функцию перемножения, как multiply<size_t>(matrix<size_t, size_t> A, matrix<size_t, size_t> B) -> matrix<size_t, size_t> (псевдокод).
Но в реальности то матрицы скорее всего будут загружаться в рантайме из какого-нибудь источника, хотя размеры и могут быть строго заданы: "вот тебе матрица 32x32, а значения я заполню в рантайме". Однако если алгоритм перемножения рекурсивный, Strassen, например, то при компиляции для умножения матриц 32x32 должны будут сгенерироваться процедуры для 16x16, 8x8 и т.д. Т.е. код сильно разбухает. Возникает вопрос как избежать этого trade off'а: и размер в компайл-тайме проверить и код не раздувать. Есть ли какие-то для этого механизмы в языках программирования вообще и в языках без non-type template parameters в частности?
Но в реальности то матрицы скорее всего будут загружаться в рантайме из какого-нибудь источника, хотя размеры и могут быть строго заданы: "вот тебе матрица 32x32, а значения я заполню в рантайме". Однако если алгоритм перемножения рекурсивный, Strassen, например, то при компиляции для умножения матриц 32x32 должны будут сгенерироваться процедуры для 16x16, 8x8 и т.д. Т.е. код сильно разбухает. Возникает вопрос как избежать этого trade off'а: и размер в компайл-тайме проверить и код не раздувать. Есть ли какие-то для этого механизмы в языках программирования вообще и в языках без non-type template parameters в частности?
В C++ - шаблоны, в Rust - дженерики. Все что вы описали одно из отличий шаблонов и дженериков. Дженерики еще могут по разному резолвиться, не только через мономерфизацию, поэтому там нельзя передавать значения в качествен папаметров. А шаблоны всегда мономирфизируются
А⚙
Народ вон как с refinement types развлекается: https://conf.researchr.org/details/aplas-2020/aplas-2020-papers/4/Neural-Networks-Secure-by-Construction-An-Exploration-of-Refinement-Types 😃
Grenade на Haskell так работает
PS
В C++ - шаблоны, в Rust - дженерики. Все что вы описали одно из отличий шаблонов и дженериков. Дженерики еще могут по разному резолвиться, не только через мономерфизацию, поэтому там нельзя передавать значения в качествен папаметров. А шаблоны всегда мономирфизируются
В растбуке написано, что в расте дженерики тоже мономорфизируются. Нашел RFC 2000 что-ли про Non-type generic parameters, но пишут, что реализовать его не так то просто. Мне сейчас интересно насколько то же умножение матриц раздуется если сделать на шаблонах того же С++, ну и вот подсказали идею с зависимыми типами.
А⚙
Pavel Samolysov
В растбуке написано, что в расте дженерики тоже мономорфизируются. Нашел RFC 2000 что-ли про Non-type generic parameters, но пишут, что реализовать его не так то просто. Мне сейчас интересно насколько то же умножение матриц раздуется если сделать на шаблонах того же С++, ну и вот подсказали идею с зависимыми типами.
Технически можно изобразить типа-числа на уровне типов и делать оптимизации на основе специализаций по размеру
M
Нет это не RAII, holding a resource is a class invariant, and is tied to object lifetime, что говорит вики, и с чем сложно поспорить, а rust как раз про lifetime и про то что он вычисляется а не привязан к скоупу или не менеджиться в ручную.
Проще говоря в расте обьект может жить и несколько с половиной скоупов завися от прописаных лайфтаймов
Проще говоря в расте обьект может жить и несколько с половиной скоупов завися от прописаных лайфтаймов
В Rust RAII, тольно он действительно не обязан быть привязан к скоупу а может быть привязан к жизненному циклу другого объекта, в этом и заключается лайфтайм анализ - проверить все эти условия. Ну и без подсказок для анализатора ему это будет трудно сделать (читай долго) поэтому и придумали хинты для лайфтаймов. Но в Rust не полностью статическая память, все еще требуются счетчики ссылок
PS
Технически можно изобразить типа-числа на уровне типов и делать оптимизации на основе специализаций по размеру
Да, думал завести какие-нибудь степени двойки, например, обернув их в типы и попробовать ими параметризовать.
А⚙
В Rust RAII, тольно он действительно не обязан быть привязан к скоупу а может быть привязан к жизненному циклу другого объекта, в этом и заключается лайфтайм анализ - проверить все эти условия. Ну и без подсказок для анализатора ему это будет трудно сделать (читай долго) поэтому и придумали хинты для лайфтаймов. Но в Rust не полностью статическая память, все еще требуются счетчики ссылок
Не "трудно", а невозможно. Вот есть функция
fn choose(&i32, &i32) -> &i32 — как тут правильно расставить лайфтаймы?А⚙
Pavel Samolysov
Да, думал завести какие-нибудь степени двойки, например, обернув их в типы и попробовать ими параметризовать.
Посмотри nalgebra
s
Не "трудно", а невозможно. Вот есть функция
fn choose(&i32, &i32) -> &i32 — как тут правильно расставить лайфтаймы?На основе тела функции. Полагаем лайфтаймы
'a, 'b, 'c, выводим ограничения.M
Не "трудно", а невозможно. Вот есть функция
fn choose(&i32, &i32) -> &i32 — как тут правильно расставить лайфтаймы?И невозможно в том числе. Но в вашем примере все зависит от того что внутри функции choose. Если она тривиальная, то лайфтайм анализ мог бы ее обработать. Да просто банально заинлайнить и потом обработать. Но если там циклы рекурсии и т д то это уже становиться очень похожим на то, что делается во время online partial evaluation - не консервативный анализ
А⚙
На основе тела функции. Полагаем лайфтаймы
'a, 'b, 'c, выводим ограничения.Это непрактично
PS
Посмотри nalgebra
Спасибо за наводку. Посмотрел еще typenum, который они используют, как раз реализация вашей идеи с числами-типами.
M
В Rust RAII, тольно он действительно не обязан быть привязан к скоупу а может быть привязан к жизненному циклу другого объекта, в этом и заключается лайфтайм анализ - проверить все эти условия. Ну и без подсказок для анализатора ему это будет трудно сделать (читай долго) поэтому и придумали хинты для лайфтаймов. Но в Rust не полностью статическая память, все еще требуются счетчики ссылок
Можно ссылку? Не то что бы я не верил понятно что будут краивые случаи, которые понятно дело можно и с лайфтаймами посчитать но месяцами, но не представляю как они с явными могут возникнуть
M
Pavel Samolysov
В растбуке написано, что в расте дженерики тоже мономорфизируются. Нашел RFC 2000 что-ли про Non-type generic parameters, но пишут, что реализовать его не так то просто. Мне сейчас интересно насколько то же умножение матриц раздуется если сделать на шаблонах того же С++, ну и вот подсказали идею с зависимыми типами.
Не делайте, это путь александреску и КО. Лучше сделать на метапрограммировании если вам нужно гененрировать и на compile time execution если считать в compile time
M
Тоесть в теории понятно что можно, но в реальности помойму нет ни одного случая когда нужно
PS
Не делайте, это путь александреску и КО. Лучше сделать на метапрограммировании если вам нужно гененрировать и на compile time execution если считать в compile time
В расте получается только через макрос.