@Dolfik ^

Если честно, то я уже потерял суть проблем с провайдерами. :)

Проблема в том, что мы не можем сохранить сборку на диск

Или получить её в памяти (побайтово)

Проблема в том, что мы не можем сохранить сборку на диск

Только в этом?

Да

А Сайм про что пишет?

И там еще какая-то проблема с IReflectedType.

Он написал про то, что сейчас делаю я :)

А что ты делаешь?

Костыляю свой сохраняльщик сборок

Но я ничего не вижу в том комментарии про сохранение сборок.

Это больно и сложно

Ну, там дело даже не в сохранении

Нам нужен просто массив байт, чтобы скормить это компилятору

Он пишет про IL, но не упоминает метаданные, это странно

Они нам точно нужны

Я все равно ничего не понимаю.

А IL можно без проблем получить

Потом расскажете, когда сделаете?

Если вообще получится

Доков вообще нету

Делаю по интуиции и ECMA-335

Конечно можно тупо по спеке, но я задолбаюсь её читать

Там ещё 100500 ньюансов

@Dolfik Вы уже разобрались, как провайдеры работают?

Мы разобрались почему они не работают под кором, и что нужно сделать, чтобы заработали

А во внутренности не вникали

Сайм хочет пофиксить это не сломая апи

Мы разобрались почему они не работают под кором, и что нужно сделать, чтобы заработали

Ну, @fvnever еще не ответили на его вопросы.

В слаке тоже не ответили

Зацени: https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/40bfff9149c9237c0a61bda3e6ed597ece743264/src/ProvidedTypes.fs#L2778

Сайм хочет пофиксить это не сломая апи

Это правильно.

В слаке тоже не ответили

Возможно, не в том слаке спрашивали. :)

https://github.com/Dolfik1/AssemblyGenerator

Пилимся, ещё

@fvnever https://github.com/fsprojects/FSharp.TypeProviders.SDK/pull/133

Кажется, Дон читает наши комменты. Ну или мы с ним мыслим в одном и том же направлении.

F# Weekly #41 – ARKit and F# https://sergeytihon.com/2017/10/08/f-weekly-41-arkit-and-f/

Доброе утро.

Хорошая статья про описание "ограниченных" типов в рамках домена. https://www.codit.eu/blog/2017/10/03/f-domain-model-validation-with-active-patterns/

Кажется, Дон читает наши комменты. Ну или мы с ним мыслим в одном и том же направлении.

Кажется, это о чем-то совсем другом. Что такое "context based provided type API"?

Кажется, это о чем-то совсем другом. Что такое "context based provided type API"?

https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/82#issuecomment-334952830

Кажется, в этом ишуе решают ту же самую проблему, которую решаем мы?

Нет.

Это старый ишшуй про какой-то новое API.

Во всяком случае, комментарий прям хорошо подходит к нашему кейсу.

Это старый ишшуй про какой-то новое API.

Мб новый API решает проблему с .NET Core?

Мб новый API решает проблему с .NET Core?

Нет, это еще до .NET Core обсуждалось.

Я посмотрел пример.

https://github.com/7sharp9/ContextBasedGenerative/blob/master/ContextBasedGenerative/TypeProvider.fs

Действительно, новый API для провайдеров. Только непонятно, в чем была проблема старого.

Но в комменте написано про .NET Core. И про бинарные зависимости. Прям реально кажется, что Дон отвечал нам :)

В том числе про неткор.

Ну, потому что решение обеих проблем — смена IL writer.

Вот и я об этом же говорю. Похоже, что проблема общая, и её будут решать.

В компиляторе у нас уже есть портабельный IL writer (почему-то я об этом не подумал), его-то Дон и хочет переиспользовать.

У меня изначально был вопрос про то, что это все значит. :)

Уже не первый раз встречаю какие-то интересные штуки около провайдеров, но не понимаю, про что они или почему не работают.

В компиляторе у нас уже есть портабельный IL writer (почему-то я об этом не подумал), его-то Дон и хочет переиспользовать.

Разве проблема только в IL?

Разве проблема только в IL?

Ну, «ILWriter» — растяжимое понятие. Я так понял, Дон под этим имеет в виду всё, что сохраняет сборку :)

Оно и понятно, что проблема не только и не столько в IL.

Уже не первый раз встречаю какие-то интересные штуки около провайдеров, но не понимаю, про что они или почему не работают.

На моей памяти: - intrinsic type extensions for provided types - type providers combinators - context based provided type API

@fvnever А ты смотрел прототип провайдеров, параметризуемых типами?

Нет, не смотрел. Нам бы с обычными для начала разобраться!

Нет, не смотрел. Нам бы с обычными для начала разобраться!

А начало появляться понимание, как они работают?

Постепенно.

Расскажешь?

Вернее, пока что я укрепляюсь в своей прошлой убеждённости, что они работают довольно просто.

Контракт такой: провайдер генерирует полноценную сборку с типами и отдаёт её (и даже не саму сборку, а байтики) компилятору. Компилятор у себя парсит эту сборку обратно, и зашивает сгенерированные типы в итоговую программу.

Это для generative. Erased работает по-другому (как именно — я пока не смотрел).

То есть SDK нужен просто для упрощения жизни? Я могу любым доступным образом собрать сборку и отдать компилятору?

Поэтому, например, чтобы добавить поддержку каких-нибудь генерик-интерфейсов, нам придётся а) поменять ProvidedTypes.fs — грубо говоря, добавить туда метод ProvideGenericInterface(...) : System.Reflection.TypeInfo, которая просто обычным рефлекшеном сгенерит тип б) поменять принимающую сторону в компиляторе — сделать, чтоб она, завидев генерик-интерфейс, корректно копировала его в выходную сборку Обе этих вещи не видятся очень уж сложными, на самом деле.

То есть SDK нужен просто для упрощения жизни? Я могу любым доступным образом собрать сборку и отдать компилятору?

Не совсем так. SDK ещё публикует тебе только те возможности генерации сборок, которые поддерживаются в компиляторе. Если ты делаешь сборки самостоятельно, то можешь нечаянно заюзать те фичи, трансляции которых компилятор не обучен, и всё сломается.

Так Сайм в итоге хочет починить сохранение, или переписать апи, и обойтись там без сохранения?

> Обе этих вещи не видятся очень уж сложными, на самом деле. На словах — да.

Так Сайм в итоге хочет починить сохранение, или переписать апи, и обойтись там без сохранения?

Пока по его словам я так понял, что он хочет использовать в тайп-провайдерах другую сохранялку. Сохранение останется, но вместо стандартного рефлекшена будет использовать IL writer, используемый в компиляторе.

При этом Дон хочет избежать бинарных зависимостей — то есть опять начать шарить файлы между проектами :)

(впрочем, это деталь реализации, и принципиального значения она не имеет в любом случае)

Если это есть в компиляторе, то пропатчить компилятор, и кормить ему не байты а Assembly

Если это вообще ок

А что за IL Writer?

Если это есть в компиляторе, то пропатчить компилятор, и кормить ему не байты а Assembly

Это не ок, потому что тогда меняется API взаимодействия между провайдером и компилятором. Два сценария: 1. Существующие провайдеры сломаются в новом компиляторе, или 2. Нам придётся поддерживать два альтернативных варианта компиляторного API.

А там и без того уже дохрена кода, плюс, насколько я понял, альтернативных вариантов API / Type Provider SDK и без того уже хватает.

А что за IL Writer?

Наверное, разговор был про это? https://github.com/Microsoft/visualfsharp/blob/master/src/absil/ilwrite.fs

Ну если бы каждый не тащил себе в код реализацию Type Provider'ов, было бы ок)

Вон — Дон как раз недавно в этом копался.

Ну если бы каждый не тащил себе в код реализацию Type Provider'ов, было бы ок)

Я проанализировал ситуацию и по итогам не считаю, что а) всё совсем плохо б) будет сложно переделать на бинарную зависимость

Ну если бы каждый не тащил себе в код реализацию Type Provider'ов, было бы ок)

А мне нравится, что это отдельная библиотека, а не зашито в компилятор и стандартную библиотеку.

Сейчас TypeProviders.fs включается в новые провайдеры средствами пакетного менеждера.

Этот файл по-настоящему не копипастят.

Так что всё более или менее ок.

Сейчас TypeProviders.fs включается в новые провайдеры средствами пакетного менеждера.

Ну так ещё ок

Хотя с другой стороны, это фича компилятора, и должна быть в стандартной поставке

А мне нравится, что это отдельная библиотека, а не зашито в компилятор и стандартную библиотеку.

Например, это в теории позволяет делать интересные вещи, вроде type providers combinators.

Если мы в будущем захотим сделать, чтоб TypeProviderSDK стала бинарной зависимостью, то можно будет это сделать без того, чтобы ломать код провайдеров. Это вообще радикальных изменений не потребует.

Как сборка System

А мне нравится, что это отдельная библиотека, а не зашито в компилятор и стандартную библиотеку.

Тут есть такая проблема, что «библиотека» всё равно получается сильно связанной с принимающей стороной в компиляторе.

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