В Scala вот есть разные реализации всей этой функциональности — cats и scalaz. И это очень положительно сказывается на экосистеме, как мне кажется.

И обе они базируются на расширенное системе типов из scala. Да и на последнем scala митапе, слышал что cats это просто “более лучше scalaz”, которая отпочковалась от нее.

Кстати да, в .net core вообще хоть планируют тайп провайдеры?

Кстати да, в .net core вообще хоть планируют тайп провайдеры?

Мы прям при тебе, в этом чате их планируем починить.

Mono конечно хорошая вещица, но хочется от него отказаться в конце-концов.

Когда мы сделаем — тогда и будет.

(ну, или кто-нибудь сделает раньше нас, это тоже отлично)

@fvnever а что там с ними не так, почему не могут просто взять и ctrl-c & ctrl-v из .Net ?

@fvnever а что там с ними не так, почему не могут просто взять и ctrl-c & ctrl-v из .Net ?

Пока что моё (даже близко не полное) видение ситуации таково: - generative type providers используют сохранение динамических сборок для какой-то цели (не факт что принципиально важной) - в .NET Core не запилена эта фича вообще, и в ближайшее время не планируется - сделать Ctrl-C — Ctrl-V на уровне .NET Core нельзя, потому что а) этого кода нет в открытом доступе, это часть проприетарной реализации .NET Framework б) этот код завязан на Windows (как минимум непринципиальные для нас части, типа генерации PDB)

Хм, да в .Net Core чот куда не плюнь - фича не запилина. Странно всё это, вроде релизы выходят, а действительно нужный функционал не добавляется.

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

Я помню и от Гебба высказывания в сторону EF Core

Я помню и от Гебба высказывания в сторону EF Core

EF Core и .NET Core — вообще разные вещи, делаются разными командами с разными приоритетами.

Нам вот в F# не очень важен EF Core, к примеру (хотя мы умеем с ним взаимодействовать, я даже сам пробовал).

Нам важны тайп провайдеры, а их нет =(

У нас есть тайп провайдеры, ефкор не нужон.

Сижу вот на mono из за них.

Нам важны тайп провайдеры, а их нет =(

Поэтому нам надо оторвать попу от стула, пойти и сделать!

Нам важны тайп провайдеры, а их нет =(

SqlProvider вроде Erased, и возможно уже поддерживается в неткоре

Поэтому нам надо оторвать попу от стула, пойти и сделать!

а парням из MS за что деньги платят?

SqlProvider вроде Erased, и возможно уже поддерживается в неткоре

Да, какой-то из SQL'ных провайдеров поддерживается.

SqlProvider вроде Erased, и возможно уже поддерживается в неткоре

https://fsprojects.github.io/SQLProvider/core/netstandard.html

А вот Rezoom.Sql, который мне больше нравится, он помоему Generative

Но Rezoom.Sql не может в другие БД

а парням из MS за что деньги платят?

А ты сам-то как думаешь? За то, что они выполняют задачи работодателя. Которые в идеале должны, но могут и не совпадать с задачами, которые интересны лично мне или тебе.

Но Rezoom.Sql не может в другие БД

Другие — это какие?

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

Разберёмся, поясним всем, поставим цели, и выполним.

Другие — это какие?

Всё что не pg, sqlite и sql server

Всё что не pg, sqlite и sql server

Запили!

А меня вот не удручает. Мы с @impworks вдвоём работали над компилятором, и даже вдвоём постоянно толкались и конфликтовали в коде. Слишком много разработчиков не нужно.

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

Сайм сказал слишком сложно там всё, и нужно большую работу проделать. Но хз, может он имел ввиду большую работу по фиче сохранения сборок, а на самом деле там без неё можно обойтись

Сайм сказал слишком сложно там всё, и нужно большую работу проделать. Но хз, может он имел ввиду большую работу по фиче сохранения сборок, а на самом деле там без неё можно обойтись

Да, я вот и хочу разобраться. И либо я дальше соглашусь с Доном (и постараюсь обнародовать внятное пояснение), либо я буду предлагать ему варианты решения.

А меня вот не удручает. Мы с @impworks вдвоём работали над компилятором, и даже вдвоём постоянно толкались и конфликтовали в коде. Слишком много разработчиков не нужно.

Разве конфликтовали? По-моему был только момент с табопробелами :)

Разве конфликтовали? По-моему был только момент с табопробелами :)

Ну, явных конфликтов не было, но было чёткое разделение в зонах ответственности. И, если кто лез в чужой код, то это было сложно :)

Да, я вот и хочу разобраться. И либо я дальше соглашусь с Доном (и постараюсь обнародовать внятное пояснение), либо я буду предлагать ему варианты решения.

а можно как-то пнуть Сайма, что бы показал, как они там тайп провайдеры в .Net накостыляли?

а можно как-то пнуть Сайма, что бы показал, как они там тайп провайдеры в .Net накостыляли?

Как они что сделали где?

Да, такое было

Весь код Сайма на гитхабе.

Как они что сделали где?

.Net Framework

.Net Framework

Я не понимаю, что ты спрашиваешь.

Весь код тайппровайдеров выложен на гитхаб.

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

Я про это.

Я про это.

При чём тут .NET Framework?

Тогда я совсем не понимаю.

Ещё раз: Сайм показал, как они реализовали тайппровайдеры. Выложил тебе код под открытой лицензией.

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

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

Просто для этого надо много кода прочитать, вот что :)

Тут не Сайма нужно пинать, а себя самого!

Аааа, я решил, что во фразе «Никто не видит» сокрыт смысл, что кота нет!

Не, я не это имел в виду, прошу прощения что ввёл в заблуждение.

Тогда наверное стоит начать с этого пункта «- в .NET Core не запилена эта фича вообще, и в ближайшее время не планируется»

А что за фича такая? Есть её кот из "большого" .Net ?

А что за фича такая? Есть её кот из "большого" .Net ?

Фича — сохранение динамических сборок (AssemblyBuilderAccess.SaveAndRun). Кода нет.

Чёрт, а вот это плохо. Тогда только MS имеет шансы на её быструю реализацию.

Пока что у меня на повестке вопрос — нужна ли нам эта фича для тайп-провайдеров вообще.

Может, и не нужна.

Хм

И как это узнать?

Читать код.

Фича — сохранение динамических сборок (AssemblyBuilderAccess.SaveAndRun). Кода нет.

Всмысле кода нет? Нет исходника реализации в .Net Framework?

Всмысле кода нет? Нет исходника реализации в .Net Framework?

Насколько я понял jkotas, там завязка на нативную часть, кода которой у нас нет. Всякие там PDB-writers.

ERROR: S client not available

https://github.com/dotnet/corefx/issues/4491#issuecomment-189756092 > In particular, the support for emitting debug information depends on unmanaged PDB writer that is very complex Windows-specific component that we have no plans to open source and bring x-plat.

Поэтому ты и хотел найти Mono.Cecil, и там реализацию посмотреть

Но ты не нашёл где это, да?

Поэтому ты и хотел найти Mono.Cecil, и там реализацию посмотреть

Это одна из веток плана для дальнейшей проработки.

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

Где-то есть мифическая ветка Mono.Cecil с недоделанным трансформатором из Assembly(Builder?), с которым хотелось бы поиграться. Но мне сходу её найти не удалось.

Вот

Можно написать автору. https://github.com/jbevain

Тут надо всем подряд писать и со всеми разговаривать. Обожди, дай я соберусь с мыслями и планами. И потом уже буду всем писать :)

Оке)

Потом мы у 7sharp9 ещё спросим, какие у него были задумки.

Я просто пинаю тебя, ради великого дела :)

Вообще... Было бы хорошо всех этих ребят собрать тут в чати.

Что бы не бегать по гитхабам.

Лучше в отдельном чате тогда уж, Gitter, например

Мне без разницы, как с кем коммуницировать. Сначала в любом случае нужно всё обдумать и самому разобраться — или хотя б составить список вопросов.

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

Лучше в отдельном чате тогда уж, Gitter, например

Правильное место для обсуждения — это канал #compiler в F# Slack.

Но в правильное место приходят с правильными вопросами.

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

чтобы задать правильный вопрос - надо знать большую часть ответа :)

Я бы хотел разобраться, мешает ли что-нибудь портировать TypeShape на .NET Core.

Это хорошая библиотека, правда, пока не получившая широкого применения.

Я бы хотел разобраться, мешает ли что-нибудь портировать TypeShape на .NET Core.

https://github.com/eiriktsarpalis/TypeShape/issues/5

Давайте разберёмся.

Вернее, давайте возьмём да скомпиляем. Похоже, оно просто возьмёт и начнёт работать.

Изменения в Reflection API — та ещё заноза. Но чуваки могли с самого начала взять пакетик с полифиллом, и всё, скорее всего, заработало бы ещё на .NET Standard 1.6. Жаль, что Эйрик был не в курсе про полифилл.

Изменения в Reflection API — та ещё заноза. Но чуваки могли с самого начала взять пакетик с полифиллом, и всё, скорее всего, заработало бы ещё на .NET Standard 1.6. Жаль, что Эйрик был не в курсе про полифилл.

Я тоже не в курсе!

Я тоже не в курсе!

https://github.com/agileobjects/NetStandardPolyfills

Судя по количеству звёздочек на гитхабе (две) — вообще никто не в курсе :)

Судя по количеству звёздочек на гитхабе (две) — вообще никто не в курсе :)

ща накидаем