F#

[109]

начал изучать F# сегодня после обеда. похоже, что к концу дня уже и закончил. никакой дополнительной гибкости по сравнению с C# не наблюдается. взять tuples. ок, я могу сматчить первый элемент как (x, _), аналогично head в списке. а как мне сматчить остаток (e.g. tail)? или как итерировать по тупелу заранее неизвестного типа? или как динамически создать тупел, имея, скажем, список типов элементов? а ведь без перечисленного мной ничего осмысленно реляционного не написать. вот у них ничего не пошевелилось в душе, когда они хуярили эти конструкторы?

Tuple(T1)
Tuple(T1, T2)
Tuple(T1, T2, T3)
Tuple(T1, T2, T3, T4)
Tuple(T1, T2, T3, T4, T5)
Tuple(T1, T2, T3, T4, T5, T6)
Tuple(T1, T2, T3, T4, T5, T6, T7)
Tuple(T1, T2, T3, T4, T5, T6, T7, T8)

bonus: Action(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16)

видимо, Билл Гейтс сказал, что 16 параметров должно быть достаточно для любого метода.

Comments

[109.livejournal.com]

перевожу на русский язык: F# не может сделать того, что дельфи могла ещё в прошлом веке, и концепция кортежа (tuple), сделанная в F# first-class citizen, имеет мало отношения к кортежам баз данных, по большому счёту бесполезна, и введена из чисто маркетинговых соображений.

[metaclass.livejournal.com]

Еще раз: не нужно путать статическую и динамическую типизации.
Дельфи(TDataset, bde и dbexpress и прочая), ADO, ADO.NET, и 90% других базоданновых либ - это все динамическая типизация.
F# tuples, C# class и struct, записи, ADT и прочее - это статическая типизация, со своей достаточно строгой теорией. Tuples в F# введены, т.к. это очевидный элемент оной теории.
Интеграция этого дела возможна, но тянет за собой множество заморочек, которые отражаются в крайней невменяемости большинства ORM-либ. Оные ORM как раз и решают задачу "адаптировать систему типов БД и систему типов языка". Прозрачной интеграции я пока не видел вообще нигде и ни разу, т.к. языки у которых есть нужные для этого фичи, либо сами по себе динамически типизированы, либо в продакшене не используются/


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

[109.livejournal.com]

> Еще раз: не нужно путать статическую и динамическую типизации

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

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

ещё раз: у меня нет в compile-time никакой информации ни о названиях полей, ни о их типах. эта информация приходит из базы в рантайме. тем не менее, ваше предположение о том, что в этом случае типизация невозможна, неверно.

[metaclass.livejournal.com]

Обычные туплы, тут где-то в комментах уже рассказывали откуда они взяты. То что они не могут быть использованы для работы с БД - это потому что вы их пытаетесь использовать не в тех целях, исходя из похоже названий и теоретической модели лежащей в их основе.

И я про это и пишу: tuple в данном случае сущность времени компиляции, поскольку информации о типах и именах в это время нет - значит его использовать нельзя.
Статическая типизация в этом случае невозможна.

[vshabanov.livejournal.com]

введена из чисто маркетинговых соображений.

Ржунимагу. Тьюплы -- способ по быстрому сгруппировать небольшие кусочки данных. Используются чтобы вернуть несколько значений из ф-ии (\x -> (x,x*2), вместо out-параметров и объявлений лишних переменных), или для каких-нить сшиваний списков (типа map (\(i,x) -> f i x) $ zip [1..] data).

Т.е. тюплы в ФЯ -- это такое локальное удобство, чтобы не заводить лишних типов-записей.

Если в тюпле больше 2-3 элементов, то это уже плохой стиль (сложно поддерживать) и лучше запись заводить с нормальными именованными полями.

Хотя в теории БД используются вроде как те же кортежи (им для теории имена полей не очень важны), но на практике удобнее таки с записями работать, а не с i-ым элементом.

Т.е. тюплы -- это не маркетинговый ход, а удобная в ФП (и не только) конструкция.

А если очень надо i-й элемент -- то либо welcome в зависимые типы (которых нет ни в F# ни в Haskell), либо также, как и во всех остальных языках -- динамическая типизация (List/Array.nth i [StringField "asdf", IntField 123, NullField]) и/или навернутый поверх нее маппер в записи и обратно.

F# хоть и убог, но всяко мощнее дельфи и уж точно может сделать то, что что дельфи могла ещё в прошлом веке.

[109.livejournal.com]

я и не спорю, что туплы для чего-то другого могут быть полезны. для того, что мне нужно - нет. хотя могли бы.

[vshabanov.livejournal.com]

А про зависимые типы -- это примерно так:

-- описание типов полей
data FScheme = FString | FInt

-- превращение описания типа поля в тип языка программирования
fType :: FScheme -> Set
fType FString = String
fType FInt    = Int

-- описание типа кортежа -- список типов полей
type TScheme = [FType]

-- превращение описания типа кортежа в тип языка программирования
tType :: TScheme -> Set
tType []     = ()
tType (x:xs) = (x, tType xs)

-- т.е. tType [FString, FInt] выдаст тип кортежа (String, (Int, ())).

-- а вот и i-тый элемент
-- ф-я принимает i, описание типа кортежа, а дальше пошли зависимые типы:
--  * 3-й аргумент имеет тип tType ts -- т.е. тюпл,
--    соответствующий заданной во 2-м параметре схеме
--  * результат -- тип, соответствующий описанию i-го поля из схемы
--
tTypeNth :: (i:Nat) -> (ts:TScheme) -> tType ts -> fType (nth ts i)
tTypeNth O      _        (x, _  ) = x
tTypeNth (S i') (_, ts') (_, xs') = tTypeNth i' ts' xs'

Но так пока можно только в Agda (которая сыровата) или в Coq (который брутален и бессердечен) ну и в еще менее популярных языках.

[109.livejournal.com]

> т.е. tType [FString, FInt] выдаст тип кортежа (String, (Int, ()))

ну вот видите, могут же, когда захотят. только нужно (String, Int) получить, а не вложенные туплы, но суть не меняется. а то "невозможно! невозможно!"

[xeno-by.livejournal.com]

http://xeno-by.livejournal.com/45951.html?thread=136319#t136319

[alexey-rom.livejournal.com]

> концепция кортежа (tuple), сделанная в F# first-class citizen, имеет мало отношения к кортежам баз данных

Естественно. Она имеет отношение к кортежам во всех остальных статически типизированных функциональных языках.

> по большому счёту бесполезна,

Очень полезна (но совсем не для того).

> и введена из чисто маркетинговых соображений.

И унаследована в неизменном виде из языка ML (http://en.wikipedia.org/wiki/ML_%28programming_language%29) 1970-х годов.

[109.livejournal.com]

ясно. а я думал, что The tuple calculus is a calculus that was introduced by Edgar F. Codd as part of the relational model in order to give a declarative database query language for this data model