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

V>Если сигнатура ф-ии помечена как clean, то в теле ф-ии не может быть не-clean операций.

И как "не-clean операции" будут отличаться от clean? Т.е. можно будет только clean-функции использовать и только константы читать?
Просто я не раз уже видел такие рассуждения "давайте сделаем аннотации чистоты" а когда начинаются вопросы отвечают как в анекдоте: "я вам дал идею, а детали вы сами продумывайте".

V>Это спекуляции, положа руку на. Мне даже от одного const очень много пользы удается извлечь, т.к. в первую очередь я использую этот модификатор для себя, то бишь сам себе бью линейкой по рукам. При наличии clean эта линейка была бы заметно увестистей. Банально хочется заствить компилятор делать больше работы по проверке кода.

Непонятен только механизм работы. И, кроме того, вы не учитываете, что мутабельность по-умолчанию оставляет мало возможностей что-то там проаннотировать. По факту, есть два устойчивых состояния: повсеместная иммутабельность с мутабельностью только там где надо и повсеместная мутабельность с чистым кодом (вроде 2+2) в следовых количествах. Все прочие соотношения "нестабильны" и приводят в перспективе к одному из этих результатов.

V>Потому что рассуждаете в сторону const=иммутабельность. Но это нерелевантное сопоставление. Распространение константности ровно противоположно направлению распространению иммутабельности. Это же по природе вещей и так должно было быть понятно: гарантии от себя противоположны требованиям от других.

Но на практике-то нужны гарантии от других.

V>Почему так? Потому что Хаскель предлагает комбинировать ф-ии программисту и проверяя их чистоту.

Ну так я и объясняю, что чистоту никто не проверяет. Чистота гарантируется по построению.

V>Предложенный модификатор clean затсавлял бы аналогично программистов так комбинировать ф-ии, чтобы не нарушать этот модификатор.

Т.е. нужно будет что-то доказывать и проверять? Ну и как это делать?

V>Разве только для этого. Вроде бы через модификатор IO компилятор позволяет опасные конструкции, типа чтения памяти (например, для связи с легаси-АПИ).

Да для чего угодно. Параметр State-то фиктивный, он ничего не хранит, а просто последовательность задает, которая в неявном виде в чистом языке отсутствует и должа быть явной, когда она нужна. Я и продемонстрировал "чтение памяти". И даже "запись в память".

V>Длинное имя абсолютно непринципиально для того, что хочу я — заставить компилятор больше мне помогать. Ему длина идентификаторов до фени.

С помощью компилятора тоже все в порядке. Но компилятор, а точнее тайпчекер, делает то, что обычно — проверяет типы, а не "вычисляет чистоту" и т.д.

V>И с помощью этих ф-ий можно будет так?
V>

V>x = 20;
V>x = x + 10;
V>

Да, с точностью до именования лексем, = использовать нельзя, это ключевое слово. Можно и короче — с += и прочим. Можно и вышеупомянутый x++ сделать, с той поправкой, что постфиксные операторы в хаскеле должны быть в скобках, т.е. (x++). Можно даже лучше, написать линзы, но не "функциональные", а с изменением по-месту, с помощью ST, а это, фактически, first-class l-values.

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

V>>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.
S>Дальнейшая чушь поскипана. Контрпример вам привели. Посыпайте голову пеплом, медитируйте до просветления. Что непонятно — спрашивайте. Обсуждение сложных вещей вроде ссылочной прозрачности и чистоты вычислений мы отложим до момента понимания вами основ — в частности, отличий настоящей иммутабельности от константности в C++.

Лучше бы ты матом высказался, это, по крайней мере, честно было бы.

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

K>Вот это он и есть — Смолток.

И?
А можно посмотреть паттерны фасад, мост, адаптер? А можно посмотреть во что вырождается паттерн State? ))

Абстрактная фабрика, конечно, пример классный. Только в ФП любой функциональный объект — точно такая же абстрактная фабрика. Так был ли мальчик?

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

WH> Лолшто?

Ага, есть немного. Надо заканчивать в 3 часа писать посты. Ес-но наоборот.

WH>Открытые ключи они на то и открытые чтобы ими ничего расшифровать было нельзя.
WH>Или ты собрался сломать ассиметричный шифр? Удачи.

Гы, я даже не собираюсь рассматривать варианты взлома системы через некие алгоритмы взлома шифрования. Это заведомо бесполезное направление. Речь о взломе через инфраструктуру.

Вот у меня лежит исходник системы со всякими новомодными шифрованиями, этой системой пользуюся даже в армии одной страны, которая слишком часто на слуху. Писал расширение к этой системе. Дык, я достоверно знаю как ее вскрыть через прослушку трафика. При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи вместо оригинального. Кароч, через проксирование трафика система вскрывается настолько банально, что даже стремно владеть такой информацией...


V>>И еще, ты так и не обрисовал, как ты себе представляешь тестирование ПО на злонамеренность. И как ты себе вообще верификацию ПО представляешь? много раз сертификацию проходил, поделись? Или как обычно последние годы — облака, белокрылые лошадки.. сплошь сферические? Ладно там верификация на опасный с т.з. типобезопасности код — это хоть как-то автоматизируется, но обсуждаемые вещи будут абсолютно типобезопасны, а глазками в сотне тыщ строк ты хрен чего поймаешь. Это такая ситуация прямо на сегодня. А ты этого никак не понимаешь, бо по-твоему, типобезопасность и изолированность что-то значат. А на самом деле через DMA прямо сейчас можно загнать любой участок памяти Сингулярити в буфер жесткого диска и прочитать обратно. Вот и нет твоей изолированности процессов. В общем, не с того конца ты подходишь к безопасности изначально. А всё потому, что пороха не нюхал и рассуждаешь угубо умозрительно.
WH>Еще раз.
WH>Это лечится при помощи IOMMU раз и навсегда.

Насчет IOMMU я уже всё говорил, спорить не о чем. Осталось подождать лет 10 и посмотреть на поддержку того зоопарка, который будет к тому времени.

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

S>+1. Всегда радуюсь, когда люди мне рассказывают, что SSL не может работать. Особенно, когда это сопровождается вееробразными движениями пальцев и отеческим тоном.

А как раз рядом показал, что надо делать.

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

V>>А теперь берем паскалеподобные языки:
V>>- макроопределений нет
V>>- enum нет
S>Как это? Куда дели enum?
S>RTFM:
S>http://www.delphibasics.co.uk/Article.asp?Name=Sets

Терпеть не могу, когда кто-то пытается натянуть сеты на enums. Ты точно писал на Дельфи?

S>То, что в Обероне их нет — это, мягко говоря, не от большого ума. Трудно найти человека, который был бы от этого "улучшения" в восторге. Даже фанаты языка жалеют об их отсутствии.

Пруф насчет фанатов? Это только от совсем большого ума жалеть можно.

Идеологически в мейнстриме enums — это "типизированные" целочисленные константы. Т.е. это два в одном:
1. Эдакие юзверские алиасы для целочисленных типов.
2. Константные значения этих типов.

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

TYPE
     Flag = BOOLEAN;

Так что, не от большого ума можа можно лишь пытаться сожалеть о том, что чего-то нет, хотя оно на самом деле есть и даже всяко удобнее.


V>>Теперь вычти второй список из первого. Что в остатке? Раскраска строк? )))
V>>Теперь аргументировано?
S>Почти. Но можно лучше — например, не допускать ляпов типа "отсутствия енумов в паскалеподобных языках".

Пытаться натягивать set на enum — вот это ляп.


V>>Ты только что повторил мой аргумент, который показывает, что разницы НЕТ, будь оно прописано в стандарте, разработчиками ли языка задано, или постепенно устаканилось через рост популярности третьесторонних генерилок.
S>Конечно же есть. Разница — ровно такая же, как между поддержкой строк в языке и "возможностью наплодить свои классы строк".

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


S>Стандарт даёт возможность разработчикам пользоваться языком и интероперировать, а в бесстандартных языках типа С++ имеется зоопарк плохо совместимых между собой "платформ" — Qt, MFC, и так далее.

Гы, а язык-то здесь причем?? В языке как раз есть стандарт STL и есть строки (аналоги StringBuilder), а то, что там MS навертели со строками в MFC, дык они минимум дважды полностью меняли внутренний дизайн строки (предпоследний был вообще баговым), и знаешь на чем устаканилось? Правильно, на том же подходе, как в STL. Стоила ли вся эта овчинка выделки, как считаешь?


V>>А мне гипертекстовые ссылки прямо из кода нравятся.
S>Гипертекстовые ссылки из кода бывают двух типов:
S>1. В коде, Go to definition — поддерживаются вменяемыми IDE безо всякой ручной раскраски. В Delphi — Ctrl+Click, в VS, емнип, клавиатурная комбинация.
S>2. Произвольные, из комментариев — поддерживаются вменяемыми IDE безо всякой ручной раскраски.

Если надо прыгнуть куда-то в код в проекте — не поддеживаются. Только по идентификаторам и можно скакать. Но внутрь метода так не заскочешь.

V>>По работе часто приходится штудировать доку, описанную в "плоском" PDF, без гипертекстовых ссылок... А документы под тысячу страниц... После MSDN хочется поставить всех к стенке и выпустить пару длинных очередей из какого-нить крупнокалиберного девайса.
S>Оберон бы вас точно так же не спас. Если авторы доки не воспользовались средствами, встроенными в PDF (вы же знали, что в нём прекрасно работают ссылки — ещё с тех времён, когда Adobe хотела заменить им HTML для вёрстки в вебе?), то средствами, встроенными в Оберон они бы тоже пренебрегли.

Дык, аргумент был не про PDF, а про то, насколько с гиперссылками удобнее, чем без них. Да, пример был построен на нерадивых технических писателях, но он показал всё что я хотел показать.


V>>Агащаз. Разработчики Сингулярити прямо ссылаются на проект SPIN на Modula-3, который был попыткой повторить Оберон в том же самом духе.
S>Это они в контексте гипертекстовых исходников ссылаются, или вы опять пытаетесь контекст подменить?

Дык, у тебя любой контекст сводится к этому:

Пример Оберона не смог никого вдохновить.

А еще один рядом вообще лично на Вирта наезжает...
Не знаю, не знаю... Как ты думаешь, кто был автором парадигмы p-код? Можешь считать подменой контекста, бо этему раскраски вроде бы договорились считать исчерпанной.

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

K>>Вот это он и есть — Смолток.

V>И?
V>А можно посмотреть паттерны фасад, мост, адаптер? А можно посмотреть во что вырождается паттерн State? ))
Посмотреть нельзя. Но вот пару цитат из книги:
Adapter

Known Uses
Pluggable adapters are common in ObjectWorks\Smalltalk [Par90]. Standard Smalltalk defines a ValueModel class for views that display a single value. ValueModel defines a value, value: interface for accessing the value. These are abstract methods. Application writers access the value with more domain-specific names like width and width:, but they shouldn't have to subclass ValueModel to adapt such application-specific names to the ValueModel interface.

Instead, ObjectWorks\Smalltalk includes a subclass of ValueModel called PluggableAdaptor. A PluggableAdaptor object adapts other objects to the ValueModel interface (value, value: ). It can be parameterized with blocks for getting and setting the desired value. PluggableAdaptor uses these blocks internally to implement the value, value: interface. PluggableAdaptor also lets you pass in the selector names (e.g., width, width directly for syntactic convenience. It converts these selectors into the corresponding blocks automatically.

Another example from ObjectWorks\Smalltalk is the TableAdaptor class. A TableAdaptor can adapt a sequence of objects to a tabular presentation. The table displays one object per row. The client parameterizes TableAdaptor with the set of messages that a table can use to get the column values from an object.

Facade

Known Uses
The compiler example in the Sample Code section was inspired by the ObjectWorks\Smalltalk compiler system [Par90].

[Par90] ParcPlace Systems, Mountain View, CA. ObjectWorks\Smalltalk Release 4 Users Guide, 1990.

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

V>Вот у меня лежит исходник системы со всякими новомодными шифрованиями, этой системой пользуюся даже в армии одной страны, которая слишком часто на слуху. Писал расширение к этой системе. Дык, я достоверно знаю как ее вскрыть через прослушку трафика. При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи вместо оригинального. Кароч, через проксирование трафика система вскрывается настолько банально, что даже стремно владеть такой информацией...
Эта атака называется http://en.wikipedia.org/wiki/Man-in-the-middle_attack
Известна миллион лет.
Если люди делают шифрованное соединение и не защищаются от этой атаки, то они просто не профпригодны.
И такой протокол никогда не пройдет через нормального безопасника.

И еще. Не стоит путать прослушивание с проксированием.
Ибо есть протоколы, защищающие от прослушивания, но не проксирования.
А есть протоколы, которые можно атаковать только через слабость алгоритмов шифрования.

V>Насчет IOMMU я уже всё говорил, спорить не о чем. Осталось подождать лет 10 и посмотреть на поддержку того зоопарка, который будет к тому времени.
Короче очередной слив засчитан.

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

V>Терпеть не могу, когда кто-то пытается натянуть сеты на enums.
Мне ваше мнение по этому вопросу глубоко безразлично. Зачем вы меняете тему?
V>Ты точно писал на Дельфи?
Да. Вы же вроде бы писали, что помните мои ранние посты?
Попробуйте для интересу сходить вот сюда.
S>>То, что в Обероне их нет — это, мягко говоря, не от большого ума. Трудно найти человека, который был бы от этого "улучшения" в восторге. Даже фанаты языка жалеют об их отсутствии.

V>Пруф насчет фанатов? Это только от совсем большого ума жалеть можно.
http://compgroups.net/comp.lang.oberon/enumeration-types/1433942
Я надеюсь, само собой понятно, что на нишевом языке никто, кроме фанатов, не пишет?

V>Идеологически в мейнстриме enums — это "типизированные" целочисленные константы. Т.е. это два в одном:
V>1. Эдакие юзверские алиасы для целочисленных типов.
V>2. Константные значения этих типов.
Я не знаю, что именно вы называете мейнстримом. Скажем, енумы в Джаве сделаны сильно по-другому, чем енумы в Object Pascal aka Delphi.
И оба сильно отличаются от сишных "алиасов" — в частности, они не совместимы по присваиванию.
V>Так что, не от большого ума можа можно лишь пытаться сожалеть о том, что чего-то нет, хотя оно на самом деле есть и даже всяко удобнее.
Я улавливаю общий паттерн в вашей манере ведения спора. Вы утверждаете чушь (типа "енум это всего лишь алиас для целочисленного типа"), а потом из неё делаете глубокие выводы.

V>>>Теперь вычти второй список из первого. Что в остатке? Раскраска строк? )))
V>>>Теперь аргументировано?
S>>Почти. Но можно лучше — например, не допускать ляпов типа "отсутствия енумов в паскалеподобных языках".

V>Пытаться натягивать set на enum — вот это ляп.
Я не понимаю, что значит "натягивать set на enum". Вы что, ещё и путаете Set type с enum type?

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

V>Гы, а язык-то здесь причем?? В языке как раз есть стандарт STL и есть строки (аналоги StringBuilder), а то, что там MS навертели со строками в MFC, дык они минимум дважды полностью меняли внутренний дизайн строки (предпоследний был вообще баговым), и знаешь на чем устаканилось? Правильно, на том же подходе, как в STL. Стоила ли вся эта овчинка выделки, как считаешь?
Считаю, что нет, и вроде бы ясно об этом написал. Вся вот эта галиматья со строками появилась ровно от того, что поддержку строк в язык так и не встроили. std::string — полная чухня. Я бы ещё простил её, если бы у строковых констант тип был не char*, а std::string.


V>Если надо прыгнуть куда-то в код в проекте — не поддеживаются. Только по идентификаторам и можно скакать. Но внутрь метода так не заскочешь.
Зачёт, этот сценарий мне в голову не пришёл.

V>Дык, аргумент был не про PDF, а про то, насколько с гиперссылками удобнее, чем без них. Да, пример был построен на нерадивых технических писателях, но он показал всё что я хотел показать.
Неубедительно. Берём джавадок — видим, что ссылки есть. Гипертекста в джаве — нету. Берём XML Doc Comments, видим: ссылки — есть. Гипертекста — нету.
Резюме: хотение гиперссылок в качестве обоснования необходимости гипертекста не катит.

V>Не знаю, не знаю... Как ты думаешь, кто был автором парадигмы p-код? Можешь считать подменой контекста, бо этему раскраски вроде бы договорились считать исчерпанной.
Автором p-кода был Вирт. Автором парадигмы — хрен его знает. Ричардс разработал INTCODE и O-code практически одновременно с Виртом.

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

I>Лучше бы ты матом высказался, это, по крайней мере, честно было бы.
Не хочу уподобляться оппоненту, несмотря на троллинг и провокации с его стороны.

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

V>Нубский, надо сказать, для 2012-го года приёмчик, приписать что-то оппоненту и пытаться вздебезги его разбить. Можно мне добавки попкорна, мне уже забавно над этим наблюдать.
Никаких инсинуаций. Все ходы записаны. Вот вопрос:

А что мешает в императивном языке использовать тот же const?

Я вам написал, что мешает. Вы, вместо того, чтобы читать, что вам пишут, приписали мне (и Klapaucius, Cyberax, и jack128) непонимание семантики слова const. Нет, мы все её как раз прекрасно понимаем. Вместе с её ограничениями.
Это вы почему-то отказываетесь понять, что возможность "наложить ограничения на себя" недостаточна. Поймите, от чистого кода защищаться не нужно — он на то и чистый. Нужно защищать чистый код от модифицирующего кода. А для этого как раз нужен тот механизм гарантий для callee, которого в const нету.

V>==========================
V>Кароч, интересующая подветка обсуждания на месте, читайТЕ её целиком.
Это та, где вы ссылаетесь на эту? Вот это приём, достойный форумного профи. Как и вырезание вопроса, отвечать на который не хочется.
Я верну его на место:

А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const.

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

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

V>>Нубский, надо сказать, для 2012-го года приёмчик, приписать что-то оппоненту и пытаться вздебезги его разбить. Можно мне добавки попкорна, мне уже забавно над этим наблюдать.
S>Никаких инсинуаций. Все ходы записаны. Вот вопрос:
S>

S>А что мешает в императивном языке использовать тот же const?

Ну вот на такое выдергивание я и высказал фи, бо в том же самом посте далее наблюдается:

... пойти еще дальше и ввести некий модификатор clean для ф-ий и методов?

Потому что, во-первых, речь шла не об иммутабельности, о ссылочной прозрачности. Это был контекст. Во-вторых, потому что с помощью const можно организовать меньше участков кода с той самой соблюдаемой ссылочной прозрачностью, чем бы мне хотелось. Но это не значит, что их нельзя организовать вообще.


S>Я вам написал, что мешает.

Вы все писали исключительно об иммутабельности, не понимая кое-какое важное отличие иммутабельности как от исходных требований, так и от реально происходящего в коде. Современный компилятор С++, если видит жизненный цикл значения, спокойно обходится даже без всяких const при оптимизации, не то, что без мифической иммутабельности. Не нужно! То бишь все плюшки ссылочной прозрачности на самом деле доступны ровно тогда, когда нет скрытых изменений данных.


S>Вы, вместо того, чтобы читать, что вам пишут, приписали мне (и Klapaucius, Cyberax, и jack128) непонимание семантики слова const. Нет, мы все её как раз прекрасно понимаем. Вместе с её ограничениями.

Я уже сказал только что: тогда вы не понимаете другого, в чем я просто не хотел никого обвинять заранее, поэтому пока пытался представить такое понимание как невнимательность и/или недостаточное знание сценариев применимости const (что не страшно, в общем-то для тех, кто не пишет постоянно на плюсах). Ну ОК, будем считать, что это принципиальное непонимание вопроса.

На самом деле там ничего сложного, достаточно было быть внимательным к постам оппонентов. Я сразу напомнил (подразумевая, что обсуждаю этот вопрос не с плюсовиками) о т.н. "распространении константности". В какую сторону константность-то распространяется, господа хорошие? Ну а теперь, второй вопрос — можно ли с помощью этой техники организовать распространение ссылочной прозрачности в след за константностью? Заметь, не "породить ссылочную прозрачность из воздуха" относительно произвольно полученой ссылки (как вы от меня требовали в примерах, ломающих якобы иммутабельность на основе const), а именно распространить, если факт ссылочной прозрачности уже есть в некоей точке алгоритма де-факто?

А откуда ссылочная прозрачность появляется? Вопрос на мильон, а ответ простой — только в месте создания значения. Вот исходная точка. Прямо отсюда можно вернуться к моим постам и, пользуясь новым знанием, посмотреть как на мои примеры, так и на общий ход рассуждений относительно const.

То бишь, в своих постах я изначально исходил из очевидной для меня (но неочевидной для окружающих, как выяснилось) цели: можно ли организовать в некоей точке видимости исходный код так, чтобы вызываемые непрозрачные для компилятора низлежащие процедуры заведомо не нарушали ссылочной прозрачности относительно обложенных const данных? Ответ — можно. Как именно — я уже показал.

Для компилятора было бы достаточно знать жизненный цикл значений и было бы достаточно гарантий от вызываемого кода. Так вот, на сегодня эта техника недостоверна из-за возможности в языке нарушать константность. Но не в том виде, как вы показали (когда ссылочной прозрачности относительно неких данных уже не было на входе процедуры), а из-за встроенных в сам язык конструкций по преодолению этой константности. Вот эти конструкции меня и раздражают.

Ну а второе важное утверждение, которое вы в упор не видите, что const — это модификатор уже существующего, порой очень функционального (не в смысле ФП) и очень полезного типа. В отличие от вашего фетиша — иммутабельности, который был бы ни разу не модификатором типа, а тупо отдельный тип. То бишь нельзя было бы один и тот же полезный тип использовать как мутабльный и как иммутабельный. Мне казалось, что этот важный момент был очевиден всем участникам обсуждения, ан нет?

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


S>Это вы почему-то отказываетесь понять, что возможность "наложить ограничения на себя" недостаточна.

Курить распространение константности. Всего достаточно.

Мы вообще что и ради чего обсуждаем? Я так предполагаю, что все в курсе, что суперкомпиляция на сегодня недоступна, что современным компиляторам запросто могут быть недоступны кишки вызываемых подпрограмм, поэтому именно от вызываемых подпрограмм требуются гарантии. Не от вызывающих. Что сами эти гарантии относительно вызываемых подпрограмм нужны исключительно для того, чтобы компиляторы могли делать все оптимизации, которые они могли бы делать в случае ссылочной прозрачности.

В общем, насчет понимания... Я как-раз таки прекрасно понимаю, что не то, что const более чем достаточно для обсуждаемой цели. Я понимаю гораздо больше, но стараюсь не писать лишний раз на этот сайт, дабы не дразнить гусей. Я понимаю, что требование иммутабельности в объявлении типа для целей ссылочной прозрачности — это требование сугубо для человека, а не компилятора. Мне просто лень было поднимать опять эти темы, но уже обсуждали подробно когда-то, и я помню реакции коллег, кому это ломает мозг и вообще переполосывает привычно размеченную территорию. Для обеспечения ссылочной прозрачности требуется отсутствие скрытого (от компилятора!) изменения данных. Это ВСЁ. Т.е. де-факто не нужна никакая иммутабельность для обеспечения ссылочной прозрачности. Пример? Пожалуйста: создавай себе локальные мутабельные переменные в процедурах (хотя бы для счетчика цикла), без передачи ссылок на эти переменные куда-то в "черную дыру", никакого нарушения ссылочной прозрачности не будет. Дык, а если та самая "черная дыра" гарантирует const относительно этой ссылки, то опять же, никакого нарушения не будет, при условии, что та дыра не сохранит эту ссылку, а только использует ее в момент вызова без нарушения const... А вот в этом самом месте тебя должно было озарить, нахрена мне вообще был нужен clean. И в чем его принципиальное отличие от const. ))) Ключевое выделил курсивом.

То бишь, опасности в случае const всё еще сохраняются, но они вовсе не в той стороне, как вы показали в примерах. Вы показали заведомую ссылочную непрозрачность и потребовали создать там прозрачность из воздуха. Детсад как он есть. Налицо непонимание происходящего.


S>Поймите, от чистого кода защищаться не нужно — он на то и чистый. Нужно защищать чистый код от модифицирующего кода. А для этого как раз нужен тот механизм гарантий для callee, которого в const нету.

Увы и ах, поэтому-то чистое ФП и не взлетело в мейнстриме до сих пор, что вы всё еще пытаетесь переложить всё на человека, забывая, зачем вообще эта ссылочная прозрачность нужна. Она нужна компилятору сугубо для оптимизаций, чтобы он мог много чего предполагать, считая свои рассуждения относительно переменных по мере трассировки их значений вдоль алгоритма доказанными. Положа руку на, мне был хотелось ограничиться одной этой фразой вместо всех постов, считая коллег достаточно любопытными, чтобы остальное раскрутить самостоятельно... Но не судьба... Ок, далее.

Помимо этого, константность (в отличие от иммутабельности) — это неплохое подспорье для организации сипмпатичного АПИ. Например, мне глубоко несимпатичны решения навроде отдельных интерфейсов ISomeReader + ISomeWriter inherits ISomeReader, где ссылку на второй интерфейс получают динамическим приведением ссылки на первый. Какая гадость, право... И такое в том же дотнете и Java сплошь и рядом. Или того хуже, возьмем иммутабельный вариант реализации объединенного изначально мутабельного интерфейса, который имеет некое св-во IsReadOnly и плюет в нас исключениями при вызове мутабельных методов в случае иммутабельной их реализации. Понятно, что ни система типов, ни компилятор уже ничем такому смертельно раненому пациенту помочь не могут. А в случае const — могут без проблем.


S>Это та, где вы ссылаетесь на эту? Вот это приём, достойный форумного профи. Как и вырезание вопроса, отвечать на который не хочется.
S>Я верну его на место:

S>

S>А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const.

Дык, я и не мог ответить на таким образом сформулированный вопрос пока видел непонимание работы const. Ведь вопрос связывает одно с другим. Я давал всё больше подсказок — но так и не увидел понимания. ОК, я сел и нахерачил это пост (выбрать на такой пост время тоже не просто). В общем, я не уверен, что и сейчас все участники поняли, как надо заставлять const работать. Но хоть собрал в одном посте все рассуждения и обрисовал ту самую неразрешимую проблему вокруг const, то бишь теперь показал, зачем мне нужен был clean. Он нужен сугубо для:

Потому что с помощью const можно организовать меньше участков кода с соблюдаемой ссылочной прозрачностью, чем бы мне хотелось.

Заведомо зная, что тут надо поднять значительный пласт материала, чтобы показать сей момент, я сразу предупредил:

Этот модификатор, будучи введенным, был бы тесно связан с const... почему именно так — объяснять не намерен. Будем считать этот вопрос планкой вхождения в тему.

Но ты же, блин... Ты же, блин, читаешь форум по диагонали. Ты же сам тут ля-ля одновременно в десятках тем, и считаешь что твои оппоненты делают такое же ля-ля только ради этого самого ля-ля. Я могу себе позволить участвовать обычно в одной теме (очень редко в двух). Поэтому, чтобы общение имело хоть какой-то смысл, было бы неплохо хотя бы иногда перестать бежать отвечать после чтения по диагонали. Посты оппонентов я читаю весьма внимательно, твои в т.ч. Ты — нет. Сорри за оффтоп, но мы дошли аж до сюда по ветке исключительно от твоей невнимательности. Можешь ради любопытства пробежаться теперь по ветке и устыдиться — все входы и выходы были даны сразу, я карт в рукаве не держу и голову людям, как некоторые твои однотимовцы, не морочу.


S>Медитировать, простите, я за вас не буду — вы опять обвините меня в том, что я вам приписываю неправильные мысли. Давайте уж как-то сами.

Ну конечно неправильные. Вы же ставили знак равенства м/у const и иммутабельностью, потом говорили, что это я, оказывается, ставлю, а потом показывали как же я не прав. )))
Это что вообще было, господа хорошие? Сколько мне надо было еще пытаться вас сфокусировать на предмете обсуждения? Ну это просто такое пффф... что теперь стало необходимо проводить ликбез непозволительной для формата форумов глубины в обсуждаемом вопросе, только лишь чтобы доказать, что я не верблюд? Ну, спасибо...

А медитировать я тебя могу отправить лишь над тем вопросом — зачем тебе эта иммутабельность вообще сдалась? Это ключ ко всему. Хотелось бы понимания, что она сама по себе не нужна, что это лишь один из способов для достижения другой полезной цели. Но ни разу не единственный способ.

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


K>И как "не-clean операции" будут отличаться от clean? Т.е. можно будет только clean-функции использовать и только константы читать?

Угу.
Если брать D в котором нечто подобное уже реализовано http://dlang.org/function.html#pure-functions то все очень жестко

does not read or write any global or static mutable state
cannot call functions that are not pure
can override an impure function, but an impure function cannot override a pure one
is covariant with an impure function
cannot perform I/O

Различать же просто компилятор просто не компилирует если условия не соблюдаются

K>Просто я не раз уже видел такие рассуждения "давайте сделаем аннотации чистоты" а когда начинаются вопросы отвечают как в анекдоте: "я вам дал идею, а детали вы сами продумывайте".

В D сделали, это потребовало коренной переделки концепции const из C++ и было основной причиной появления D2.
http://dlang.org/const3.html

По сути получилось три уровня

Immutable то что невозможно никак изменить, для сложных объектов действует транзитивно, в общем чисто функциональные типы.
Const это данные только для чтения, близко к C++ const.
И обычные изменяемые данные.

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


V>Ну вот на такое выдергивание я и высказал фи, бо в том же самом посте далее наблюдается:
V>

V>... пойти еще дальше и ввести некий модификатор clean для ф-ий и методов?

Ну а я отвечу фи на ваш способ выдергивания. Потому что в оригинале было не троеточие, а "или":

Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов?

Что кагбэ подразумевает равноправность решений по убиранию const_cast и введению модификатора clean.

V>Потому что, во-первых, речь шла не об иммутабельности, о ссылочной прозрачности. Это был контекст. Во-вторых, потому что с помощью const можно организовать меньше участков кода с той самой соблюдаемой ссылочной прозрачностью, чем бы мне хотелось. Но это не значит, что их нельзя организовать вообще.
Я не очень понимаю, как вы собираетесь организовывать "участки кода со ссылочной прозрачностью", выходя за пределы одного метода.
Вот мы имеем, скажем,

void foo(const int &x)
{
   cout << x; // 1
   bar();
   cout << x; // 2 
}

Можно ли в точке 2 заменить "адрес" x его "значением", закешированным в точке 1?

V>Вы все писали исключительно об иммутабельности, не понимая кое-какое важное отличие иммутабельности как от исходных требований, так и от реально происходящего в коде. Современный компилятор С++, если видит жизненный цикл значения, спокойно обходится даже без всяких const при оптимизации, не то, что без мифической иммутабельности.
Вы опять делаете необоснованные предположения о том, чего не понимают ваши оппоненты. Ключевое ограничение выделено.
Вопрос только в том, что жизненный цикл значения длиной в одно тело метода малоинтересен на практике. Интересна возможность собирать из мелких кубиков целостные решения, и выводить свойства целого из свойств частей.

V>На самом деле там ничего сложного, достаточно было быть внимательным к постам оппонентов.
V>То бишь, в своих постах я изначально исходил из очевидной для меня (но неочевидной для окружающих, как выяснилось) цели: можно ли организовать в некоей точке видимости исходный код так, чтобы вызываемые непрозрачные для компилятора низлежащие процедуры заведомо не нарушали ссылочной прозрачности относительно обложенных const данных? Ответ — можно. Как именно — я уже показал.
Ну вам же привели на ваше "можно" контрпримеры.

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

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

V>Мы вообще что и ради чего обсуждаем? Я так предполагаю, что все в курсе, что суперкомпиляция на сегодня недоступна, что современным компиляторам запросто могут быть недоступны кишки вызываемых подпрограмм, поэтому именно от вызываемых подпрограмм требуются гарантии. Не от вызывающих. Что сами эти гарантии относительно вызываемых подпрограмм нужны исключительно для того, чтобы компиляторы могли делать все оптимизации, которые они могли бы делать в случае ссылочной прозрачности.
Ну покажите же мне, какие оптимизации может делать компилятор при компиляции foo(const int& x) по сравнению с компиляцией foo(int& x).

S>>Я верну его на место:

S>>

S>>А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const.

V>Дык, я и не мог ответить на таким образом сформулированный вопрос пока видел непонимание работы const.
Нет никакого непонимания работы const.

V>Ведь вопрос связывает одно с другим. Я давал всё больше подсказок — но так и не увидел понимания. ОК, я сел и нахерачил это пост (выбрать на такой пост время тоже не просто).
То есть как обычно — у вас хватило времени налить воды, но кода с примером применения clean мы так и не увидели. ЧиТД.

S>>Медитировать, простите, я за вас не буду — вы опять обвините меня в том, что я вам приписываю неправильные мысли. Давайте уж как-то сами.
V>Ну конечно неправильные. Вы же ставили знак равенства м/у const и иммутабельностью, потом говорили, что это я, оказывается, ставлю, а потом показывали как же я не прав. )))
Никто не ставил знаков равенства. Говорили, что для изоляции чистого кода от мутабельного const не работает. И вы мне тут капсом пишете что нет, он для этого не работает. Зато, предположительно, будет работать clean. Но пока непонятно как. Давайте код в студию, а то без него разговор смысла не имеет.

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

S>Как это? Куда дели enum?
S>RTFM:
S>http://www.modula2.org/reference/enumerations.php
S>http://www.delphibasics.co.uk/Article.asp?Name=Sets
S>То, что в Обероне их нет — это, мягко говоря, не от большого ума. Трудно найти человека, который был бы от этого "улучшения" в восторге. Даже фанаты языка жалеют об их отсутствии.

Кстати, enum на мой взгляд вообще очень мутная концепция. По крайней мере с точки зрения ООП. Чужеродная примесь. Хотя в некоторых кусках кода выглядит полезно, однако фиг знает — может быть существует что-то получше енумов. Еще нехороший момент — для удобства использования требует встраивания в компилятор, эмулировать другими языковыми средствами (чтобы с сохранением этого самого удобства) нельзя...

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

FR>В D сделали, это потребовало коренной переделки концепции const из C++ и было основной причиной появления D2.
FR>http://dlang.org/const3.html

FR>По сути получилось три уровня

FR>Immutable то что невозможно никак изменить, для сложных объектов действует транзитивно, в общем чисто функциональные типы.
FR>Const это данные только для чтения, близко к C++ const.
FR>И обычные изменяемые данные.

Во, это все круто. Мне нравится. Правильно сделано.

Есть еще мысль — надо убрать из языка все ссылки вообще. Передача параметров только копированием значения (семантически, а так компилятор может провести анализ и заменить значение ссылкой). От совсем опасных указателей избавились, теперь пока ссылки выкинуть. ИМХО, сразу уберется куча потенциальных ошибок и код будет более организованным. Циклические структуры данных и рекурсия в пролете.

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

ARK>Кстати, enum на мой взгляд вообще очень мутная концепция. По крайней мере с точки зрения ООП.
С точки зрения ООП — да.
А ООП с точки зрения енумов — мутная концепция. Непонятно, зачем нужен тип данных, у которого может быть произвольное количество попарно различных экземпляров

ARK>Чужеродная примесь. Хотя в некоторых кусках кода выглядит полезно, однако фиг знает — может быть существует что-то получше енумов.
Ну, традиционные енумы как-то очень-очень ограничены. В том плане, что их взаимозаимозаменяемость в известных мне языках уж очень упрощена: либо всё совместимо со всем, либо ничего ни с чем.
А тем временем можно представить себе всякие интересные сценарии — типа сужения/расширения набора легальных значений — которые бы позволяли тайп чекеру отлавливать больше багов, чем можно сейчас.

ARK>Еще нехороший момент — для удобства использования требует встраивания в компилятор, эмулировать другими языковыми средствами (чтобы с сохранением этого самого удобства) нельзя...
Ну, это у всего так. Невозможно эмулировать А на Б с сохранением того же удобства.
Хотя всё зависит от того, как енумы определены. Скажем, если бы енумов не было в джаве, можно было бы их эмулировать на основе класса с приватным конструктором и набором константных статик полей.

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

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

ARK>>Кстати, enum на мой взгляд вообще очень мутная концепция. По крайней мере с точки зрения ООП.
S>С точки зрения ООП — да.
S>А ООП с точки зрения енумов — мутная концепция. Непонятно, зачем нужен тип данных, у которого может быть произвольное количество попарно различных экземпляров

Ну вот когда появятся енум-ориентированные ЯП, тогда можно будет и это обсудить.

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

ARK>>Чужеродная примесь. Хотя в некоторых кусках кода выглядит полезно, однако фиг знает — может быть существует что-то получше енумов.
S>Ну, традиционные енумы как-то очень-очень ограничены. В том плане, что их взаимозаимозаменяемость в известных мне языках уж очень упрощена: либо всё совместимо со всем, либо ничего ни с чем.
S>А тем временем можно представить себе всякие интересные сценарии — типа сужения/расширения набора легальных значений — которые бы позволяли тайп чекеру отлавливать больше багов, чем можно сейчас.

Имеется в виду "наследование енумов"?

ARK>>Еще нехороший момент — для удобства использования требует встраивания в компилятор, эмулировать другими языковыми средствами (чтобы с сохранением этого самого удобства) нельзя...
S>Ну, это у всего так. Невозможно эмулировать А на Б с сохранением того же удобства.
S>Хотя всё зависит от того, как енумы определены. Скажем, если бы енумов не было в джаве, можно было бы их эмулировать на основе класса с приватным конструктором и набором константных статик полей.

Да, но это уже неудобно, бойлерплейт.

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

WH>Эта атака называется http://en.wikipedia.org/wiki/Man-in-the-middle_attack
WH>Известна миллион лет.
WH>Если люди делают шифрованное соединение и не защищаются от этой атаки, то они просто не профпригодны.

Увы, для защиты от этой атаки нужна дополнительная линия связи реалтайм, по которой пойдет дополнительный секрет. В сценарии общения по одному проводу, да еще в полуавтоматизированном режиме, защиты от нее нет, бо для обоих сторон удаленный подставной ендпоинт неотличим от оригинального. То бишь даже вариант заранее присланного по почте пароля не канает, ведь тот идет тоже через прокси. В общем не забываем, что в сценариях взлома всегда предполагается, что все алгоритмы известны.


WH>И такой протокол никогда не пройдет через нормального безопасника.

Татышо! Простой пример: ты входишь в SSH и тебя программа спрашивает, импортировать ли тот ключ с того IP, твои действия? А действия безопасника?
Не изобретай, кароч.


WH>И еще. Не стоит путать прослушивание с проксированием.

Стоит, стоит. Любой твой IP-трафик проходит десяток и больше ендпоинтов, прежде, чем попадет к цели.


WH>Ибо есть протоколы, защищающие от прослушивания, но не проксирования.

Относительно исходной темы об инфраструктуре — это слабые спекуляции.


WH>А есть протоколы, которые можно атаковать только через слабость алгоритмов шифрования.

Дык, сейчас уже сильных алгоритмов в опен-сорсе столько, что... Смотри хотя бы Crypto++ обертку... Да еще бывают для надежности накручивают шифрование многократно, возводя требуемое время для вскрытия в степень. Я в эту тему даже не хочу копать, нереал.


V>>Насчет IOMMU я уже всё говорил, спорить не о чем. Осталось подождать лет 10 и посмотреть на поддержку того зоопарка, который будет к тому времени.
WH>Короче очередной слив засчитан.

Короче, не компосируй мой процессор. Рядом уже подробно всё обсудили, сколько можно повторяться об одном и том же? Твои доводы, что "IOMMU будет мало" — очередные спекуляции чистой воды...

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

WH>>Эта атака называется http://en.wikipedia.org/wiki/Man-in-the-middle_attack
WH>>Известна миллион лет.
WH>>Если люди делают шифрованное соединение и не защищаются от этой атаки, то они просто не профпригодны.

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

http://en.wikipedia.org/wiki/Public_key_infrastructure