Я в одном согласен: неуважительное отношение одних участников к другим — это плохо, и чем меньше будет этой фигни, тем лучше для коммьюнити. Давай замнём этот оффтоп?
Поддерживаю!
Чем больше на этом форуме будет аргументов и чем меньше флэйма, тем лучше всем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, igna, Вы писали:
I>Здесь тоже статический полиморфизм?:
I>
I>template <std::size_t N>
I>class array_of_ints {
I> int value[N];
..
I> array_of_ints& operator+=(int v)
I> {
I> for (int i = 0; i < N; ++i)
I> value[i] += v;
I> return *this;
I> }
I>
В некотором смысле да, так как по сути array_of_ints с разыми значениями параметров типа являются разными типами. Так что "+=" будет работать над разными типами.
Другое дело, что использование констатн в качестве параметров типов довольно бессмысленно на мой взгляд. И в следствии этого данный код тоже бессмысленнен.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Z>Если в Nemerle функции — first-class- тогда и у него есть.
Несомненно повторить приведенное тобой извращение можно. Есть тольк две проблемы:
1. curry в твоем примере полиморфна (так как допускает применение разных функций), что приводит к необходимости кроме комбинаторов воспользоваться еще и дженериками.
2. Операторы в немерле нельзя напрямую использовать как функцию (насколько я понял, хотя может и ошибаюсь).
Исходя из этих замечаний нужно ввести две функции обертки для операторов (
// Функции-обертки над операторами ">" и "+".
def GreaterThan(x, y) { x > y }
def Add(x : int, y) { x + y }
// Curry полиморфна, что в Немерле нужно указывать явно. По умолчанию будет производиться
// вывод типов который выведет тип фунции для первого применения и сочтет второе
// (полиморфное) применение ошибкой.
// T - тип параметров.
// R - тип возвращаемого значения функции.
// f - это фукнция имеющая тип "T * T -> R". Звездочкой разделяются параметры, а после "->"
// идет описание возвращаемого значения функции.
def Curry[T, R](f : T * T -> R) { fun(x) { fun(y) { f(x, y); } } }
// Остальное как в примере на Схеме.
def Positive(value) { Curry(GreaterThan)(0)(value) }
def Add42(value) { Curry(Add)(42)(value) }
// Тесты:
System.Console.WriteLine(Positive(2));
System.Console.WriteLine(Positive(-1));
System.Console.WriteLine(Add42(2));
System.Console.WriteLine(Add42(-1));
Результат выводимый на консоль:
False
True
44
41
Единственно, что... за такой код в реальных проектах я бы потрывал кое чего, так как он неоправданно сложен.
Вот так:
def Positive(value) { value > 0 }
def Add42(value) { value + 42 }
было бы куда проще.
Так вот это все к делу, как я понимаю, не относится.
Как я понимаю карринг — это сопсобность создавать комбинаторы (аналогичные приведенным в примерах) по месту, просто передавая в качестве параметров одной функции другую частично примененную.
В этом смысле карринга не в Немерле, не Лиспах нет. Но несомннено, что это не является припятствием для создания комбинаторов.
Ну, и главно. Это все соревнования в длинне пенисов. Ведь если действительно потребуется упрощенное создание комбинаторов, то нет проблем написать макрос который решит проблему наиболее чистым образом.
Z>Странно, но я прочитав "Grokking Nemerle" — так и не смог грокнуть насколько функции first-class, а насколько это все макросы Просветите меня.
Для этого не нжно було чить "Grokking". Об этом говорится во введении. Собственно я уже продемонстрировал применение функционалов. Но можно описать это дело проще.
Функция может быть передена в качестве параметра или возвращена в качестве возвращаемого значения. Кроме того функция может быть частью кортежа (tuple-а), класса, структуры или варинта.
Описывается тип функции так... Параметры функции перечисляются через символ "*". Возвращаемое значение отделяется строкой "->". Собственно символ "*" используется и при описании кортежей. Более того, в Немерле кортежи взаимозаменяемы со списком параметров, так что описание функции можно представить как описание двух кортежей разделенного строкой "->".
Примеры:
// Переменная позволяющая хранить ссылку на функцию принимающую
// два параметра типа инт и возвращающая булево значение.
mutable f1 : int * int -> bool;
// Функция принимающая в качестве параметра другую функцию (int * int -> bool), два значения типа int и возвращающая инвертированное значение вызова переданной фукнции.
def Func(f : int * int -> bool, x : int, y : int) : bool
{
!f(x, y)
}
// Используя вывод типов можно записать эту же функцию так:
def Func(f : int * int -> bool, x, y)
{
!f(x, y)
}
// или так:
def Func(f, x : int, y : int) : bool
{
!f(x, y)
}
// или даже так:
def Func(f, x, y)
{
!f(x, y)
}
При этом функция не получается полиморфной. Все типы включая тип функционала вычисляются исходя из первого применения. Точнее используется алгоритм накладвания ограничений. Например, в таком коде:
using System.Console;
def GreaterThan(x, y) { x > y }
def Func(f, x, y)
{
!f(x, y)
}
WriteLine(Func(GreaterThan, 3, 5));
все типы прекрасно будут выведены.
Выведение типов доступно только для вложенных функций и переменных. Все типы полей и методов должны задаваться явно.
Язык позволяет как объявлять вложенные фукнции захватывающие контекст как лямбды, так и реальные лямбды. Локальные фукнции описываются так:
def LocalFunc(param1, param2) { /* тело */ }
при этом можно использовать локальный контест:
mutable x = 1;
def AddX(y) { x + y }
WriteLine(AddX(4));
x++;
WriteLine(AddX(4));
вывод:
5
6
Типы параметров и возвращаемых значений можно описывать по необходимости. Например, если компилятор выдал не очень внятное сообщение об ошибке, то лучше уточнить типы. Это приведет к более ясному сообщению.
Лямбды в Немерле описываются так:
fun(x, y){ /*тело фукнции*/ }
Для лямбд тоже доступн вывод типов и захват локального контекста.
Есть макрос позволяющий записывать безымянные фукнции с одним параметром в стиле Лиспа:
lambda параметр -> выражение
но этот макрос находится в отдельном пространстве имен Nemerle.Extensions. Да и смысла особого его применять нет.
Лучше создать макрос в стиле C# 3.0.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Кстати, мне ужасно не нравится его название. Давай обсудим это
сложный вопрос — а как оно вообще произносится
насколько я понял, есть несколько вариантов. Сами поляки произносят как Немерл(е), но есть еще англизированный вариант. Про него пишут "it rhymes with M-Perl"
Здравствуйте, VladD2, Вы писали:
VD>Другое дело, что использование констатн в качестве параметров типов довольно бессмысленно на мой взгляд. И в следствии этого данный код тоже бессмысленнен.
На текущем уровне развития оптимизаторов это бывает весьма полезно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
> Получается, что тебя радует просто возражение, а не реальные аргументы.
Порекомендую лучше посмотреть на твой собственный стиль возражений:
BLA>Причем макросы в немерле — это вообще говоря антифункциональная вещь.
Во как? Прэлесно!
BLA> То есть они не first-class values,
Ну, и что? Кому-то это мешает? Мне — нет.
BLA> их нельзя передавать куда-то или возвращать, хотя со стороны они выглядят как функции. Удачи
маленьким любителям функциональных языков.
Действительно удачи любителям функциональных языков. А лично мне это все на фиг не упало. Внутри макроса
я без проблем могу использовать любой стиль. Сами макросы я опять же могу использовать из любого стиля.
Обернуть макрос в фнкцию проблемы не составляет.
Т.е. ты даже не позволяешь себе принять во внимание тот факт, что для кого-то некоторые вещи могут быть важными. Тебе не важно -- и все, после этого хоть потоп.
Подобным образом со мной общались, когда я пытался выяснить, есть ли потенциальные проблемы с синтаксическими макросами в Nemerle. Так что, как я вижу, ничего не изменилось.
> Вынесением суждений без наличия информации, ты банально выносишь > недоверие чужому мнению. Прчем аргументировать это недоверие ты не > хочешь. Тебе достаточно того, что "ты не веришь". Так вот это не > конструктивно и в общем-то оскорбительно.
Оскорбительно? Ой какие мы нежные!
Ты попобуй поискать мои возражения в стиле "не верю" в ответах Vermicious Knid или Oyster-у. Поскольку люди разработали себе репутацию говорящих по существу. А вот у тебя подобной репутации в моих глазах нет. Уж извини. Слишком часто я убеждался, что принимать твои слова на веру просто так нельзя. Даже в этой теме ты не корректно высказался по поводу OCaml-а. Недавно ты еще утверждал, что GC рвет всех и вся, хотя даже простые тесты это опровергают. Можно еще вспомнить твой рассказ о вреде преждевременных оптимизаций... Так что в твоем случае срабатывает принцип "'поверьте мне как министру' не верю именно как министру" ((C) Жванецкий) срабатывает на 100%.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
VD>>Другое дело, что использование констатн в качестве параметров типов довольно бессмысленно на мой взгляд. И в следствии этого данный код тоже бессмысленнен. WH>На текущем уровне развития оптимизаторов это бывает весьма полезно.
Ну, оптимизаторы, на мой взгляд, должны работать без костылей. Но все же интересно о чем ты говоришь. Поясни, плиз.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, оптимизаторы, на мой взгляд, должны работать без костылей. Но все же интересно о чем ты говоришь. Поясни, плиз.
Например в STL есть такая штука как std::valarray.
Эту штуку использовали в boost::math::quaternion вот таким образом:
Тут создаются два valarray которые внутри выделяют динамическую память. Такм образом идет обращение к динамической, создаются обработчики исключений плюс у оптимизитора связаны руки.
Если сделать так:
То никакой динамической памяти не понадобится. Болие того оптимизатор может это все разложить по регистрам.
Эта замена при компиляции на VC++8 разагнала boost::math::quaternion в 15 раз.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Другое дело, что использование констатн в качестве параметров типов довольно бессмысленно на мой взгляд.
Foreword
by Scott Meyers
. . .
... a column by John Barton and Lee Nackman in the
January 1995 C++ Report that described how templates could be used to perform typesafe dimensional
analysis with zero runtime cost. This was a problem I'd spent some time on myself, and I knew that many
had searched for a solution, but none had succeeded. Barton and Nackman's revolutionary approach made
me realize that templates were good for a lot more than just creating containers of T.
As an example of their design, consider this code for multiplying two physical quantities of arbitrary
dimensional type:
template<int m1, int l1, int t1, int m2, int l2, int t2>
Physical<m1+m2, l1+l2, t1+t2> operator*(Physical<m1, l1, t1> lhs,
Physical<m2, l2, t2> rhs)
{
return Physical<m1+m2, l1+l2, t1+t2>::unit*lhs.value()*rhs.value();
}
Even without the context of the column to clarify this code, it's clear that this function template takes six
parameters, none of which represents a type!
. . .
(Modern C++ Design: Generic Programming and Design Patterns Applied, Andrei Alexandrescu)
Здравствуйте, igna, Вы писали:
VD>>Другое дело, что использование констатн в качестве параметров типов довольно бессмысленно на мой взгляд.
I>
I>by Scott Meyers
I>. . .
I>
I>template<int m1, int l1, int t1, int m2, int l2, int t2>
I>Physical<m1+m2, l1+l2, t1+t2> operator*(Physical<m1, l1, t1> lhs,
I> Physical<m2, l2, t2> rhs)
I>{
I> return Physical<m1+m2, l1+l2, t1+t2>::unit*lhs.value()*rhs.value();
I>}
I>
Эту химию настклько трудно понять, что я бы бил линейкой по рукам всем тем кто пытается писать код так. К тому же не трудно придставить диагностику ошибок выдаваемую компилятором. Нормальная система типов в хорошо расширяемом языке не должна требовать каких-то подпорок.
Например, в Немерле можно делать операторы макросами. При этом во время компиляции доступны любые проверки типов. То есть мы можем контролировать любые аспекты поведения оператора явно, используя те же возможности языка, что и в прикладных программах. По-моему, это намного более простой, понятный и гибкий подход.
Ну, а вот такие примеры — это восхищение тем, что проблема решается хоть как-то хотя совершенно не очевидными средствами.
Мне вот интересно если Мэерс не описал этот прикол, то сколько бы программистов доперли до него? Боюсь, что еденицы.
И еще один вопрос. Склько программистов используют подобные приколы в своем коде?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>... Нормальная система типов в хорошо расширяемом языке не должна требовать каких-то подпорок.
Как можно ли реализовать размерности на C#? А на Nemerle?
Чтобы при умножении типа размерности кг^n1*м^m1*сек^l1 на тип размерности кг^n2*м^m2*сек^l2 получался тип размерности кг^(n1+n2)*м^(m1+m2)*сек^(l1+l2).
Здравствуйте, igna, Вы писали:
I>Как можно ли реализовать размерности на C#? А на Nemerle?
Я не привык когда мне отвечают вопросом на вопрос. Так что если хочешь получить ответ на свои вопросы, то потрудись сначала ответить на чужие вопросы заданные ранее. Глядишь и желание отвечать отпадет. Напоминаю вопросы:
Мне вот интересно если Мэерс не описал этот прикол, то сколько бы программистов доперли до него?
Склько программистов используют подобные приколы в своем коде?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, igna, Вы писали:
I>Как можно ли реализовать размерности на C#? А на Nemerle?
Если такие же как на C++, т.е. compile-time, то на C# никак. На Nemerle это возможно, но слишком сложно чтобы этим заниматься без крайней необходимости. Проблема тут скорее в .NET, а не в Nemerle. Идеология дженериков слишком далека от идеологии шаблонов C++, т.е. они тут совершенно не помогут и придется придумывать что-то очень хитрое и не побоюсь этого слова извращенное.
Макросы Nemerle в общем-то и не проектировались как замена шаблонам, это нечто совершенно другое и решает зачастую совсем другие задачи. Вот реализовать compile-time движок шаблонов а-ля C++ это задача для макросов, а "реализовать размерности" скорее всего нет. Т.е. макросы это в первую очередь для расширения языка, а не для написания библиотек/програм.
А вообще ни C#, ни Nemerle не конкуренты C++ в том классе задач, где нужны подобные возможности. Ни "zero runtime cost", ни "производительность любой ценой", ни тем более "optimize prematurely!" пожалуй не является девизом ни первого, ни второго языка.
Из "новых" языков пожалуй только D сможет соперничать с C++ в этом вопросе. Сейчас правда в D только-только появилась такая фича как implicit template instantiation и она пока еще слишком сырая. Конечно и сейчас реализовать аналогичную функциональность можно, но придется использовать статические шаблонные функции вместо операторов и есть пара других нюансов. А вот когда она станет полностью юзабельной(как минимум к релизу 1.0), то C++ останется в пролете. Вот как это будет примерно выглядеть:
import std.stdio;
abstract class aPhysical {}
class physical(int M, int L, int T) : aPhysical
{
enum { M = M, L = L, T = T }
public double value;
public this(double value)
{
this.value = value;
}
template opMulT(P) { alias physical!(M+P.M, L+P.L, T+P.T) opMulT; }
public template opMul(P : aPhysical)
{
opMulT!(P) opMul(P rhs)
{
return new opMulT!(P)(value * rhs.value);
}
}
override char[] toString()
{
return std.string.format("%.2f kg^%d * m^%d * sec^%d", value, M, L, T);
}
}
void main()
{
auto value1 = new physical!(1,1,1)(2.0);
auto value2 = new physical!(3,2,1)(3.0);
auto result = value1 * value2;
// 6.00 kg^4 * m^3 * sec^2
writef("%s\n", result.toString());
}
Еще есть язык Fortress, пока только в виде спецификации. Вроде бы там подобные типы планируется поддерживать на уровне языка, так как язык ориентирован на разного рода "научные" вычисления, правда по поводу compile-time не уверен.
у меня была реализована подобная система. Сейчас работаю над следующей версией, в которой будут устранены некоторые недостатки текущей версии (например, типизированные константы для работы с системами единиц без взаимнооднозначного соответствия).
[/offtopic]
Здравствуйте, eao197, Вы писали:
BLA>>Причем макросы в немерле — это вообще говоря антифункциональная вещь.
E>Во как? Прэлесно!
а мне тоже интересно, почему это вдруг "антифункциональная вещь"
BLA>> их нельзя передавать куда-то или возвращать, хотя со стороны они выглядят как функции. Удачи E>маленьким любителям функциональных языков.
Ну а в Лиспе вообще всё "выглядит как функция". И что, Лисп — это антифункциональный язык?
и вообще, зачем их куда-то передавать или возвращать?
E>Подобным образом со мной общались, когда я пытался выяснить, есть ли потенциальные проблемы с синтаксическими макросами в Nemerle. Так что, как я вижу, ничего не изменилось.
твои проблемы — надуманные. Даже если они и станут актуальными для кого-то, то эти проблемы решаются за пару дней работы над компилятором, с помощью введения алиасов или полностью квалифицированных имен для макросов (если их еще нет)
Если тебя это так сильно заботит, почему бы не спросить на форуме разработчиков?
E>Можно еще вспомнить твой рассказ о вреде преждевременных оптимизаций...
Здравствуйте, VladD2, Вы писали:
VD>Мне вот интересно если Мэерс не описал этот прикол, то сколько бы программистов доперли до него?
VD>Склько программистов используют подобные приколы в своем коде?
И еще актуальнее — сколько программистов сможет понять, как это работает и вообще зачем это нужно, без недельного копания в литературе?
