На сегодня имеем '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 // шак: 1
for (i in [1 .. 10 .. 2]) // шаг: 2
for (i in [10 .. 1 .. -1]) // шаг: -1

4. Вместо ".." использовать операции сравнения < , <= , > , >= для более понятного кода.
Это улучшит итерации где надо писать Length — 1.

foreach (i in [1 .. 10])        // 1..10 , шаг 1
for     (i in [1 <= 10])        // 1..10 , шаг 1

foreach (i in [1 .. 10 - 1])    // 1..9 , шаг 1
for     (i in [1 <  10])        // 1..9  , шаг 1

foreach (i in [10, 9 .. 1])     // 10..1 , шаг -1
for     (i in [10 >= 1])        // 10..1 , шаг -1

foreach (i in [10, 9 .. 1 + 1]) // 10..2 , шаг -1
for     (i in [10 >  1])        // 10..2  , шаг -1

foreach (i in [1, 3 .. 10])     // 1..10 , шаг 2
for     (i in [1 <= 10 .. 2])   // 1..10 , шаг 2

foreach (i in [1, 4 .. 10 - 1]) // 1..9 , шаг 3
for     (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 было-бы неплохо, ведь по синтаксису можно определить что хочет пользователь.

Здравствуйте, BogdanMart, Вы писали:

BM>как-бы и ёжу понятно, что for оптимальнее.

Это лечится докручиванием foreach-макроса, правда подобный код нужен совсем нечасто.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, BogdanMart, Вы писали:

BM>>как-бы и ёжу понятно, что for оптимальнее.

H>Это лечится докручиванием foreach-макроса, правда подобный код нужен совсем нечасто.

Конкретно нужно править Util.n.
Можно просто вызывать for из кода и будет тот же самый оптимальный код.

Здравствуйте, _nn_, Вы писали:

Это ничего не даст.
Я против.

Здравствуйте, _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...

Здравствуйте, 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 выглядит проще

foreach (i in [1 .. 10])

Здравствуйте, _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 специальным образом обрабатывает именно лист-компрешеншон.

Здравствуйте, _nn_, Вы писали:

__>Предложение:
__>1. Перенести 'for' в стиле С в Nemerle.Imperative.

Значит так, Nemerle 1.0 ПОЛНОСТЬЮ закрыт для изменений. Правятся только баги!

Все новшества попавшие в транк буду нещадно вычищать.

Я понятно выражаюсь?

Здравствуйте, 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 умеет обрабатывать эту конструкцию особо.