Здравствуйте, VladD2, Вы писали:
VD>Вообще-то там на графие жабоскрип запихали в один квадрат с шарпом и жабой,
Так более тормозного квадрата там уже не было.
Re[7]: C# for Systems Programming
От:
Аноним
Дата:
07.01.14 10:13
Оценка:
Здравствуйте, VladD2, Вы писали:
DM>>Давно проверял? DM>>Эта проблема была очень давно, и мне казалось, ее уже давно исправили. VD>Вообще не проверял. Слышал год назад от тех кто плотно использует Скалу. Уверен, что ничего не изменится пока они for на макросах не перепишут. Но они вроде как пока только в тестовом режиме идут. Или я отстал от жизни?
только вчера лазил посмотреть во что превращается простой for по списку и массиву. Там полиморфизм, специфичный для каждого контейнера.
Вот такой код
val A = List(1 to 10 : _*)
A foreach println
превращается в
@inline override final
def foreach[B](f: A => B) {
var these = this
while (!these.isEmpty) {
f(these.head)
these = these.tail
}
}
а для массивов в
override /*IterableLike*/
def foreach[U](f: A => U): Unit = {
var i = 0
val len = length
while (i < len) { f(this(i)); i += 1 }
}
Ни в одном, ни во втором случае я не вижу проблем для оптимизатора.
Здравствуйте, Аноним, Вы писали:
А>Ни в одном, ни во втором случае я не вижу проблем для оптимизатора.
Я очень рад за тебя. Жаль только что оптимизатором работаешь не ты, потому что люди испльзующие Скалу на практике говорят о замедлении в несколько раз (точную цифру не помню, то ли 5, то ли 10).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
I>>Какой будет тип у r? Почему функция должна возвращать какой то другой тип ?
A>То что тип аргумента int и тип результата int — это понятно, компилятор это знает. Но какой тип должен быть у f?
Func<> разумеется. Мулька в том, что C# не умеет вот такой тип Func<void>, вместо этого есть Action, что совершенно идиотская идея и причина в ограничениях CLR. Теоретически, можно на уровне языка устранить эту разницу, но в C# этого не стали делать, ибо основная идея C# это прозрачность и принцип наименьшего удивления.
Дальше вот такая хрень — Func<int, int> нельзя присвоить Action, итого — получается отстой. Все методы приходится дублировать для Action или требовать писать необязательный return.
Итого — одна хрень в наличии. Вторая хрень:
Func<M<X>,M<Y>> Lift<M, X, Y>(Func<X,Y> f) where ля ля ля {
return (mx) => mx.Bind(x => M.Return(f(x)));
}
Вот такое надо писать для каждого типа M + расставлять подсказки компилятору
Все вместе это означает следующее — каждый раз, когда возникат необходимость в высокоуровневых средтсвах, надо ждать модификации компилятора, это было c
1 yield
2 async/await
3 Nullable
и тд
Здравствуйте, Ikemefula, Вы писали:
A>>То что тип аргумента int и тип результата int — это понятно, компилятор это знает. Но какой тип должен быть у f? I>Func<> разумеется.
#1
Вопрос на засыпку: какой в таком случае должен быть тип у f, если
var f = (int x1, int x2, ... int x20) => x1 + x2 + ... + x20;
#2
System.Func<T, TResult> ― это просто тип делегата. Он ничем не лучше любого другого типа делегата с той же сигнатурой, например:
delegate TResult Func<T, TResult>(T arg);
delegate TResult МамаМылаРаму<T, TResult>(T arg);
Func<int, int> f1 = x => x * 2;
МамаМылаРаму<int, int> f2 = x => x * 2;
// типы разные
I>Мулька в том, что C# не умеет вот такой тип Func<void>, вместо этого есть Action, что совершенно идиотская идея и причина в ограничениях CLR. Теоретически, можно на уровне языка устранить эту разницу, но в C# этого не стали делать, ибо основная идея C# это прозрачность и принцип наименьшего удивления.
#3
Не знаю ни про какие ограничения CLR. Хочешь тип делегата без параметров и возвращаемого значения и чтобы назывался Func?
delegate void Func();
Func f = Console.WriteLine;
I>Дальше вот такая хрень — Func<int, int> нельзя присвоить Action, итого — получается отстой. Все методы приходится дублировать для Action или требовать писать необязательный return.
Так между ними ничего общего. Как их можно присваивать?
delegate void AAA();
AAA a = Console.WriteLine;
a = x => x * 2; // это должно быть разрешено?
// как потом вызывать?
a(); // так
a(1); // или так?
#4
var f = (int x) => x * 2;
Почему лямбда должна стать именно делегатом? Она с таким же успехом может стать выражением:
Здравствуйте, alexzz, Вы писали:
A>#1 A>Вопрос на засыпку: какой в таком случае должен быть тип у f, если A>
A>var f = (int x1, int x2, ... int x20) => x1 + x2 + ... + x20;
A>
Аналогичные рассуждения, выводится чз Func и x1 + x2 + ... + x20
A>#2 A>System.Func<T, TResult> ― это просто тип делегата. Он ничем не лучше любого другого типа делегата с той же сигнатурой, например: A>
А в Киеве дядька.
A>#3
A>Не знаю ни про какие ограничения CLR.
Это, похоже и есть основная причина. Щас это устраним - void на самом деле никакой не тип, а прямое указание, какой код будет сгенерирован, то есть, для void нет никакого типа или аналога типа.
Отсюда ясно, что не-тип нельзя использовать как тип.
>Хочешь тип делегата без параметров и возвращаемого значения и чтобы назывался Func?
Я хочу
1. параметризовать Func и любой дженерик с помощью void
2. объявить переменную с типом void
Допустим C# убог - сделай это в IL, там нет ограничений раз ты про них не знаешь :)))
Как только у тебя будет это готово, приходи :)) дам тебе 100(сто) американских долларов одной купюрой. :)))
I>>Дальше вот такая хрень - Func<int, int> нельзя присвоить Action, итого - получается отстой. Все методы приходится дублировать для Action или требовать писать необязательный return.
A>Так между ними ничего общего. Как их можно присваивать?
Очень легко - если void сделать типом, то внезапно окажется, что можно генерировать одинаковый код и можно Func<int, int> использовать вместо Func<int, void>
А отсюда ясно, что костыль Action<T> не нужен или его можно сделать совместимым с Func<T, void> по присваиванию
A>[c#]
A>delegate void AAA();
A>AAA a = Console.WriteLine;
A>a = x => x * 2; // это должно быть разрешено?
A>// как потом вызывать?
A>a(); // так
A>a(1); // или так?
A>
Ни то ни другое.
x => x * 2 это, если x будет int, Func<int, int>, соответсвенно его можно было бы использовать вместо Action<int> или Func<int, void>
A>#4 A>
A>var f = (int x) => x * 2;
A>
A>Почему лямбда должна стать именно делегатом? Она с таким же успехом может стать выражением:
Мы говорим не о том, кто кому должен, а про варианты дизайна языка. Это понятно ? Отсюда правильно использовать сослагательное наклонение.
Использование синтаксиса лямбды для экспрешнов было плохой идеей. Первое это функция, второе это цитирование.
Лямбда-делегат и лямбда-экспрешн это две большие разницы — это пол-беды. Всё гораздо хуже
вот это компилируется
Func<int> a = () => while(true) return 1;
а вот это — нет
Expression<Func<int>> a = () => while(true) return 1;
Даже в текущем дизайне, по принципу меньшего удивления стоило бы сделать лямбду именно функцией, ибо экспрешны не поддерживают полный синтаксис в лямбдах.
Т.е. экспрешны это такой костылёк. Для чего его ввели — для того, что бы умельцы не написали сотню ни с чем не совместимых Linq- и прочих провайдеров.
Такого делегата Func<...> с 21 параметром не существует.
A>>#2 A>>System.Func<T, TResult> ― это просто тип делегата. Он ничем не лучше любого другого типа делегата с той же сигнатурой, например: A>>[c#] I>А в Киеве дядька.
Ты почему-то привязался именно к группе типов делегатов System.Func. Но Func — это же не какой-то особенный тип делегатов. Почему компилятор должен приводить лямдбу именно одному из типов System.Func, а не к любому другому с подходящей сигнатурой?
I>Мы говорим не о том, кто кому должен, а про варианты дизайна языка. Это понятно ? Отсюда правильно использовать сослагательное наклонение.
Теперь понятно. Я думал, ты серьёзно, а оказалось, фантазируешь.
Здравствуйте, alexzz, Вы писали:
I>>Аналогичные рассуждения, выводится чз Func и x1 + x2 + ... + x20
A>Такого делегата Func<...> с 21 параметром не существует.
Это принципиальная проблема ?
A>>>#2 A>>>System.Func<T, TResult> ― это просто тип делегата. Он ничем не лучше любого другого типа делегата с той же сигнатурой, например: A>>>[c#] I>>А в Киеве дядька.
A>Ты почему-то привязался именно к группе типов делегатов System.Func. Но Func — это же не какой-то особенный тип делегатов. Почему компилятор должен приводить лямдбу именно одному из типов System.Func, а не к любому другому с подходящей сигнатурой?
Именно так.
I>>Мы говорим не о том, кто кому должен, а про варианты дизайна языка. Это понятно ? Отсюда правильно использовать сослагательное наклонение. A>Теперь понятно. Я думал, ты серьёзно, а оказалось, фантазируешь.
Ты не отвлекайся, торопись всё разоблачить и опровергнуть
Здравствуйте, Ikemefula, Вы писали:
I>>>Аналогичные рассуждения, выводится чз Func и x1 + x2 + ... + x20 A>>Такого делегата Func<...> с 21 параметром не существует. I>Это принципиальная проблема ?
Три:
1. Компилятор не будет угадывать тип делегата, к которому нужно привести лямбду. Может и иногда делает, но в данном случае не будет.
2. Если бы стал, такого типа делегата всё равно нет.
3. Если бы компилятор придумал новый подходящий тип делегата, ты бы мог пользоваться полученным экземпляром только локально, так же как экземплярами анонимных типов.
Пока ты кардинально не перепишешь спецификацию в нескольких местах и не напишешь свой компилятор, это принципиальные проблемы.
A>>Ты почему-то привязался именно к группе типов делегатов System.Func. Но Func — это же не какой-то особенный тип делегатов. Почему компилятор должен приводить лямдбу именно одному из типов System.Func, а не к любому другому с подходящей сигнатурой? I>Именно так.
Что именно так? Я тупой, не понимаю ответа.
I>>>Мы говорим не о том, кто кому должен, а про варианты дизайна языка. Это понятно ? Отсюда правильно использовать сослагательное наклонение. A>>Теперь понятно. Я думал, ты серьёзно, а оказалось, фантазируешь. I>Ты не отвлекайся, торопись всё разоблачить и опровергнуть
Ты хочешь, чтобы компилятор или рантайм сделали что-то, что они делать не будут. Хоть прыгай с бубном, хоть свечку ставь — не будут. Что мне тут опровергать или разоблачать?
Здравствуйте, alexzz, Вы писали:
A>Три: A>1. Компилятор не будет угадывать тип делегата, к которому нужно привести лямбду. Может и иногда делает, но в данном случае не будет.
Спасибо, капитан — развитие С# уже давно пошло по другому пути
A>2. Если бы стал, такого типа делегата всё равно нет.
Надо полагать "если бы", то были бы принципиальные сложности ввести такой тип предопределенным или генеренным компилером ?
Обосновать можешь ?
A>3. Если бы компилятор придумал новый подходящий тип делегата, ты бы мог пользоваться полученным экземпляром только локально, так же как экземплярами анонимных типов.
Если делегаты совместимы по присваиванию, как я показал, то нет никаких проблем
То же самое с анонимными типами — их специально сделали такими вот корявыми. Если, скажем, сделать реализацию интерфейсов в анонимных классах, то уже большая часть проблем снимается.
A>Пока ты кардинально не перепишешь спецификацию в нескольких местах и не напишешь свой компилятор, это принципиальные проблемы.
Ужос ! В других язык сделали,а в C# — "нивазможна, патамушта это нивазможна ваапще"
A>>>Ты почему-то привязался именно к группе типов делегатов System.Func. Но Func — это же не какой-то особенный тип делегатов. Почему компилятор должен приводить лямдбу именно одному из типов System.Func, а не к любому другому с подходящей сигнатурой? I>>Именно так.
A>Что именно так? Я тупой, не понимаю ответа.
Если делегаты совместимы по присваиванию, то не ясно, зачем тебе какой то другой тип
A>>>Теперь понятно. Я думал, ты серьёзно, а оказалось, фантазируешь. I>>Ты не отвлекайся, торопись всё разоблачить и опровергнуть
A>Ты хочешь, чтобы компилятор или рантайм сделали что-то, что они делать не будут. Хоть прыгай с бубном, хоть свечку ставь — не будут. Что мне тут опровергать или разоблачать?
Чего они не будут делать это я сам тебе рассказал. Ты поначалу говорил что никаких проблем-ограничений нет.
Разговор начался с того, что я показал, какая из фич в C# сильно ограничивает возможности разработчика.
Неразрешимых проблем нет, но кодить в сложных случаях придется намного больше, при чем местами получишь комбинаторный взрыв и никуда от этого не денешься.
Здравствуйте, Ikemefula, Вы писали:
I>Если делегаты совместимы по присваиванию, как я показал, то нет никаких проблем
Но делегаты разных типов не совместимы по присваиванию, даже если сигнатуры одинаковые.
I>Если делегаты совместимы по присваиванию, то не ясно, зачем тебе какой то другой тип
Делегаты разных типов не совместимы по присваиванию.
A>>Ты хочешь, чтобы компилятор или рантайм сделали что-то, что они делать не будут. Хоть прыгай с бубном, хоть свечку ставь — не будут. Что мне тут опровергать или разоблачать? I>Чего они не будут делать это я сам тебе рассказал. Ты поначалу говорил что никаких проблем-ограничений нет.
Это был кто-то другой.
I>Разговор начался с того, что я показал, какая из фич в C# сильно ограничивает возможности разработчика.
Наш разговор начался, когда ты сказал, что у c# хилый вывод типов, а я спросил, какой же тип должен вывести компилятор для f
Здравствуйте, alexzz, Вы писали:
I>>Если делегаты совместимы по присваиванию, как я показал, то нет никаких проблем A>Но делегаты разных типов не совместимы по присваиванию, даже если сигнатуры одинаковые.
Я в курсе, принципиальных ограничений для этого нет, это искусственное ограничение "мы решили вот так"
I>>Если делегаты совместимы по присваиванию, то не ясно, зачем тебе какой то другой тип A>Делегаты разных типов не совместимы по присваиванию.
Спасибо, капитан, Func<string> нельзя присвоить в Func<int>. А если ты про Action и Func<int>, то проблема в CLR. Все остальные случаи это искусственные ограничения.
A>>>Ты хочешь, чтобы компилятор или рантайм сделали что-то, что они делать не будут. Хоть прыгай с бубном, хоть свечку ставь — не будут. Что мне тут опровергать или разоблачать? I>>Чего они не будут делать это я сам тебе рассказал. Ты поначалу говорил что никаких проблем-ограничений нет.
A>Это был кто-то другой.
Значит ктото с твоего аккаунта пишет
I>>Разговор начался с того, что я показал, какая из фич в C# сильно ограничивает возможности разработчика.
A>Наш разговор начался, когда ты сказал, что у c# хилый вывод типов, а я спросил, какой же тип должен вывести компилятор для f A>
