На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.
Примеры:
// 1.for (mutable i = 1; i <= 10; ++i)
foreach (i in [1 .. 10])
// 2.for (mutable i = 0; i < 10; ++i)
foreach (i in [0 .. 10 - 1])
// 3.for (mutable i = 0; i < 10; i += 2)
foreach (i in [0 , 2 .. 10 - 1])
Предложение:
1. Перенести 'for' в стиле С в Nemerle.Imperative.
2. Переименовать foreach в for.
3. Изменить синтаксис с шагом в foreach на менее конфликтный:
Сейчас неясно что должен выдавать такой код: foreach (i in [1, 1 .. 3])
for (i in [1 .. 10]) // 1..10 // шак: 1for (i in [1 .. 10 .. 2]) // шаг: 2for (i in [10 .. 1 .. -1]) // шаг: -1
4. Вместо ".." использовать операции сравнения < , <= , > , >= для более понятного кода.
Это улучшит итерации где надо писать Length — 1.
foreach (i in [1 .. 10]) // 1..10 , шаг 1for (i in [1 <= 10]) // 1..10 , шаг 1foreach (i in [1 .. 10 - 1]) // 1..9 , шаг 1for (i in [1 < 10]) // 1..9 , шаг 1foreach (i in [10, 9 .. 1]) // 10..1 , шаг -1for (i in [10 >= 1]) // 10..1 , шаг -1foreach (i in [10, 9 .. 1 + 1]) // 10..2 , шаг -1for (i in [10 > 1]) // 10..2 , шаг -1foreach (i in [1, 3 .. 10]) // 1..10 , шаг 2for (i in [1 <= 10 .. 2]) // 1..10 , шаг 2foreach (i in [1, 4 .. 10 - 1]) // 1..9 , шаг 3for (i in [1 < 10 .. 3]) // 1..9 , шаг 3
P.S.
Предложение касается в большей степени Nemerle 2 , чем 1.
Здравствуйте, _nn_, Вы писали:
__>На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.
__>Примеры: __>[nemerle] __>// 1. __>for (mutable i = 1; i <= 10; ++i) __>foreach (i in [1 .. 10])
Ну не совсем, например тот-же код из первого примера после декомпиляции віглядит так:
public void @for()
{
int i = 0;
i = 1;
while (true)
{
if (i > 10)
{
break;
}
Console.WriteLine(i);
i++;
}
}
public void @foreach()
{
int num = 0;
bool flag = false;
int num3 = 0;
num = 1;
int num2 = 10;
flag = num <= num2;
num3 = num2 - 1;
bool flag2 = num3 > num2;
while (flag)
{
num2 = num;
if (flag2)
{
flag = num >= num3;
}
else
{
flag = num <= num3;
}
num++;
Console.WriteLine(num2);
}
}
как-бы и ёжу понятно, что for оптимальнее.
но использовать вместо кочевого слова forach for было-бы неплохо, ведь по синтаксису можно определить что хочет пользователь.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, BogdanMart, Вы писали:
BM>>как-бы и ёжу понятно, что for оптимальнее.
H>Это лечится докручиванием foreach-макроса, правда подобный код нужен совсем нечасто.
Конкретно нужно править Util.n.
Можно просто вызывать for из кода и будет тот же самый оптимальный код.
Здравствуйте, _nn_, Вы писали:
__>На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.
__>Предложение: __>1. Перенести 'for' в стиле С в Nemerle.Imperative. __>2. Переименовать foreach в for. __>3. Изменить синтаксис с шагом в foreach на менее конфликтный: __>Сейчас неясно что должен выдавать такой код: foreach (i in [1, 1 .. 3])
Не надо этого никому не нужного новаторства. Тем более на надо делать конфликтующих операторов. Большая часть тех кто начинает осваивать Nemerle — это люди с опытом C#, Java или C++. Причем первых явно большинство. Так вот не надо усложнять им жизнь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.
__>>Предложение: __>>1. Перенести 'for' в стиле С в Nemerle.Imperative. __>>2. Переименовать foreach в for. __>>3. Изменить синтаксис с шагом в foreach на менее конфликтный: __>>Сейчас неясно что должен выдавать такой код: foreach (i in [1, 1 .. 3])
VD>Не надо этого никому не нужного новаторства. Тем более на надо делать конфликтующих операторов. Большая часть тех кто начинает осваивать Nemerle — это люди с опытом C#, Java или C++. Причем первых явно большинство. Так вот не надо усложнять им жизнь.
А где конфликт тут ?
В Java вон оставили for , а семантика foreach и никто не жалуется.
Я не предлагаю убрать старый for совсем, а перенести его в другой namespace.
Ведь break, continue и так недоступны по умолчанию.
Насчет названия, можно оставить foreach.
Но указания диапазона в foreach все равно нет в C#. Это хотелось бы улучшить.
Здравствуйте, _nn_, Вы писали:
__>На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.
Мне видится самым прямым решением расширить синтаксис list comprehensions, правда синтаксис нужен более интуитивный. Тогда в foreach можно будет добавить оптимизацию, раскрывающую в таких ситуациях его в обычный цикл. Убирать for не вижу смысла, он не более императивный чем foreach.
Здравствуйте, _nn_, Вы писали:
__>Предложение: __>1. Перенести 'for' в стиле С в Nemerle.Imperative.
Нейтрально. __>2. Переименовать foreach в for.
двояко, for i in T мне нравится больше, хотя семантически foreach правильнее __>3. Изменить синтаксис с шагом в foreach на менее конфликтный:
[1 .. 10 .. 2] — это ужасно ) Звучит как сначала дойдём до 10 , потом спустимся к 2 __>4. Вместо ".." использовать операции сравнения < , <= , > , >= для более понятного кода.
Я против )
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, _nn_, Вы писали:
__>>На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.
Z>Мне видится самым прямым решением расширить синтаксис list comprehensions, правда синтаксис нужен более интуитивный. Тогда в foreach можно будет добавить оптимизацию, раскрывающую в таких ситуациях его в обычный цикл. Убирать for не вижу смысла, он не более императивный чем foreach.
Как это связанно ?
List comprehension и foreach различны в семантике.
Первый возвращает список, а второй возвращает void.
Итого в List comprehension мы всегда создаем список с результатом, а в foreach никогда.
Здравствуйте, _nn_, Вы писали:
__>На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.
__>Предложение: __>1. Перенести 'for' в стиле С в Nemerle.Imperative. __>2. Переименовать foreach в for. __>3. Изменить синтаксис с шагом в foreach на менее конфликтный: __>Сейчас неясно что должен выдавать такой код: foreach (i in [1, 1 .. 3])
Кстати не все, что можно сделать фором ты сделаешь форичем, ведь фор можно использовать и для других целей, так как оно позволяет выполнять любой код в своих параметрах
Например
for(mutable reader = command.ExecuteReader(sqlCommand); reader.Read()
{}
//Пример высосаны из пальца, так как там еще надо диспоуз вызвать, но суть в том что фор это не просто перечисление натуральных чисел.
+ какое там безболезненно, for и foreach используються в огромном количестве кода на Nemerle, думаю для многих такая "фитча" превратиться в неплохой нежданчик.
Но вот если оставить фору свой синтаксис, но сделать чтобы фор модно было использовать как форич -- это +1 (т.е. оставить на месте форич(для совместимости), но сделать чтобы фор парсил свой синтаксис и работал как фор и как форич, ато писать форич очень впадло)
и еще зделать, чтобы фор автоматом дописывал mutable, если не написал разработчик.
Здравствуйте, BogdanMart, Вы писали:
BM>Здравствуйте, _nn_, Вы писали:
__>>На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.
__>>Предложение: __>>1. Перенести 'for' в стиле С в Nemerle.Imperative. __>>2. Переименовать foreach в for. __>>3. Изменить синтаксис с шагом в foreach на менее конфликтный: __>>Сейчас неясно что должен выдавать такой код: foreach (i in [1, 1 .. 3])
BM>Кстати не все, что можно сделать фором ты сделаешь форичем, ведь фор можно использовать и для других целей, так как оно позволяет выполнять любой код в своих параметрах
BM>Например BM>for(mutable reader = command.ExecuteReader(sqlCommand); reader.Read() BM>{}
BM>//Пример высосаны из пальца, так как там еще надо диспоуз вызвать, но суть в том что фор это не просто перечисление натуральных чисел.
Я как раз и против такого использования for.
Такой код обычно не по делу.
Через while можно получить аналогичное поведение.
А если что-то частое, то для этого методы и макросы.
В любом случае этот макрос желательней переместить в Nemerle.Imperative, чтобы было меньше соблазна.
BM>+ какое там безболезненно, for и foreach используються в огромном количестве кода на Nemerle, думаю для многих такая "фитча" превратиться в неплохой нежданчик.
Для этого документация конечно.
BM>Но вот если оставить фору свой синтаксис, но сделать чтобы фор модно было использовать как форич -- это +1 (т.е. оставить на месте форич(для совместимости), но сделать чтобы фор парсил свой синтаксис и работал как фор и как форич, ато писать форич очень впадло)
А тогда зачем foreach нужен будет ?
Взять тот же F#, там нет for-а как С , а foreach называется for. И для перечисления используется синтаксис for i = 1 to 10 .
Никто не жалуется что нет for-а в стиле C
BM>и еще зделать, чтобы фор автоматом дописывал mutable, если не написал разработчик.
А это наверное можно сделать, но тогда нельзя будет использовать for (def x = X(); x.HasValue; x.MoveNext())
Здравствуйте, _nn_, Вы писали:
__>Итого в List comprehension мы всегда создаем список с результатом, а в foreach никогда.
А ты засунь List comprehension в foreach...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, _nn_, Вы писали:
__>>Итого в List comprehension мы всегда создаем список с результатом, а в foreach никогда. WH>А ты засунь List comprehension в foreach...
И как это будет выглядеть ?
foreach (i in $[ x | x in [1 .. 10] ])
Или имелось ввиду так ?
foreach ($[ i | i in [1 .. 10] ])
Тогда точно надо другой синтаксис ведь оригинальный foreach выглядит проще
Здравствуйте, _nn_, Вы писали:
Z>>Мне видится самым прямым решением расширить синтаксис list comprehensions, правда синтаксис нужен более интуитивный. Тогда в foreach можно будет добавить оптимизацию, раскрывающую в таких ситуациях его в обычный цикл. Убирать for не вижу смысла, он не более императивный чем foreach.
__>Как это связанно ? __>List comprehension и foreach различны в семантике. __>Первый возвращает список, а второй возвращает void. __>Итого в List comprehension мы всегда создаем список с результатом, а в foreach никогда.
Да, но семантически, не считая возможности изменения i внутри цикла
for (mitable i = 0; i < 10; i++) == foreach (i in $[0 .. 9])
Поэтому все твои предложения семантически реализуемы через list comprehensions. Потом дело оптимизации в таких случаев обойтись без генерации списка.
Здравствуйте, WolfHound, Вы писали:
__>>Итого в List comprehension мы всегда создаем список с результатом, а в foreach никогда. WH>А ты засунь List comprehension в foreach...
Он там и используется. Макрос foreach специальным образом обрабатывает именно лист-компрешеншон.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>Предложение: __>>1. Перенести 'for' в стиле С в Nemerle.Imperative.
VD>Значит. Так Nemerle 1.0 ПОЛНОСТЬЮ закрыт для изменений. Правятся только баги!
VD>Все новшества попавшие в транк буду нещадно вычищать.
VD>Я понятно выражаюсь?
Да мы уже вроде договорились, что фич в транк писаться не будет.
Это мысли на будущее.
Здравствуйте, _nn_, Вы писали:
__>Да мы уже вроде договорились, что фич в транк писаться не будет. __>Это мысли на будущее.
Я на всякий пожарный предупреждаю. Мне уже надоело, что как только формируется стабильная версия которую можно зарелизить, появляется новая фича и тестирование приходится продолжать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, _nn_, Вы писали:
Z>>>Мне видится самым прямым решением расширить синтаксис list comprehensions, правда синтаксис нужен более интуитивный. Тогда в foreach можно будет добавить оптимизацию, раскрывающую в таких ситуациях его в обычный цикл. Убирать for не вижу смысла, он не более императивный чем foreach.
__>>Как это связанно ? __>>List comprehension и foreach различны в семантике. __>>Первый возвращает список, а второй возвращает void. __>>Итого в List comprehension мы всегда создаем список с результатом, а в foreach никогда.
Z>Да, но семантически, не считая возможности изменения i внутри цикла Z>
Z>for (mitable i = 0; i < 10; i++) == foreach (i in $[0 .. 9])
Z>
Z>Поэтому все твои предложения семантически реализуемы через list comprehensions. Потом дело оптимизации в таких случаев обойтись без генерации списка.
А часто нужно менять счетчик внутри цикла ?
Если нужно то для этого лучше использовать while.
Так сегодня и можно писать foreach (i in $[0 .. 9])
Под list comprehension я понимаю $[ x | x in l ].
Тут не создается список по любому, foreach умеет обрабатывать эту конструкцию особо.