Latched, pinned, and marked dirty

я уверен, что ты понимаешь, что я имею в виду, только прикидываешься. у меня нет никаких "zhopej", когда я код пишу. да и у тебя нет. а есть row metadata в виде, например, Type list.

и GetValue(i) напиши тоже заодно (см. выше), чтобы два раза не вставать.

From:

про GetValue я уже написал там
Type list - это то же самое, закат солнца вручную - реализация динамической типизации руками поверх языка со статической типизацией.
Во всех попадавшихся мне под руку языках интеграция этого в статическую типизацию или невозможна, или реализуется через метапрограммирование на макросах, или через инфернальный type-level programming типа того же HList. А i там приходится выражать в нумералах чёрча, ага.
Еще один вариант - Reflection

И кстати, насчет GetValue(i) - предлагаю сразу задуматься, какие применения для него? Я пока вижу только как адаптер к нетипизированным вещам вроде DataGrid или типа "вывести тупл целиком в строку".

From:

> И кстати, насчет GetValue(i) - предлагаю сразу задуматься, какие применения для него?

эээ... вообще-то через него, или его аналог, работает вообще всё что database-related, включая "типизированные" датасеты, таблицы, whatever.

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

я не вижу, почему так принципиально трудно сделать нормальную языковую поддержку для операции, например, [int; string] -> int * string - при том что, как ты сам правильно заметил, сделать это через reflection не представляет проблем (unless число элементов в списке типов больше восьми ;).

всё, я пошел спать, глаза слипаются.

From:

[typeof(int);typeof(string)] -> int*string?

Теоретически трудно сделать, да. Т.к это означает все те же compile-time вычисления.

From:

Рискну выказать предположение.
GetValue(i) нужен для одной единственной цели - построить итерацию по таплу для обработки.
По идее, тут достаточно показать человеку как использовать параметрические функции а также map/etc, и проблема уйдёт.

Это в дополнении к:
http://109.livejournal.com/539588.html?thread=2049476#t2049476

From:

map тут не поможет же, мы ж итерируемся не по списку (данным), а по структуре(метаданным).
Тут помогло бы что-то вроде автоматической генерации подобной функции для любого типа тайпла. Т.е. все тайплы реализуют какой-нибудь интерфейс(typeclass в терминах хаскеля) с методами GetFieldCount GetFieldName(i), GetValue(i) и прочая.

From:

Ну если у нас гетерогенный контейнер - список сумма - то why not?

From:

эээ, ты что имеешь в виду?
Конвертировать тупл в гетерогенный список типа [SqlInt int;SqlString string], а тип тупла в [Type] и потом по ним итерироваться?
Но функцию конвертации в любом случае без компилятора не сделаешь. И вообще это в дотнете встроенное уже есть, reflection

Вот обратное - из типов и списков сгенерить тупл - уже без метапрограммирования не сделаешь.

From:

> Конвертировать тупл в гетерогенный список типа [SqlInt int;SqlString string]

wait, так нет же гетерогенных списков.

From:

type SqlType=
| SqlInt of int
| SqlString of string

let sqlItems = [SqlInt 1; SqlString "test" ]

Вот. Вполне себе гетерогенный список.

From:

ну вот да, что-то типа этого. ну и хотелось бы языковую поддержку хотя бы для операций [type1; type2; ...] -> (type1 * type2 * ...) и GetValue(i)

а, ну и ещё - возможно, что это и так есть, просто я не знаю - хотелось бы иметь человеческое инстанцирование из type variable, типа:

class My1 {}
class My2 {}
Type t;
t = My1;
My1 my1 = t.New();// инстанцируем My1
t = My2;
My2 my2 = t.New();// инстанцируем My2

в дельфи было что-то близкое, но я забыл уже. понятно, что через Reflection в дотнете это можно, хочется straightforward syntax.

From:

Да, да, в дельфи это именно так и было, и в .NET этого очень дико не хватает.

From:

ну так покажите же уже наконец человеку, как итерировать по таплу, а то пока все пишут, что это невозможно.

параметрические функции - это функции с параметрами, да? (что такое параметрические функции в математике я знаю, а что вы тут имели в виду - нет)

From:

let mapTuple callback tuple = match tuple with
Tuple(a) -> (callback a);
Tuple(a,b) -> begin (callback a); (callback b); end;
Tuple(a,b,c) -> begin (callback a); (callback b); (callback c); end;
....

end;

mapTuple you_function your_tuple.

From:

callback какой тип будет иметь?
Ну и вообще это закат солнца вручную.

From:

type tuple_1 'a = 'a
and tuple_2 'a 'b = 'a * 'b
and ...
and callback_argument = tuple_1 | tuple_2 | ....
and calback_result a 'b ... = 'a | 'b | 'c ...;
let callback : callback_argument -> callback_result

From:

нет, не означает. генерики в донете, если вам неизвестно, инстанцируются в рантайме, в отличие от плюсов, например.

From:

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

From:

я не вижу, почему так принципиально трудно сделать нормальную языковую поддержку для операции, например, [int; string] -> int * string - при том что, как ты сам правильно заметил, сделать это через reflection не представляет проблем (unless число элементов в списке типов больше восьми ;)..
Список имеет тип List A = A * List A | EmptyList.

Список это элемент типа A и ещё точно также список, либо пустой список.
Другими словами, списки гомогенны (содержат элементы одинакового типа данных).

Если же у нас списки гетерогенные - начинается веселуха.

В терминах ООП у нас вводится базовый класс Base и два наследника - A и B
И мы получается список Base'ов... А не список A, B.

В терминах ФЯП это описывается как:
Base = A | B
List Base = Base * List Base | EmptyList;

Теперь приходим к понимаю, что для списка длиной два есть четыре варианта:
A, A
A, B
B, A
B, B

Ну и как это говно типизировать?
Вот и появлются tuple.

Tuple 'a 'b = a' * 'b;
get (a,b) i = match i with
0 -> a
1 -> b
end;

Какой тип результата get?
Естественно, a | b

Теперь проблема понятна?

From:

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

From:

Вот именно, о чём и речь

From:

> Если же у нас списки гетерогенные - начинается веселуха

в F# нет гетерогенных списков.

> Теперь проблема понятна?

она и до того была понятна - в F# нет языковой поддержки для довольно тривиальной вещи, которая мне нужна.

From:

она и до того была понятна - в F# нет языковой поддержки для довольно тривиальной вещи, которая мне нужна.
Её нигде нет. Кроме, разве что, Haskell

From:

В хаскеле в приемлемом для мозга виде тоже нет :)

From: