История изменений

вот смотри как сейчас сделан litle-lang

Это я ещё с первого раза понял, и почему не нравится, тоже ясно. Но тут вопрос в том, парсер заменён или добавлен второй. Судя по Судя по тому, что «Little can call Tcl, Tcl can call Little», добавлен второй. Т.е. тебя напрягает то, что он прибит гвоздями к одной версии, и эта версия, вообще говоря, не та, которая тебе нужна? Но ведь можно тянуть этот форк, и применять патч к каждой следующей версии tcl/tk. Останется только проблема того, что он будет конфликтовать с существующим, но тогда его можно просто переименовать.

иметь в build зависимостях сорцы tcl, нужные ему от tcl функции получать от libtcl.so.

Это возможно только в случае, если tcl экспортирует достаточно для того, чтобы это реализовать. Это во-первых. Когда я делал Яр, я сделал достаточно много форков. Потому что даже в лиспе с его «всё паблик», декораторами и горячим переопределением далеко не всегда возможно держать в стороне нужный тебе патч. Иногда патчить исходники - это, по сути, единственная возможность получить решение, принципиально отличающееся от форка. А уж в Си возможностей для этого на порядок меньше. Поэтому вместо того, чтобы кодить, они боролись бы с запретами, и не факт, что победили бы. Это я говорю абстрактно, не глядя в код tcl/tk, может быть там всё шоколадно. Но я просто из опыта подобного проекта могу предположить, что им нужна была вся инфраструктура интерпретатора tcl/tk, в т.ч. private части.

Но в целом, конечно, то, как ты хочешь, было бы лучше для пользователей.

вот смотри как сейчас сделан litle-lang

Это я ещё с первого раза понял, и почему не нравится, тоже ясно. Но тут вопрос в том, парсер заменён или добавлен второй. Судя по Судя по тому, что «Little can call Tcl, Tcl can call Little», добавлен второй. Т.е. тебя напрягает то, что он прибит гвоздями к одной версии, и эта версия, вообще говоря, не та, которая тебе нужна? Но ведь можно тянуть этот форк, и применять патч к каждой следующей версии tcl/tk. Останется только проблема того, что он будет конфликтовать с существующим, но тогда его можно просто переименовать.

иметь в build зависимостях сорцы tcl, нужные ему от tcl функции получать от libtcl.so.

Это возможно только в случае, если tcl экспортирует достаточно для того, чтобы это реализовать. Это во-первых. Когда я делал Яр, я форкал всё, что мне нужно. Потому что даже в лиспе с его «всё паблик», декораторами и горячим переопределением далеко не всегда возможно держать в стороне нужный тебе патч. Иногда патчить исходники - это, по сути, единственная возможность получить решение, принципиально отличающееся от форка. А уж в Си возможностей для этого на порядок меньше. Поэтому вместо того, чтобы кодить, они боролись бы с запретами, и не факт, что победили бы. Это я говорю абстрактно, не глядя в код tcl/tk, может быть там всё шоколадно. Но я просто из опыта подобного проекта могу предположить, что им нужна была вся инфраструктура интерпретатора tcl/tk, в т.ч. private части.

Но в целом, конечно, то, как ты хочешь, было бы лучше для пользователей.