для оптимизации было бы полезно делать преобразования кода при выполнении
например a*b+a*c -> a*(b+c)

или fun1(fun2(x,y),y) -> fun1(x, fun2(x,y)) и т д

Здравствуйте, Аноним, Вы писали:

А>для оптимизации было бы полезно делать преобразования кода при выполнении
А>например a*b+a*c -> a*(b+c)

В компиляторе после Type4 строится граф выполнения (CFG) и что-то с ним происходит, но для такого преобразования нужно доказывать дистрибутивность операции * над совершенно конкретными операндами.

А>или fun1(fun2(x,y),y) -> fun1(x, fun2(x,y)) и т д

Для таких вещей нужно доказывать коммутативность и прочая.

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

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

H>Здравствуйте, Аноним, Вы писали:

А>>для оптимизации было бы полезно делать преобразования кода при выполнении
А>>например a*b+a*c -> a*(b+c)

H>В компиляторе после Type4 строится граф выполнения (CFG) и что-то с ним происходит, но для такого преобразования нужно доказывать дистрибутивность операции * над совершенно конкретными операндами.

А>>или fun1(fun2(x,y),y) -> fun1(x, fun2(x,y)) и т д

H>Для таких вещей нужно доказывать коммутативность и прочая.

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


Вообще то в начале я написал

a:Matrix*b:Matrix+a*c:Matrix -> a*(b+c)
fun1(fun2(x:int,y:int),y) -> fun1(x, fun2(x,y))

довольно сильная оптимизация

Здравствуйте, Аноним, Вы писали:

А>Вообще то в начале я написал

А>a:Matrix*b:Matrix+a*c:Matrix -> a*(b+c)
А>fun1(fun2(x:int,y:int),y) -> fun1(x, fun2(x,y))

Что-то я не видел слова Matrix в начале топика. К тому же нужно обладать определенным знанием об устройстве этого класса.

А>довольно сильная оптимизация

И при том элементарно реализуемая человеком.

Может быть лучше мы будем заниматься действительно реальными вещами?

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

H>Здравствуйте, Аноним, Вы писали:

А>>Вообще то в начале я написал

А>>a:Matrix*b:Matrix+a*c:Matrix -> a*(b+c)
А>>fun1(fun2(x:int,y:int),y) -> fun1(x, fun2(x,y))

H>Что-то я не видел слова Matrix в начале топика. К тому же нужно обладать определенным знанием об устройстве этого класса.

А>>довольно сильная оптимизация

H>И при том элементарно реализуемая человеком.

H>Может быть лучше мы будем заниматься действительно реальными вещами?

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

Здравствуйте, Аноним, Вы писали:

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

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

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

В вот это точно не в наш форум.

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

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

H>В вот это точно не в наш форум.

Макросы-операторы работают в генериках, а вот обычные обработчики операторов — это статические методы, как-то не слишком ясно как их применять там.

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

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

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

H>>В вот это точно не в наш форум.

H>Макросы-операторы работают в генериках, а вот обычные обработчики операторов — это статические методы, как-то не слишком ясно как их применять там.

macros fun(t:T) request<T*T> ....

Данный макрос выдаст ошибку еслидля типа T не определена операция умножения
argument T request operation T*T....

Здравствуйте, Аноним, Вы писали:

А>Данный макрос выдаст ошибку еслидля типа T не определена операция умножения
А>argument T request operation T*T....

Ок. Перефразирую: как в .NET задать ограничение на наличие в параметре генерика T некоторого статического члена S?

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

H>Здравствуйте, Аноним, Вы писали:

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

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

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

H>В вот это точно не в наш форум.

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

Здравствуйте, Аноним, Вы писали:

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

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

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

H>>>В вот это точно не в наш форум.

H>>Макросы-операторы работают в генериках, а вот обычные обработчики операторов — это статические методы, как-то не слишком ясно как их применять там.

А>macros fun(t:T) request<T*T> ....

А>Данный макрос выдаст ошибку еслидля типа T не определена операция умножения
А>argument T request operation T*T....

Вполне рабочий код:

  class X
  {
    public static @+(_ : X, _ : X) : X
    {
      X()
    }
  }

  module Program
  {
    Test[T](a : T, b : T) : X where T : X
    {
      a + b
    }
  }

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

H>Здравствуйте, Аноним, Вы писали:

А>>Данный макрос выдаст ошибку еслидля типа T не определена операция умножения
А>>argument T request operation T*T....

H>Ок. Перефразирую: как в .NET задать ограничение на наличие в параметре генерика T некоторого статического члена S?

причем тут нет?

С помощью рефлекшен проверять при развороте макроса.
Насколько я знаю макросы не работают в самом нете, а работают при компиляции

Здравствуйте, Аноним, Вы писали:

А>С помощью рефлекшен проверять при развороте макроса.

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

module Program
{
Test[T](a : T, b : T) : Т request(T+T)
{
a + b
}
}
При вызове макроса он поругается не на какую то внутренность например на a+b в макросе, а на сам макрос


Вообще это улучшение вывода ошибок.

Здравствуйте, Аноним, Вы писали:

А> module Program
А> {
А> Test[T](a : T, b : T) : Т request(T+T)
А> {
А> a + b
А> }
А> }
А>При вызове макроса он поругается не на какую то внутренность например на a+b в макросе, а на сам макрос

Что такое request(T+T) ?

Здравствуйте, Аноним, Вы писали:

А> module Program
А> {
А> Test[T](a : T, b : T) : Т request(T+T)
А> {
А> a + b
А> }
А> }
А>При вызове макроса он поругается не на какую то внутренность например на a+b в макросе, а на сам макрос

Ну и код несколько бессмысленнен — у произвольного типа T оператор + не определен. И это не ограничение Немерле, это ограничение .NET.

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

H>Здравствуйте, Аноним, Вы писали:

А>> module Program
А>> {
А>> Test[T](a : T, b : T) : Т request(T+T)
А>> {
А>> a + b
А>> }
А>> }
А>>При вызове макроса он поругается не на какую то внутренность например на a+b в макросе, а на сам макрос

H>Что такое request(T+T) ?

на этапе компиляции делается проверка существования операции T+T и в случае ее не возможности выдается сообщение
"для макроса Test[T](a : T, b : T) : Т требуется операция T+T"

Здравствуйте, Аноним, Вы писали:

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

H>>Здравствуйте, Аноним, Вы писали:

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

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

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

H>>В вот это точно не в наш форум.

А>А зачем компилятору доказывать инвариантность выражений?
А>Тот кто описал операцию, тот и доказывает.

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

Здравствуйте, Аноним, Вы писали:

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

H>>Здравствуйте, Аноним, Вы писали:

А>>> module Program
А>>> {
А>>> Test[T](a : T, b : T) : Т request(T+T)
А>>> {
А>>> a + b
А>>> }
А>>> }
А>>>При вызове макроса он поругается не на какую то внутренность например на a+b в макросе, а на сам макрос

H>>Что такое request(T+T) ?

А>на этапе компиляции делается проверка существования операции T+T и в случае ее не возможности выдается сообщение
А>"для макроса Test[T](a : T, b : T) : Т требуется операция T+T"

Это как бы вообще не макрос — это обычный метод. Ошибка сейчас и так выдается.

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

H>Здравствуйте, Аноним, Вы писали:

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

H>>>Здравствуйте, Аноним, Вы писали:

А>>>> module Program
А>>>> {
А>>>> Test[T](a : T, b : T) : Т request(T+T)
А>>>> {
А>>>> a + b
А>>>> }
А>>>> }
А>>>>При вызове макроса он поругается не на какую то внутренность например на a+b в макросе, а на сам макрос

H>>>Что такое request(T+T) ?

А>>на этапе компиляции делается проверка существования операции T+T и в случае ее не возможности выдается сообщение
А>>"для макроса Test[T](a : T, b : T) : Т требуется операция T+T"

H>Это как бы вообще не макрос — это обычный метод. Ошибка сейчас и так выдается.


где выдается? в указании на макрос или в нутрях его на строчку?