class A<T>
{
public static T add(T left, T right)
{
return left + right;
}
}
Как можно провернуть это на Nemerle ?
P.S.
На мой взгляд нужно было бы в Nemerle починить баг .Net-а и добавить интерфейсы типа IAdd, IMultiply ..., а базовые типы наследовать от них.
Таким образом можно было бы писать:
class A[T] where T : IAdd
{
public static add(left : T, right : T) : T
{
left + right;
}
}
30.01.07 17:50: Перенесено модератором из 'Декларативное программирование' — IT
__>P.S. __>На мой взгляд нужно было бы в Nemerle починить баг .Net-а и добавить интерфейсы типа IAdd, IMultiply ..., а базовые типы наследовать от них.
Возьмите сразу класс типа Num из Хаскелла и его наследников. Здесь
deniok wrote:
> Возьмите сразу класс типа Num из Хаскелла и его наследников. Влад
хвалит.
А хаскеллисты в кафе хаят: Num is such a fat and greedy class
Им кольца и группы подавай.
Здравствуйте, _nn_, Вы писали:
__>Как можно провернуть это на Nemerle ?
Я как-то переписывался с Камилом по этому поводу, он обещал подумать. Но с тех пор так ничего и не сдвинулось. Пришли лишь к выводу, что вряд ли это возможно без поддержки со стороны компилятора.
__>P.S. __>На мой взгляд нужно было бы в Nemerle починить баг .Net-а и добавить интерфейсы типа IAdd, IMultiply ..., а базовые типы наследовать от них. __>Таким образом можно было бы писать: __>
__>class A[T] where T : IAdd
__>{
__> public static add(left : T, right : T) : T
__> {
__> left + right;
__> }
__>}
__>
Хмм. Не совсем тебя понимаю. Ну есть тип int. Ну наследует IAdd, в котором есть метод Add. Такой код я еще понимаю:
public static add(left : T, right : T) : T
{
left.Add(right);
}
В общем тут не с интерфейсами играться надо, а с where кондишнами. Я предлагал банальный вариант:
Здравствуйте, ie, Вы писали:
ie>Здравствуйте, _nn_, Вы писали:
__>>Как можно провернуть это на Nemerle ?
ie>Я как-то переписывался с Камилом по этому поводу, он обещал подумать. Но с тех пор так ничего и не сдвинулось. Пришли лишь к выводу, что вряд ли это возможно без поддержки со стороны компилятора.
__>>P.S. __>>На мой взгляд нужно было бы в Nemerle починить баг .Net-а и добавить интерфейсы типа IAdd, IMultiply ..., а базовые типы наследовать от них. __>>Таким образом можно было бы писать: __>>
__>>class A[T] where T : IAdd
__>>{
__>> public static add(left : T, right : T) : T
__>> {
__>> left + right;
__>> }
__>>}
__>>
ie>Хмм. Не совсем тебя понимаю. Ну есть тип int. Ну наследует IAdd, в котором есть метод Add. Такой код я еще понимаю: ie>
ie> public static add(left : T, right : T) : T
ie> {
ie> left.Add(right);
ie> }
ie>
Имелось ввиду так.
ie>В общем тут не с интерфейсами играться надо, а с where кондишнами. Я предлагал банальный вариант: ie>
ie> class A[T] where T : operator+
ie>
Тоже вариант
Надо только иметь возможность определить возвращаемый тип типа:
class A[T] where T : operator+// default - (T, T) : Tclass B[T] where T : operator+(T, int) : T
Здравствуйте, _nn_, Вы писали:
__>На C# такое не проходит, а хотелось бы. __>
__>class A<T>
__>{
__> public static T add(T left, T right)
__> {
__> return left + right;
__> }
__>}
__>
__>Как можно провернуть это на Nemerle ?
Так точно нельзя. Вместо этого можно объявить интерфейс:
using System.Console;
interface ISum[T]
{
Add(x : T, y : T) : T;
}
class SumInt : ISum[int]
{
public Add(x : int, y : int) : int { x + y }
}
class SumDouble : ISum[double]
{
public Add(x : double, y : double) : double { x + y }
}
public module Program
{
Test[T](sum : ISum[T], x : T, y : T) : void
{
WriteLine(sum.Add(x, y))
}
Main() : void
{
Test(SumInt(), 1, 2);
Test(SumDouble(), 1.1, 2.0);
}
}
Но куда проще использовать функции высшего порядка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>На C# такое не проходит, а хотелось бы. __>>
__>>class A<T>
__>>{
__>> public static T add(T left, T right)
__>> {
__>> return left + right;
__>> }
__>>}
__>>
__>>Как можно провернуть это на Nemerle ?
VD>Так точно нельзя. Вместо этого можно объявить интерфейс: VD>
VD>using System.Console;
VD>interface ISum[T]
VD>{
VD> Add(x : T, y : T) : T;
VD>}
VD>class SumInt : ISum[int]
VD>{
VD> public Add(x : int, y : int) : int { x + y }
VD>}
VD>class SumDouble : ISum[double]
VD>{
VD> public Add(x : double, y : double) : double { x + y }
VD>}
VD>public module Program
VD>{
VD> Test[T](sum : ISum[T], x : T, y : T) : void
VD> {
VD> WriteLine(sum.Add(x, y))
VD> }
VD> Main() : void
VD> {
VD> Test(SumInt(), 1, 2);
VD> Test(SumDouble(), 1.1, 2.0);
VD> }
VD>}
VD>
Это не решение все равно.
Для конкретного варианта может и подойдет, но изяществом и простотой не отличается.
VD>Но куда проще использовать функции высшего порядка.
Макрос который будет это все генерировать ?
А типы ему вручную задавать что ли ?
Здравствуйте, _nn_, Вы писали:
__>Это не решение все равно. __>Для конкретного варианта может и подойдет, но изяществом и простотой не отличается.
Дык как раз в конкретных случаях это решение очень даже подходит. А вот заниматься фигней вроде обобщенных библиотек сложения — это конечно маразм.
VD>>Но куда проще использовать функции высшего порядка. __>Макрос который будет это все генерировать ? __>А типы ему вручную задавать что ли ?
Какие типы? Какие макросы?
Проблема в том, что ты думашь на С++. Вот и проблемы у тебя этого порядка.
В дотнете нет чего-то похожего на классы типов Хаскеля. Так что приделать интерфес извне нельзя.
Оданако в конкретных случаях прекрасно подходят фукнции высшего порядка. Абстрагируй свои алгоритмы с помощью фукнциональных объетов и все будет ОК.
Здравствуйте, ie, Вы писали:
__>>Надо только иметь возможность определить возвращаемый тип типа: __>>
__>>class A[T] where T : operator+// default - (T, T) : T
__>>class B[T] where T : operator+(T, int) : T
__>>
ie>+1, но мне хотя бы дефолтноый случай
И какой IL это должно порождать. К тмоу же такие специализированные операторы — это верх кривизны.
В обще, это мышление на С++. Не более того. В дотнете это не прокатит. Такое только макросами или шаблонами сделать можно. Так как это не полиморфизм, а перегрузка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>Это не решение все равно. __>>Для конкретного варианта может и подойдет, но изяществом и простотой не отличается.
VD>Дык как раз в конкретных случаях это решение очень даже подходит. А вот заниматься фигней вроде обобщенных библиотек сложения — это конечно маразм.
VD>>>Но куда проще использовать функции высшего порядка. __>>Макрос который будет это все генерировать ? __>>А типы ему вручную задавать что ли ?
VD>Какие типы? Какие макросы?
VD>Проблема в том, что ты думашь на С++. Вот и проблемы у тебя этого порядка.
А это здесь не при чем. Проблема с C#, а не с C++ VD>В дотнете нет чего-то похожего на классы типов Хаскеля. Так что приделать интерфес извне нельзя.
В этом и вопрос можно ли добавить такую функциональность через Nemerle ?
VD>Оданако в конкретных случаях прекрасно подходят фукнции высшего порядка. Абстрагируй свои алгоритмы с помощью фукнциональных объетов и все будет ОК. VD>Вот погляди на то как, например, реализуется обобщенная функция сортировки
Здравствуйте, _nn_, Вы писали:
VD>>Проблема в том, что ты думашь на С++. Вот и проблемы у тебя этого порядка. __>А это здесь не при чем. Проблема с C#, а не с C++
Проблема в обрезе мышления. Проблемы можно решать по разному. Можно тексутальными шаблонами, а можно декомпозицией функций. Дотнет не предоставляет первый подход, но позволяет использовать второй.
VD>>В дотнете нет чего-то похожего на классы типов Хаскеля. Так что приделать интерфес извне нельзя. __>В этом и вопрос можно ли добавить такую функциональность через Nemerle ?
Систему типов дотнета изменить невозможно ни в каком языке. Можно толко попытаться содать внешнюю видимость. Примерно это делают шаблоны в С++. Но такое решение противоречит самому духу дотнета. Ведь написанные с использованием шаблонов функции будут доступны только в виде исходников, так как факрически для любого сочетания типов компилятору прийдется создавать перегруженный вариант фукнции (тупо дублировать код). Это решение принципиально не совместимо с динамикой присущей дотенту.
Красивым решением было бы использовать идею "внешних интерфейсов" которые в Хаскеле были называны классами типов. Но боюсь, что без поддержки со стороны рантайма это невозможно. Хотя тут по уму нужно проводить отдельное исследование.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
VD>>>Проблема в том, что ты думашь на С++. Вот и проблемы у тебя этого порядка. __>>А это здесь не при чем. Проблема с C#, а не с C++
VD>Проблема в обрезе мышления. Проблемы можно решать по разному. Можно тексутальными шаблонами, а можно декомпозицией функций. Дотнет не предоставляет первый подход, но позволяет использовать второй.
Я не отрицаю, что можно решить эту задачу и другими способами. но хочется чтобы и первый вариант был возможен.
.
VD>Красивым решением было бы использовать идею "внешних интерфейсов" которые в Хаскеле были называны классами типов. Но боюсь, что без поддержки со стороны рантайма это невозможно. Хотя тут по уму нужно проводить отдельное исследование.
Без поддержки со стороны рантайма можно, без поддержки компилятора -- нет. Вариант на Java: JavaGI: Generalized Interfaces for Java. Макросов Nemerle на это не хватает.
Здравствуйте, Alexey Romanov, Вы писали:
AR>Без поддержки со стороны рантайма можно, без поддержки компилятора -- нет. Вариант на Java: JavaGI: Generalized Interfaces for Java. Макросов Nemerle на это не хватает.
Надо изучать. Боюсь, все же, что это решение будет конфликтовать с динамикой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexey Romanov, Вы писали:
AR>Без поддержки со стороны рантайма можно, без поддержки компилятора -- нет. Вариант на Java: JavaGI: Generalized Interfaces for Java. Макросов Nemerle на это не хватает.
