Сложные виды циклов(цикл Дейкстры, цикл «Паук», etc.)

школьники и без знания таких страшных слов догадываются вкорячить switch унутырь while и сдать лабы пораньше.

Тем более для Серьезного Бизнеса требуется динамически конфигурируемый вариант сего, а встроенные конструкции тут обламываются - перед обычным хеш-словарем с коллбаками-значениями

Так вот и я думаю, какой толк с них...

Боюсь, всё дело в том, что эти штуки родом из того времени, когда подобное было примерно тем, что сейчас называют паттернами.

А вот на лиспе можно любой цикл сделать на макросах на раз-два!11

Гоуту хватит всем.

докажи на примере

На одном макросе — loop :D

Сложные конструкции, которые удобнее разбить на несколько простеньких.

Для некоторых задач рекурсивный обход был бы весьма и весьма... мы жалели, что его нету. Другое дело, что это вещь все же узко заточенная, завязанная на представление данных, и не очень понятно как его можно в общем виде реализовать.

Перегрузить для структуры данных Traversable?

WTF?

Проблема в том, что бы это эффективно было реализовано, без накладных расходов.

Смотрите на историю развития паскаля/модулы/оберона. Там был цикл Дейкстры, который потом все-таки выкинули.

Да ладно, в Обероне вроде как раз while имеет опциональную else if ветку.

Действительно, не нужно.

Можно подробнее? Как это должно было бы выглядеть?

даже не пытайся... :)

хотя у меня возникла мысль написать такой же комментарий.

просвящайся, что уж

http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html

http://www.haskell.org/haskellwiki/Foldable_and_Traversable

если нужно изменение структуры и возможность проивольного перемещения, то есть Zippers, с хорошими реализациями поверх Foldable и Traversable.

А для плюсов?;-)

про плюсы это не ко мне, я умею на них только хэлловорды типа имплементации реверс инженеринга работы со всякими проприетарными протоколами (когда-то давно и не правда), и байндить их к языкам, с которыми умею рабоать.

Но подозреваю, что если аккуратно написать классы позволяющие выполнять те же методы, что определены в Foldable,Functor,Traversable и сделать реализации этих методов для используемых структур данных, то можно получить аналог, а зипперы с плюсах не нужны, т.к. это подход к immutable данным.

Можно подробнее? Как это должно было бы выглядеть?

Ну есть традиционный обход:

struct Cell{...};
int Nx, Ny;
Cell* data = new Cell[Nx*Ny];
for(int iy=0; iy<Ny; iy++)
    for(int ix=0; ix<Nx; ix++){
        Cell &c = data[ix+iy*Nx];
        ...
    }

int rank;
Cell* data = new Cell[(1<<rank)*(1<<rank)];
rec_for(int ix, iy, pos; rank){
    Cell &c = data[pos];
    ...
}

Ну так что то подобное наск я понял мы и делаем... а хочется на уровне ЯП;-)

На первый взгляд я не могу найти принципиальных проблем, мешающих сделать аналог на плюсах.

Хочется по аналогии, че нить вроде:

зачем это в ЯП, в котором даже вместо обычных массивов синтаксический сахар, а двумерных массивов и не было отродясь? Ну сделай итератор такой хитрый, не вижу проблемы…

Но ведь loop не труЪ вроде бы, синтаксис у него некошерный, не-лисповский, не?

в Обероне вроде как

раз while имеет опциональную else if ветку

В Python while имеет необязательную ветку else. Как и for. А больше там циклов и нет :)

интересует степень полезности

Приходилось использовать, например при анализе генома.

жалел ли кто-либо об отсутствии прямой поддержки в языках

Используется редко, легко эмулируется do { if.. else if } while(); так что отдельная синтаксическая конструкция просто замусорила бы ЯП. Так что не нужно.

если на уровне ЯП == поддержка в управляющих структурах или общепринятый метод, то да, такого не может не хотеться. Т.е., например, в haskell это не специальный сахар или конструкции, а обычный язык, но при этом метод решения задачи через данные интерфейсы является общепринятым.

В питоне другой смысл у else для циклов. А в обероне мона прям цикл Дейкстры писать. Вон у Вирта в новом издании «алгоритмов» он используется:

i := 0; j := 0;
WHILE (i <= N-M) & (j < M) & (s[i+j] = p[j]) DO
    INC( j )
ELSIF (i <= N-M) & (j < M) DO
    INC( i );
    j := 0
END

труЪ/нетруЪ какая разница, это же CL :)

Да, в Оберон-07 есть. А из компонентного паскаля выкинули.

да я не совсем точен, более корректный аналог это библиотеки traverable, functor, foldable на шаблонах, т.е. при сборке все функции уже известны и возможно заинтайнены, так что в рантайме это не вносит накладных расходов. (Если не используюся экзестенциальные классы)

ну мы такое сами руками делаем, но через шаблоны ес-но, рекурсивно. Компиляется только долго.

Есть трушный iter. Скобочек много, как и положено в лиспе. Выглядит правильно. Что мне особенно нравится - iter можно дополнять своими клозами.

loop в некоторых реализациях тоже можно дополнять.

Касательно iter - в последнем sbcl появилась возможность локальных имён для package (для остальных реализаций есть отдельная либа), так вот, используя данный механизм, достаточно ли будет указывать локальное имя только перед именем макроса, или придётся все ключевые слова предварять им? Последнее - плохая реализация, ибо всасывать всё подряд в локальное пространство имён, равно как и писать тонны лапши - плохо.

Понятия не имею. Я использую lispworks.

ладно, вижу что сумбурно написал :) iter импортируешь или нет? Если не импортировать - использовать удобно?

Импортирую iter целиком. Мне, вообще, нравится правило, принятое в мире Java, когда сущности стандартной библиотеки имеют уникальные имена, за очень редким исключением. И в лиспе я стараюсь давать уникальные имена. Создаю множество пакетов, которые экспортируют такие имена. Все пакеты импортирую целиком, кроме стандартных capi и graphics-ports (gp). Сначала было трудно давать такие имена, но сейчас привык.

В жабке проще в том плане, что классы - сами по себе пространства имён. В свете наличия возможности приписывать «пакетам» локальные «никнэймы», не считаю уникальные public имена, содержащие префиксы «принадлежности», хорошей практикой. Равно как и макросы, сравнивающие ключевые символы без учёта возможной принадлежности этих символов разным пакетам, т.е. не через symbol-name. Если, конечно, такое поведение не определено спецификацией пакета.