школьники и без знания таких страшных слов догадываются вкорячить switch унутырь while и сдать лабы пораньше.
Тем более для Серьезного Бизнеса требуется
динамически конфигурируемый вариант сего, а встроенные конструкции тут обламываются - перед обычным хеш-словарем с коллбаками-значениями
Для некоторых задач рекурсивный обход был бы весьма и весьма... мы жалели, что его нету. Другое дело, что это вещь все же узко заточенная, завязанная на представление данных, и не очень понятно как его можно в общем виде реализовать.
про плюсы это не ко мне, я умею на них только хэлловорды типа имплементации реверс инженеринга работы со всякими проприетарными протоколами (когда-то давно и не правда), и байндить их к языкам, с которыми умею рабоать.
Но подозреваю, что если аккуратно написать классы позволяющие выполнять те же методы, что определены в Foldable,Functor,Traversable и сделать реализации этих методов для используемых структур данных, то можно получить аналог, а зипперы с плюсах не нужны, т.к. это подход к immutable данным.
зачем это в ЯП, в котором даже вместо обычных массивов синтаксический сахар, а двумерных массивов и не было отродясь? Ну сделай итератор такой хитрый, не вижу проблемы…
Приходилось использовать, например при анализе генома.
жалел ли кто-либо об отсутствии прямой поддержки в языках
Используется редко, легко эмулируется do { if.. else if } while(); так что отдельная синтаксическая конструкция просто замусорила бы ЯП. Так что не нужно.
если на уровне ЯП == поддержка в управляющих структурах или общепринятый метод, то да, такого не может не хотеться. Т.е., например, в haskell это не специальный сахар или конструкции, а обычный язык, но при этом метод решения задачи через данные интерфейсы является общепринятым.
да я не совсем точен, более корректный аналог это библиотеки traverable, functor, foldable на шаблонах, т.е. при сборке все функции уже известны и возможно заинтайнены, так что в рантайме это не вносит накладных расходов. (Если не используюся экзестенциальные классы)
loop в некоторых реализациях тоже можно дополнять.
Касательно iter - в последнем sbcl появилась возможность локальных имён для package (для остальных реализаций есть отдельная либа), так вот, используя данный механизм, достаточно ли будет указывать локальное имя только перед именем макроса, или придётся все ключевые слова предварять им? Последнее - плохая реализация, ибо всасывать всё подряд в локальное пространство имён, равно как и писать тонны лапши - плохо.
Импортирую iter целиком. Мне, вообще, нравится правило, принятое в мире Java, когда сущности стандартной библиотеки имеют уникальные имена, за очень редким исключением. И в лиспе я стараюсь давать уникальные имена. Создаю множество пакетов, которые экспортируют такие имена. Все пакеты импортирую целиком, кроме стандартных capi и graphics-ports (gp). Сначала было трудно давать такие имена, но сейчас привык.
В жабке проще в том плане, что классы - сами по себе пространства имён. В свете наличия возможности приписывать «пакетам» локальные «никнэймы», не считаю уникальные public имена, содержащие префиксы «принадлежности», хорошей практикой. Равно как и макросы, сравнивающие ключевые символы без учёта возможной принадлежности этих символов разным пакетам, т.е. не через symbol-name. Если, конечно, такое поведение не определено спецификацией пакета.