UtoECat
в любом случае, если сахар не принесет никакой пользы, то будет просто большая "разминка", я сейчас думаю над системой типов как в .NET и многопоточке
В luau, например, с типами ситуация такая, что они только для анализатора, парсером в vm они игнорятся полностью... В отсутствии типов, на самом деле, есть плюсы... А вот как ты многопоток делать собрался я не знаю...
Михаил
да, нужно перелопачивать систему модулей
таким образом нужно для каждого вызова require собирать свою табличку с выдвинутыми глобальными переменными... и когда модуль вызывается второй раз за время работы программы, нужно эти глобалки снова высунуть.....
Михаил
а что высунуть......
UtoECat
?
Ну или не так оно называется... Representation какой-то там, куда c# и подобные языки компилятся, и он уже портабельный и всё такое. Байткод по сути.
Михаил
ну ладно надо думать
Михаил
пока что махина поддается изменениям и кое-как работает
UtoECat
а я хочу этот анализатор соединить с анализатором для JIT таким образом что жит будет еще ускоряться
Например если обфусцировать код надо, информация о типах это жопа. Как и просто для оптимизаций размера. Это много информационного мусора. Редко когда, но помешает обязательно.
UtoECat
пока что махина поддается изменениям и кое-как работает
В этом и проблема)) Тебе бы на задаче сфокусироваться под которую язык делаешь. а то получится ещё более оторваннее от реальности, чем стандарты c++
Михаил
я думаю над операторами еще
Михаил
вот смотри как тебе этот код
Михаил
local operator<index> ~. = rawget; local operator<newindex> ~. = rawset;
Михаил
теперь можно делать так foo~.bar = 12; точно так же как и rawset
Михаил
и rawget подобно
Михаил
У меня диссонанс)
да, operator<newindex> ~. это функция принимающая 3 значения
Михаил
ровно в том же порядке, как и rawset
Михаил
поэтому я присвоил ей rawset
UtoECat
теперь можно делать так foo~.bar = 12; точно так же как и rawset
rawset не имеет оператора intentionally, как мне кажется) Потому что ими можно сломать логику кастомных index и newindex
Михаил
а в недрах либ где ты намеренно ломаешь логику, там и определяешь этот локальный оператор))
Михаил
Михаил
ТАК ВОТ
Михаил
в чем идея
Михаил
может вообще операторы в стандартных либах не определять?
Михаил
или по минимуму только
Михаил
а определяться они будут только в виде локальных чтобы сокращать код?
Михаил
local operator<index> ~. = rawget; local operator<newindex> ~. = rawset;
именно в таком виде но для других функций
UtoECat
а в недрах либ где ты намеренно ломаешь логику, там и определяешь этот локальный оператор))
Ты её не так часто "ломаешь", чтобы приходилось целый оператор под это выделять)
Михаил
именно в таком виде но для других функций
и тогда вполне можно будет не пользоваться этими setfenv() где попало
Михаил
Ты её не так часто "ломаешь", чтобы приходилось целый оператор под это выделять)
но там у меня он используется примерно 4 раза и мне так проще
Михаил
правда дебажить потом пришлось..
Михаил
Михаил
но продебажил ниче
Михаил
вот у этого (self~.(upper))~.(k) и этого self~.(upper)~.(k) разный смысл
Михаил
когда этот оператор последовательно идет типа self~.upper~.key то все ок
Михаил
слева направо
Михаил
а тут видимо пытается заиметь upper~.(k) а за ним self~.(...)
Михаил
мда, вообще луа более очевидный.. и понятно че синтаксис такой простой и немногословный
UtoECat
а тут видимо пытается заиметь upper~.(k) а за ним self~.(...)
+1 нюанс о котором надо помнить, и о который можно споткнуться)
Михаил
сейчас кажется можно его так засыпать операторами что будет неотличим от брейнфак
Михаил
но не нужно
Михаил
серьезно вот _>>_<<<_[_]>>>>>._<<<_ валидная конструкция только _ не определен и операторы эти
Михаил
а точно
Михаил
но _ я не могу не использовать это имя переменной
Михаил
вообще можно попробовать и без него
UtoECat
вообще можно попробовать и без него
Не, на этом этапе проще уйти в метапрограммирование и генерить луашный код из более простого для работы представления) Тем более, что это не так уж и сложно.
Михаил
но написать библиотеку для такого будет не просто брейнфак это просто термоядерное высушивание мозга будет
Михаил
учитывая что оператор >>>>>. кодируется в нечто.... и его нужно раскодировать
Михаил
чтобы из имени получить количество >
Михаил
а из них по метаметоду __index получить еще кое чего
Михаил
Это вообще один оператор)
да один целый оператор из 6 символов
Михаил
вроде будет __LRop_tgggggr
UtoECat
да один целый оператор из 6 символов
Вот то-то и оно... Не надо пытаться засунуть утку в зайца) или как там оно.
Михаил
проверил > = nameof >>>>>. __LRop_pgggggt
UtoECat
но это возможно...
"Возможно", но не значит, что это делать оптимально.
Михаил
очевидно
UtoECat
очевидно
Даже в исследовательских целях...
Михаил
а это не для пользы. брейнфак это брейнфак
Михаил
мы щас про что говорим
Михаил
про развитие языка или насиловать моск
UtoECat
мы щас про что говорим
Про аналогию утки и bf, и зайца как твоего яп)
Михаил
ну я понял. ладно тогда еще вброшу что я сделал совершеннно бесполезный яп и так же его назвал
UtoECat
про развитие языка или насиловать моск
Ты уже плохо различаешь эти два состояния, мне кажется))
Михаил
уже говорил тут о нем
Михаил
Ну зато опыт)
ну мда, я кое че узнал о GC похожим на плюсовый... и его очень просто сделать когда на плюсах прогаешь
Михаил
ну, shared_ptr
Михаил
не решетка
UtoECat
ну, shared_ptr
Так это не gc)))
Михаил
просто он опциональный
Михаил
его можно реализовать на япе так что он выглядит как gc