Re: Система типов для компонентного программирования.
От: hardcase Пират http://nemerle.org
Дата: 27.08.11 13:18
Оценка:
Здравствуйте, AlexCab, Вы писали:

Предлагаю изучить VHDL прежде чем придумывать что-то свое.
http://nemerle.org/Banners/?t=Developer!&g=dark /* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: Система типов для компонентного программирования.
От: AlexCab LinkedIn
Дата: 27.08.11 14:57
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Предлагаю изучить VHDL прежде чем придумывать что-то свое.
Thanks, интересная штука.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[9]: Система типов для компонентного программирования.
От: samius Россия http://sams-tricks.blogspot.com
Дата: 31.08.11 13:39
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


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


V>Да? А я вот затрудняюсь обычно четко сформулировать... Например, как назвать атомарное изменение состояния у целой схемы?

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

V>В итоге, при моделировании мы поочередно обсчитываем компоненты, изменяя их состояние, но не вызываем при этом побочных эффектов для других вычислений. Т.е. обеспечиваем некую транзакционность и чистоту просто через организацию вычислительного процесса. Характерно, что сей подход я стараюсь использовать максимально везде в обычном коде, автоматически имея восстанавливаемые состояния в случае исключений. Т.е. просто явно отделяем "чистые" вычисления от момента смены состояния. Цифровое железо тоже аналогично работает, и поэтому более надежно, чем софт, ведь оно не проходит через невалидные состояния в процессе работы.

Хорошо организованный вычислительный процесс не мешает быть коду императивным.
Я так думаю, что даже если процесс выстроен так, что побочные эффекты не влияют на другие вычисления но тем не менее могут быть наблюдаемы, это будет императивный код.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.