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

no4>Я думаю, хаскель может. Только нет такого транслятора, который в SQL бы транслировал и синтаксис будет другой — не точечный.

Почему нет транслятора?

В HaskellDB

oaklands = do{ x <- table authors
             ; restrict (x!city .==. constant "Oakland")
             ; project (au_fname = x!au_fname
                        ,au_lname = x!au_lname)
             }

транслируется в

SELECT X.FirstName, X.LastName
FROM   Authors AS X
WHERE  X.City = 'OakLand'

пример отсюда

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

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

no4>>Я думаю, хаскель может. Только нет такого транслятора, который в SQL бы транслировал и синтаксис будет другой — не точечный.

D>Почему нет транслятора?

Мне не нравится, что этот код знает, откуда он выбирает данные. Мне хотелось бы, чтобы код использовал стандартные способы работы с коллекциями и list comprehensions.

Еще, мне кажется, что, если я определю функцию sqr x = x * x то она не будет транслирована в SQL и ее придется поднимать в монаду по частям.

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

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

NGG>>В таком случае обычные orm инструменты (н-р, хибернейт) ничем не хуже и даже лучше, так как позволяют провести перед компиляцией инспекцию кода на предмет корректности имён.

BZ>я полагаю, что они делают то же самое, только средствами внешними по отношению к языку?

В общем да. Инспектор это "отдельная программа" для анализа исходников.


Ниже привели в пример haskelldb. Выглядит любопытно, но решает часть "задачи". Он позволяет сделать sql запросы типизированными, но не видно как можно управлять маппингом данных на таблицы базы данных. Я имею ввиду проблему нестыковки ООП и баз данных. Поскольку элементы оо присутствуют в хаскелл, там тоже должна возникать эта проблема при попытке сохранять сложные иерархии в базу... Или не изменяемое состояние объектов приводит к тому, что она не возникает?

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


no4>Мне не нравится, что этот код знает, откуда он выбирает данные. Мне хотелось бы, чтобы код использовал стандартные способы работы с коллекциями и list comprehensions.

no4>Еще, мне кажется, что, если я определю функцию sqr x = x * x то она не будет транслирована в SQL и ее придется поднимать в монаду по частям.

liftM sqr?

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

no4>Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.

Ты хочешь декларативно описать вычисления над структурой коллекции, в которой currentSalary это что? Просто задача не очень ясна...

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

D>liftM sqr?

А так получится? Оно потом транслируется?

D>Бесшовно не получится, поскольку одновременно скрещиваются разные типы вычислений.

Вот. А собственно хочется именно этого.

no4>>Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.

D>Ты хочешь декларативно описать вычисления над структурой коллекции, в которой currentSalary это что? Просто задача не очень ясна...

currentSalary это функция, которая возвращает текущую зарплату сотрудника по этой структуре. Как она это делает, это ее дело. Допустим в версии 1 она возвращала поле структуры, в версии 2 она возвращает последнее значение из истории изменения зарплаты.

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

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

NGG>>>В таком случае обычные orm инструменты (н-р, хибернейт) ничем не хуже и даже лучше, так как позволяют провести перед компиляцией инспекцию кода на предмет корректности имён.

BZ>>я полагаю, что они делают то же самое, только средствами внешними по отношению к языку?

NGG>В общем да. Инспектор это "отдельная программа" для анализа исходников.


NGG>Ниже привели в пример haskelldb. Выглядит любопытно, но решает часть "задачи". Он позволяет сделать sql запросы типизированными, но не видно как можно управлять маппингом данных на таблицы базы данных. Я имею ввиду проблему нестыковки ООП и баз данных. Поскольку элементы оо присутствуют в хаскелл, там тоже должна возникать эта проблема при попытке сохранять сложные иерархии в базу... Или не изменяемое состояние объектов приводит к тому, что она не возникает?

Никакого специального волшебства. Есть DBDirect, который подключается к БД и генерит модули (на Хаскеле) с описанием метаданных. Поставленная тобой проблема не решается инспекцией при компиляции: если структура БД может меняться, то она, знаешь ли, может меняться после компиляции программы с тем же успехом, что и до.

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

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

D>>liftM sqr?

no4>А так получится? Оно потом транслируется?

Я с HaskellDB играл довольно давно, и уже не помню, как там упакованы выражения. Но принципиальных проблем не вижу — в монадическое вычисление можно через liftM поднять любую обычную функцию. Сборка SQL происходит в рантайме, по ходу дела в момент, когда значение sqr потребуется, оно и вычислится.

D>>Бесшовно не получится, поскольку одновременно скрещиваются разные типы вычислений.

no4>Вот. А собственно хочется именно этого.

no4>>>Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.

D>>Ты хочешь декларативно описать вычисления над структурой коллекции, в которой currentSalary это что? Просто задача не очень ясна...

no4>currentSalary это функция, которая возвращает текущую зарплату сотрудника по этой структуре. Как она это делает, это ее дело. Допустим в версии 1 она возвращала поле структуры, в версии 2 она возвращает последнее значение из истории изменения зарплаты.

Так это же совершенно неважно! В Хаскелле главное, чтобы тип был тот же. Если тип

currentSalary::Employee -> Float

то пихай её в любое место, где ожидается Employee -> Float.

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

NGG>Дабы не теоризировать на пустом месте, попробую написать на хаскел игру реверси и сравнить ощущения.

вот из сегодняшнего cafe:

For example, yesterday I rewrote and extended a program that I wanted to develop in Haskell in just 3 hours using dotnet, while I spend weeks trying do this in Haskell. Of course, I'm a Haskell newbie and a dotnet expert, so this is not a fair comparison. However, I got a strange feeling, which I want to share with you First of all, it was a *horrible* experience to program C# again; I needed to type at least 3 times the amount of code, much of which was boilerplate code, and the code is not elegant. Haskell really changed my point of view on this; before I knew Haskell, I found C# (I'm talking C# 3.0 here) a really neat and nice language. On the other hand, the great Visual Studio IDE and Resharper addin made it at least 3 times faster to type, navigate, refactor, and debug the code... Somehow, I get things done really really really fast in C#, albeit in an "ugly" way. Once again, I just wish Haskell had such an IDE... And yes, I know of the existance of Visual Haskell, EclipseFP, Haskell Mode for Emacs (which I'm using), VIM, YI, but still, these do not compare with the experience I have when using Visual Studio/Resharper (or Eclipse or IntelliJ/IDEA for Java). But that might just be me of course...

A slightly frustrated Peter

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

D>Так это же совершенно неважно! В Хаскелле главное, чтобы тип был тот же. Если тип

D>currentSalary::Employee -> Float

D>то пихай её в любое место, где ожидается Employee -> Float.

Ну то есть Float она, конечно, не вернёт, IO Float — может.

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

no4>>>Я думаю, хаскель может. Только нет такого транслятора, который в SQL бы транслировал и синтаксис будет другой — не точечный.

D>>Почему нет транслятора?

no4>Мне не нравится, что этот код знает, откуда он выбирает данные. Мне хотелось бы, чтобы код использовал стандартные способы работы с коллекциями и list comprehensions.

наверно, не list comprehension, а monad comprehension. ибо первый по определению может работать только с готовыми списками, возвращёнными из БД, а тебе нужна генерация sql-запроса в соответствии с заданными критериями

no4>Еще, мне кажется, что, если я определю функцию sqr x = x * x то она не будет транслирована в SQL и ее придется поднимать в монаду по частям.

как-то в cafe публиковали пример, где определялась структура для символьных вычислений, и давалось определение (*) и прочего, работающее с этой структурой. после чего ты мог писать что-ниьбудь типа 2*3+4 и в зависимости от типа результата он возвразался в числовом или сивольном виде

можно попытаьься определить '*' и прочие элементарные функции так, чтобы их испольщования транслировались в sql-код

no4>Т.е. проблема не в том. чтобы сделать внутренний DSL специально для работы с SQL, а в том, чтобы использовать существующий язык унифицированно для работы с абстракцией коллекции и т.д.

поскольку это всё же совершенно разные языки, само по себе это не заработает — надо делать. и тут вопрос скорее в том, какие хаскел предоставляет средства для создания DSEL. средства эти имхо мощнее чем в С* языках: монады, lazy evaluation, type inference

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

NGG>Ниже привели в пример haskelldb. Выглядит любопытно, но решает часть "задачи". Он позволяет сделать sql запросы типизированными, но не видно как можно управлять маппингом данных на таблицы базы данных.

думаю, для описания маппинга нужно делать отдельные декларации

>Я имею ввиду проблему нестыковки ООП и баз данных. Поскольку элементы оо присутствуют в хаскелл, там тоже должна возникать эта проблема при попытке сохранять сложные иерархии в базу... Или не изменяемое состояние объектов приводит к тому, что она не возникает?

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

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

no4>Вот еще если бы всякий синтаксический сахар типа list comprehensions был бы привязан не к конкретной реализации списков а к некоей абстракции...

Отличная мысль . Именно такая мысль пришла несколько лет назад эрлангистам. Они это назвали qlc — query list comprehensions. Это есть в составе стандартной либы Эрланга. Легко прикручивается к абсолютно любому источнику данных — надо реализовать один простой абстрактный интерфейс.

Ну и конечно — база данных Эрланга (mnesia), разумеется, поддерживает qlc.

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

no4>>Вот еще если бы всякий синтаксический сахар типа list comprehensions был бы привязан не к конкретной реализации списков а к некоей абстракции...

G>Отличная мысль . Именно такая мысль пришла несколько лет назад эрлангистам.

+ http://rsdn.ru/Forum/message/2341360.1.aspx

Автор: BulatZiganshin
Дата: 08.02.07

T>Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива?

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

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

BZ>во-первых, в хаскеле нет элементов ОО. во-вторых, иерархии объектов (не классов) — обычное дело для любых языков с динамическим распределением памяти, начиная с паскаля, но они легко ложатся на связь таюблиц ключеыыми полями. так что я просто не в курсе — какие проблемы вы имеете в виду?

Допустим, у нас есть такая "модель" предметной области:

Course ->* Assignment ->* Question <-* Answer *-> User
*-> Instructor
*->* Student

User = Instructor | Student

Сразу встаёт вопрос: как будем хранить в базе Instructor'ов и Student'ов?
Можно создать общую таблицу, можно создать по отдельной, можно общие поля хранить в общей таблице, а различные в разных.

Отношение Course *->*Student тоже не радует. Для его представления придётся создать доп. таблицу, т.к. одними только fkeys тут не обойтись.

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

Как они связаны с теми типами данных, что были использованны на входе? Отдалённо, т.к. полученные типы зависимы от выбора проектировщика бд. Их использование приведёт к связыванию логики предметной области (бизнес логики) со способом хранения данных и к усложнению кода (засчёт снижения абстракции).
Опять же, чтобы не обращаться за каждым объектом в базу, придётся писать кеши, заботиться о транзакциях, а всё это опять превращается в код, который нужно поддерживать и который, в сущности, одинаков для всех приложений работающих с базами данных. В ОО мире этот код выносится в ORM библиотеки и позволяет писать бизнес логику оперирующую с объектами определёнными в пердметной области, а не с полями всяко-разных таблиц.

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

BZ>довольно типичное, я бы сказал, мнение

Угу, я чувствую примерно тоже самое

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



T>>Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива?

S>а последний?
S>задача была отсортировать, поэтому не стоит из неё пытаться выдумать другие задачи, которые лягут под своё решение.

нет, речь здесь идёт о том, что lazy алгоритмы более реюзабельны, чем строгие — в данном случае нет нужды писать отдельную процедуру поиска миним. элемента, она реализуется просто как head.sort

T>>В случае Хаскеля O(n).
Т>Не всегда. Иногда и O(n^2).

Заменим на сортировку слиянием, будет O(n).

T>>Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива?
S>а последний?

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

S>задача была отсортировать, поэтому не стоит из неё пытаться выдумать другие задачи, которые лягут под своё решение.

А что выдумывать-то?

Я это уже неоднократно использовал.

Такие, вот, дела.

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

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

no4>>>Вот еще если бы всякий синтаксический сахар типа list comprehensions был бы привязан не к конкретной реализации списков а к некоей абстракции...

G>>Отличная мысль . Именно такая мысль пришла несколько лет назад эрлангистам.

BZ>+ http://rsdn.ru/Forum/message/2341360.1.aspx

Автор: BulatZiganshin
Дата: 08.02.07

Отличный пост. Слушай, мне вот что подумалось. В С++ можно перекрывать оператор "запятая" . Можно там, пользуясь этим, изобразить злые монады?