N>Вопрос 1: почему '(' <method_parameters> ')' нельзя пропускать, как в C#?
Такой синтаксис. Но откровенно говоря fun на сегодня исползуется очень редко.
Лично я его использую тольк если у лямбды тело должно быть блоком.
А так удобнее пользоваться синтаксисом C# 3.0 или вообще частичным применением функций/операторов:
using System;
using System.Console;
using Nemerle.Utility;
def f = WriteLine : string -> void;
f("Вызов фукнции через ссылку");
def f = WriteLine(_);
f("Частичное применение функции");
def f = WriteLine("Еще однин вариант - '{0}'", _);
f("частичного применения функции");
def formatFromOuterContext = "{0} с замыканием на внешний контекст!";
def f = WriteLine(formatFromOuterContext, _);
f("Частичное применение функции");
def lst = [1, 2, 4, 6, 9];
mutable sum0 = 0;
lst.Iter(x => sum0 += x); // лямбда с одним параметром (и замыканием на внешюю переменную)
WriteLine($"sum0 = $sum0");
def lst = [1, 2, 4, 6, 9];
def sum1 = lst.Fold(0, (x, y) => x + y); // лямбда с двумя параметрами
WriteLine($"sum1 = $sum1");
def lst = [1, 2, 4, 6, 9];
def sum2 = lst.Fold(0, _ + _); // частичное применение оператора +
WriteLine($"sum2 = $sum2");
def lst = [1, 2, 4, 6, 9];
def lst = lst.Map(_.ToString()); // частичное применение метода
def sum3 = lst.Fold("", _ + _); // частичное применение оператора +
WriteLine($"sum3 = '$sum3'");
N>Вопрос 2: как юзать <method_type_parameters> в этом контексте?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
N>Вопрос 1: почему '(' <method_parameters> ')' нельзя пропускать, как в C#?
Из-за того что типы идут после параметров — читабельность получается никакая.
Здравствуйте, GlebZ, Вы писали:
N>>Вопрос 1: почему '(' <method_parameters> ')' нельзя пропускать, как в C#? GZ>Из-за того что типы идут после параметров — читабельность получается никакая. GZ>
GZ> fun a:int, b:int :double{ a+b }
GZ>
Я имел в виду не такой вариант, а то что скобки (вместе с содержащимися в них параметрами!) в C# можно опускать, если ни один из параметров не используется внутри анонимного блока. В таком случае совместимость типов проверяется только по возвращаемому значению.
Здравствуйте, nikov, Вы писали:
N>Я имел в виду не такой вариант, а то что скобки (вместе с содержащимися в них параметрами!) в C# можно опускать, если ни один из параметров не используется внутри анонимного блока. В таком случае совместимость типов проверяется только по возвращаемому значению.
В немерле нельзя пропускать список параметров, но можно вместо неиспользуемых параметров ставить вилдкард-символ:
someObj.SomeEvent += (_, _) => someCode();
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В немерле нельзя пропускать список параметров, но можно вместо неиспользуемых параметров ставить вилдкард-символ: VD>
Здравствуйте, nikov, Вы писали:
N>Я имел в виду не такой вариант, а то что скобки (вместе с содержащимися в них параметрами!) в C# можно опускать, если ни один из параметров не используется внутри анонимного блока. В таком случае совместимость типов проверяется только по возвращаемому значению.
Кстати, можно ввести предложение о том, чтобы в местах, где требуется делегат или функциональный тип, можно было передавать просто блок кода?
Ну, типа:
obj.SomeEvent += { ... };
или
f({ ... });
вот только боюсь, что такое может привести к ошибкам (случаяно забытым параметрам) и читабельность может оказаться весьма сомнительно. К тому же не ясно что делать в пдобных случаях:
def f() : A -> B
{
{ B() }
}
?
Считать этот блок лямбдой? Или все же это простоблок?
Компилятор конечно может посчитать это дело лямбдо, но если это ошибка, то она будет замазана.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>А почему бы не писать так:
N>
N>someObj.SomeEvent += fun { someCode() };
N>
N>?
Дык выигрыш по сравнению с:
someObj.SomeEvent += fun(_, _) { someCode() };
или
someObj.SomeEvent += (_, _) => someCode();
Хотя сделать то что ты хочешь элементарно. Я сейчас занимаюсь тем, что обучаю парсер разбирать более запушенные случаи вроде:
class A :
{
}
или
f(a :) : { }
так как при наборе кода в студии такая фигня встречается часто, но надо и в таких случаях распарсивать сами классы и методы. fun без скобок из той же степи. Нужна всего одна дополнительная проверка.
Так что кидай идею в конференцию. Если народ решит, что это хоршо (не будет возражения) то добавим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, можно ввести предложение о том, чтобы в местах, где требуется делегат или функциональный тип, можно было передавать просто блок кода?
В общем, я написал реквест в трекер. Просто блок делать не будут из-за неоднозначности. Возможность опускать скобки, видимо, будет.
А полиморфизм для анонимных методов запретят. Ибо не понятно, во что его компилировать.
Здравствуйте, nikov, Вы писали:
N>В общем, я написал реквест в трекер. Просто блок делать не будут из-за неоднозначности. Возможность опускать скобки, видимо, будет. N>А полиморфизм для анонимных методов запретят. Ибо не понятно, во что его компилировать.
Это... Вот что хочется сказать.
Хороших идей которые можно было бы реализовать бесчисленное множество. Но каждая новая идея отдаляет момент релиза языка. Так что ты старайся генерировать этих идей по меньше. Ни то будет ситуация как с Ди, когда язык 5 лет в доработках. То что есть сейчас уже лучше любого языка для дотнета (а то и вообще), и хорошо бы его все же зарелизить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это... Вот что хочется сказать. VD>Хороших идей которые можно было бы реализовать бесчисленное множество. Но каждая новая идея отдаляет момент релиза языка. Так что ты старайся генерировать этих идей по меньше. Ни то будет ситуация как с Ди, когда язык 5 лет в доработках. То что есть сейчас уже лучше любого языка для дотнета (а то и вообще), и хорошо бы его все же зарелизить.
Где оценка +100 ??
А вообще, я определенно в восторге от Владимира. Он мало того, что багов за 3 дня нашел больше, чем я за все время работы с Nemerle, так еще и форум Декларативное программирование превратил в форум по Немерлу. Так держать!!!
Здравствуйте, VladD2, Вы писали:
VD>Это... Вот что хочется сказать. VD>Хороших идей которые можно было бы реализовать бесчисленное множество. Но каждая новая идея отдаляет момент релиза языка. Так что ты старайся генерировать этих идей по меньше. VD>То что есть сейчас уже лучше любого языка для дотнета (а то и вообще), и хорошо бы его все же зарелизить.
Мне тоже хочется, чтобы он зарелизился, но все-таки мне трудно согласиться с такой позицией.
Во-первых, мои идеи никого не обязывают реализовывать их немедленно.
Во-вторых, мне не хочется, чтобы какие-то недоработки в дизайне языка закрепились бы в стандарте, и потом разработчика вынуждены бы были поддерживать совместимость с ними в следующих версиях (что мы наблюдаем во многих других языках).
В-третьих... на меня просто нашло вдохновение
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, nikov, Вы писали:
N>>В общем, я написал реквест в трекер. Просто блок делать не будут из-за неоднозначности. Возможность опускать скобки, видимо, будет. N>>А полиморфизм для анонимных методов запретят. Ибо не понятно, во что его компилировать.
VD>Это... Вот что хочется сказать. VD>Хороших идей которые можно было бы реализовать бесчисленное множество. Но каждая новая идея отдаляет момент релиза языка. Так что ты старайся генерировать этих идей по меньше. Ни то будет ситуация как с Ди, когда язык 5 лет в доработках. То что есть сейчас уже лучше любого языка для дотнета (а то и вообще), и хорошо бы его все же зарелизить.
А я несогласен. Лучше уж проработать и осмыслить все тонкие моменты и только потом делать релиз. С D кстати не так. Там до сих пор несмотря на выход 1.0 еще дорабатывать и дорабатывать. Также было и с .NET. Более менее им стали пользоваться только с 1.1. Да и вообще эти релизы скорее для маркетинговой шумихи. Вон MS выпустили .NET 3.0, а баги в CLR, которые проявились даже до выхода .NET 2.0 остались (здесь). Все равно разработка — это вечная бета. Можно только стабилизировать набор фич и назвать это 'Nemerle 1.0'. Но это только буквами будет отличаться от 'Nemerle 0.9.4'.
А идеи они просто в голове возникают, почему бы ими не поделиться с другими? Тем более что их можно реализовывать независимо от багфиксинга, как например сделал Snaury с Late.
Здравствуйте, nikov, Вы писали:
N>Мне тоже хочется, чтобы он зарелизился, но все-таки мне трудно согласиться с такой позицией. N>Во-первых, мои идеи никого не обязывают реализовывать их немедленно.
И тем не мнее они отвлекают от исправления и переработки жизненно важных фич.
N>Во-вторых, мне не хочется, чтобы какие-то недоработки в дизайне языка закрепились бы в стандарте,
Если речь идет об ошибке или явной нелогичности, то нет вопросов. Согласен. Но когда речь идет о незначительных улучшениях которые могут быть спокойно реализованы потом и не приводят к ломающим изменениям, то несогласен.
Например, идея упростить матчинг по тюпла конечно зравая, но совершенно не приоритетная. Если этого не будет в первой версии никто не пострадает.
N> и потом разработчика вынуждены бы были поддерживать совместимость с ними в следующих версиях (что мы наблюдаем во многих других языках).
Зачем? Мы же говорим об улучшения. Их еросто не будет в первой версии, а во второй их можно будет добавить.
N>В-третьих... на меня просто нашло вдохновение
Это хорошее чувство. Но бурную энергию особо важно направить в мирное русло.
Вот помог бы нам с интерграцией разобраться. Там зачастую нужно править компилятор. Глядишь по ходу пьесы, как втянешся, сам доделаешь то что считашь нужным.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.