На сегодня имеем '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.

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

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

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

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

__>На сегодня имеем 'for' в стиле С# и foreach с мощным синтаксисом, который умеет итерировать как и for.

Мне видится самым прямым решением расширить синтаксис list comprehensions, правда синтаксис нужен более интуитивный. Тогда в foreach можно будет добавить оптимизацию, раскрывающую в таких ситуациях его в обычный цикл. Убирать for не вижу смысла, он не более императивный чем foreach.

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

BM>и еще зделать, чтобы фор автоматом дописывал mutable, если не написал разработчик.

Ну и нахрена это "зделать" скажите на милость? Изменяемых переменных должно быть поменьше. Если программист решил такую переменную использовать, то это должно быть явно видно, особенно когда код читает не его автор. От таких, с позволения сказать, оптимизаций вреда больше чем пользы.

Здравствуйте, _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_, Вы писали:

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

Здравствуйте, _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_, Вы писали:

__>Предложение:
__>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 умеет обрабатывать эту конструкцию особо.