Писать Иколайси сложно, у меня возникают баги то тут, то там, а я затыкаю их костылями. Пока не развивал сам Иколайси в -> Иколайси[Лайси], но делаю библиотеку mem. А в ней планирую очень простой сабмодуль vector, состоящий всего из одного дженерика и штук 15 темплейтов. Еле исправил баги, из-за которых темплейты не парсились. Представляете, в правиле парсинга nestedanyth было записано: nestedanyth = dapa.forward()
Тут 2 ошибки. Во-первых вложенность при помощи < и > не должна быть, ведь эти символы используются в операторах сравнения. Во-вторых, я забыл, что dapapy.anything после парсинга не включает в себя токен, который заканчивает dapapy.anything, соответсвенно надо было в каждое миниправило добавить + dplit['rXbracket']. Кстати, насчёт парсинга, я недавно понял, а ведь же современные компиляторы выдают сразу 10, 20, 30 и больше ошибок насчёт кода. Чтобы это сделать, в будущем надо будет перевести парсинг безпроцессинговой части Лайси на парсинг не символов (чарактеров), а токенов. Тогда можно будет сделать отдельные правила для написания инструкций (которые оканчиваются на ;) и потом только проверять правильность их написания, чтобы писать, какие переменные недекларированы и всё такое.
Ещё я подумал о том, что в библиотеку mem надо будет сделать такую хорошую структуру, ух. Я её незвание не придумал, но может будет называться linked. Суть её в том, что есть объект в куче и на него могут ссылаться N указателей и ведётся их учёт. Если удалить один из указателей, то он просто вычтется из структуры учёта, а когда указателей останется 0, то и сам объект удалится. Что-то подобное linked используется у меня в графическом движке и ГУИ-библиотеке, там один и тот же виджет/меш может отрисовываться в разных местах благодаря этому. А хорошо бы, чтоб можно было не только меш перелинковывать, но и материалы, текстуры, анимации и всё такое. Ещё подумываю о том, чтобы в библиотеке mem была такая структура как chunk. Это элемент некоторой размерности, некоторого измерения, который может иметь смежные чанки и у каждого одинаковое кол-во внутренних элементов. Вот майнкрафтовские чанки подходят под такой критерий или ещё какие. Но я не уверен в полезности такого отдельного абстрактного элемента, так как, а что если надо сделать чанки шестиугольными или вообще бесформенными и смежность будет определяться по-другому, незнаю, можно ли это нормально реализовать. И что если будет гораздо удобнее использовать обычные октодеревья или N-деревья, это, конечно же, совершенно другая структура данных, но... А в библиотеку math надо будет сделать сабмодуль image для компьютерного зрения и обработки изображений и других тензоров N-ной размерности. Ну типа фильтр применить, заресмплить, задетектить края или углы, оптический поток и всё такое.
