Возможность программирования на более низком, чем ОЛ схемы уровне

[Владимир Ситников]

так какие проблемы, помогите разработчику

Вы тут сделали 15 опечаток в слове "устройтесь в ОВЕН" )

[capzap]

Вы тут сделали 15 опечаток в слове "устройтесь в ОВЕН" )

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

[Владимир Ситников]

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

Разумеется, делать язык с нуля это непростая задача. Разумеется, простых + - будет недостаточно. Даже потом вкрячить "приведние int-float-int-bool-date-..." уже не так просто. Вкрячить "вызов макросов" (куда же без этого?) -- тоже непросто (даже чисто технически, без оглядки на маркетологов).
Разумеется, если захотеть, то вкрячить можно что угодно куда угодно, но тут мы обсуждаем не несущую зубочистку, а решение которое можно было бы поддерживать хотя бы 5 лет.

Я и говорил, что, если делать, то не блок-формулу, а p-code блок (IL блок). С p-code таких проблем нет. Там проверки правильности гораздо проще, т.к. каждая команда уже почти готова к выполнению. С расширяемостью гораздо проще и т.п.
Да, на IL гораздо сложнее писать (возможно, в большинстве случаев будет сложнее, чем на FBD), но это не страшно, т.к. кому надо те напишут. А уж конверторов в этот самый IL потом можно всех мастей сделать (хоть внутри ОЛ, хоть вне ОЛ).

а вполне серьезная работа которая за день не делается

Я уже приводил свои оценки, сколько займёт прикручивание p-code блока в ОЛ:

Итого 7 мифических человеко-недель = 1.5 (формат) + 0.6 (блок) + 1 (чтение) + 1 (запись) + 1 (компилятор) + 1 (симуляция) + 1 (документация)