Re[40]: Оберон круче всех!
От: vdimas Россия  
Дата: 09.08.12 12:13
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

V>>Мне нужен ИНСТРУМЕНТ, чтобы я мог описывать типы с безопасными АПИ.

S>Инструмент для этого подходит любой. Безопасные АПИ можно клепать хоть на K&R С. Вот только доказать это не удастся.

Из-за ссылочной непрозрачности, так ведь? На С++ сегодня аналогично — невозможно. Медицинский факт. Нужен некий предложенный мною clean (он же pure в D2). Нужно убрать хаки константности. Нужно распространять константность на значения, располагаемые по адресу из ссылочных типов.


V>>Как описывать это безопасное АПИ — я показал более одного раза.

S>

V>>Что мне для этого надо — уже пояснил. Без хаков ты это безопасное АПИ не сломаешь никак.

S>Я показал, и неоднократно, как ваше "безопасное" АПИ ломается на раз-два.

Оно никак не ломается даже в твоих примерах. Дай ссылку или скопируй сюда самый каверзный из приведенных — я разберу его пошагово. А так же покажу как допилить до безопасного варианта, если требуется. Безопасность определяется в ТЗ, ес-но, и более ничем.

Столкновение происходит сугубо в твоём понимании семантики const. Я специально заменил его на "ref in" на шарпоподобном языке, чтобы семантика более соответствовала названию модификатора переменной-аргумента. Другой семантики у const НЕТ, и ты ругаешь за то, что ееё нет. Но это обсуждение в никуда. Я вызвался расписать безопасный сценарий именно в этой семантике. Почему мне не нужна явная иммутабельность — уже говорил. Потому, что это прибитые гвоздями ограничения к типам, а мне надо над одними и теми же данными разрабатывать чистые и нечистые алгоритмы. Выделенное ключевое. Помнишь, я тебе обрисовывал сценарий устойчивого к исключениям кода? ИМХО, в пространстве иммутабельности это заведомо невоможно без лишних приседаний/копирований. Может я и ошибаюсь — тогда покажи как это возможно.


V>>Как вылечить твои примеры, чтобы они были безопасными — я тоже уже комментировал.

S>Да никак их не вылечить.

Ты давай ТЗ, а я дам решение. А то пока что были сниппеты кода, от которых ты безосновательно много чего хотел.

V>>Ты можешь привести любой пример и я покажу как его вылечить. Я ХЗ где здесь rocket scince?

S>Нет никакой rocket science. Есть упорное непонимание в лице одного субъекта того, как работает компилятор.

Он работает, как ему скажешь. Если ты ему дал кривой код, он честно его скомпилит и выполнит.

V>>Если бы ты описывал иммутабельный объект на C# разве ты был бы не в состоянии визуально обнаружить некую ошибку, нарушающую эту иммутабельность?

S> "Визуально"... Визуально я и в С могу найти. А могу — не найти. Нету в шарпе (и вообще в дотнете) средств статически проверить иммутабельность. Система типов не та.

Воот, а в С++ есть. ))
Даже замечание насчет кривизны распространения константности на ссылочные переменные-мемберы разруливается устоявшимся способом:
template<typename T>
class SmartPtr {
  T * target_;
  ...
  T * get() { return target_; }
  const T * get() const { return target_; }
}


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

V>>Аналогично насчет моих const и clean. Только мне легче гораздо, бо компилятор много чего контроллирует.

S>Я же показал вам пример с вашим const и clean, который показывает, что никаких гарантий такой clean не даёт.

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

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

S>Ещё раз объясню: я прекрасно понимаю семантику const. Это вы не понимаете, почему она бесполезна.
S>Вы показали ровно один изолированный пример, где время жизни идентификатора полностью контролируется компилятором.

Ес-но. И трекается глазами программиста. Это необязательно могла бы быть константа. Это может быть откуда-то полученное значение, сохраненной во временной переменной. По-сути, каждая новая строчка кода может оперировать над данными, у которых ссылочная прозрачность соблюдена, а может нет. Я могу делать такие выводы, трекая в уме алгоритм, протаскивая по коду ссылочную прозрачность, ориентируясь на сигнатуры вызываемых ф-ий/методов. Заметь, operator=() [присвоение] — точно такая же сигнатура некоей ф-ии. Это ключ к пониманию твоих собственных примеров.

При наличии инструмента описания безопасного АПИ всех объектов, начиная с самого нижнего уровня, я просто буду охотиться за гораздо меньшим кол-вом ошибок в нейтивных программах. Ведь с виду в коде всегда всё правильно, но где-то "унутре" возникают самые разнообразные сочетания эффектов. А транзитивная распространяемость модификатора clean поможет мне в случае, если я забыл о нем на некоем низлежащем уровне, то уж вышестоящий мне "напомнит". И не будет никаких эффектов "унутре".

S>Шаг вправо-влево — и всё, никаких бенефитов.

V>>Вот этот пример читал: http://www.rsdn.ru/forum/philosophy/4838650.1.aspx
Автор: vdimas
Дата: 01.08.12
?

S>Читал. Отлично. То есть вся ссылочная прозрачность действует ровно в пределах одного метода, на локальную переменную, и только до тех пор, пока мы не произвели вызов, где ссылка на неё фигурирует в качестве не-конст параметра.
S>Это и есть ваше "константность прекрасно распространяется"?

Да именно, это и есть определение ссылочной прозрачности. Я хочу точно знать, что происходит с КАЖДЫМ локальным значением в КАЖДОЙ ф-ии/методе, когда передаю не копию значения, а ссылку. Весь мой код состоит из ровно таких же ф-ий/методов, так что мне гарантий в пределах одного метода — более чем достаточно.


S>В вашем примере компилятор не может оптимизировать код foo — по причине, которую я вам уже семь раз изложил, а вы полагаете эту причину "непониманием семантики const". Ну так код foo и надо в первую очередь оптимизировать! В случае нормальной архитектуры вы строите код из отдельных модульных кусочков. Вся реальная работа происходит где-то внутри функций, а не в клее, которым вы их соединяете. И как раз там нет никакой пользы от константности.


==============
Почему я, собсно, мусолю эту тему. Низлежащая современная модель вычислений железок, увы, доживет до моей смерти как профессионала. До твоей тоже. Это очередной медицинский факт. То бишь надо исходить из того, что есть. За ситуацией в суперкомпиляции я слежу с периодичностью раз в год примерно... На сегодня эта ситуация еще не преодолела зачаточный уровень и не скоро преодолеет — никаких предпосылок. Буквально единицы лет назад в академических кругах научились делать "суперкомпиляторный анализ" императивного кода, до этого вообще был детский сад, представляющий из себя чуть продвинутую бета-редукцию над ФП. Почему так медленно идёт движение в этой области? Любое ветвление в программе — это лишний множитель комбинаторного кол-ва вариантов исполнения, то бишь сложность анализа от сложности алгоритма — степенная. Современные компиляторы проводят анализ в самых простейших случаях до 10 уровней глубины, в сложных — дай бог 2-3. Исходники gcc открыты, можно посмотреть самому. Понимаешь, из-за степенной природы происходящего, наблюдаемая вроде бы неплохая геометрическая прогрессия в росте мощщи железа ничего кроме пессимизма не вызывает. Ни ты, ни я не увидим "золотого века IT". Например, gcc в последних версиях медленно но верно догоняет MS VC по эффективности конечного образа. Именно поэтому gcc таки относительно скоро нагонит MSVC, что он его настигнет прямо в точке насыщения возможностей, выжимаемых из машин разработчиков. Это я всё к тому, что в течении ближайших 10-20 лет никакое самое вылизанное ФП по эффективности не догонит аналогично вылизанный императив даже близко. На плюсах я сижу неплотно лет 20, плотно более 15 лет. Все их достоинства и недостатки собственной задницей ощущал не раз, так же как знаю как с ними бороться. Я могу выжимать из машины максимум, умею это и люблю. Помимо выжимания, есть определенные способности находить нетривиальные ошибки даже в чужом коде. Считай, у меня в сформировалась некая статистика по причинам всех этих ошибок. Самые популярные, ес-но, не те ярлыки, которые навешивают на плюсы — типа выхода за границы диапазонов. Самые популярные сегодня — это неверное представление о работе собственных многопоточных программ, иногда откровенные гонки. Причем, эти гонки не из-за непоходимости разработчиков, ес-но, а из-за всего здесь обсуждаемого, из-за скрытого неявного поведения/зависимостей, которое в реальном коде образуется немыслимыми сочетаниями сценариев. Обычный разработчик уже на глубину более 3-х уровней зависимостей смотрят с ооочень большим трудом и не часто. В идеале хотелось бы 1 уровень. И мне/нам обсуждаемые языковые ср-ва помогут заметно сэкономить на отладке. А если брать предлагаемую банальную иммутабельность — наоборот, добавит работы и снизит эффективность решения. С другой стороны, видя здесь резкую реакцию на "выскочку, идущую против генеральной линии партии", таки есть сомнения — что я еще не увидел? Вдруг есть еще кое-какие моменты?

Просто пока что в меня тыкали примерами, скажем, заведомо нерелевантными обсуждаемому. Все примеры отталкивались от некоего гипотетического требования к семантике const, которого (1) нет и (2) мне, как разработчику на этом языке — не нужно (по приведенным в 3-й раз причинам).
===========
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.