@ProLuaSnooze - страница 524

Михаил

Типо... Ты буквально переизобретёшь dotnet и IR на этом этапе)) Не то, что это плохо...

?

UtoECat

в любом случае, если сахар не принесет никакой пользы, то будет просто большая "разминка", я сейчас думаю над системой типов как в .NET и многопоточке

В luau, например, с типами ситуация такая, что они только для анализатора, парсером в vm они игнорятся полностью... В отсутствии типов, на самом деле, есть плюсы... А вот как ты многопоток делать собрался я не знаю...

Михаил

да, нужно перелопачивать систему модулей

таким образом нужно для каждого вызова require собирать свою табличку с выдвинутыми глобальными переменными... и когда модуль вызывается второй раз за время работы программы, нужно эти глобалки снова высунуть.....

Михаил

а что высунуть......

UtoECat

?

Ну или не так оно называется... Representation какой-то там, куда c# и подобные языки компилятся, и он уже портабельный и всё такое. Байткод по сути.

Михаил

В luau, например, с типами ситуация такая, что они только для анализатора, парсером в vm они игнорятся полностью... В отсутствии типов, на самом деле, есть плюсы... А вот как ты многопоток делать собрался я не знаю...

а я хочу этот анализатор соединить с анализатором для JIT таким образом что жит будет еще ускоряться

UtoECat

таким образом нужно для каждого вызова require собирать свою табличку с выдвинутыми глобальными переменными... и когда модуль вызывается второй раз за время работы программы, нужно эти глобалки снова высунуть.....

Куда высунуть, ты о чём?) Глобалки в такой конфигурации... Не глобалки вообще) в которой я описал

UtoECat

Куда высунуть, ты о чём?) Глобалки в такой конфигурации... Не глобалки вообще) в которой я описал

Там полная изоляция именно

Михаил

ну ладно надо думать

Михаил

пока что махина поддается изменениям и кое-как работает

UtoECat

а я хочу этот анализатор соединить с анализатором для JIT таким образом что жит будет еще ускоряться

Например если обфусцировать код надо, информация о типах это жопа. Как и просто для оптимизаций размера. Это много информационного мусора. Редко когда, но помешает обязательно.

UtoECat

пока что махина поддается изменениям и кое-как работает

В этом и проблема)) Тебе бы на задаче сфокусироваться под которую язык делаешь. а то получится ещё более оторваннее от реальности, чем стандарты c++

Михаил

я думаю над операторами еще

Михаил

вот смотри как тебе этот код

Михаил

local operator<index> ~. = rawget; local operator<newindex> ~. = rawset;

Михаил

теперь можно делать так foo~.bar = 12; точно так же как и rawset

Михаил

и rawget подобно

UtoECat

local operator<index> ~. = rawget; local operator<newindex> ~. = rawset;

У меня диссонанс)

Михаил

У меня диссонанс)

да, 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

серьезно вот _>>_<<<_[_]>>>>>._<<<_ валидная конструкция только _ не определен и операторы эти

Погоди, в bf нет же стандартном _ оператора? Там только +-<>[].,

Михаил

а точно

Михаил

но _ я не могу не использовать это имя переменной

Михаил

вообще можно попробовать и без него

UtoECat

вообще можно попробовать и без него

Не, на этом этапе проще уйти в метапрограммирование и генерить луашный код из более простого для работы представления) Тем более, что это не так уж и сложно.

Михаил

но написать библиотеку для такого будет не просто брейнфак это просто термоядерное высушивание мозга будет

Михаил

учитывая что оператор >>>>>. кодируется в нечто.... и его нужно раскодировать

Михаил

чтобы из имени получить количество >

UtoECat

учитывая что оператор >>>>>. кодируется в нечто.... и его нужно раскодировать

Это вообще один оператор)

Михаил

а из них по метаметоду __index получить еще кое чего

Михаил