DRAKON.SU

Текущее время: Суббота, 27 Апрель, 2024 21:32

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 242 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 13  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 21 Июнь, 2020 18:24 

Зарегистрирован: Понедельник, 15 Июнь, 2020 19:38
Сообщения: 179
Владимир Паронджанов писал(а):
Михаил Кузьмин писал(а):
Транслятор готовит данные. Выполнение происходит в виртуальной машине.

Если я правильно понял, у Михаила Кузьмина на выходе транслятора отсутствует исполняемый код (executable code).

Именно так Михаил и задумал. Михаил создал транслятор, который готовит данные (декларации), но не исполняемый код.

Таким образом транслятор Михаила Кузьмина отличается от обычного транлятора.

Может быть, это отличие стоит закрепить терминологически.
Транслятор Михаила Кузьмина — это декларативный транслятор, сокращенно детранслятор, или Д-транслятор.

https://ru.wikipedia.org/wiki/%D0%A2%D1 ... 0%BE%D1%80
Это из википедии терминология..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 21 Июнь, 2020 18:43 

Зарегистрирован: Понедельник, 15 Июнь, 2020 19:38
Сообщения: 179
Детранслятор выполняет обратную работу. Из кода делает текст.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 21 Июнь, 2020 18:59 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5851
Откуда: Москва
Михаил Кузьмин писал(а):
Детранслятор выполняет обратную работу. Из кода делает текст.
Вы правы, я ошибся.

Вот исправленный текст.
Цитата:
Может быть, это отличие стоит закрепить терминологически.
Транслятор Михаила Кузьмина — это декларативный транслятор, сокращенно Д-транслятор.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 21 Июнь, 2020 19:07 

Зарегистрирован: Понедельник, 15 Июнь, 2020 19:38
Сообщения: 179
Владимир Паронджанов писал(а):
Транслятор Михаила Кузьмина — это декларативный транслятор, сокращенно Д-транслятор.

Если увижу определение этого термина, то с удовольствием и сразу соглашусь


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 21 Июнь, 2020 19:34 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5851
Откуда: Москва
Владимир Паронджанов писал(а):
Транслятор Михаила Кузьмина — это декларативный транслятор, сокращенно Д-транслятор.

Михаил Кузьмин писал(а):
Если увижу определение этого термина, то с удовольствием и сразу соглашусь

Это для меня трудная задача. Могу ошибиться, но попробую.
Цитата:
Декларативный транслятор — это транслятор, который готовит декларации (данные) для передачи их в виртуальную машину (например, в контроллер) для формирования исполняемого кода и исполнения. Декларативный транслятор не создает исполняемый код.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 21 Июнь, 2020 20:25 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 133
Откуда: Киев
Михаил Кузьмин писал(а):
Для разработки и отладки это очень удобно.
Это абсолютно неудобно. Повторюсь, у меня даже диска D: не было, чтобы поместить туда файл. Требовать помещать что-то в корень диска хоть в целях отладки, хоть в иных целях - это бессмыслица.

Михаил Кузьмин писал(а):
Comdiv писал(а):
Единственное, что удалось понять, это то, что ничего не работает. На любую попытку запуска кнопкой Start, выдаётся исключение.
То, что я хотел объяснить, я писал. Что вы хотели увидеть я не знаю.
Может быть, я хотел увидеть, что для начала хотя бы трансляция пройдёт без выпадения исключений? Уж не знаю как понимать Ваш ответ. Может, Вы не понимаете, что означает "выдаётся исключение"?

Михаил Кузьмин писал(а):
Comdiv писал(а):
Полное описание означает набор деклараций? Исполняемого кода там нет.
На этот вопрос я частично ответил в начале описания своей системы. Вы, видимо, не обратили внимания. Необходимо поменять представление о работе компьютера. Моя машина полностью определяется декларациями.
Вы это заявили, но не ответили, что не одно и то же. И уже судя по примерам НОД и сортируемого массива, Вы сами опровергли заявленное, так как в примерах исполняемый код есть. Заявлять-то можно любое технофэнтэзи.

Михаил Кузьмин писал(а):
Все понятия формализованы. Это принципиальное построение системы. Здесь нет ничего что не определено. От типов данных, до структуры, синтаксиса и выполнения. Т.е. Мы имеем голую память. Загружаем систему и она начинает работать.
Если говорить откровенно, "формализация" похожа на шизофазию. Работающий код мог бы это опровергнуть, но ничего не работает. Трансляция завершается выпадением исключения, а программы для исполнения кода, как выяснилось, Вы даже не стали предоставлять. Вы думали, что без исполнения трансляция непонятно чего в непонятно что имеет смысл? Это если бы трансляция, хотя бы, работала. Сейчас я могу подтвердить лишь то, что программа на Visual Basic, похожая по исполнению на переделанный стандартный пример-редактор, при собственной загрузке умеет загружать какое-то содержимое из файла D:\Lad.Lada и позволяет загружать и редактировать rtf-файлы.

Михаил Кузьмин писал(а):
Что вам нужно зависит от того. что вы хотите попробовать. Вы просили транслятор, я вам его прислал. Что б понять что вы хотите посмотреть надо общаться.
Скажите, что ещё я должен написать, чтобы стало понятней о цели получения транслятора, кроме написанного ранее:
Цитата:
Транслятор нужен для того, чтобы пробовать что-нибудь писать и тут же исполнять.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 21 Июнь, 2020 20:27 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 133
Откуда: Киев
Владимир Паронджанов писал(а):
Д-транслятор.
Получился нечаянный сарказм


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 21 Июнь, 2020 20:39 

Зарегистрирован: Понедельник, 15 Июнь, 2020 19:38
Сообщения: 179
Comdiv писал(а):
Владимир Паронджанов писал(а):
Д-транслятор.
Получился нечаянный сарказм

Та ничего. Зато теперь я знаю зачем нужен транслятор.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 22 Июнь, 2020 09:21 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5851
Откуда: Москва
Comdiv писал(а):
Транслятор нужен для того, чтобы пробовать что-нибудь писать и тут же исполнять.

Если согласиться с таким пониманием транслятора, как считает Comdiv, то термин "транслятор" в сообщениях Михаила Кузьмина порождает недоразумения и вводит в заблуждение.

Значительная часть сообщений этой темы была вызвана разной трактовкой понятия "транслятор".

Как же быть?

Для того, чтобы подобные недоразумения не возникали впредь, желательно, чтобы Михаил отказался от вводящего в заблуждение термина "транслятор", потому что
Comdiv писал(а):
без исполнения трансляция непонятно чего в непонятно что


По-видимому, здесь нужен какой-то другой термин.
Может быть, подойдет термин "препроцессор"?

Или я не прав?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 22 Июнь, 2020 09:26 

Зарегистрирован: Понедельник, 15 Июнь, 2020 19:38
Сообщения: 179
Владимир Паронджанов писал(а):
Если согласиться с таким пониманием транслятора, как считает Comdiv, то термин "транслятор" в сообщениях Михаила Кузьмина порождает недоразумения и вводит в заблуждение.

Значительная часть сообщений этой темы была вызвана разной трактовкой понятия "транслятор".

Как же быть?

Для того, чтобы подобные недоразумения не возникали впредь, желательно, чтобы Михаил отказался от вводящего в заблуждение термина "транслятор", потому что
Comdiv писал(а):
без исполнения трансляция непонятно чего в непонятно что


По-видимому, здесь нужен какой-то другой термин.
Может быть, подойдет термин "препроцессор"?

Или я не прав?

https://ru.wikipedia.org/wiki/%D0%A2%D1 ... 0%BE%D1%80
Цитата:
Виды трансляции:

компиляция;
в исполняемый код
в машинный код
в байт-код
транспиляция;
интерпретация;
динамическая компиляция.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 22 Июнь, 2020 10:29 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 133
Откуда: Киев
Владимир Паронджанов писал(а):
Comdiv писал(а):
Транслятор нужен для того, чтобы пробовать что-нибудь писать и тут же исполнять.
Если согласиться с таким пониманием транслятора, как считает Comdiv, то термин "транслятор" в сообщениях Михаила Кузьмина порождает недоразумения и вводит в заблуждение.

Я не подразумеваю никакого особого понятия транслятора, которое обязывает без дополнительных средств исполнять программу. Более точной была бы просьба выложить исполнитель языка, что бы он из себя не представлял. Но это должно было быть понятно и из ответа на вопрос, зачем мне нужен транслятор. Просто во многих случаях для исполнения достаточно и транслятора.

Есть подозрение, что полного исполнителя языка мы не дождёмся. Если уж система так плохо написана, что не может быть нормально исполнена нигде, кроме компьютера автора, то можно предложить хотя бы сделать видео с демонстрацией работы чего-нибудь от исходного кода до исполнения, например, вычисления того же НОД и сортировки массива. Будет понятней, в каком состоянии разработка.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 22 Июнь, 2020 11:10 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 234
Откуда: Украина, Киев
Михаил Кузьмин писал(а):
Здесь три файла.. Старый транслятор.
Скачал, запустил. Ничего не понял


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 22 Июнь, 2020 11:42 

Зарегистрирован: Понедельник, 15 Июнь, 2020 19:38
Сообщения: 179
Ярослав Романченко писал(а):
Михаил Кузьмин писал(а):
Здесь три файла.. Старый транслятор.
Скачал, запустил. Ничего не понял

Вы меня удивляете. А что вы хотели понять? Инструкцию читать не обязательно. Сразу потыкать хочется. Я только рассказывать начал.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 23 Июнь, 2020 16:47 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Михаил Кузьмин писал(а):
Булевы переменные служат для хранения результата определения истинности высказывания. Так как у нас нет необходимости сохранять этот результат, то нет необходимости и в булевых переменных.

Однако, исходя из поверхностных изложений, представленных здесь, неочевидно, почему исчезает необходимость в хранении предыстории высказываний.
Михаил Кузьмин писал(а):
5. Приятная неожиданность.
Формулируя задачу в терминах событий, мы фактически превращаем описание концепта (а все программирование теперь заключается в этом) в реакцию на внешние события.

Сами события являются понятийными конструкциями и формулирование задачи в терминах событий мы решаем все проблемы программирования.

Всё же, неясно, как решается проблема "callback hell".
Например, сложно понять, как выразить конъюнкцию (соответственно и реакцию на нее) таких событий как "Change Value" (согласно примеру сортировки массива выше). Интуитивно, по-видимому, требуемый функционал распадается на части -- на каждое интересующее событие необходимо устанавливать отдельный обработчик (или подписку), эти обработчики должны предусматривать изменение и анализ состояния неких общих вспомогательных объектов (т.е. вести предысторию событий/высказываний, для чего и булевы переменные, вроде бы, не лишние) и т.д.
Неясна форма динамики системы в функциональном разрезе ("управление callback-ами") -- как система изменяет своё поведение/реакцию. Вроде бы, декларируется существование возможности динамической настройки подписок. Однако неочевидно, как потенциальная смена реакций соотносится с "адресной шиной" (с некой очередью реакций на события или их совокупностью, т.е. с набором уже "горячих" объектов, заявивших о событиях. И, в целом, семантика заполнения очереди событий/реакций пока не представлена). Интуитивно сложно представить, как, к примеру, можно переключить реакцию (изменить метод) на события вида "Change Value" выше, особенно с учётом:
Михаил Кузьмин писал(а):
Память должна быть не двоичным массивом, а содержать самостоятельные семантические единицы (Концепты)с нулевой иммутабельностью. Т.е. с формально определенной и неизменяемой структурой и неизменяемым выполняемым контентом (определение мое) Атрибуты могут быть доступны извне.

Понятие «выполняемый контент» означает что-то типа методов (императивная часть).

В неком файле System.rtf содержится какой-то концепт Automat. Может быть существует какая-то более "высокоуровневая" форма представления системы в виде взаимодействующих автоматов с изменяемым состоянием/поведением, комплексными "событиями" и пр. ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 23 Июнь, 2020 19:37 

Зарегистрирован: Понедельник, 15 Июнь, 2020 19:38
Сообщения: 179
Михаил Кузьмин писал(а):
Булевы переменные служат для хранения результата определения истинности высказывания. Так как у нас нет необходимости сохранять этот результат, то нет необходимости и в булевых переменных.

PSV100 писал(а):
Однако, исходя из поверхностных изложений, представленных здесь, неочевидно, почему исчезает необходимость в хранении предыстории высказываний.

Команды выполняются не подряд. Если в какой-то момент необходимо проверить исполнение какого-то события достаточно к нему адресоваться. Хранить состояние нет необходимости. Кроме того есть еще интересная технология работы с перечислимыми концептами ( в том числе и событиями) Получается нечто типа оператора Select Case. Но мы до этого еще не дошли. Я жду когда будут вопросы по счетчику электричества. Не все сразу надо вываливать. Постепенно ввожу к новому образу мышления.

Михаил Кузьмин писал(а):
5. Приятная неожиданность.
Формулируя задачу в терминах событий, мы фактически превращаем описание концепта (а все программирование теперь заключается в этом) в реакцию на внешние события.

Сами события являются понятийными конструкциями и формулирование задачи в терминах событий мы решаем все проблемы программирования.

PSV100 писал(а):
Всё же, неясно, как решается проблема "callback hell".
Например, сложно понять, как выразить конъюнкцию (соответственно и реакцию на нее) таких событий как "Change Value" (согласно примеру сортировки массива выше). Интуитивно, по-видимому, требуемый функционал распадается на части -- на каждое интересующее событие необходимо устанавливать отдельный обработчик (или подписку), эти обработчики должны предусматривать изменение и анализ состояния неких общих вспомогательных объектов (т.е. вести предысторию событий/высказываний, для чего и булевы переменные, вроде бы, не лишние) и т.д.
Неясна форма динамики системы в функциональном разрезе ("управление callback-ами") -- как система изменяет своё поведение/реакцию. Вроде бы, декларируется существование возможности динамической настройки подписок. Однако неочевидно, как потенциальная смена реакций соотносится с "адресной шиной" (с некой очередью реакций на события или их совокупностью, т.е. с набором уже "горячих" объектов, заявивших о событиях. И, в целом, семантика заполнения очереди событий/реакций пока не представлена). Интуитивно сложно представить, как, к примеру, можно переключить реакцию (изменить метод) на события вида "Change Value" выше, особенно с учётом:
Конъюкция фактически реализуется в последовательности выполнения концептов группируя в фигурные скобки.(дизъюнкция реализуется квадратными скобками. См. правила выполнения групп
Михаил Кузьмин писал(а):
Память должна быть не двоичным массивом, а содержать самостоятельные семантические единицы (Концепты)с нулевой иммутабельностью. Т.е. с формально определенной и неизменяемой структурой и неизменяемым выполняемым контентом (определение мое) Атрибуты могут быть доступны извне.

Понятие «выполняемый контент» означает что-то типа методов (императивная часть).

PSV100 писал(а):
В неком файле System.rtf содержится какой-то концепт Automat. Может быть существует какая-то более "высокоуровневая" форма представления системы в виде взаимодействующих автоматов с изменяемым состоянием/поведением, комплексными "событиями" и пр. ?

Автомат это класс концептов с параметрами-объектами со стандартным взаимодейсвием между ними. Например, автомат счетчик теплопотерь. С параметрами термометрами на входе-выходе теплоносителя и объекта счетчика объема теплоносителя.

Хорошие вопросы. Спасибо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 25 Июнь, 2020 18:24 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
1

Михаил Кузьмин писал(а):
PSV100 писал(а):
Например, сложно понять, как выразить конъюнкцию (соответственно и реакцию на нее) таких событий как "Change Value" (согласно примеру сортировки массива выше).

Конъюкция фактически реализуется в последовательности выполнения концептов группируя в фигурные скобки.(дизъюнкция реализуется квадратными скобками. См. правила выполнения групп
PSV100 писал(а):
Однако, исходя из поверхностных изложений, представленных здесь, неочевидно, почему исчезает необходимость в хранении предыстории высказываний.

Команды выполняются не подряд. Если в какой-то момент необходимо проверить исполнение какого-то события достаточно к нему адресоваться. Хранить состояние нет необходимости. Кроме того есть еще интересная технология работы с перечислимыми концептами ( в том числе и событиями) Получается нечто типа оператора Select Case. Но мы до этого еще не дошли.

Может быть, как раз ключевое в том, что "мы до этого еще не дошли" (до сути некоего оператора Select Case). Поскольку исходя из:
Михаил Кузьмин писал(а):
События определены как изменение состояния памяти высказыванием (выражением, понятием). Определение истинности высказывания является метафункцией относительно высказывания, потому может выполняться параллельно и не только императивно, но и методом логического разбора (как в Прологе).
[...]
Если смотреть шире, то событие — это изменение состояния памяти. Если память представлена не двоичными кодами, а сущностями, имеющими семантический смысл, то проверка изменения состояния заключается в проверке некоторого высказывания (выражения) на истинность.

Как видим, проверка высказывания на истинность и понятие "событие" имеет одинаковую природу.
[...]
Применяя механизм событий и подписок мы позволяем выполняться такой системе в многопроцессорных системах, ибо анализ состояния (они же события) не приводит к изменению памяти.

Подписка заключается в адресации либо к собственному контенту, либо к контенту другого концепта. В обоих случаях никаких коллизий не возникает.
[...]
Работа виртуальной машины (ВМ) заключается в адресации концептов (возможно, с параметром) и анализом адресуемого концепта на наличие подписок. В случае наличия подписок, происходит проверка на выполнение событий, указанных в подписках и переход на реакцию, в случае если событие произошло.

Нечто похожее на прерывание по адресу концепта. Потому нет необходимости в операторе If и команд перехода.

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

создаётся впечатление, что имеется некое переплетение понятий события, факта его обнаружения, действий в качестве реакций. Неясно, почему в предлагаемой архитектуре не возникают коллизии, почему нет потребности в предыстории высказываний (проблематика не в самих булевых переменных как таковых. Условная "атомарность" операций "pattern matching"-а понятна).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 25 Июнь, 2020 18:29 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
2

Предлагаю оттолкнуться от следующего понимания, что есть событие (и прочие ключевые определения алгоритмики там же по ссылке):
https://forum.drakon.su/viewtopic.php?f=170&t=6063&start=60#p101337
Цитата:
7.5. Алгоритмика процессов и управляющие структуры

Процесс, состояние, событие, действие. От описания структуры
системы произвольной природы перейдем теперь к изучению структур
разнообразных процессов, происходящих в системе и ее объектах на
разных иерархических уровнях, к построению структурных моделей
процессов и других характеристик динамической системы. В наиболее
общем виде понятие процесса определяется как упорядоченная во
времени последовательность состояний, событий, действий,
взаимообусловленных причинными и целевыми связями прообъектов системы
и внешнего окружения. Последовательность есть линейно
упорядоченное множество прообъектов, которые можно занумеровать целыми или
натуральными числами в соответствии с текущими моментами времени
так, что если номер п> т, то время tn >= tm. Понятие состояния
уточним чуть позже, а событие понимается как ощутимое, выше порога
различимости, изменение состояний, скажем, |S1 — S2| > delta(Sr), которое
можно привязать к определенному моменту или интервалу
времени, либо достижение системой целевого, либо выделенного состояния
S0 = S(t), иначе, событие есть совместное бытие S и S0.
...

В примере сортировки массива видна коллизия:
Код:
‘Создаем массив Integer A
Integer A "Change Value" ‘Две подписки на событие “Change Value”

‘В первой сравниваем текущий элемент со следующим
{A [Index] ~ A [Index+1]) > A [Index+1]:=: A [Index] ‘Если событие > то меняем.

‘Во второй подписке сравниваем текущий элемент с предыдущим
A [Index] ~ A [Index-1]) < A [Index]:=: A [Index -1] ‘Если < то меняем
} [] ‘Определение массива Integer

В случае возникновения события "Change Value" в определенный момент виртуального времени условно фиксируем некое целевое состояние (массива) S0. Пусть при исполнении первой подписки сработает операция обмена ":=:". В этом случае изменяется массив, возникает новое событие "Change Value". Политика диспетчеризации реакций на события неизвестна -- вероятно далее либо выполняются подписки на новое событие, либо эта реакция откладывается (делается запись в некую "шину адресаций") и продолжается исполнение подписки, ассоциированной с фактом предыдущего события. Однако в любом случае, когда будет выполняться "вторая подписка" на событие, ассоциированное с состоянием S0, текущее состояние массива уже иное.
Возможно для конкретной задачи выше такие побочные эффекты приемлемы. Однако в общем случае неясно, как решаются вопросы "реентерабельности" реакций, когда важна корректность состояния (без хранения предысторий высказываний).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 25 Июнь, 2020 18:36 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
3

Михаил Кузьмин писал(а):
PSV100 писал(а):
Например, сложно понять, как выразить конъюнкцию (соответственно и реакцию на нее) таких событий как "Change Value" (согласно примеру сортировки массива выше).

Конъюкция фактически реализуется в последовательности выполнения концептов группируя в фигурные скобки.(дизъюнкция реализуется квадратными скобками.

Ключевое (в том числе) в том, что событие не только "изменение состояния памяти" здесь и сейчас. В целом события условно привязаны к виртуальному времени (или к реальному). Комплексные события (коньюнкции и прочие дизъюнкции) могут предполагать изменение одной и той же "ячейки памяти", но в разные моменты.

Предлагаю рассмотреть конкретную задачку, предельно упрощённую. Пусть необходимо организовать реакцию на работу условной клавиатуры, или пользователя её использующего. Для простоты установим, что имеются некие символьные клавиши, при нажатии которых необходимо напечатать символ. Имеется одна управляющая клавиша. Одновременное нажатие любых клавиш невозможно (нет понятий вида "клавиша нажата/отжата", только "тык по кнопке"). Если была нажата управляющая клавиша, то следующее нажатие клавиши:
* символьной -- требует особой печати символа (пусть в верхнем регистре);
* управляющей -- приводит к временному отключению обработки символьных клавиш (их нажатие игнорируется) пока не будет нажата управляющая клавиша.

Пусть имеются два входных канала -- недетерминированные потоки входных данных: один для ввода сигналов нажатия управляющей клавиши, другой -- всех символьных клавиш.

Поверхностное упрощённое решение, в "нейтральном" (всем понятном) императивном стиле:
Код:
// два входных объекта-канала, имеют "событие" OnChange в виде указателя на функцию,
// выполняемую в случае возникновения соответствующего ввода
input
  Cmd: channel of bool; // "командная клавиша"
  Char: channel of int; // "символьные клавиши"

var
  // в переменной фиксируется факт нажатия управляющей клавиши
  PreCmd: bool := false;

  // в переменной фиксируется факт запрета обработки символьных клавиш
  DisableChar: bool := false;

// императивная часть
begin
  // установка обработчиков событий

  // реакция на ввод командной клавиши
  Cmd.OnChange := function () {
    if DisableChar then // если был запрет обработки символьных клавиш
      DisableChar := false;
      PreCmd := false;
    elif PreCmd then  // был зафиксирован факт нажатия упр. клавиши
      DisableChar := true;  // установить запрет обработки симв. клавиш
    else
      PreCmd := true;  // фиксируем факт нажатия упр. клавиши
    end
  };

  // реакция на ввод символьных клавиш
  Char.OnChange := function (c: int) {
    if not DisableChar then // если нет запрета обработки
      if PreCmd then        // ранее была нажата упр. клавиша
        print(toUpper(c));
        PreCmd := false;    // "сбрасываем" флаг "предыдущего нажатия" упр. клавиши
      else
        print(c);
      end
    end
  };
 
  // "главный управляющий" цикл, организующий работу целевой подсистемы ("добыча и выдача" ввода/вывода),
  // в данном случае неважно как именно
  loop
    ...
  end;
end;

Основной акцент на двух реагирующих алгоритмах, совместно исполняемых. Подчёркнута необходимость сохранять "историю высказываний" о состоянии и в дальнейшем её применять, причём совместно всеми алгоритмами, включая и для "реализации" понятия "конъюнкции событий вида Change Value одного и того же ("одной и той же входной ячейки памяти") в разные моменты времени, смежные в данном случае" -- событие как "нажата упр. клавиша, затем вновь упр. клавиша", и др.

В том числе через "предысторию" может быть организован и контроль "реентерабельности" реакций при потребности, например, если бы была возможность и необходимость для чего-то "подмешивать" сообщения во входные потоки со стороны обработчиков событий (к примеру, через флаги вида DisableChar выше "отключать/включать" необходимые реакции).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 25 Июнь, 2020 18:39 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
4

PSV100 писал(а):
Неясна форма динамики системы в функциональном разрезе ("управление callback-ами") -- как система изменяет своё поведение/реакцию. Вроде бы, декларируется существование возможности динамической настройки подписок.
[...]
Интуитивно сложно представить, как, к примеру, можно переключить реакцию (изменить метод) на события вида "Change Value" выше, особенно с учётом:
Михаил Кузьмин писал(а):
Память должна быть не двоичным массивом, а содержать самостоятельные семантические единицы (Концепты)с нулевой иммутабельностью. Т.е. с формально определенной и неизменяемой структурой и неизменяемым выполняемым контентом (определение мое) Атрибуты могут быть доступны извне.

Понятие «выполняемый контент» означает что-то типа методов (императивная часть).
[...]
Обратим внимание, что для группы концептов, определенных в непосредственно нельзя добавлять и удалять элементы группы.


Есть подозрение, что динамически устанавливать "callback"-и нельзя (видимо, есть семантические особенности обработки "шины адресаций" или в целом политики диспетчеризации реакций на события).

В примере выше через переменную DisableChar "включается/отключается" реакция (в алгоритме обработки симв. клавиш). В данном случае условные выражения и логика их применения простые. В общем случае возможны комплексные сложные зависимости. В таких случаях удобнее в целом менять реакцию (ака перейти в иное "автоматное состояние", мол достигли необходимого состояния и часть проверок ненужны, заодно меньше и runtime-затраты).
Для пред. примера такая техника могла бы быть в таком виде:
Код:
input
  Cmd: channel of bool;
  Char: channel of int;

var
  PreCmd: bool := false;

// обработчик упр. клавиши
function HandleCmd() {
  if Char.OnChange = null then   // обработка "симв. клавиш" неустановлена
    Char.OnChange := HandleChar; // ... установить
    PreCmd := false;
  elif PreCmd then
    Char.OnChange := null;       // ... отключить
  else
    PreCmd := true;
  end
};

// обработка симв. клавиш
function HandleChar(c: int) {
  if PreCmd then               // уже нет проверок на "запреты"
    print(toUpper(c));
    PreCmd := false;
  else
    print(c);
  end
};

begin
  Cmd.OnChange := HandleCmd;
  Char.OnChange := HandleChar;

  loop
    ...
  end;
end;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 25 Июнь, 2020 18:50 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
5

Михаил Кузьмин писал(а):
PSV100 писал(а):
В неком файле System.rtf содержится какой-то концепт Automat. Может быть существует какая-то более "высокоуровневая" форма представления системы в виде взаимодействующих автоматов с изменяемым состоянием/поведением, комплексными "событиями" и пр. ?

Автомат это класс концептов с параметрами-объектами со стандартным взаимодейсвием между ними.

Попробую уточнить насчёт "более высокоуровневой" формы.

Примеры выше являются представителями "инверсии управления" -- если постановку задачи мы могли выразить условно в виде "неформальной системы уравнений" (ака конъюнкции выражений в системе уравнений, т.е. комплексно, сжато, в едином месте определив предписание), то сама реализация системы "разорвана на части" -- исходная постановка управления разнесена на куски в виде набора совместно исполняемых алгоритмов, взаимодействующих через общие объекты для реализации политики управления ("поставщики событий управляют процессом"). Без тестирования/интерпретации (и прочей верификации) нет уверенности в отсутствии косяков (и, в целом, понять общее управление на основе "исходного кода" не просто даже для такой малой задачки, поток управления теперь косвенный, его необходимо восстанавливать наблюдателю).

Попробуем уменьшить такой эффект. Как раз здесь на форуме в смежных темах вновь заговорили насчёт автоматных методик, заодно вспомнилось применение некоторых принципов "SWITCH-технологии":
https://forum.drakon.su/viewtopic.php?f=62&t=6097&start=40#p100667
https://forum.drakon.su/viewtopic.php?f=62&t=6097&start=40#p100673
https://www.kit-e.ru/articles/circuit/2006_12_118.php

Система представляется как комплекс взаимодействующих автоматов. Вводится некое понятие такта системы (аля шаг-итерация условного "управляющего" цикла). Автоматы "выявляют" события и уведомляют своих "соседей", но с целью упрощения разруливания взаимосвязей осуществляется задержка "обнаружения событий" на один такт.
Потренируемся на примерах выше, схематично:
Код:
type
  // Тип-enum, выражающий текущее состояние "события":
  // - неактивное (необнаруженное);
  // - установленное (но доступное "потребителям" на следующем такте);
  // - активное (доступное "потребителям")
  EventState = {Inactive, Stated, Active};

  // enum как "автоматное" состояние процесса печати символов
  PrintState = {Active, Idle};

var
  // состояние "события" нажатия управл. клавиши
  EventCmd: EventState := Inactive;
  // состояние "события" нажатия симв. клавиш
  EventChar: EventState := Inactive;
  // код веденного символа
  Char: int = 0;
  // флаг для фиксации события "предыдущего" нажатия управл. клавиши
  PreCmd: bool := false;
  // текущее "автоматное" состояние процесса печати символов
  ProcPrintState: PrintState := Active;

// процесс обработки состояний "событий" в конце каждой итерации системы
// для подготовки следующего такта:
// Если событие было "активным", то оно "переводится" в "неактивное",
// если было "обнаруженным" -- в "активное"
// (также фиксируется "предыдущее нажатие" управл. клавиши)
function ProcessEvents() {
  if EventCmd = Active then
    EventCmd := Inactive;
    PreCmd := true;
  elif EventCmd = Stated then
    EventCmd := Active;
  else
    PreCmd := false;
  end;

  if EventChar = Active then
    EventChar := Inactive;
  elif EventChar = Stated then
    EventChar := Active;
  end;
};

// функция для фиксации "обнаружения" ("установки") события нажатия управл. клавиши
function SetCmd() {
  EventCmd := Stated;
}

//...символьной. клавиши
function SetChar(c: int) {
  EventChar := Stated;
  Char := c;
}

// функция для опроса "получения" (или "существования установки") события нажатия упр. клавиши
function RecvCmd(): bool {
  return EventCmd = Active;
}

//...символьной. клавиши
function RecvChar(): bool {
  return EventChar = Active;
}

// Процесс обнаружения нажатия управл. клавиши
function ProcessCmd() {
  ...
  if cond then // каким-то образом обнаруживаем "внешний ввод нажатия"
    SetCmd();
  end;
};

//...символьной. клавиши
function ProcessChar() {
  ...
  if cond then
    SetChar(GetChar());
  end;
};

// Процесс печати символов в виде "автомата" из двух состояний.
// Основная логика управления ключевым "прикладным" процессом
// теперь собрана в одном месте (в разрезе конкретных автоматных состояний,
// и "переходом" в эти состояния теперь занимается лишь сам данный процесс),
// в т.ч. с учётом того, что во время такта системы могут
// отсутствовать "целевые" события.
function ProcessPrint() {
  case ProcPrintState of
  | Active:
      if RecvCmd() & PreCmd then
          ProcPrintState := Idle;
      elif RecvChar() & PreCmd then
          print(toUpper(Char));
      elif RecvChar() then
        print(Char);
      end;

  | Idle:
      if RecvCmd() then
          ProcPrintState := Active;
      end;
  end;
};

// главная императивная часть в виде некоего "управляющего" цикла
// (каждая итерация есть "такт" системы)
begin
  loop
    ProcessCmd();
    ProcessChar();
    ProcessPrint();
    ProcessEvents();
  end;
end;

Большая часть содержания выше это, скорее, реализация "фреймворка" для обеспечения работы процесса печати (однако нужная, чтобы выразить суть принципов снижения "инверсии управления"). Недостаток методики -- в задержке реакций на один такт, при этом сложновато выразить/выявить "предшествующие" события аля "нажатие упр. клавиши на пред. такте" (да и технически "дёргаются" все процессы при каждой итерации).

К примеру, средства, реализующие так называемую "синхронную модель" вычислений (также на основе политики "логических тактов") могут быть более гибкими/оптимальными -- уже конструктивно выявлять все зависимости по производству/потреблению данных и организовывать соответствующее следование реакций, или же в runtime блокировать/приостанавливать потребителей до возникновения события или конца такта системы (или не активировать процессы без надобности) и пр.
На каком-нибудь Lustre/Lucid Synchrone процесс печати выше, например, может быть сведён к системе уравнений, нечто вроде (диалект ML, упрощённо по мотивам -- определен процесс, принимающий на вход нажатия упр. и симв. клавиш, стандартный оператор "pre(...)" означает "пред. значение" (вместо "ручного" сохранения результатов "высказываний о состоянии"), имеются и иные "потоковые" операторы):
Код:
let ProcessPrint(cmd: bool, char: int) = void where
    automaton
    | Active =>
        do
            if char & pre(cmd) then print(toUpper(char))
            elif char then print(char)
        unless cmd & pre(cmd) then Idle

    | Idle =>   
        do () unless cmd then Active
    end


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 242 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 13  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB