@fvnever а может эти типы можно получить через какое-то API?

Да, можно. Но для этого надо передать туда какие-то метадататокены. А чтоб их извлечь из байтов — надо распарсить IL!

Получить тип + токен

Дайте хоть почитать, что Сайм написал по поводу провайдеров

А там интересно, читай!

Ну ссылку киньте

https://github.com/Microsoft/visualfsharp/issues/2406

В общем, всё к тому идёт, что генеративным провайдерам на коре быть. Я уверен, что коллективными усилиями мы их запилим.

Там интересно, да

Особенно некоторые пассажи

@fvnever но нависла новая угроза

Типы в IL коде

Mono.Reflection!

А ещё там вчера была какая-то managed-читалка IL, но я её сегодня уже не могу найти. Похоже, Дон её перепрятал ?

Щас Сайм скажет, что в компиляторе есть ещё какой-то рефлекшн

Он был в TPSDK.

Как я понял, в компилятор он тащить пока не хочет поддержку generic tp

Хотя было бы неплохо

А нет, Сайм не скажет

Скажу я

https://github.com/Microsoft/visualfsharp/issues/2406

Во! https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/193707a4771b4ff6358a95fab46e6f39d5ed0513/src/AssemblyReaderReflection.fs

И, действительно, из мастера этот файл уже удалили :)

А что за файл .fsy?

https://github.com/Microsoft/visualfsharp/blob/master/src/absil/ilpars.fsy

Это для fsyacc, наверное?

Э, чо, не, погодь

Там парсер IL-кода на fsyacc чтоли?

Хз

Bus factor компилятора равен единице.

Я же сказал, нам не нужен будет даже Mono.Reflection :D

Я же сказал, нам не нужен будет даже Mono.Reflection :D

Зато нам будет нужен код из компилятора, который ещё страшнее.

Bus factor компилятора равен единице.

А вот нифига, будет надо — разберёмся!

А вот нифига, будет надо — разберёмся!

Разберитесь, потом обсудим. :)

Зато нам будет нужен код из компилятора, который ещё страшнее.

Тише ты, а то щас всех новичков распугаешь

Разберитесь, потом обсудим. :)

Потом ты уже будешь обсуждать с моим лечащим врачом.

В общем, Фридрих, LSD нам ещё пригодится

В общем, Фридрих, LSD нам ещё пригодится

Всё равно прорвёмся, нам нечего бояться.

У тебя хоть есть идеи, с чего начать?

у вас есть репо то, чтоб хотябы понять что вы делаете?)

у вас есть репо то, чтоб хотябы понять что вы делаете?)

Репо есть, но понять невозможно ?

У тебя хоть есть идеи, с чего начать?

Я предлагаю продолжать придерживаться плана. - делаем штуку на System.Reflection.Metadata - для парсинга байткодов берём Mono.Reflection

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

у вас есть репо то, чтоб хотябы понять что вы делаете?)

Приходи через полгода.

а вот провайдеры еще не открывал

До меня дошло, зачем нужны erased providers

Их просто проще реализовать и поддерживтаь

До меня дошло, зачем нужны erased providers

я так понял чтобы жирные сборки не плодить

Приходи через полгода.

Какие полгода, Сайм сказал там работы на день ?

Какие полгода, Сайм сказал там работы на день ?

Это ему на день. А @Liminiens пусть через полгода приходит :)

Я предлагаю продолжать придерживаться плана. - делаем штуку на System.Reflection.Metadata - для парсинга байткодов берём Mono.Reflection

Ты уверен, что это нужно?

работы на день, а реабилитации на полгода

Ты уверен, что это нужно?

Что именно?

Что именно?

Данный прототип

Ну, Дон не уверен :)

Я предлагаю вот что.

Он вселил неуверенность в меня :)

Я вижу сценарий, по которому реально работы на день.

Mono.Reflection + Mono.Cecil.

Может быть, код на System.Metadata.Reflection тоже пригодится, не знаю.

Надо собрать прототип из этого, а дальше посмотреть, сконвертуется ли провайдер. Мало ли, вдруг ещё на что-то напоремся.

Может быть, код на System.Metadata.Reflection тоже пригодится, не знаю.

Опыт полученный там точно пригодится

Но если Mono проще, почему бы и нет

И параллельно уже можно будет начинать делать нормальное решение на ilwriter.fs (и, видимо, на AssemblyReaderReflection.fs тоже).

Опыт полученный там точно пригодится

Вот да, за экспу работаем.

А чем ридер поможет?

Ну а полученную либу можно будет и оставить как есть. Я уже написал, что это будет просто общественно полезным артефактом.

А чем ридер поможет?

Ридер у нас будет выполнять роль Mono.Reflection.

Ну если есть понимание, давай делать на моно

Пока, вроде, есть. Будем делать на Mono.

Надо ещё разобраться, как верифицировать сборки)

Надо.

peverify есть конечно, но он ругается на сборки, сгенерированные компилятором

Кто-нибудь пробовал Mutable.Fody? https://github.com/ndamjan/Mutable.Fody

А как это работает? Само чтоли? В смысле, никаким атрибутом не нужно помечать?

Видимо, не нужно.

Но тогда оно все типы помутирует. А это редко нужно, я думаю.

Может быть нужно только из какого-нибудь неймспейса, например.

На сколько я помню fody достаточно гибко настраивается (для сборки, для неймспейса и т.д.)

Надо только доки разыскать. :)

А, то есть это предлагается рулить настройками самого Fody? Тогда ок.

Ну да, это же addin для fody.

Добрый день. Подскажите, пожалуйста, мне нужен метод который возвращает обобщенный тип abstract GetResponse : unit -> 'provider, в наследнике я пытаюсь, к примеру, вернуть строку из метода, но ругается с ошибкой, ожидается тип 'a, а получен тип string. Не могу понять, как вернуть обобщенный результат, можно ли вообще это сделать? Вот мое переопределение: override this.GetResponse () = "result"

А что такое 'provider? На каком уровне привязан этот аргумент?

вообще ни на каком, то есть это только метод по сути должен знать, что он возвращает

А как это в C# бы выглядело? Кажется, никак.

Ну вот смотри, ты в родителе объявил метод GetResponse<'T>(): 'T

Значит, он должен возвращать любой тип, который захочет вызыватель.

ну да, что-то я запарился) спасибо

Я думаю, что твоя задача решается - либо вообще без наследования - либо через параметризирование родительского типа переменной <'provider>

Да, второй вариант я как раз хотел сделать, я внутри наследника уже знаю, что мне нужно вернуть)

В контексте этого же вопроса. Сейчас пытаюсь вернуть обобщенный тип JsonProvider. У меня есть тип type LoginResponse = JsonProvider<"..путь к файлу..">. Результатом я указываю этот тип LoginResponse и пытаюсь вернуть вот так: LoginResponse.GetSample(), а в ответ выдает: ожидался тип LoginResponse, а получен JsonProvider<...>.Root. Кто-нибудь встречался с такой проблемой?

В контексте этого же вопроса. Сейчас пытаюсь вернуть обобщенный тип JsonProvider. У меня есть тип type LoginResponse = JsonProvider<"..путь к файлу..">. Результатом я указываю этот тип LoginResponse и пытаюсь вернуть вот так: LoginResponse.GetSample(), а в ответ выдает: ожидался тип LoginResponse, а получен JsonProvider<...>.Root. Кто-нибудь встречался с такой проблемой?

LoginResponse.Root

Это тип твоего json.

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

Решил вопрос так: объявил выше type provider = LoginResponse.Root и засунул provider в параметр, все работает, а напрямую не работает)

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

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

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

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

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

Просто помни, что это ненастоящие типы.