Здравствуйте, Klapaucius, Вы писали:
V>>Ссылочная прозрачность на основе типобезопасности дает точно такой же эффект контроллируемой мутабельности.
K>А мы о чем сейчас говорили?
О том, что для этого не нужна никакая специальная монада, а достаточно обычной статической типобезопасности в обычном императивном языке. Без вот этого динамического приведения типов как в популярных средах исполнения.
K>Ну так это же и хорошо. Потому, что ФП существует в том числе и для решения проблем с сайд-эффектами.
Здравствуйте, vdimas, Вы писали:
V>О том, что для этого не нужна никакая специальная монада, а достаточно обычной статической типобезопасности в обычном императивном языке.
1) Монада, действительно не нужна, а точнее не обязательна. Это только один из интерфейсов IO, из коробки есть еще аппликативный функтор (менее мощный) и стрелки (той же мощности). Можно добавлять и другие интерфейсы, если это нужно.
2) В инстансе класса Monad для IO нет ничего специального. Обычный библиотечный код.
3) Ссылочная прозрачность и обеспечивается "обычной статической типобезовасностью". IO — это абстрактный тип, конструктор которого из модуля, где он определен, не экспортируется. Зато экспортируется набор операций, которые позволяют работать с IO безопасным образом. Скомбинировать их (штатным образом) так, чтоб нарушилась ссылочная прозрачность нельзя — в этом и весь фокус. Разумеется, имея лазейку для приведения любых типов к любым можно пробить дыру в абстрактности IO и реализовать опасные операции, нарушающие ссылочную прозрачность.
V>Без вот этого динамического приведения типов как в популярных средах исполнения.
Какое еще динамическое приведение?
V>И каким образом ФП решает эти проблемы?
Предоставлением альтернативных решений, там где они возможны, средствами изоляции и классификации эффектов (на уровне системы типов в том числе), инструментарием декомпозиции общего назначения, который можно и для улучшения императивного кода использовать, помимо прочего.
... << 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
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Kernan, Вы писали:
K>>Сергей Губанов, вы реинкарнировали в vdimas?
V>И да, ты произнес ключевое слово, теперь ты вне игры. Следующий.
V>))
Да я и так вне игры после наблюдения за психоделической веткой "синтаксический оверхед".
Здравствуйте, Klapaucius, Вы писали:
V>>И каким образом ФП решает эти проблемы?
K>Предоставлением альтернативных решений, там где они возможны, средствами изоляции и классификации эффектов (на уровне системы типов в том числе), инструментарием декомпозиции общего назначения, который можно и для улучшения императивного кода использовать, помимо прочего.
А что мешает в императивном языке использовать тот же const?
В С++ модификатор const прекрасно распространяется, обслуживается и гарантируется... Мешает дыра через приведение в стиле С или всякие const_cast, но ведь можно представить такой же точно язык, где этих дыр нет?
Или пойти еще дальше и ввести некий модификатор clean для ф-ий и методов? И чтобы этот модификатор точно так же распространялся и обслуживался системой типов языка для ф-ий и методов аналогично как const для значений?
Просто если уж говорить про тот самый "синтаксический оверхед", то примитивная операция x++ над регистром x в Хаскеле выглядит довольно многословно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>Особую остроту придает тот факт, что перечисленные пункты не новость, а старше того же Оберона многократно, но так и не взлетели. И не взлетят, бо противоречат инкапсуляции ООП/КОП.
AVK>Ужас то какой. Ну расскажи тогда, как в православном ООП 21 века следует разруливать такие ситуации: есть некое значение, которое может быть представлено следующим образом: как строка, как поток и как объектная ссылка? Будем руками везде дискриминант анализировать без какого либо контроля? Или городить над 3 вариантами визитор?
Православное ООП 21 века — это Java/C#? Да, там других вариантов похоже нет.
А вообще это насколько частая/нормальная ситуация? Чтобы значение было настолько разнородным. Лично мне такое, кажется, вообще не встречалось, правда я компиляторы не пишу.
V>>Ты потребовал его абстрактность, а это нефункциональные требования, то бишь это просто диктуется неким твоим де-факто дизайном операций вокруг AST. AVK>Нет такого. Есть вполне конкретная задача — хранить и использовать значение, которое может быть трех видов.
Она полностью решена. Но не в том виде, как ты от меня требовал. Тебя это задело.
Я тебе уже сказал что надо делать — дать сюда отрывок кода целиком на любом из твоих вариантов, и я верну его переделанным в мой вариант. Это было так сложно?
V>>Мне вообще всё равно, на каком механизме run-time полиморфизма ты решил сделать свой абстрактный тип данных. Принципиальной разницы у тебя НЕТ. А у меня есть. AVK>Вот вся суть твоих сообщений.
Суть была ниже и она никуда не делась, то сообщение на месте.
AVK>Ты нахватался обрывочных знаний, но как дело доходит до конкретики и применения, то начинаются сплошные разводы на воде.
Ну попроси кого-нить из коллег объяснить, делов-то... Того же Вольфхаунда. Он хоть и вредный, но соображающий.
AVK>Вобщем, в очередной раз заканчиваю общение с тобой из-за физической невозможности вчитываться в десятки килобайт расплывчатого текста в каждом сообщении.
Ай молодца. Сначала потребовал предоставить код и пояснить о чем речь, но стоило предоставить и то и другое, как решил испариться.
================
Короче, я не удивлен. К чему ты клонил, было понятно сразу. Но я честно предупредил, что вариантов больше 2-х. Так что будем считать, что ты обиделся на то, что твой пример относительно "ООП 21" (С) был неудачным.
Здравствуйте, AndrewVK, Вы писали:
V>>А на то, что ты не хотел спросить, я бы предпочел увидеть основные операции по этому значению, прежде чем что-то советовать.
AVK>Основная операция ровно одна — потребление этого значения. Строка парсится, стрим выкачивается в память, объект используется как есть.
Хм. В таком случае алгебраический тип не нужен — нужен просто один метод для "объекта как есть" и пара конвертеров из строки и из объекта.
В первом же коротком посте была упомянута суть приведенного впоследствии решения:
А может удобней будет протянуть сразу "замкнутый" типизированный алгоритм на нужную струткуру данных? Зачастую многократно и удобнейи эффективней, чем упаковывать значние конкретного типа в абстрактное и распаковывать затем на паттерн-матчинге или визиторе.
Поискал сейчас и увидел, что в функциональных языках аналогичный трюк избавлению от алгТД называется "CPS-трансформация". На плюсах таким же точно трюком для избавления от визитора пользуюсь уже давно. Оч удобно, всем рекомендую.
====================
Ну и характерно, что ты процитированное предложение сразу скипнул при ответе. И затем всячески делал вид, что такого способа не существует, пытаясь перевести обсуждение в сравнение исключительно алгТД vs визитор. Несерезно.
Здравствуйте, AlexRK, Вы писали:
ARK>Православное ООП 21 века — это Java/C#?
Это ты vdimas спроси. Он тут нам рассказывает, что АлгТД с ООП несовместимы.
ARK>А вообще это насколько частая/нормальная ситуация?
В некоторых задачах — очень частая. Мои пример — из DSL для импорта данных. Там значение полей может быть указано так:
<where v:Code="SomeCode"> <!-- Просто строка в атрибуте -->
<v:Quantity>25.5</v:Quantity> <!-- А здесь надо ее к decimal преобразовать -->
<v:Ref>SomeClass.RefID</v:Ref> <!-- Здесь ссылка, которую надо отресолвить и достать по ней данные -->
<v:Ref2>USD</v:Ref2> <!-- А здесь ссылка по значению, значение которой получается запросом к тому, на что ссылаются со сравнением уникального поля, которое, собственно, и указано в теле тега -->
<v:Description file="Description1.txt"/> <!-- Здесь значение хранится в другом файле. При этом загружать файл в память весь нельзя, нужно перелить через буфер фиксированного размера в другой поток. -->
</where>
Вот все эти значения должны обрабатываться по единым правилам до тех пор, пока непосредственно не нужно будет что то читать в БД или загружать туда. А вот когда понадобится, то надо выполнить операцию формирования запроса уникальным для каждого типа значения способом.
Так вот, АлгТД позволяют решать такие задачи практически идеальным способом, ничуть не выбиваясь из ООП (и в F# и в Немерле они все равно сводятся к обычным классам с дискриминантами). И я бы еще понял, если бы речь зашла о том, что, в принципе, задачи, решаемые ими, можно решить статически, без участия рантайм полиморфизма, но при чем тут инкапсуляция — мне вообще непонятно, так как АлгТД выставляют наружу вполне себе классический контракт из набора свойств и дискриминанта, никак не афишируя внутреннюю структуру хранения и реализации.
ARK>Лично мне такое, кажется, вообще не встречалось, правда я компиляторы не пишу.
Тут такое дело — если ты не знаешь что это и для чего, то ты можешь просто не видеть те места, где они дают существенный выигрышь. К примеру, даже сейчас товарищи некоторые считают, что все нововведения C# 3 бесполезны и им некуда их применить.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>Поискал сейчас и увидел, что в функциональных языках аналогичный трюк избавлению от алгТД называется "CPS-трансформация".
Не знаю что ты там искал, но CPS-трансформация никакого отношения к диспетчеризации не имеет, это способ преобразовать прямой код в декларативное продолжение, которое потом можно сделать ленивым, асинхронным и т.п. АлгТД этим никак не заменяется.
V>Ну и характерно, что ты процитированное предложение сразу скипнул при ответе.
Открою тебе страшную тайну — я твои простыни целиком не читаю, мне времени жалко.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AlexRK, Вы писали:
ARK>Хм. В таком случае алгебраический тип не нужен — нужен просто один метод для "объекта как есть" и пара конвертеров из строки и из объекта.
Не понял. Напиши псевдокод.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
V>>Поискал сейчас и увидел, что в функциональных языках аналогичный трюк избавлению от алгТД называется "CPS-трансформация". AVK>Не знаю что ты там искал, но CPS-трансформация никакого отношения к диспетчеризации не имеет, это способ преобразовать прямой код в декларативное продолжение, которое потом можно сделать ленивым, асинхронным и т.п. АлгТД этим никак не заменяется.
У него просто идея фикс вместо парсер -> AST -> работа с АСТ совмещать парсер с работой в одной куче кода. Про то, что это не только говнокод, но еще и не всегда возможно он слушать не хочет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот все эти значения должны обрабатываться по единым правилам до тех пор, пока непосредственно не нужно будет что то читать в БД или загружать туда. А вот когда понадобится, то надо выполнить операцию формирования запроса уникальным для каждого типа значения способом.
А иерархия классов тут не более предпочтительное решение?
AVK>Так вот, АлгТД позволяют решать такие задачи практически идеальным способом, ничуть не выбиваясь из ООП (и в F# и в Немерле они все равно сводятся к обычным классам с дискриминантами). И я бы еще понял, если бы речь зашла о том, что, в принципе, задачи, решаемые ими, можно решить статически, без участия рантайм полиморфизма, но при чем тут инкапсуляция — мне вообще непонятно, так как АлгТД выставляют наружу вполне себе классический контракт из набора свойств и дискриминанта, никак не афишируя внутреннюю структуру хранения и реализации.
Вероятно, инкапсуляция при том, что дает возможность сделать псевдо-АТД. В том же Обероне вариант реализации: сделать запись, все поля данных скрыты, дискриминант открыт только на чтение, считать значение можно только с помощью соответствующих процедур, записать значение с соответствующим дискриминантом — тоже только процедурами. Таким образом, сделать некорректный АТД не выйдет. Хотя может быть имелось в виду что-то иное.
AVK>Тут такое дело — если ты не знаешь что это и для чего, то ты можешь просто не видеть те места, где они дают существенный выигрышь. К примеру, даже сейчас товарищи некоторые считают, что все нововведения C# 3 бесполезны и им некуда их применить.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AlexRK, Вы писали:
ARK>>Хм. В таком случае алгебраический тип не нужен — нужен просто один метод для "объекта как есть" и пара конвертеров из строки и из объекта.
AVK>Не понял. Напиши псевдокод.
class Consumer
{
public void Consume(Foo foo) { ... }
}
static class Utils
{
public static Foo StreamToFoo(Stream stream) { ... }
public static Foo StringToFoo(Stream stream) { ... }
}
Что-то в этом роде.
Хотя если надо наше значение везде "таскать" по коду (правда зачем?), а конвертить в последний момент — такой вариант не подойдет.
Здравствуйте, AlexRK, Вы писали:
ARK>>>Хм. В таком случае алгебраический тип не нужен — нужен просто один метод для "объекта как есть" и пара конвертеров из строки и из объекта. AVK>>Не понял. Напиши псевдокод.
ARK>
ARK> class Consumer
ARK> {
ARK> public void Consume(Foo foo) { ... }
ARK> }
ARK> static class Utils
ARK> {
ARK> public static Foo StreamToFoo(Stream stream) { ... }
ARK> public static Foo StringToFoo(Stream stream) { ... }
ARK> }
ARK>
ARK>Что-то в этом роде.
Это некорректный код и я мысли все равно не понял.
ARK>Хотя если надо наше значение везде "таскать" по коду (правда зачем?)
Затем, что они сперва обрабатываются по общим правилам. К примеру, исходный код иерархический, а интерпретатору скармливаются плоские данные, последовательный набор операций, в которых все иерархии свернуты определенным образом. И используются такие значения далеко не в одном месте.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AlexRK, Вы писали:
ARK>А иерархия классов тут не более предпочтительное решение?
А что с ней делать? Виртуальный метод — не вариант, потому что алгоритмов, использующих эти данные не один, и эти алгоритмы не требуют логической связи от AST к ним. Визитор? Или еще какой вариант?
ARK>Вероятно, инкапсуляция при том, что дает возможность сделать псевдо-АТД
Непонятно.
ARK>. В том же Обероне вариант реализации: сделать запись, все поля данных скрыты, дискриминант открыт только на чтение, считать значение можно только с помощью соответствующих процедур, записать значение с соответствующим дискриминантом — тоже только процедурами.
Это и есть АлгТД. Только без поддержки языка (не фатально) и без контроля гарантированного учета всех возможных вариантов, который обеспечивает ПМ или правильно реализованный визитор (а вот это уже фатально).
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Это некорректный код и я мысли все равно не понял.
Я ошибся, во втором статическом методе надо вместо "Stream stream" поставить "String str".
Мысль такая, что в этом "алгебраическом типе" три значения не являются полностью гетерогенными, а по сути — одним и тем же в разных представлениях. Плюс основная операция обработки одна. Поэтому я предложил превратить сразу потоки и строки в объект и дальше везде работать с ним.
ARK>>Хотя если надо наше значение везде "таскать" по коду (правда зачем?)
AVK>Затем, что они сперва обрабатываются по общим правилам. К примеру, исходный код иерархический, а интерпретатору скармливаются плоские данные, последовательный набор операций, в которых все иерархии свернуты определенным образом. И используются такие значения далеко не в одном месте.
Если значение "в трех ипостасях" будет использоваться не в одном месте, то в этих нескольких местах перед использованием будет преобразование из Stream или String в объект? Или каким образом этот АлгТД еще будет использоваться? Или я чего-то не понял.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AlexRK, Вы писали:
ARK>>А иерархия классов тут не более предпочтительное решение?
AVK>А что с ней делать? Виртуальный метод — не вариант, потому что алгоритмов, использующих эти данные не один, и эти алгоритмы не требуют логической связи от AST к ним. Визитор? Или еще какой вариант?
Я имел в виду именно виртуальный метод "операция формирования запроса". Если алгоритмов несколько — выносим их в общий интерфейс. Или по каким-то причинам обработка должна обязательно быть где-то извне?
ARK>>. В том же Обероне вариант реализации: сделать запись, все поля данных скрыты, дискриминант открыт только на чтение, считать значение можно только с помощью соответствующих процедур, записать значение с соответствующим дискриминантом — тоже только процедурами.
AVK>Это и есть АлгТД. Только без поддержки языка (не фатально) и без контроля гарантированного учета всех возможных вариантов, который обеспечивает ПМ или правильно реализованный визитор (а вот это уже фатально).
+1. Да, все верно. Для реализации этого всего необходима инкапсуляция. Такое вот у меня возникло (возможно очевидное и примитивное) предположение на вопрос "причем тут инкапсуляция".
Здравствуйте, WolfHound, Вы писали:
V>>>Поискал сейчас и увидел, что в функциональных языках аналогичный трюк избавлению от алгТД называется "CPS-трансформация". AVK>>Не знаю что ты там искал, но CPS-трансформация никакого отношения к диспетчеризации не имеет, это способ преобразовать прямой код в декларативное продолжение, которое потом можно сделать ленивым, асинхронным и т.п. АлгТД этим никак не заменяется. WH>У него просто идея фикс вместо парсер -> AST -> работа с АСТ совмещать парсер с работой в одной куче кода.
