Дон прямо сейчас рассказывает о type providers.
http://bit.ly/bfWDkA

Выглядит очень круто. Никакого генеренного кода — все типы являются виртуальными и получаются на лету, пока пишется код. При этом есть поддержка сторогой типизации и интеллисенс(!).

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

Здравствуйте, Кэр, Вы писали:

А где можно скачать видео?
А то после просмотра презентации остались не ясные моменты.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Кэр, Вы писали:

WH>А где можно скачать видео?
WH>А то после просмотра презентации остались не ясные моменты.

Хм, там видео доступно для повторных просмотров Скачать вроде пока нельзя, если трафик на учете.

Вообще, я в этот форум не просто так запостил — обсудить будет вполне интересно. Если мы тут коллективно что-то не сможем понять — то я задам вопрос Дону по внутреннему email, тут обычно довольно охотно отвечают. Из Эрика Мейерса я в свою время просто вагон полезной информации получил

Здравствуйте, Кэр, Вы писали:

Кэр>Хм, там видео доступно для повторных просмотров
У меня при переходе по ссылке все время говорит произошла хрен знает какая ошибка.
Другие презентации работают.
Что я делаю не так?

Здравствуйте, WolfHound, Вы писали:

Кэр>>Хм, там видео доступно для повторных просмотров
WH>У меня при переходе по ссылке все время говорит произошла хрен знает какая ошибка.
WH>Другие презентации работают.
WH>Что я делаю не так?

У меня проблем не было. Можно в саппорт сайта стукнуть. Узнаю про видео на скачку — выложу здесь ссылку.

Здравствуйте, Кэр, Вы писали:

Кэр>Выглядит очень круто. Никакого генеренного кода — все типы являются виртуальными и получаются на лету, пока пишется код. При этом есть поддержка сторогой типизации и интеллисенс(!).

Только что посмотрел видео, мне кажется, что type provides это, один в один, описание макросов, точнее одного из use cases'ов их применения. Интересно было бы посмотреть на реализацию, жаль что не доступна.

Здравствуйте, Кэр, Вы писали:

Кэр>Выглядит очень круто.
Можете объяснить что в этом крутого? Имхо, муть какая то. Сложность написания провайдера точно такая же как и для кодогенератора, при этом код можно использовать в любом языке, а провайдер только в одном. Может конечно F# сейчас живет в каком то своем мире где нужен инетлисенс для всех источников данных в мире, но по моему это не задача языка. Лучше бы макросы сделали.

Починили.

Здравствуйте, Рысцов Денис, Вы писали:

РД>Только что посмотрел видео, мне кажется, что type provides это, один в один, описание макросов, точнее одного из use cases'ов их применения. Интересно было бы посмотреть на реализацию, жаль что не доступна.
После того как они это зарелизят я думаю ты сможешь прикрутить это к немерле макросом за несколько часов.
Единственное что нужно будет добавить в компилятор поддержку имен с пробелами.
Можно как у них, а можно просто строковый литерал в качестве имени использовать.
Уверен что Влад это за пару часов сделает.

Здравствуйте, dotneter, Вы писали:

D>Можете объяснить что в этом крутого? Имхо, муть какая то. Сложность написания провайдера точно такая же как и для кодогенератора,
Что-то мне подсказывает что таки значительно ниже.

D>при этом код можно использовать в любом языке, а провайдер только в одном.
Это мелкософт при желании может очень легко исправить.

D>Может конечно F# сейчас живет в каком то своем мире где нужен инетлисенс для всех источников данных в мире, но по моему это не задача языка. Лучше бы макросы сделали.
Ну да. Макросами эта задача тоже очень легко решается.
Но сделать толковые макросы не просто. Я бы даже сказал что под это дело нужно дизайнить сам язык, а прикрутить макросы к языку который на это не рассчитан очень не просто.

Здравствуйте, Рысцов Денис, Вы писали:

Кэр>>Выглядит очень круто. Никакого генеренного кода — все типы являются виртуальными и получаются на лету, пока пишется код. При этом есть поддержка сторогой типизации и интеллисенс(!).

РД>Только что посмотрел видео, мне кажется, что type provides это, один в один, описание макросов, точнее одного из use cases'ов их применения. Интересно было бы посмотреть на реализацию, жаль что не доступна.

Какая разница как это реализовывать? Цимус идеи-то не в этом. Главное — что генеренного кода, которым надо управлять нет, а типизированный код все равно есть.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, dotneter, Вы писали:

WH>Что-то мне подсказывает что таки значительно ниже.
В обоих случаях нам нужно знать всю информацию о типе, на основе которой либо генерируются классы, либо эта информация отдается через интерфейс провайдера. Возьмем например файл ресурсов, где там вам видется снижение сложности?


WH>Это мелкософт при желании может очень легко исправить.
Может в С# 6 оно и появится, только сейчас тогда какой в этом смысл?


WH>Но сделать толковые макросы не просто. Я бы даже сказал что под это дело нужно дизайнить сам язык, а прикрутить макросы к языку который на это не рассчитан очень не просто.
К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.

Здравствуйте, Кэр, Вы писали:

Кэр>Какая разница как это реализовывать? Цимус идеи-то не в этом. Главное — что генеренного кода, которым надо управлять нет, а типизированный код все равно есть.
Видишь суслика? А он есть.
Просто код генерируется компилятором F#.
В данном случае это очевидный хардкод поддержки библиотеки в язык.
Язык с макросами с одной строны может решать эту проблему также эффективно и при этом не нужно будет тащить все это если оно не нужно.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Кэр, Вы писали:

Кэр>>Какая разница как это реализовывать? Цимус идеи-то не в этом. Главное — что генеренного кода, которым надо управлять нет, а типизированный код все равно есть.
WH>Видишь суслика? А он есть.
WH>Просто код генерируется компилятором F#.

Дык нет. Там есть интерфейс провайдера типа. А компилятор и среда разработки умеет как-то с этим интерфейсом работать. Код генерить тут совсем необязательно — достаточно получить метаданные типа.

WH>В данном случае это очевидный хардкод поддержки библиотеки в язык.
WH>Язык с макросами с одной строны может решать эту проблему также эффективно и при этом не нужно будет тащить все это если оно не нужно.

Это один из вариантов реализации. Всего-навсего. Я знаю, что вы ребята тут немножко безумные по поводу того, что вариант решения проблемы Немерле — это единственный правильный и лучше просто нигде нет — практически для любых задач. Но мне даже начинать дискуссию в эту сторону не особо интересно.

Здравствуйте, dotneter, Вы писали:

D>В обоих случаях нам нужно знать всю информацию о типе, на основе которой либо генерируются классы, либо эта информация отдается через интерфейс провайдера. Возьмем например файл ресурсов, где там вам видется снижение сложности?
Как минимум нам не нужно генерировать сам код.
Текстовая кодогенерация задача не простая и багоемкая.
Также нам не нужно будет возиться с перегенерацией этого кода.

D>Может в С# 6 оно и появится, только сейчас тогда какой в этом смысл?
А этого и сейчас и в F# нет.
Оно на F#3 запланировано.

D>К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.
Ну да. Содрали все с немерла.
Вот только я так и не понял можно ли делать так (см выделенное):

  macro whenmacro (cond, body)
  syntax ("when", "(", cond, ")", body)
  {

    def res1 = Util.locate(cond.Location,
      match (cond)
      {
        | <[ $subCond is $pattern ]> with guard = null
        | <[ $subCond is $pattern when $guard ]> =>
          def res2 = match (pattern)
          {
            | PT.PExpr.Call when guard != null =>
              <[ match ($subCond) { | $pattern when $guard => $body : void | _ => () } ]>
            | PT.PExpr.Call =>
              <[ match ($subCond) { | $pattern => $body : void | _ => () } ]>
            | _ => <[ match ($cond) { | true => $body : void | _ => () } ]>
          }
          res2
        | _ => <[ match ($cond : bool) { | true => $body : void | _ => () } ]>
      });

    res1
  }

Здравствуйте, Кэр, Вы писали:

Кэр>Дык нет.
А ты внимательно его послушай. Там было несколько оговорок на счет того что нет явной кодогенерации.

Кэр>Там есть интерфейс провайдера типа. А компилятор и среда разработки умеет как-то с этим интерфейсом работать. Код генерить тут совсем необязательно — достаточно получить метаданные типа.
Вот собственно по этим метаданным код и генерируется.
Обрати внимание на выделенное...

 public interface ITypeProvider
    {
        Type GetType(string name, 
                     BindingFlags bindingAttr);
        
        Expression GetInvokerExpression(
                      MethodBase syntheticMethodBase, 
                      ParameterExpression[] parameters);

        event System.EventHandler Invalidate;

        Type[] GetTypes();   
    }

Кэр>Это один из вариантов реализации. Всего-навсего. Я знаю, что вы ребята тут немножко безумные по поводу того, что вариант решения проблемы Немерле — это единственный правильный и лучше просто нигде нет — практически для любых задач. Но мне даже начинать дискуссию в эту сторону не особо интересно.
Мы не безумные. Мы до мозга костей практичные.
А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, dotneter, Вы писали:

WH>Как минимум нам не нужно генерировать сам код.
WH>Текстовая кодогенерация задача не простая и багоемкая.
У них же код как то генерируется с использованием провайдера, получается мы сравниваем то что есть с тем чего нет. Можно реализовать тот же самый генератор котрый будет использовать их интерфейс но результат будет не на лету а в файл. Задачачи же полностью эквивалетные, разница только в том где хранить то что генерируется, плюс у них часть функционала уже реализовано, но никто не запрещает сделать тоже самое для кодогенератора.
WH>Также нам не нужно будет возиться с перегенерацией этого кода.
Они же файл не каждый раз будут читать, скорее всего кешируют, значит нужно как то отслеживать актуальность кеша. Котогенератор может поступать также. Все те же проблемы и их решения.

D>>К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.
WH>Ну да. Содрали все с немерла.
Если они даже и слабее макросов Немерла, это не умиляет их полезность.

Здравствуйте, dotneter, Вы писали:

D>>>К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.
WH>>Ну да. Содрали все с немерла.
D>Если они даже и слабее макросов Немерла, это не умиляет их полезность.

В Boo есть существенная проблема — нету сопоставления с образцом. Без ПМ-а производить декомпозицию кода — безумие.

Здравствуйте, WolfHound, Вы писали:

Кэр>>Дык нет.
WH>А ты внимательно его послушай. Там было несколько оговорок на счет того что нет явной кодогенерации.

Как я сказал — мне довольно все равно, как это реализовано под капотом. Главное тут, что мне управлять сгенерированным кодом не нужно. Даже если там есть какая-то специальная магия, которую нужно понимать для реализации своего провайдера — то она должна хорошо закрываться стандартными классами. Чтобы наружу была выставлена только логика как одни метаданные (например, WMI) конвертируются в метаданные .Net классов — большего там не надо.

Кэр>>Там есть интерфейс провайдера типа. А компилятор и среда разработки умеет как-то с этим интерфейсом работать. Код генерить тут совсем необязательно — достаточно получить метаданные типа.
WH>Вот собственно по этим метаданным код и генерируется.
WH>Обрати внимание на выделенное...
WH>

WH> public interface ITypeProvider
WH>    {
WH>        Type GetType(string name, 
WH>                     BindingFlags bindingAttr);
        
WH>        Expression GetInvokerExpression(
WH>                      MethodBase syntheticMethodBase, 
WH>                      ParameterExpression[] parameters);
WH>
WH>        event System.EventHandler Invalidate;

WH>        Type[] GetTypes();   
WH>    }
WH>

Expression — это expression, это объекты в памяти. Я так думаю что там генерить код макросом, а потом компилировать код совсем необязательно. Не нужны там особо никакие сложные выражения. Либо вообще не нужны методы там, либо это будут очень простые прокси-вызовы.

WH>Мы не безумные. Мы до мозга костей практичные.
WH>А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие.

Да тут это обсуждалось миллионы раз. Есть другие точки зрения. Излишняя гибкость бывает тоже вредной. Например, С++ макросы, которые переписывают исходный код несколько раз — даже если там есть проверки — это уже плохой стиль. Просто потому что возникает слишком много сюрпризов при чтении кода. И язык, который позволяет сделать то, что надо с одной стороны и не позволяет отстрелить себе ногу с другой — не является никаким безумием, а является очень правильной альтернативой. Если бы были железные контр-примеры, что, например, C# не позволяет чего-то очень критичного, что позволяет Немерле — то у вас не было бы таких проблем в убеждении всех остальных, что эта степень свободы так необходима.

Здравствуйте, Кэр, Вы писали:

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

Кэр>Expression — это expression, это объекты в памяти.
Которые используются для чего?

Кэр>Я так думаю что там генерить код макросом, а потом компилировать код совсем необязательно. Не нужны там особо никакие сложные выражения. Либо вообще не нужны методы там, либо это будут очень простые прокси-вызовы.
Они просто эту самую генерацию и компиляцию засунули прямо в компилятор.

Кэр>Да тут это обсуждалось миллионы раз. Есть другие точки зрения.
И принадлежат они исключительно тем кто этими механищмами ни разу не пользовался...

Кэр>Излишняя гибкость бывает тоже вредной. Например, С++ макросы, которые переписывают исходный код несколько раз — даже если там есть проверки — это уже плохой стиль.

Ты же не понимаешь о чем говоришь.
Совсем не понимаешь.
Макросы немерле не имеют ничего общего с макросами С++.
Вот например:
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/ComputationExpressions/Test/EnumerableTest.n
Знаешь что нужно было сделать чтобы внутри ComputationExpressions заработал интелисенс?
Ничего. Он сам заработал.

Кэр>Просто потому что возникает слишком много сюрпризов при чтении кода.
Так не возникает.
Я тебе как практик говорю.
И это при том что код на немерле состоит из макросов чуть меньше чем полностью.

Кэр>И язык, который позволяет сделать то, что надо с одной стороны
Так ведь не позволяет.

Кэр>и не позволяет отстрелить себе ногу с другой — не является никаким безумием, а является очень правильной альтернативой.
В том же немерле граблей по факту меньше чем в C#.

Кэр>Если бы были железные контр-примеры, что, например, C# не позволяет чего-то очень критичного, что позволяет Немерле — то у вас не было бы таких проблем в убеждении всех остальных, что эта степень свободы так необходима.
Оба языка полны по тьюрингу.
Проблема в том что на C# писать приходится порой раз в 10 больше.
Но кого это волнует?
Ведь C# сделали в майкрософт. А майкрософт как известно ошибаться не может.