Форум
Декларативное программирование
Тема
Как правильно задавать вопросы
B
I
abc
U
X
3
X
3
H1
H2
H3
H4
H5
H6
Asm
C/C++
C#
Erlang
Haskell
IDL
Java
Lisp
MSIL
Nemerle
ObjC
OCaml
Pascal
Perl
PHP
Prolog
Python
Ruby
Rust
SQL
VB
Здравствуйте, FR, Вы писали: FR>Здравствуйте, vdimas, Вы писали: FR>>>В ПМ (для ML семейства) нет "приведения неизвестного устройства значения к [b]известному[/b]" это тупо выбор _заранее_ [b]известных вариантов[/b]. V>>Удивил. Разве это: V>>"приведения неизвестного устройства значения к известному" V>>вызвало затруднение в прочтении? FR>Нет. FR>Затруднения вызывает ваша альтернативная логика в данном вопросе. FR>Путаете динамическое ветвление и динамическую типизацию. V>>Решил сказать тоже самое своими словами? Или в моем случае известно не настолько _заранее_ насколько у тебя? :) FR>В твоем, например в случае dynamic_cast, конечно известно намного меньше. FR>dynamic_cast производит поиск соответствия в рантайме, успех при этом не гарантирован. В результате получаем указатель через который FR>можем исполнить код _не известный_ на этапе компиляции (например подгруженная dll). FR>ПМ ничего ни ищет в рантайме, все возможные пути исполнения и код который будет исполнятся известны заранее, он только передает FR>управление этим заведомо известным путям исполнения. V>>Скипнул код. В коде ты привел классический union, содержимое которого как раз достоверно неизвестно до проверки метки, назначенной одному из завернутый в union типов. FR>В случае АлгТД точно также содержимое совершенно достоверно известно до проверки метки. И как в случае union метка, в случае АлгТД FR>ПМ только актуализирует какой конкретный из заранее известных вариантов выбрать. V>>И да, если это было возражение, то ты забыл нарисовать аналогичный пример с динамической типизацией, скажем, для механики дотнета, выраженной в описании этой механики на том же С. Т.к. я говорил, что это одно и то же, надо было привести обе механики и показать, что это не одно и то же. FR>В дотнете к сожалению не разбираюсь. V>>Т.е. предположим, код на дотнете примерно такой: V>>if(type == typeof(Type1)) ... V>>else if (type == typeof(Type2)) ... FR>Не вижу тут полноценной динамической типизации. FR>Эмуляцию, притом не полную, ее средствами статики да вижу. FR>При полной эмуляции у нас типы Type1, Type2 и т. д. заранее не известны и (псевдо)код будет примерно такой: FR>if(typetable.find(type)){ FR>func = typetable.get_func(type); FR>func(...); FR>} FR>typetable заполняется в рантайме. V>>Нарисуй происходящее так же на С, потом сравни с собственным вариантом на switch и попробуй найти принципиальные отличия. V>>Если найдешь, вернемся к обсуждению... покажу, где у тебя ошибка. FR>Если брать настоящую динамическую типизацию, то паттерн матчинг я не нарисую, так как его смысл в ней FR>во многом теряется, вернее он вырождается в некую структурную распаковку, сравнивать которую со статическим FR>ПМ мало осмысленно. FR>Если взять такой элементарный динамический код: FR>[python] FR>def tst(a, b): FR> a.append(b) FR>[/python] FR>То выполнятся он будет примерно так: FR>. определяем тип 'a' ищем в его списке методов 'append' FR>. если не нашли просматриваем всех предков и ищем метод там, если не нашли рантаймное исключение FR>. если нашли пробуем вызывать подставив 'b' если число аргументов не совпало снова рантаймное исключение FR>. успешно вызываем 'append' FR>То есть сплошной поиск никак несводимый к switch.
Теги:
Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например:
"Visual Studio" .NET
Имя, пароль:
Загрузить
Нравится наш сайт?
Помогите его развитию!
Отключить смайлики
Получать ответы по e-mail
Проверить правописание
Параметры проверки …