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

L>Хороший гибрид — мёртвый гибрид.

Ну, ну. Ваша вера действительно крепка. А вось она и сдвинет горы.

L>OOHaskell, O'Haskell, куча разных имплементаций OO в Haskell — где они все? Вывод напрашивается: OO в Haskell не нужен

Ну, или Haskell не нужен. Всегда ведь есть альтернативные решения.

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

цель языков вообще какая? повысить эффективность разработки, исполнения и т.д.

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

т.е. инкапсуляция может делаться только в обмен на гарантии: на гарантии надежности, безбажности, эффективности и т.д.

но во многих случаях — эти гарантии не соблюдаются, и не обеспечиваются.
и тогда для достижения максимальной эффективности — необходимо понять где кроятся причины неэффективности, как это можно исправить, и есть ли для этого возможности (доступ)\
для решения этой задачи — и необходимо понимать: как язык устроен, какие в нем уровни, какие есть исполнители, какую задачу они решают на отлично, какие — не очень.

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

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

Вот код изменяющий цену конкретного товара:

         | SetProductPrice(name, price) ->
             let productMap' = Map.add name { Key = name; Price = price } productMap

Объясни какой компилятор мне запретит вместо этого написать так:

         | SetProductPrice(name, price) ->
             let productMap' = Map.Empty

и испортить все товары?

При использовании мутабельных объектов эта функция выглядела бы так:

SetProductPrice(Product product, int price)
{
  product.Price = price;
}

и все продукты не могла бы испортить физически.

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

U>>Т.е. в общем случае функция передвигающая песчинку должна обладать правами на пересоздание, а соответственно и на произвольное изменение/уничтожение вселенной. Как это сочетается с требованиями надежности и безопасности совершенно не понятно.
S>Любая функция может создавать любые данные, но подменить что-либо не в состоянии, если это не предусмотрено дизайном.
S>Так где проблемы с безопасностью?

http://rsdn.ru/forum/philosophy/4060401.1.aspx

Автор: Undying
Дата: 01.12.10

K>В общем случае прямой доступ не может поддерживать более полный комплект операций. Будут некоторые операции, которые недоступны при опосредованном доступе, а некоторых операций, доступных из опосредованного не будет в прямом.
K> Иначе языки прогрммирования не имели бы смысла.

вот тут мне кажется кроется корень твоего не понимания.

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

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

и надо четко различать — речь идет о языке, или об исполнителях встроенных в язык.
например, вывод типов в языке — это встроенный исполнитель, но не сам язык. валидация типов — это тоже исполнитель, но не сам язык.

спросишь — зачем такие сложности, и зачем так делить?

ответ все тотже — достижение максимальной эффективности.
например, исполнитель вывода типов — очень часто ведет себя неэффективно, и при этом нет хорошего способа им поуправлять.
например, в сложной системе типов — бывает несколько путей преобразований из типа A в тип B.
при этом обычно нет хороших способов зафиксировать какой путь преобразования лучше выбирать — и это уже одна из проблем которая сажает эффективность разработки.

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

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

S>Начал на C# и припух. Тяжеловат он для чистого FP. Потому написал на F#. Если что непонятно — предлагаю скомпилировать и воспользоваться рефлектором с таргетингом в C#.

Как будет выглядеть код при увеличении числа уровней иерархии?

         | SetProductPrice(name, price) ->
             let productMap' = Map.add name { Key = name; Price = price } productMap

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

Я правильно понимаю, что в этом случае код станет примерно таким?

         | SetProductPrice(name, price) ->
             let productMap' = Map.add name { Key = name; Price = price } shop.productMap
             let shop' = { shop with ProductMap = productMap' }

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

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

U>Объясни какой компилятор мне запретит вместо этого написать так:

U>

U>         | SetProductPrice(name, price) ->
U>             let productMap' = Map.Empty
U>

U>и испортить все товары?

U>При использовании мутабельных объектов эта функция выглядела бы так:

U>

U>SetProductPrice(Product product, int price)
U>{
U>  product.Price = price;
U>}
U>

U>и все продукты не могла бы испортить физически.

Ты тут немного перемешал уровни ответственности. Код, обновляющий карту продуктов — это код верхнего уровня. Запрещать ему что-то делать самому себе нет резона.
Это как если бы код, достающий из коллекции определенный продукт для передачи SetProductPrice испортил бы коллекцию продуктов не обращаясь к SetProductPrice.

т.е. это проблема уровня "кто мне запретит написать в MAIN Kill(myself);".

А аналог SetProductPrice выглядел бы так:

Product UpdateProduct(Product product, int newPrice)
{
     return new Product(product.Name, price);
}

Соответственно этот код доступа к миру не имеет и изменить его не может никак.

U>

U>         | SetProductPrice(name, price) ->
U>             let productMap' = Map.Empty
U>

U>и испортить все товары?

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

ps

SetProductPrice(Product product, int price)
{
  product.Price = price;
}

и на хера такой костыль? т.е. зачем ты хочешь это записать именно в виде отдельного метода?

ты вроде хотел записать:
хочу разрешить васе пупкину доступ на изменение поля price в продуктовой корзине
или может вообще хотел записать
хочу разрешить всем пользователям с ролью пользователь_уровня_1 доступ на изменение поля price в продуктовой корзине

так если ты это хотел записать, так это и запиши:

world access role user_level_1 readonly
  productMap access role user_level_1 readonly
    products access role user_level_1 readonly
       price access role user_level_1 readwrite

так ты хотел чтобы это проверялось на уровне компиляции? и твой компилятор такую запись не понимает и не умеет такое делать?

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

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

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

U>Как будет выглядеть код при увеличении числа уровней иерархии?

U>Например, список товаров является частью иммутабельного объекта магазин.

U>Я правильно понимаю, что в этом случае код станет примерно таким?

U>

U>         | SetProductPrice(name, price) ->
U>             let productMap' = Map.add name { Key = name; Price = price } shop.productMap
U>             let shop' = { shop with ProductMap = productMap' }
U>

да

U>И чем больше будет уровней иерархии тем больше строчек кода придется писать для того, чтобы изменить значение нижнего уровня?
верно.
Но это гораздо меньше, чем придется написать строчек кода, что бы обезопаситься от такого:
shop.Products["foo].Price = int.MinValue;

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

L>>Обсуждали уже. Классы типов — всего лишь сахар для естественного в мире ФП приёма. Так что это не аналог. Это просто сахар для своего чисто ФП-шного приёма абстракции. Который с успехом можно применять в любом ФЯ.
VD>Я не знаю кто и где это обсуждал, но точно знаю, что классы типов есть только в одном языке. Так что обсуждать тут нечего.

http://www.rsdn.ru/forum/decl/4035631.1.aspx

Автор: lomeo
Дата: 12.11.10

Это ответ на твоё сообщение, также ниже по треду ты отметился тоже. Так что пропустить это сообщение ты не мог.

Ещё раз — классы типов может и есть только в одном языке, но сахарят они стандартный dictionary-passing style. Твоё желание свести абстракцию к миру ОО вполне понятно, вот только идёт оно в разрез с реальностью.

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

L>>OOHaskell, O'Haskell, куча разных имплементаций OO в Haskell — где они все? Вывод напрашивается: OO в Haskell не нужен
VD>Ну, или Haskell не нужен. Всегда ведь есть альтернативные решения.

Смотри — Haskell есть и используется. OO в Haskell есть и не используется. Разницу чувствуешь?

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

DG>в данном коде ты еще ничего не испортил.
DG>ты создал свою локальную переменную productmap', которая никакого отношения к исходной корзине не имеет

Значит, я плохо понял как на F# происходит перезапись ссылки на объект, и надо эту строчку записать иначе. Смысл моего утверждения от этого не поменяется.

DG>так если ты это хотел записать, так это и запиши:
DG>

DG>world access role user_level_1 readonly
DG>  productMap access role user_level_1 readonly
DG>    products access role user_level_1 readonly
DG>       price access role user_level_1 readwrite
DG>

DG>так ты хотел чтобы это проверялось на уровне компиляции? и твой компилятор такую запись не понимает и не умеет такое делать?

И что с этой хренью делать на практике?

Вот я читаю код, допустим меня интересует количество элементов в ProductList. Далее я вижу в коде строчку:

ModifyProduct(product);

Код этой функции я могу не смотреть, т.к. компилятор гарантирует, что эта функция ни при каких обстоятельствах не может изменить количество элементов в ProductList. Если же обновление продукта делать так как это делает samius, то смотреть надо каждую функцию, т.к. любая функция может поменять все что угодно.

И что тут дадут твои user_level? Позволят наплодить в коде лишних сущностей, чтобы потом в коде точно никто не разобрался?

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

S>Ты тут немного перемешал уровни ответственности. Код, обновляющий карту продуктов — это код верхнего уровня. Запрещать ему что-то делать самому себе нет резона.

Т.е. передвижение любой песчинки во вселенной становится кодом верхнего уровня. Соответственно ошибка при передвижении любой песчинки может уничтожить вселенную.

S>А аналог SetProductPrice выглядел бы так:
S>

S>Product UpdateProduct(Product product, int newPrice)
S>{
S>     return new Product(product.Name, price);
S>}
S>

S>Соответственно этот код доступа к миру не имеет и изменить его не может никак.

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

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

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

S>>Ты тут немного перемешал уровни ответственности. Код, обновляющий карту продуктов — это код верхнего уровня. Запрещать ему что-то делать самому себе нет резона.

U>Т.е. передвижение любой песчинки во вселенной становится кодом верхнего уровня. Соответственно ошибка при передвижении любой песчинки может уничтожить вселенную.

Это не обязательно так. Если вселенная доверяет коду изменить песчинку, она возьмет новую песчинку у кода. Если вселенная доверяет изменить набор цен — она отдаст набор цен тому коду и заберет у него новый набор цен.
Тут очень просто контроллировать то, что ты доверяешь коду с помощью сигнатуры метода.

S>>А аналог SetProductPrice выглядел бы так:
S>>

S>>Product UpdateProduct(Product product, int newPrice)
S>>{
S>>     return new Product(product.Name, price);
S>>}
S>>

U>Дальше ты этот код где будешь вызывать? Вот у тебя пользователь нажал на кнопку, пользователь работает с конкретной песчинкой, но тебе все равно придется заменять вселенную новым объектом, т.е. благодаря иммутабельности действие пользователя работающего с песчинкой вызывает код, который может уничтожить вселенную.

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

U>И чем больше будет уровней иерархии тем больше строчек кода придется писать для того, чтобы изменить значение нижнего уровня?

имхо, опять все мешается в кучу. уровень описания, исполнения, синтаксис и ограничения текущих трансляторов, привычки программистов и т.д.

в данном случае тут можно выделить три разные задачи:
1. описание того, что внешняя сторона хотела изменить
2. описание того, чему равно корректное состояние системы после изменения
3. описание того, что необходимо сделать, что перевести систему из состояния до данного конкретного изменения к корректному состоянию после изменения.

первую задачу удобнее (максимально емко) записывать тем же способом, которым она сейчас записывается в объектных императивных языках, в виде цепочки идентификаторов слева и нового значения справа:

world.productMap.product(подгузники).price = 145р;

вторую задачу удобнее (максимально емко) записывать через построение мира с нуля, как это принято в ФЯ

newworld:world merge(this oldworld:world, world-delta:world-delta)
{
   newworld = new world{product-map = oldworld.product-map.merge(world-delta.product-map);
}
..
newproductmap:product-map merge(this oldproductmap:product-map, productmap-delta: productmap-delta)
{
   newproductmap = new productmap
   {
    products = products.merge(productmap-delta.products),
    totalprice = products.select(product=>product.price).sum()
   };
}

newproduct:product merge(this oldproduct:product, product-delta: product-delta)
{
   newproduct = new product{name = oldproduct.name, price = product-delta.price};
}

третью задачу удобно (максимально емко) записывать так же как первую (формирование такого сообщения делается автоматически)

world.productMap.product(подгузники).price = 145р;  
world.productMap.totalprice = (75$, 307р);

такое сообщение может посылаться системой терминалу вывода (например, от server-а в браузер, если расчет корзины делается на сервере)

U>Код этой функции я могу не смотреть, т.к. компилятор гарантирует, что эта функция ни при каких обстоятельствах не может изменить количество элементов в ProductList. Если же обновление продукта делать так как это делает samius, то смотреть надо каждую функцию, т.к. любая функция может поменять все что угодно.

U>И что тут дадут твои user_level? Позволят наплодить в коде лишних сущностей, чтобы потом в коде точно никто не разобрался?


Ты до сих пор пользуешься notepad-ом который не умеет сформировать обзор кода под тот вопрос, который ты задал?
значит в топку — notepad.
возьми IDE — которая тебе сможет представить такое представление кода, из которого тебе будет наглядно понятно, к чему у тебя доступ есть, а к чему нет.

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

U>И что тут дадут твои user_level?

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

сейчас ты такое зафиксировать не можешь, хотя именно это текущие задачи и требуют.

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

DG>как минимум гибкость и возможность прямо в коде зафиксировать, что например есть уровень доступа администратора, есть уровень доступа продвинутого пользователя, есть уровень простого пользователя, есть уровень гостя.

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

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

DG>можно пример когда прямой доступ поддерживает меньше операций, чем опосредованный?

Например, когда непосредственный доступ нарушает гарантии, которые сразу делают неработающими челый класс операций на "опосредованном" уровне.

DG>и что это за человек такой, который менее мощный чем посредник(язык описания)?

Человек в данном случае владеет мощностью языка описания, как оператор экскаватора владеет мощностью экскаватора. Ну или как оператор лопаты владеет мощностью лопаты.

DG>во-первых: что является результатом обхода?

Ленивый список правильных ответов. Решатель находит первй правильный ответ, если требуем следующий — ищет дальше. Ну или не находит.

DG>во-вторых: обход узлов гарантированно делается наиэффективнейшим образом, который ни для какого случая нельзя улучшить?

Не гарантировано. точно так же как и компилятор любого языка не компилирует код на этом языке в гарантированно наиэффективнейший машинный код.

K>>Программист может указать в какие ветви заходить в первую очередь, в какие во вторую и т.д.
DG>если в разных случаях — это по разному, то как это указывается?

Решатель обходит дерево в том порядке, в каком оно описано в коде. Слева направо, сверху вниз. Декларативный смысл програмы на Прологе от перестановки не меняется, а вот эффективность и завершимость программы — еще как.

DG>в-третьих: в математике есть такое утверждение, что для многих задач проверка правильности решения делается намного эффективнее, чем поиск самого решения.
DG>это позволяет использовать стратегию, что если при предыдущем запуске мы уже обход сделали и зафиксировали для ряда узлов правильный ответ, то при следующем запуске лучше начинать с проверки правильности предыдущего решения, и только при его неверности делать полный обход.
DG>как эту стратегию реализовать единожды на прологе?

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

K>>Примеры языков без такого доступа. Потому, что это фантастика. Ну вот представьте, что вы реализуете экспериментальный язык. Компилируемый. Вам для него нужна стандартная библиотека. В которой будет ввод/вывод. Для этого вам нужно как то взаимодействовать с ОС.

DG>доступ к внешнему окружению != доступ к исполнителю самого языка.

Но это не касается языка в общем случае. Можно ведь организовать доступ к исполнителю через api.

DG>в .net-е много чего есть, но нет доступа к уровню JIT-трансляции.

Но .net — это не язык. Берете бэкенд в LLVM и делаете что хотите.

DG>цель языков вообще какая? повысить эффективность разработки, исполнения и т.д.

Да.

DG>разработчик языка скрывая возможность доступа к исполнителю или к транслятору — берет на себя обязательство, что при этом и исполнитель, и транслятор — все делают самым эффективным образом.

Никто на себя таких обязательств и не берет. это невыполнимые обязательства.

DG>т.е. инкапсуляция может делаться только в обмен на гарантии: на гарантии надежности, безбажности, эффективности и т.д.

Не обязательно.

DG>но во многих случаях — эти гарантии не соблюдаются, и не обеспечиваются.

Вот именно.

DG>и тогда для достижения максимальной эффективности — необходимо понять где кроятся причины неэффективности, как это можно исправить, и есть ли для этого возможности (доступ)\
DG>для решения этой задачи — и необходимо понимать: как язык устроен, какие в нем уровни, какие есть исполнители, какую задачу они решают на отлично, какие — не очень.

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

DG>язык сам по себе не может добавлять операций.

Может.

DG>их либо умеет делать — управляющий (человек), либо управляемый (исполнитель).

Уметь мало. Нужно еще и делать. Какой смысл уметь выкопать канал одной лопатой, если на практике этого не сделать?

DG>язык — это в первую очередь описание(фиксация) того, что хочет управляющий от управляемого.
DG>и соответственно цель(критерий оптимальности) языка — это максимально емко и точно передать желание от управляющего к управляемому.

"Емкость" и "точность" — противоречивые требования, если под точностью понимается детальность.

DG>и надо четко различать — речь идет о языке, или об исполнителях встроенных в язык.
DG>например, вывод типов в языке — это встроенный исполнитель, но не сам язык. валидация типов — это тоже исполнитель, но не сам язык.

DG>спросишь — зачем такие сложности, и зачем так делить?

DG>например, исполнитель вывода типов — очень часто ведет себя неэффективно, и при этом нет хорошего способа им поуправлять.
DG>например, в сложной системе типов — бывает несколько путей преобразований из типа A в тип B.
DG>при этом обычно нет хороших способов зафиксировать какой путь преобразования лучше выбирать — и это уже одна из проблем которая сажает эффективность разработки.

Не понял, какое значение тут имеет какой-то путь преобразования? И о какой эффективности идет речь? Времени компиляции?

Кстати сказать, в языках с выводом типов бывают средства управления выводом типов. От опциональных аннотаций типов и до Хаскелевских деректив вроде NoMonomorphismRestriction или IncoherentInstances.

DG>что самое интересное.. исполнитель вывода типов очень похож на исполнителя из пролога.

Да, сходство есть. Те же многопараметрические тайпклассы с фундепами в Хаскеле — это что-то напоминающее эдакий тайплевел-Пролог.

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

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

U>Сейчас я руководствуюсь простым принципом, если функция модифицирует песчинку, то только песчинку она на вход и получает. И этот простой принцип позволяет добиться высокой надежности,

и этот простой принцип помогает решать только простые задачи (задачи с очень малым кол-вом вариантов)

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

и вот уже твоя маленькая песчинка для ответа на вопрос "сколько стоит?" должна получать на вход весь мир.

и соответственно, ты себя обманываешь — когда считаешь, что ты понимаешь сложность задач которые [b]хочется и требуется{/b] решать.
и это не идет ни в какое сравнение с той сложностью задач: которые ты уже решаешь и которую помогают решать твои текущие подходы и текущий язык.

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

L>Смотри — Haskell есть и используется. OO в Haskell есть и не используется. Разницу чувствуешь?

Я чувствую разницу когда вижу как используется ООЯ и как хаскель. Применение Хаскеля на фоне ООЯ не видно в микроскоп. И вижу что нет никаких проблем в совместном использовании ООП и ФП. Они прекрасно друг-друга дополняют. Абстракции верхноего уровня — ООП, реализация — ФП + где надо ИП. Результат получается отличнийший. И не нужны промывания мозгов, вера, объяснения, заумности... Абстракции в ООП проработаны отлично. Методология проектирования отточена и хорошо описана во многих источниках. Тоже самое об ФП сказать нельзя. Да и по твоим же словам ФП заканчивается хаскелем. Что не может не настораживать.