Вчера Костис Сагонас (для тех, кто не знает — он один из основных людей, стоящих за HiPE/DIALYZER) написал в erlang questions о том, что скоро можно будет указывать типы для функций в Эрланге аля:
-spec(foo/2 :: ((integer(), float()) -> atom())).
И эти спецификации будут проверяться на соотвествие коду функций.
Через месяц это дело будет представлено на Erlang Workshop и по планам будет написан EEP, и, скорее всего, эта фича появится уже в R12B (обещаемый где-то в районе Нового Года).
Здравствуйте, VladD2, Вы писали:
VD>Не погу не позлорадствовать . VD>С удовольствием послушаю коментарии всех борцов за динамическую типизацию.
"Static Typing Where Possible, Dynamic Typing When Needed"
Эрлангу, на самом деле, этого очень не хватает. Их интерпретатор слишком уж медленный
Здравствуйте, Cyberax, Вы писали:
C>"Static Typing Where Possible, Dynamic Typing When Needed"
C>Эрлангу, на самом деле, этого очень не хватает. Их интерпретатор слишком уж медленный
Есть немного, хотя отчасти это раньше при помощи guards решалось.
После Workshop, думаю, появятся материалы — можно будет посмотреть, что конкретно это даст.
Здравствуйте, Курилка, Вы писали:
К>Вчера Костис Сагонас (для тех, кто не знает — он один из основных людей, стоящих за HiPE/DIALYZER) написал в erlang questions о том, что скоро можно будет указывать типы для функций в Эрланге аля:
К>
К>И эти спецификации будут проверяться на соотвествие коду функций. К>Через месяц это дело будет представлено на Erlang Workshop и по планам будет написан EEP, и, скорее всего, эта фича появится уже в R12B (обещаемый где-то в районе Нового Года).
Не понятно, этот контракт будет использоваться для проверки корректности поставщика (т.е. тела функции) или потребителя (т.е. вызывателя функции), или и того и другого? Проверки выполняются во время компиляции или исполнения?
Вообще, как эта штука будет работать с динамическим обновлением кода, когда новая версия foo/2 сможет получать или возвращать значения других типов?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Не понятно, этот контракт будет использоваться для проверки корректности поставщика (т.е. тела функции) или потребителя (т.е. вызывателя функции), или и того и другого? Проверки выполняются во время компиляции или исполнения?
E>Вообще, как эта штука будет работать с динамическим обновлением кода, когда новая версия foo/2 сможет получать или возвращать значения других типов?
Если отвечать честно — без понятия
Надо Костиса спросить (хотя не факт, что ответит)
Я думаю, что это чисто компайл-тайм фича аля явские дженерики.
Здравствуйте, eao197, Вы писали:
E>Не понятно, этот контракт будет использоваться для проверки корректности поставщика (т.е. тела функции) или потребителя (т.е. вызывателя функции), или и того и другого? Проверки выполняются во время компиляции или исполнения?
Собственно привожу ответ Тобиаса Линдала (в оригинале, переводить реально ломает ):
The extension we suggest is a language to write specifications (or
contracts as we like to call them). The language is very similar to the
language of edoc, with the difference that the contracts are parsed and
live their lives as compiler attributes rather than comments.
The contracts should not necessarily be used by the compiler, but rather
for tools that can benefit from the kind of information that is given.
Obvious examples are Edoc and Dialyzer, and since we are developing
Dialyzer, our focus is slightly more aimed towards the type information
we benefit from.
The dynamic nature of Erlang limits the static checking of the contracts
somewhat, but our idea is to use the same philosophy as Dialyzer is
using. When a contract cannot hold this is reported, but otherwise it is
trusted as a promise given by the user. "I promise that this function
will be used in the way I specify. Please tell me if I missuse it."
Checking the contracts dynamically is probably costly, but we have
started a project to investigate how costly it is, and how it can be
used in instrumented systems for testing purposes. Perhaps it can be
used while running testsuites to find if the contracts are broken during
the tests.
Also, I can imagine that the specifications can be used for test case
generations, it can probably be useful for QuickCheck, EUnit and any
other tool that can benefit from the information about how the user
intends the program to behave.
To sum up. The contracts are a way for programmer to express intentions
in a way that can be used for tools without having to parse human
language written in comments. The tools can then use the information for
whatever purposes they want, and also provide feedback to the user about
the contracts. The contracts will not (at least not in our proposal)
affect the semantics of Erlang, and the only effect on syntax is that
you are allowed to include contracts as attributes.
Тут же Jay Parlar заметил очевидную аналогию с аннотациями, которые в пайтон 3000 добавляют.
VD>С удовольствием послушаю коментарии всех борцов за динамическую типизацию.
Из дальгейшего обсуждения там же:
The extension we suggest is a language to write specifications (or
contracts as we like to call them). The language is very similar to the
language of edoc, with the difference that the contracts are parsed and
live their lives as compiler attributes rather than comments.
The contracts should not necessarily be used by the compiler, but rather
for tools that can benefit from the kind of information that is given.
...
The dynamic nature of Erlang limits the static checking of the contracts
somewhat, but our idea is to use the same philosophy as Dialyzer is
using. When a contract cannot hold this is reported, but otherwise it is
trusted as a promise given by the user. "I promise that this function
will be used in the way I specify. Please tell me if I missuse it."
...
To sum up. The contracts are a way for programmer to express intentions
in a way that can be used for tools without having to parse human
language written in comments. The tools can then use the information for
whatever purposes they want, and also provide feedback to the user about
the contracts. The contracts will not (at least not in our proposal)
affect the semantics of Erlang, and the only effect on syntax is that
you are allowed to include contracts as attributes.
Здравствуйте, Mamut, Вы писали:
M>The contracts should not necessarily be used by the compiler, but rather M>for tools that can benefit from the kind of information that is given.
Было бы реально круто, если бы этими аннотациями пользовался HiPE.
Здравствуйте, Курилка, Вы писали:
G>>Было бы реально круто, если бы этими аннотациями пользовался HiPE.
К>Было бы реально странно, если их авторы у себя же в проектах не использовали своё творение
В мире много реально странных вещей, не так ли? Поддержке этих аннотаций Хайпом вполне могут дать низкий приоритет "когда нибудь".
Собственно вот доклад о сути предлагаемого расширения языка. Сам только начал читать, поэтому ничего сейчас сказать не могу (плюс в erlang questions было совсем небольшое обсуждение этой темы)
Здравствуйте, VladD2, Вы писали:
VD>Не погу не позлорадствовать . VD>С удовольствием послушаю коментарии всех борцов за динамическую типизацию.
Я считаю типизацию дополнительным инструментом (встроенным в компилятор) для верификации кода. Но как любой инструмент, он должен позволять НЕ использовать его если он не нужен (трудно представить молоток, согласившись использовать который больше не сможешь выпустить его из рук), и крайне желательно не накладывать много ограничений на остальную работу, не связанную с его применением.
То есть я считаю, язык должен позволять не писать типы вообще, и только если хочется задокументировать и верифицировать некоторые вещи — указать типы. Меня можно считать борцом за динамическую типизацию?
Типизация в ерланге появляется как раз в наиболее естественном виде, в то же время как статическая типизация в популярных реализациях типа Паскаля или С++ не соответствует обоим критериям хорошего инструмента.
Здравствуйте, Кодёнок, Вы писали:
Кё>Типизация в ерланге появляется как раз в наиболее естественном виде, в то же время как статическая типизация в популярных реализациях типа Паскаля или С++ не соответствует обоим критериям хорошего инструмента.
Только есть одно "но", что типизация там на данный момент сугубо динамическая (т.е. всё проверяется в рантайме, т.е. на сложение строки и числа тебе сейчас никто ничего не скажет до момента выполнения этого кода, хотя есть, конечно, юнит-тесты как один из вариантов неких гарантий правильности), хотя, судя по всему, это может несколько измениться.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я считаю типизацию дополнительным инструментом (встроенным в компилятор) для верификации кода. Но как любой инструмент, он должен позволять НЕ использовать его если он не нужен (трудно представить молоток, согласившись использовать который больше не сможешь выпустить его из рук), и крайне желательно не накладывать много ограничений на остальную работу, не связанную с его применением...
Я считаю безопастность дополнительным инструментом (встроенным в лифт) для предотвращения повреждений пасажиров. Но как любой инструмент, он должен позволять НЕ использовать его если он не нужен (трудно представить молоток, согласившись использовать который больше не сможешь выпустить его из рук), и крайне желательно не накладывать много ограничений на остальную деятельность, не связанную с его применением.
То есть я считаю, язык должен позволять не закрывать двери вообще, и только если пасажир хочется — закрывать. Меня можно считать борцом за динамическую типизацию?
Думаю ты понял... Типизация как и безопастность не инструмент. Так что все аналогии тут ошибочны.
Типизация — это дополнительный контроль над нашими ошибками и средство повышения производительности. Оно является аспектом, а не объектом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Думаю ты понял... Типизация как и безопастность не инструмент. Так что все аналогии тут ошибочны.
А вот эта твоя аналогия ошибочна и мне её игнорировать, или она не ошибочна и пытается мне что-то показать?
VD>Типизация — это дополнительный контроль над нашими ошибками и средство повышения производительности. Оно является аспектом, а не объектом.
Называй как хочешь. Главное, что она дополнительная, и вообще есть места, где она не нужна. Если типизированность это неотделимый аспект, значит должен быть полноценный вывод типов из контекста. Если это дополнительный внешний механизм, значит он должен включаться или выключаться.
Здравствуйте, Кодёнок, Вы писали:
Кё>Называй как хочешь. Главное, что она дополнительная, и вообще есть места, где она не нужна. Если типизированность это неотделимый аспект, значит должен быть полноценный вывод типов из контекста. Если это дополнительный внешний механизм, значит он должен включаться или выключаться.
А вот это уже детали реализации...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
