Вот я излагал логическую схему. Она нужна, чтобы смотреть на нее целиком, а не на пункты по отдельности. Повторю, поэтому:
1) Предположим, что для того, чтобы HiAsm встал в ряд с общеупотребимыми языками программирования - необходимо признание сообщества "продвинутых программеров"
2) Первый пункт возражения - конечность элементной базы для решения любой задачи. Решаем низкоуровневой элементной базой + механизмом контейнеров (с наследованиями, и т.п..). Чем ниже уровень интеграции, тем меньше объем элементной базы.
Ну и для "любых" остаются 2 позиции: рекурсии, и динамические указатели на класс (решаемо, но требует отдельного обсуждения).
3) Но чем ниже этот уровень, тем острей становится вопрос эффективности результирующего кода. Именно для признания. Тестировать правильность решений по 1-му пп. пункту можно и на устойчивой, но неэффективной схеме кодогенерации.
4) Как вывод: ну никуда мы не денемся от создания своего парсера, чтобы объяснить "продвинутому сообществу", что новый класс (элемент) на каждый чих - это совсем не то, что они привыкли видеть в результирующих кодах классических компиляторов (и что интересно - там это их значительно меньше расстраивает, чем в HiAsm).
Но получается - не совсем связанные это вопросы, как-бы
Создание возможностей в среде - это круг решаемых задач.
Один прием "ай достаточно прописать" чего стоит.
Функционирование проверяем на имеющейся схеме.
Параллельно - сильно думаем над парсером.
И даже после начала функционирования 4-й версии - должно быть какое-то время совместного существования.
Думается...
Вот Вячеслав-то расстроится из-за вопросов совместимости
Поиск
Друзья
Администрация