gudleifr писал(а):
Т.к. "визуальный стек" будет, явно, реализован по-другому, DUP и DROP будут там бесполезны.
А если низкоуровневая реализация (интерпретатор ШК или подпрограммный код) будет традиционной, просто добавится еще "интерпретатор" визуального представления? Если этот интерпретатор (входными данными для него будут не тексты, а списки адресов(?) визуальных структур) будет давать ровно тот же результат, что и обычный интерпретатор?
gudleifr писал(а):
"Мощность" как раз пострадает, т.к. снабжение графическим интерфейсом столь простых сущностей здорово утяжелит систему, неизбежно ограничивая возможности программиста.
Под "мощностью" я имел ввиду функциональные возможности. С учетом того, что я сказал выше, они пострадать не должны. Возможна некоторая потеря скорости, но пока кажется, что возможен даже некоторый выигрыш, если использовать прекомпилированные исходники (как у Мура в colorForth). Редактор, да, будет медленнее, но в графической среде все обычные текстовые редакторы тяжеловесные...
Ограничений программиста не будет, т.к. "визуальность" можно рассматривать как
прозрачную надстройку над обычной системой, но с дополнительным функционалом - подсказки, анализ, генерация исходников, рефакторинг и т.п. .