LINUX.ORG.RU

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

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

Deleted
()
Ответ на: комментарий от forCe

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

ilammy ★★★
()

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

Miguel ★★★★★
()

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

AIv ★★★★★
()

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

buddhist ★★★★★
()

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

anonymous
()
Ответ на: комментарий от dmfd

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

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

qnikst ★★★★★
()
Ответ на: комментарий от AIv

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

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

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

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

qnikst ★★★★★
()
Ответ на: комментарий от AIv

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

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

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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];
    ...
}
фактически размещение данных data делает ся на основе квадро-деревьев с фиксированным рангом rank, ix, iy - координаты ячейки на плоскости.

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

dmfd
()
Ответ на: комментарий от AIv

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

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

drBatty ★★
()
Ответ на: комментарий от forCe

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

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

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

Virtuos86 ★★★★★
()

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

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

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

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

auto12884839
()
Ответ на: комментарий от AIv

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

qnikst ★★★★★
()
Ответ на: комментарий от Virtuos86

В питоне другой смысл у 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

anonymous
()
Ответ на: комментарий от forCe

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

buddhist ★★★★★
()
Ответ на: комментарий от AIv

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

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

AIv ★★★★★
()
Ответ на: комментарий от buddhist

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

dave ★★★★★
()
Ответ на: комментарий от dave

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

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

yyk ★★★★★
()
Ответ на: комментарий от dave

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

yyk ★★★★★
()
Ответ на: комментарий от yyk

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

dave ★★★★★
()
Ответ на: комментарий от dave

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

yyk ★★★★★
()
Последнее исправление: yyk (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.