Основные операторы у всех текстовых языков одни и те же. По этой причине пользователю Каскды без разницы какой текстовый язык будет использован при разработке макросов. Разработчику Каскады нужен готовый компилятор текстового языка, который можно интегрировать в Каскаду. Тут бы В.Ситникова надо послушать, он бы мог что-то толковое посоветовать.Сообщение от rovki
Последний раз редактировалось IVM; 04.07.2019 в 10:28.
Да. Вы правы. Ситникова послушать было бы полезно.Но он вряд ли опустится до таких
мелочей.
Последний раз редактировалось Andrey2; 03.07.2019 в 20:48.
Вы раньше под каким ником были?
HMI for Android http://www.hmi-kascada.ru/kaskada/
Я два года просто наблюдал. Но когда речь зашла о текстовом языке в Каскаде-решил высказать свои соображения. Потому
что это интересное направление. Я внимательно читал высказывания Сапкара-но они мне как бы не. Послушать бы ещё Ситникова. Мне просто интересно послушать автора и мнения специалистов. Я сам не очень. Просто интересно знать вектор развития.
Последний раз редактировалось Andrey2; 03.07.2019 в 21:20.
У вас есть Каскада (с сайта),если есть ,я дам ключ ,что бы поиграли...?
электронщик до мозга костей и не только
Я же сообщил,что игрался.Года полтора назад.
1) Про Android я не особо в курсе, и с Rhino могут быть проблемы. Например, Rhino (~JavaScript) на обычной Java активно генерирует код для оптимизации вычислений. Не факт, что это всё допустимо в Android. Например, может оказаться, что Rhino запускается, но работает крайне медленно
2) По моему опыту (разработки среды программирования на ST), ST -- неудачный язык с точки зрения системы типов. Там понамешали знаковых, беззнаковых битовых и прочих типов, при этом в стандарте нет чёткого определения того, какой тип переходит в какой.
3) При добавлении "скриптового языка" важно определиться каким образом будет идти обращение аргументам и состоянию системы.
Например, если пишем макрос преобразования датчика, то всё просто: у него вход это значение датчика, выход это результат обработки. И ничего другого такому блоку не нужно.
Если же значение хочет зависеть, например, от "текущего номера экрана", то уже интереснее.
Можно "текущий номер экрана" объявлять точно так же входным сигналом этого блока (т.е. из текстового языка разрешать обращение только ко входам). Это неплохой подход, и при этом будет сразу видно "от чего зависит блок". Но, возможно, придётся объявлять слишком много. Например, если блок зависит от времени, то удобно бы было обращаться к "текущему времени" без объявления его отдельным входом.
И тут начинается: "всегда существующая переменная с номером экрана", "всегда существующая переменная с текущем временем" (а, возможно, это несколько переменных, т.к. переменные "час", "минута" тоже удобны, и на Android не хочется набирать длинных выражений в духе to_number(to_char(current_date(), "HH")). И к прочим системным регистрам (или как они в К* называются) тоже удобно обращаться прямо так.
Так тоже можно делать, но главное сделать так, чтобы для каждого вычисления не приходилось заново проставлять текущие значения всех этих переменных. Ведь окажется, что выражение простое (x+y*z), а для его вычисления мы начинаем проставлять 100500 переменных (которые потом не используются).
Вот пример кода из Apache JMeter: https://github.com/apache/jmeter/blo...java#L123-L149
Там они для каждого выполнения скрипта проставляют 11 переменных, и делать так в К* вряд ли желаемо.
Конечно, варианты есть, и нужно просто задуматься над этим. Как видно, в JMeter не задумались.
По языкам же, думаю, стоит перебрать несколько популярных и посмотреть в каком состоянии есть готовые реализации для Android и не сильно ли косо будут выглядеть формулы.
JavaScript (возможно), Lua (возможно), Python (вряд ли)
Эзотерика в духе ClojureScript, Forth, Tcl, Eta-lang это забавно, но вряд ли для К*
Ваши права
Ответить с цитированием