Записи, макросы, скала, вывод типов, SQL

[metaclass]

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

Идея в следующем: у меня в Clojure большая часть DSL основана на том, что я могу в любое место описания строк-колонок-ячеек отчета (условно говоря, Excel-like таблица фиксированной формы, заполняемая автоматом из проводок) в любой момент добавить атрибут типа :skip-in-vat true и обработать его. При этом мне нужно это изменить ровно в двух местах - описание документа ("данные") и расчетный алгоритм ("код"). Типов тут нет, а вместо них - структуры данных, скомбинированные из словарей, массивов и атомарных данных.

Но с динамически типизированными языками, а особенно с Clojure с ее destructring и прагматичным подходам к совместимости типов имеется постоянно проблема вида "сунул лишние скобки, на место числа попал массив и через 100500 вызовов когда дело дошло до суммирования, оператор + сдох от попытки просуммировать ссылку на массив со стек-трейсом на три страницы". Причем если мне такие ошибки чинить достаточно легко, то менее опытным коллегам это вырывает мозг.

В F# и прочих типизированных языках же мне придется сначала ползти в описание записи (если там записи вообще есть), добавлять поле или хуже того - еще один вариант для алгебраического типа, править вызовы конструкторов (если оверлоадинга нет) и прочая и прочая.

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

Языки же кроме F#, Scala и Clojure можно не рассматривать вообще - на них аналогичные задачи или сводятся к "наняли 100 ртишников по одному на объект предметной области и написали вручную" или к "написали самодельный лисп с хаскелем на дельфи/C#" или к "используем безумные ORM с еще более дикими, чем SQL языками и внешними декларативными описаниями".
Т.е. я не говорю, что они не пригодны - но затраты ресусов на решение задачи на таких языках заметно больше.

Comments

[qehgt.livejournal.com]

>В F# и прочих типизированных языках же мне придется сначала ползти в описание записи
Ну, не всё так плохо. В последнем F# есть Type Providers - они решают именно эту задачу: например, из SQL базы построить строго типизированные F#-классы.

[theiced.livejournal.com]

я вижу только одну проблему: "то менее опытным коллегам это вырывает мозг" - заменить этих коллег на нормальных.

[theiced.livejournal.com]

ололо

[v-l-a-d.livejournal.com]

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

[voidex.livejournal.com]

Заменить на нормальных, конечно, лучше, но дольше и сложнее.

[tzirechnoy.livejournal.com]

Написать на clojure статический анализатор кода. Вроде lintа. Но с хинтами по поводу возвращаемых запросами типов.

Или сделать полноразмерные unit- и functionality- тэсты и прочее CI.

Можно и то и другое.

[metaclass.livejournal.com]

Второе есть. Склоняюсь прикрутить первое, для ускорения поиска ошибок заранее.

[gds.livejournal.com]

> Языки же кроме F#, Scala и Clojure можно не рассматривать вообще

можно рассматривать окамл, где данная проблема решается "расширяемыми записями", всё типизировано.

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

в окамле это -- синтаксическое расширение, генерирующее тип по схеме и запросу. Для некоторых вещей есть http://pgocaml.forge.ocamlcore.org/ и http://www.strauss-acoustics.ch/macaque-pgocaml.html .

[theiced.livejournal.com]

окамл негуманен

[veremeenko-alex.livejournal.com]

и рыбку съесть и ...

[metaclass.livejournal.com]

Оно самое.

[vshabanov.livejournal.com]

Лучше всего это сделано в Ur/Web. Там пишешь SQL запрос, или рисуешь какую-нибудь HTML формочку и он сам определяет, какие будут поля в результате. Там правда есть проблема с километровыми сообщениями об ошибках, когда он выводит всю запись (но это по идее решаемо, если выводить только разницу).

Еще есть ocaml. Там можно создавать объекты по месту (без описания класса) и он сам определит, какой у них тип.

В том же Хаскеле можно работать с записями не так:

r = MyRecord { mrField1 = 1, mrField2 = "asdf" }
case r of
    MyRecord { mrField1 = f1, mrField2 = f2 } ->
    -- или MyRecord f1 f2

а так

instance Default MyRecord where 
    def = MyRecord { mrField1 = 0, mrField2 = "" }
r = def { mrField1 = 1, mrField2 = "asdf" }
case r of
    MyRecord {..} -> mrField1 + 2
-- или просто mrField1 r + 2

Тогда не надо будет править конструкторы.

Ну и в принципе, можно создавать такие же словари в типизированных языках.

[jdevelop.livejournal.com]

беда записей в цацкеле - это неудобство их использования

[jakobz.livejournal.com]

Блин, хотел камент отредактировать, а стер его вместо этого. Короче мне вот хочется чего-то типа TypeScript, но чтобы работало в гораздо большем количестве случаев.

function makeObject() {
	return {
		a : 1,
		b : 2
	}
}

function alterObject(obj) {
	obj.c = 3
	return obj
}

var o = makeObject()
console.log(o.c) //The property 'c' does not exist on value of type '{ a: number; b: number; }'
var o2 = alterObject(o)
console.log(o2.c) // Тут всё ок
console.log(o.c)  // The property 'c' does not exist on value of type '{ a: number; b: number; }' -- а такое не осиливает

http://www.typescriptlang.org/Playground/

[avnik.livejournal.com]

В питоне (точнее Zope) можно приводить один тип к другому (точнее к интерфейсу в рамках zope.interface),или кинь исключение/верни дефолт если не получилось (+можно приводить много значений к одному) -- но это не свойство языка, это библиотечный костыль

[plumqqz.livejournal.com]

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

[metaclass.livejournal.com]

Ну да, я пытаюсь сколхозить зависимые типы малой кровью.
И чтобы оно все из базы данных приходило без издевательств над здравым смыслом вида "а теперь мы схему базы данных пишем не на SQL а на руби".
Пока единственный вариант - либо генерить код, либо динамическая типизация.

[osdm.livejournal.com]

В TypeScript такое есть - строгая типизация + вывод типов.

[vit-r.livejournal.com]

Но с динамически типизированными языками, а особенно с Clojure с ее destructring и прагматичным подходам к совместимости типов имеется постоянно проблема вида "сунул лишние скобки, на место числа попал массив и через 100500 вызовов когда дело дошло до суммирования, оператор + сдох от попытки просуммировать ссылку на массив со стек-трейсом на три страницы". Причем если мне такие ошибки чинить достаточно легко, то менее опытным коллегам это вырывает мозг.

Это говорит только о том, что не поставленны внутренние проверки, которые должны отловить абнормальную ситуацию сразу. Причём, расставить такие проверки в нужных местах могут даже "менее опытные коллеги"

[metaclass.livejournal.com]

Да, надо приучить себя инварианты проверять сразу.

[veremeenko-alex.livejournal.com]

и рыбку съесть и ...

[thedeemon.livejournal.com]

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

[isorecursive.livejournal.com]

Можно, конечно. Просто надо макросом вычитывать схему и генерировать функции-вытаскиватели данных как

def getOstatki(...) = {
  ...bd access generated code...
  new {
  ...schema-based generated code...
  }
}

В местах использования структурно квантифицироваться по нужным полям.
Если речь не о аргументах метода, а о непосредственном использовании, то можно и без квантификации: getOstatki(...).someField

[si14.livejournal.com]

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

Мне кажется, секрет в фиксации инвариантов — если сама функция использует какое-то поле пришедших данных, то она должна контролировать его наличие, но только и исключительно его (а не «типа рекорда», например). Желательно — в том числе статически (но я не знаю примеров этого кроме костыля в typed clojure), желательно в рантайме тоже с минимальным количеством усилий. Насколько я понимаю, ничего готового нет; но можно попробовать, как я уже упомянул выше, пользоваться стилем из Erlang'а: выматчивать в голове функции все куски данных, которые нужны для неё или её потомков.