Здравствуйте, vdimas, Вы писали:
V>Важно, что ср-вами языка нельзя сделать наоборот для случая ссылок/указателей на это значение, т.е. нельзя const int & привести к int &. Когда берется копия значения (как ты показал), там вообще проблемы нет.
Никакой копии не берётся. Язык так устроен, что я ссылку на mutable XXX спокойно передаю туда, где ждут ссылку на const XXX.
RTFM-мьте до просветления.
S>>То, что я не могу изменить этот инт, не означает, что никто не может.
V>Дык, твой аргумнет известный, я же его и привел: V>
V>Мешает дыра через приведение в стиле С или всякие const_cast, но ведь можно представить такой же точно язык, где этих дыр нет?
Нет, вы привели совершенно другой аргумент. Это аргумент про то, что функция, в которую уехала ссылка на константу (callee), может её взломать через const_cast, обманув ожидания caller-а.
А я говорю про то, что даже убрав из языка C-style cast и const_cast, мы оставляем возможность caller-у обмануть ожидания callee по константности переданной ссылки. Если callee хочет работать с переданным ему по ссылке значением, он обязан сделать копию руками. Если вам это непонятно, то дизайном языков заниматься пока рано — спрашивайте, будем разьяснять.
V>И вообще, речь была не столько о С++, сколько о том, можно ли вообще сделать императивные языки столь же безопасными, как функциональные. Модификатор const и предложенный модификатор clean позволяют организовать ссылочную прозрачность в нужных местах для императивного языка. Надо лишь, чтобы эта гарантия соблюдалась.
Я не знаю семантики "предложенного модификатора clean".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Важно, что ср-вами языка нельзя сделать наоборот для случая ссылок/указателей на это значение, т.е. нельзя const int & привести к int &. Когда берется копия значения (как ты показал), там вообще проблемы нет. S>Никакой копии не берётся. Язык так устроен, что я ссылку на mutable XXX спокойно передаю туда, где ждут ссылку на const XXX.
Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит. Когда речь идет о гарантиях, то нас интересует ровно обратный сценарий, когда мы вводим модификатор const для некоей ссылки/указателя, и эта гарантия полностью соблюдается. Только при соблюдении гарантий речь может идти о ссылочной прозрачности, даже если мы эту ссылку в процессе вычислений куда-то передаём (я думал и так понятно, где находится тот самый момент нарушения ссылочной прозрачности в императивных языках). Болезнь современного С++ в том, что через эти гарантии легко перешагнуть прямо ср-вами языка. Лично меня это раздражает, бо эти перешагивания мне не нужны (да и другим тоже). Но безопасность кода всегда потенциально под угрозой.
S>RTFM-мьте до просветления.
Пользуясь случаем, я бы предложил прогуляться в сад. ))
S>>>То, что я не могу изменить этот инт, не означает, что никто не может.
V>>Дык, твой аргумнет известный, я же его и привел: V>>
V>>Мешает дыра через приведение в стиле С или всякие const_cast, но ведь можно представить такой же точно язык, где этих дыр нет?
S>Нет, вы привели совершенно другой аргумент. Это аргумент про то, что функция, в которую уехала ссылка на константу (callee), может её взломать через const_cast, обманув ожидания caller-а.
S>А я говорю про то, что даже убрав из языка C-style cast и const_cast, мы оставляем возможность caller-у обмануть ожидания callee по константности переданной ссылки.
Обмана никакого нет, если ты неконстантное значение захочешь привести к константе, ведь ты не нарушишь ни одного контракта.
S>Если callee хочет работать с переданным ему по ссылке значением, он обязан сделать копию руками.
Никто никому ничего не обязан. Для императива вся его декомпозиция заключается в декомпозиции кода по обработке данных. А если эта обработка многостадийная, то вот и получи ссылку на неконстантное значение. Зачем это всё? Да пустяки, всего лишь примерно на порядок-полтора эффективнее в нагрузочных сценариях, чем аналогичное, выполненное в функциональной чистоте.
См. с чего пошла речь изначально. Никто не собирался запрещать мутабельность как таковую (на современных архитектурах рассуждения в эту область отдают либо академичностью, либо непревзойденным нубством), речь лишь о том, чтобы отделять мух от котлет, то бишь, если мы ввели иммутабельность в некий контракт, то этот контракт должен быть соблюдён. Точка.
S>Если вам это непонятно, то дизайном языков заниматься пока рано — спрашивайте, будем разьяснять.
А не пробовал лечить по фотографии? ))
Если бы ты хоть примерно представлял, какие проблемы возникают при дизайне языков... Константность — это вообще дело десятое, если не сотое. При всей моей желчи в адрес текущего положения дел в С++ я-то прекрасно отдаю себе отчет, что язык не был разработан с 0-ля в прошлые выходные. Що маэмо те маэмо, включая гирю на ногах из почти 40 лет жизни исходного языка Си.
V>>И вообще, речь была не столько о С++, сколько о том, можно ли вообще сделать императивные языки столь же безопасными, как функциональные. Модификатор const и предложенный модификатор clean позволяют организовать ссылочную прозрачность в нужных местах для императивного языка. Надо лишь, чтобы эта гарантия соблюдалась.
S>Я не знаю семантики "предложенного модификатора clean".
Это блуждающе обсуждалось многократно. Суть предложения в том, чтобы награждать контракт ф-ии/метода неким модификатором (например, "clean"), который требовал бы функциональной чистоты от самих вычислений в теле ф-ии и во всех вложенных вызовах. Этот модификатор, будучи введенным, был бы тесно связан с const... почему именно так — объяснять не намерен. Будем считать этот вопрос планкой вхождения в тему.
И зря ты скипнул тему насчет Maybe... Для императивных языков требуется, я бы сказал, "креативное решение" проблемы нулевых ссылок. ))) На эту тему стоит помозговать. Контракты Spec# относительно этого — это даже не детсад, а ясельная группа.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
V>>>Важно, что ср-вами языка нельзя сделать наоборот для случая ссылок/указателей на это значение, т.е. нельзя const int & привести к int &. Когда берется копия значения (как ты показал), там вообще проблемы нет. S>>Никакой копии не берётся. Язык так устроен, что я ссылку на mutable XXX спокойно передаю туда, где ждут ссылку на const XXX.
V>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.
Хм, не вредит??
int x = 10;
int const & y = x; // мне казалось, что y - не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)
x = 12;
std::cout << "y = " << y << std::endl; // а вот получите болт.
V>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.
Дальнейшая чушь поскипана. Контрпример вам привели. Посыпайте голову пеплом, медитируйте до просветления. Что непонятно — спрашивайте. Обсуждение сложных вещей вроде ссылочной прозрачности и чистоты вычислений мы отложим до момента понимания вами основ — в частности, отличий настоящей иммутабельности от константности в C++.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит. S>Дальнейшая чушь поскипана. Контрпример вам привели.
Нет. Попробуешь ты привести контример?
S>Посыпайте голову пеплом, медитируйте до просветления. Что непонятно — спрашивайте.
Да мне и так понятно, что тебе непонятно. Читай мой пост еще раз. Медленно. Потом думай, где контракт, а где его соблюдение.
S>Обсуждение сложных вещей вроде ссылочной прозрачности и чистоты вычислений мы отложим до момента понимания вами основ — в частности, отличий настоящей иммутабельности от константности в C++.
Обсуждать бесполезно, пока ты не поймешь, что именно я написал насчет гарантий. Пока что у тебя какое-то своё кино.
Здравствуйте, Jack128, Вы писали:
V>>Коллега, ну это гребаныый стыд уже. Ес-но, приводить к const можно, это никому не повредит.
J>Хм, не вредит?? J>
J> int x = 10;
J> int const & y = x; // мне казалось, что y - не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)
J> x = 12;
J> std::cout << "y = " << y << std::endl; // а вот получите болт.
J>
Ну у тебя та же детская ошибка, которую Синклер допускает уже 3-й пост подряд... Кто кому тут здесь определяет контракт? В какую сторону идет распространение константности, на напомнишь?
Что значит "// мне казалось, что y — не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)"??? Тебе до фени, т.к. тебе с этим константным значением ничего нельзя сделать. Теперь см. на свою константность с т.з. вызывающего кода. Когда ты объявляешь себя const для окружающих — это ТЫ гарантируешь, что ТЫ не будешь это значение изменять.
Т.е. ты не можешь как-то требовать константности от вызывающего, но ты можешь гарантировать нечто важное тем, кто тебя вызывает. Далее, согласно правилам распростанения const теперь требуешь константности от вызываемых ТОБОЙ ф-ий для обработки этих же данных. И эта константность будет гарантироваться низлежащими ф-ия для ТЕБЯ. Обратил внимание, в какую сторону распространяется требование константности? А в какую сторону распространяется "чистый" код по факту применения этой константности? Ровно в противоположную. Теперь полегчало?
Если нет, см простой пример:
int m1(const int &) {...}
void m2() {
int x = 10;
// мутабельная часть метода
x = 20;
// абсолютно чистый участок относитльно переменной x - ты никак не сможешь её изменить ДО ВОЗВРАТА ИЗ m1()int y = m1(x);
// опять мутабельная часть кода
x = 30;
}
Описанное верно для случая видимости данных из одного потока.
В общем, изначально речь шла о том, что:
Чистые ФЯ и не запрещают мутабельность — они дают инструментарий для разделения кода на чистый и остальной.
Такое разделение я показал в методе m2. Чтобы оно работало со всеми присущими ФП обещанными плюшками в "чистых" участках кода, гарантии константности должны соблюдаться, то бишь из языка надо убрать дыры, позволяющие её обходить.
Здравствуйте, vdimas, Вы писали:
V>Если нет, см простой пример:
V>int m1(const int &) {...}
V>void m2() {
V> int x = 10;
V> // мутабельная часть метода
V> x = 20;
//Что за идиотский бред!
//А я вот так сделаю
start_thread(&x);
V> // абсолютно чистый участок относитльно переменной x - ты никак не сможешь её изменить ДО ВОЗВРАТА ИЗ m1()
V> int y = m1(x);
V> // опять мутабельная часть кода
V> x = 30;
V>}
void mutator(void *data)
{
int *x=(int*) data;
while(true)
{
*x=rand(); //Happy debugging!
}
}
void start_thread(int *x)
{
beginthread(&mutator, x);
}
Нету в С/С++ никаких таких гарантий. И сделать их нельзя. Const/volatile — это механизм создания контекстов кода, он ничуть не гарантирует целостности данных банально из-за того, что данные передаваемые в константный контекст могут одновременно использоваться в другом потоке из неконстантного.
Здравствуйте, vdimas, Вы писали:
V>Нет. Попробуешь ты привести контример?
Зачем? Вы все ещё не понимаете того, который вам уже привели. V>Обсуждать бесполезно, пока ты не поймешь, что именно я написал насчет гарантий. Пока что у тебя какое-то своё кино.
Я-то как раз всё понимаю. Вы уже почти разобрались — роете в правильную сторону. Попробуйте предоставить гарантии константности для callee, оставаясь в рамках С++.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
J>>Хм, не вредит?? J>>
J>> int x = 10;
J>> int const & y = x; // мне казалось, что y - не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)
J>> x = 12;
J>> std::cout << "y = " << y << std::endl; // а вот получите болт.
J>>
V>Ну у тебя та же детская ошибка, которую Синклер допускает уже 3-й пост подряд... И даже облажавшись, продолжаем обвинять всех остальных в том, что они идут не в ногу? V>Кто кому тут здесь определяет контракт? В какую сторону идет распространение константности, на напомнишь?
Конечно же callee определяет контракт для caller.
V>Что значит "// мне казалось, что y — не может поменяться, это же ссылка на КОНСТАНТУ(неизменяемое значение)"??? Тебе до фени, т.к. тебе с этим константным значением ничего нельзя сделать. Теперь см. на свою константность с т.з. вызывающего кода. Когда ты объявляешь себя const для окружающих — это ТЫ гарантируешь, что ТЫ не будешь это значение изменять.
О! Правильная мысль. V>Т.е. ты не можешь как-то требовать константности от вызывающего, но ты можешь гарантировать нечто важное тем, кто тебя вызывает.
Вот ещё одна правильная мысль. Именно про это я и писал — что если хочется "потребовать константности от вызывающего", то надо сразу при вызове делать полную копию. Иначе полагаться ни на что нельзя — а это запрет оптимизаций, а также возможные нарушения в логике работы.
V>Далее, согласно правилам распростанения const теперь требуешь константности от вызываемых ТОБОЙ ф-ий для обработки этих же данных. И эта константность будет гарантироваться низлежащими ф-ия для ТЕБЯ. Обратил внимание, в какую сторону распространяется требование константности? А в какую сторону распространяется "чистый" код по факту применения этой константности? Ровно в противоположную. Теперь полегчало?
Ну конечно же не полегчало. Потому что вы продолжаете непонимать ограниченность модели, несмотря на то, что оно у вас перед глазами.
V>Если нет, см простой пример: V>
V>int m1(const int &) {...}
V>void m2() {
V> int x = 10;
V> // мутабельная часть метода
V> x = 20;
V> // абсолютно чистый участок относитльно переменной x - ты никак не сможешь её изменить ДО ВОЗВРАТА ИЗ m1()
V> int y = m1(x);
V> // опять мутабельная часть кода
V> x = 30;
V>}
V>
V>Описанное верно для случая видимости данных из одного потока.
Ну, в данном конкретном случае x видим только из одного потока. Более того — из одного контекста. Так что риска нет.
Но m1 об этом ничего не знает, она не может полагаться на ваше честное слово в том, что её будут вызывать исключительно с константами либо со ссылками на локальную переменную.
Первый способ нарушить эти ожидания — использовать аргумент в нескольких потоках.
Второй способ — вызывать из m1() код, который может иметь другой способ доступа к аргументу.
Например, callback-метод, определённый в объекте-владельце аргумента. Безо всяких потоков нарушаем ожидания m1().
V>Такое разделение я показал в методе m2. Чтобы оно работало со всеми присущими ФП обещанными плюшками в "чистых" участках кода, гарантии константности должны соблюдаться, то бишь из языка надо убрать дыры, позволяющие её обходить.
Чтобы оно работало со всеми присущими плюшками, придётся изменить семантику const. Потому что в нынешнем виде этот const ничего не гарантирует вызываемому. Вы не можете в рамках С++ выразить сигнатуру "дайте мне ссылку на объект, который точно не изменится, хотя бы в пределах времени моего исполнения".
А в ФП — можете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>А что мешает в императивном языке использовать тот же const?
Это тут уже подробно обсудили.
V>Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов? И чтобы этот модификатор точно так же распространялся и обслуживался системой типов языка для ф-ий и методов аналогично как const для значений?
Зачем какие-то специальные идентификаторы, если можно уже имеющейся системой типов обойтись? И как этот идентификатор будет "обслуживаться"? Каким-то чудо-анализатором кода? Да и сложно извлечь какую-то выгоду из крошечных pure островков в океане мутабельности — польза будет только от обратного соотношения, если мутабельность сократится до островков.
В языках, где это реально работает, чистота функций гарантируется по построению. Начинается все с базовой иммутабельности — const-ов для этого не достаточно. Однако, изменяемые ссылки нужны и мы добавляем в чистый язык соотвествующие функции:
readMutVar :: MutVar a -> a
writeMutVar :: MutVar a -> a -> ()
Так делается в SML и в этот момент эта "чистота по построению" теряется. Т.е. в случае "в основном иммутабельного" языка вроде ML это решение уровня библиотеки (по большому счету, некоторая модификация языка нужна — неявный runIO для main).
Мы же сейчас строим чистый язык, так что этот вариант для нас не подходит — нам нужна другая библиотека.
Делаем функции работы с изменяемыми ссылками чистыми:
readMutVar :: MutVar a -> State -> (State, a)
writeMutVar :: MutVar a -> a -> State -> State
Все, теперь сайд-эффект обозначен как "изменение" некоторого фиктивного параметра State — т.е. сайд-эффектом он быть перестал, ссылочная прозрачность не нарушается.
Но у нас все еще есть проблема: из таких функций можно собрать функцию, которая чистой не является, ссылочную прозрачность нарушает.
Как же быть? Если в языке есть уникальные типы — мы просто делаем State уникальным:
readMutVar :: MutVar a -> *State -> (*State, a)
writeMutVar :: MutVar a -> a -> *State -> *State
Все, теперь "нечистая" комбинация таких функций просто не пройдет тайпчек.
Ну а что делать, если у нас уникальных типов нет?
Нам поможет другой аспект типобезопасности — обычная инкапсуляция.
readMutVar :: MutVar a -> State -> (State, a)
-- слегка поправим сигнатуру:
writeMutVar :: MutVar a -> a -> State -> (State,())
-- теперь сходство становится очевидным:newtype IO a = IO (State -> (State, a))
readMutVar :: MutVar a -> IO a
writeMutVar :: MutVar a -> a -> IO ()
Теперь реализуем комбинаторы для этих функций, которые сохраняют уникальность State, и экспортируем их, а конструктор IO не экспортируем.
Вот теперь любая функция у нас чистая по построению (пока мы не нарушим инкапсуляцию IO).
Как видите, мы обошлись без монад, поэтому я и говорил, что они не нужны. Но желательны. Для чего? Для уменьшения писанины.
Выше я упоминал "безопасные комбинаторы". Для удобства их нужно много, а минимальный их набор — две штуки. Так вот, набор удобных комбинаторов, выражаемых в терминах этих базовых двух — одинаков для всех монад. А описываемое выше протаскивание параметра-состояния — это монада state. Поэтому вместо отдельной инфраструктуры построения безопасных (с точки зрения ссылочной прозрачности) мутирующих функций нам нужно просто реализовать инстанс класса Monad для IO (две функции). Плюс к тому, для монад делается синтаксический сахар, который маскирует всю эту "обвязку" из комбинаторов.
Класс Monad — это только одно из доступных решений. В хаскеле сейчас "из коробки" есть две иерархии таких интерфейсов для комбинации вычислений Functor/Applicative/Monad и (менее популярные) стрелки.
V>Просто если уж говорить про тот самый "синтаксический оверхед", то примитивная операция x++ над регистром x в Хаскеле выглядит довольно многословно.
Этот "синтаксический оверхэд" (зло)намеренный. В стандартной библиотеке хаскеля для таких функций любят придумывать имена вроде пожалуйстаПрочитайЗначениеПоЭтойСтрашнойСтрашнойИзменяемойСсылке и написаниеЭтогоЧудовищноДлинногоИмениФункцииЯвляетсяНаказаниемЗаИзменениеПеременной. Ну, как написание ключевых слов Оберона является наказанием за то, что программист решил написать код на Обероне. Все это, с моей точки зрения, идиотизм. Но в случае хаскеля это можно исправить, сильно улучшить краткость и удобство работы с мутабельными ссылками/массивами, просто описав удобные функции в библиотеке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Cyberax, Вы писали:
C>Нету в С/С++ никаких таких гарантий. И сделать их нельзя.
Может тебе стоило перечитать хоть немного из ветки, прежде чем бросаться с шашкой на танк?
Да и нехорошо скипать кючевое:
Описанное верно для случая видимости данных из одного потока.
А то ты сам с собой споришь.
C>Const/volatile — это механизм создания контекстов кода, он ничуть не гарантирует целостности данных банально из-за того, что данные передаваемые в константный контекст могут одновременно использоваться в другом потоке из неконстантного.
— const гарантирует даже из другого потока (если не пользовать дыры приведения типов), просто ты не подал переменнуюв другой поток как const.
— Зачем мне рядом с const нужен был еще один модификатор clean для ф-ий, который, оп-па, в некоторых сценариях уже прямо сейчас покрывается const? Наверно потому, что есть сценарии, где не покрывается?
Вот всяко более простой пример, чем ты привел:
void m3(int & a, const int & b) {
a++;
}
void m2() {
int x = 10;
// участок уже нечистый, т.к. мы вызываем нечистый методint y = m3(x, x);
}
Вот здесь особенно хорошо видно, зачем мне модификатор clean для кода.
Здравствуйте, Sinclair, Вы писали:
V>>Ну у тебя та же детская ошибка, которую Синклер допускает уже 3-й пост подряд... S> И даже облажавшись, продолжаем обвинять всех остальных в том, что они идут не в ногу?
Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ... поэтому я как раз-то хотел его обсудить — некий clean. Т.е., до этого поста ты даже не понимал, зачем я вообще рассуждаю относительно еще одного модификатора? Круто! ))
V>>Кто кому тут здесь определяет контракт? В какую сторону идет распространение константности, на напомнишь? S>Конечно же callee определяет контракт для caller.
ЧТД. Поэтому я прямо сейчас остановлюсь и даю тебе еще одну попытку. Ты НЕ знаешь, как работает const в С++. Ты НЕ понимаешь, как можно выстроить полезные гарантии на основе const, то бишь для тебя, будь ты программистом С++, этот модификатор был бы более чем бесполезен...
В общем, спасибо за честность, но я уже 4 поста назад сказал, что ты неправильно понимаешь, зачем этот const вообще нужен. Будем считать, что я понятия не имею, что именно ты пытаешься обсуждать... Мне даже лень, если честно, фантазировать в сторону той семантики const, которую ты себе надумал и затем вдребезги "разбил". Может, как-нить потом на эту тему. Могу лишь дать ключевую затравку: модификатор const относится исключительно к данным (даже если стоит при экземплярном методе, то он стоит перед this), а надуманный мной модификатор clean стоял бы исключительно как модификатор сигнатуры ф-ий/методов. В общем, даже одна эта деталь должна была заставить тебя помедитировать — почему именно так? Еще не поздно, кстате.
Здравствуйте, Sinclair, Вы писали:
S>Я-то как раз всё понимаю. Вы уже почти разобрались — роете в правильную сторону. Попробуйте предоставить гарантии константности для callee, оставаясь в рамках С++.
Здравствуйте, Klapaucius, Вы писали:
V>>А что мешает в императивном языке использовать тот же const? K>Это тут уже подробно обсудили.
Еще нет. Всё самое интересное только начинается. Рекомендую последить за темой. ))
V>>Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов? И чтобы этот модификатор точно так же распространялся и обслуживался системой типов языка для ф-ий и методов аналогично как const для значений?
K>Зачем какие-то специальные идентификаторы, если можно уже имеющейся системой типов обойтись? И как этот идентификатор будет "обслуживаться"? Каким-то чудо-анализатором кода?
Прямо компилятором и будет, не нужно никакое чудо. Если сигнатура ф-ии помечена как clean, то в теле ф-ии не может быть не-clean операций.
K>Да и сложно извлечь какую-то выгоду из крошечных pure островков в океане мутабельности — польза будет только от обратного соотношения, если мутабельность сократится до островков.
Это спекуляции, положа руку на. Мне даже от одного const очень много пользы удается извлечь, т.к. в первую очередь я использую этот модификатор для себя, то бишь сам себе бью линейкой по рукам. При наличии clean эта линейка была бы заметно увестистей. Банально хочется заствить компилятор делать больше работы по проверке кода.
K>В языках, где это реально работает, чистота функций гарантируется по построению. Начинается все с базовой иммутабельности — const-ов для этого не достаточно.
Потому что рассуждаете в сторону const=иммутабельность. Но это нерелевантное сопоставление. Распространение константности ровно противоположно направлению распространению иммутабельности. Это же по природе вещей и так должно было быть понятно: гарантии от себя противоположны требованиям от других.
Так вот, я утверждаю, что не смотря на противоположное направление распространения константности, таки можно добиться гарантий иммутабельности в некоей конкретной точке.
K>Теперь реализуем комбинаторы для этих функций, которые сохраняют уникальность State, и экспортируем их, а конструктор IO не экспортируем. K>Вот теперь любая функция у нас чистая по построению (пока мы не нарушим инкапсуляцию IO).
Спасибо за расшифровку IO, но ее читал уже давно. Напомню мой недавний тезис:
Просто если уж говорить про тот самый "синтаксический оверхед", то примитивная операция x++ над регистром x в Хаскеле выглядит довольно многословно.
Почему так? Потому что Хаскель предлагает комбинировать ф-ии программисту и проверяя их чистоту. Предложенный модификатор clean затсавлял бы аналогично программистов так комбинировать ф-ии, чтобы не нарушать этот модификатор.
K>Как видите, мы обошлись без монад, поэтому я и говорил, что они не нужны. Но желательны. Для чего? Для уменьшения писанины.
Разве только для этого. Вроде бы через модификатор IO компилятор позволяет опасные конструкции, типа чтения памяти (например, для связи с легаси-АПИ).
K>Выше я упоминал "безопасные комбинаторы". Для удобства их нужно много, а минимальный их набор — две штуки. Так вот, набор удобных комбинаторов, выражаемых в терминах этих базовых двух — одинаков для всех монад. А описываемое выше протаскивание параметра-состояния — это монада state. Поэтому вместо отдельной инфраструктуры построения безопасных (с точки зрения ссылочной прозрачности) мутирующих функций нам нужно просто реализовать инстанс класса Monad для IO (две функции). Плюс к тому, для монад делается синтаксический сахар, который маскирует всю эту "обвязку" из комбинаторов. K>Класс Monad — это только одно из доступных решений. В хаскеле сейчас "из коробки" есть две иерархии таких интерфейсов для комбинации вычислений Functor/Applicative/Monad и (менее популярные) стрелки.
V>>Просто если уж говорить про тот самый "синтаксический оверхед", то примитивная операция x++ над регистром x в Хаскеле выглядит довольно многословно.
K>Этот "синтаксический оверхэд" (зло)намеренный. В стандартной библиотеке хаскеля для таких функций любят придумывать имена вроде пожалуйстаПрочитайЗначениеПоЭтойСтрашнойСтрашнойИзменяемойСсылке и написаниеЭтогоЧудовищноДлинногоИмениФункцииЯвляетсяНаказаниемЗаИзменениеПеременной.
Длинное имя абсолютно непринципиально для того, что хочу я — заставить компилятор больше мне помогать. Ему длина идентификаторов до фени.
K>Ну, как написание ключевых слов Оберона является наказанием за то, что программист решил написать код на Обероне. Все это, с моей точки зрения, идиотизм.
ХЗ, в том же С++ я вынужден разметкой комментов выделять отдельные ф-ии, чтобы они не сливались с окружающим "фоном". На паскалевских языках такое выделение идет изкаробки через ключевые слова.
K>Но в случае хаскеля это можно исправить, сильно улучшить краткость и удобство работы с мутабельными ссылками/массивами, просто описав удобные функции в библиотеке.
Здравствуйте, vdimas, Вы писали: V>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ...
Ровно про это вам и писали. Это вы предлагали использовать модификатор const для обеспечения "всех нужных гарантий". Это вас интересовало "что мешает в императивном языке использовать тот же const". Отлично — потребовалось всего пять дней и восемь постов чтобы понять, что же именно мешает.
А теперь, если вам хочется поговорить про гипотетический модификатор clean, то приведите пример того, как с его помощью вы собрались решать проблему, неразрешимую при помощи const. И постарайтесь избегать умозаключений на тему того, кто тут насколько знает С++ — они мало кому интересны. Я вам про это уже говорил. Если у вас цель — довыступаться до бана, то так и напишите на модераторский адрес.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ... поэтому я как раз-то хотел его обсудить — некий clean. Т.е., до этого поста ты даже не понимал, зачем я вообще рассуждаю относительно еще одного модификатора? Круто! ))
Здравствуйте, Sinclair, Вы писали:
V>>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ... S>Ровно про это вам и писали. Это вы предлагали использовать модификатор const для обеспечения "всех нужных гарантий".
Фи, какие грязные инсинуации. В общем, ЧТД.
Нубский, надо сказать, для 2012-го года приёмчик, приписать что-то оппоненту и пытаться вздебезги его разбить. Можно мне добавки попкорна, мне уже забавно над этим наблюдать.
==========================
Кароч, интересующая подветка обсуждания на месте, читайТЕ её целиком.
V>>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ... поэтому я как раз-то хотел его обсудить — некий clean. Т.е., до этого поста ты даже не понимал, зачем я вообще рассуждаю относительно еще одного модификатора? Круто! ))
FR>В C++ никаких гарантий нет.
Дык, были бы гарантии, не было бы обсуждений, что бы мне хотелось в С++ доработать.
Здравствуйте, Klapaucius, Вы писали:
K>Зачем какие-то специальные идентификаторы, если можно уже имеющейся системой типов обойтись? И как этот идентификатор будет "обслуживаться"? Каким-то чудо-анализатором кода? Да и сложно извлечь какую-то выгоду из крошечных pure островков в океане мутабельности — польза будет только от обратного соотношения, если мутабельность сократится до островков.
По мне тоже система типов лучше, но модификаторы типа const тоже вполне нормально для императивных языков, но
в C++ const это во многом чистая косметика (хотя даже это дает возможность писать более надежный код), вот в D
все уже серьезно.
Польза очень даже извлекается, во первых оптимизация кода и перенос вычислений в compile time второе
многопоточность.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
V>>>Кого всех-то? Я пока обвиняю только тех, кто считает, что const — это требования гарантий от других, а не декларация предоставления гарантий от себя. Желаемого тебе модификатора типа, означающего требование гарантий от других в С++ НЕТ... S>>Ровно про это вам и писали. Это вы предлагали использовать модификатор const для обеспечения "всех нужных гарантий".
V>Фи, какие грязные инсинуации. В общем, ЧТД.
V>Нубский, надо сказать, для 2012-го года приёмчик, приписать что-то оппоненту и пытаться вздебезги его разбить. Можно мне добавки попкорна, мне уже забавно над этим наблюдать.
V>========================== V>Кароч, интересующая подветка обсуждания на месте, читайТЕ её целиком.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
И даже облажавшись, продолжаем обвинять всех остальных в том, что они идут не в ногу?
