f
template Attr() {.pragma.}Size: a a a
2021 June 01
G
я генерацию процедур планировал делать через ужасный
implSerializeFor(Kek, Lol, ...)f
Да да, у меня в начале было тоже самое - https://github.com/haxscramper/nimtraits/blob/d09af1e649ccf1435e1313205eb3d28f19f8996a/tests/tNimTraits.nim#L80
G
да-да)
f
Абсолютно идентично. Потом я решил попробовать это все же сделать через дженериг который вызывает макрос с typed аргументом -- пока работает нормально но я постоянну жду какой-то непонятной боли когда оно начнет генерировать невменяемые ошибки изза типов
f
И общей извращенности конструкции
f
there are basically three corners to the triangle of pain.
concepts, statics, and generics.
you mix those together and you are in mratsim territory. woe be the coder who trespasses therein.
so where does handling types in macros go, in your triangle?
okay, so it's a tetrahedron of pain, wise guy.
concepts, statics, and generics.
you mix those together and you are in mratsim territory. woe be the coder who trespasses therein.
so where does handling types in macros go, in your triangle?
okay, so it's a tetrahedron of pain, wise guy.
G
с типами я уже помучался, они просто не выводились, пришлось делать так https://github.com/nim-lang/Nim/issues/16108#issuecomment-732638091
f
И еще нет возможности получить значение констант из самого типа - их просто нет в AST (т.е. там получается что-то совершенно невменяемое когда все константы превращаются в инты и уже нет никакой возможности их получить обратно), так что некоторые типы надо регистрировать через
storeTraits(DocEntry, dekAliasKinds, dekProcKinds, dekStructKinds)f
И еще я поддерживаю значения по умолчанию которые делаются через трехэтажную default прагму которая убирает все значения, но потом через getTypeInst можно получить как они были написаны в коде. Т.е. мне приходится два раза объект парсить и уже потом с этим работать
G
я два раза тип паршу, чтобы дженерик вывести :D
VB
я не парился. у меня просто 1 раз объект разбирается и всё
f
Ну для простых случаев да, это работает, но когда начинаются всякие
enum E = a, bconst c = {a, b}kind: E
of c
f
Мне сказали что для типизированного AST пока нет спецификации так как это практически в чистом виде детали реализации
VB
я такие успешно игнорирую. :) в моём понимании необходимости сериализации таких извращений - нет.
f
Самый крупный пользователь typed макросов это CPS и они какие-то вещи чистят постепенно
f
Ну конкретно это было
(и еще пять сетов), так что я бы не хотел иметь два места в коде где мне нужно постоянно обновлять эти наборы энумов
const dekStructKinds* = { dekObject, dekDefect, dekException, dekEffect }
type
DocEntry* = ref object
case kind*: DocEntryKind
# ...
of dekStructKinds:
superTypes*: seq[DocId]
of dekAliasKinds:
baseType*: DocType(и еще пять сетов), так что я бы не хотел иметь два места в коде где мне нужно постоянно обновлять эти наборы энумов
f
Т.е. да, можно чуть больше забить на эргономику (что я и хотел сделать в какой-то момент), но все же так лучше
f
Функциональных преимуществ понятное дело ноль, только удобство пользования
VB
ну я уже сказал что сериализовать юнионы - изврат по большому счёту + дикий перерасход по памяти.