Все просто ))

Он заинлайнит. :D

решение я уже привёл и оно классическое: использовать обёртки в виде семейства классов с виртуальными функциями. оптимизировано максимально, читается легко, портянок нет.

можно вместо этого использовать сахар в виде swith (Все просто )) (комментарий) вот этот вот тихий ужас, например). иногда — это тоже отчасти правильное решение, но, в общем случае, плохо расширяемое, нечитабельное и портянистое.

вы не поверите...

сперва нужно еще разобраться какую именно функцию вызывать. болид формулы 1 тоже принципиально ничем не отличается от ваз 2106.

виртуальные функции. а у вас — нечитабельная и нерасширяемая портянка. очень весело будет читать ваш код, когда начнётся юникод, или порядок поменяется. например, если надо будет сделать так:

dispatch 'a' = Just forB
dispatch 'b' = Just forC 
dispatch 'с' = Just forC
dispatch 'd' = Just forD
dispatch 'e' = Just forA
dispatch 'f' = Just forF
dispatch 'ф' = Just forRF
dispatch 'a' = Just forRA
dispatch _   = Nothing

Нет никакого повторения терминов (повторения dispatch вопрос стиля и решается через case, нет излишних конструкций. Каждое выражение несет конкретный смысл:

Получить имя. Передать в branching. Если имя диспатчится, выполнить forAllNonDefault, а затем функцию к которой придиспатчилось. Иначе, выполнить forDefault.

Не, порядок не важен. А со свитчем это единственное вменяемое решение в условиях задачи.

Я не знаком с виртуальными функциями, а примеры в википедии выглядят страшно.

Я уже обновил немного пример и если ожидается, что dispatch разростется, то можно сделать так:

dispatch name = case name of
  'a' -> forA
  'b' -> forB
  'c' -> forC
   .....
  _ - -> fail "no function dispatched"   

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

Если поменяется порядок, то я незнаю как можно отразить это в коде лаконичнее чем «значение -> функция»

A eще лучше вот так

dispatch = \case
  'a' -> forA
  'b' -> forB
  'c' -> forC
   .....
  _ - -> fail "no function dispatched"   

имеется в виду когда «а» внезапно начнёт соответствовать forB, а «t» — какой-нибудь forY.

branching myLongNameOfVariable
    | Just f <- dispatch myLongNameOfVariable = forAllNonDefault >> f
    | otherwise = forDefault

Вот это понравилось, всмысле выразительность возможностей ))

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

противоречит условию «лаконичным» и «без лапши» — если потребуется 2 одинаковых switch, или разных, но тоже по буквам. тогда свитчи разрастаются ещё в ту портянку...

а виртуальные фу-ции для ровно для решения подобных задач и придумали)

В таком случае хз, возможно считать не валидным.

Ну если применить из абстракций к жизни, то, пусть это будет ограниченное число значений в каком-нить конфиге, и на каждое значение уже заготовлены обработчики forN() плюс, если не распознали по значению, тогда тупо дефолт. И да, соответствие имен значение<->обработчик не гарантировано.

а вообще в этот тред этого вашего царя бы позвать

т.к. нужно организовать вызов функции по принципу ключ-значение.

как это сделать, я уже писал: Все просто )) (комментарий) , где for_letter() — виртуальная функция.

Да, царя не хватает, щаз бы разрулил каким-нить супермакросом ))

Ну, а в for_letter() будет содержаться все тот же маппинг между значением и соответствующим действием. Что поменялось?

ага, именно в таком примере и надо виртуальные функции юзать, обернув в в них forN()

for_letter() это таки лишний переход куда-то там еще из текущего скопа.

то, что этот маппинг будет «невидим». for_letter() не будет содержать в себе свитча, просто автоматом, по скрытому указателю вызовется нужная функция.

лишний, но switch работает ровно также) потому, что так тупо быстрее портянок из if

Каким образом этот автомат без свитча узнает какую функцию вызвать при определенном значении если в нем не будет аналога

\case
  'a' -> forA
  'b' -> forB

?

Свич будет ближе по «прыжку» ровно как и ифы, в сравнении с дерганьем чего-то лежащим далеко в другом месте. Ну это да, типа экономия на спичках и все такое. Тем не менее.

Необходимо оптимизировать (переходы по адресу, кол-во условий/вызовов/переменных) и сделать лаконичным, понятным, читаемым, без лапши, копипасты, расширяемым для большего кол-ва значений за наименьшее кол-во телодвижений

Слишком много параметров нужно минимизировать. Минимизировать можно только один параметр. Условие некорректное.

Вобщем хочу увидеть этот хитрый for_letter()

Условие некорректное

Понимаю. Ну можно уточнить для полной абстракции и синтетики:

Нельзя выйти из текущего скопа, нельзя добавлять вспомогательные сущности (массивы, списки), можно юзать свитчи и/или ифы.

И, в целом, оно получилось. Да, выглядит достаточно портянисто, но отвечает всем критериям задачи по максимум, чтобы ни один из этих критериев «не обидеть».

Пусть еще немного пообсасывают, если никто аналог не выложит, тогда вброшу портянку ))

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

А оно без лапши и копипасты, да ))

Это те самые ужасные и сложные монады

Это крутая фича же. Я сразу понял чо оно делает, нативно конечно, но понял.

Свич будет ближе по «прыжку» ровно как и иф

только вот такой инструкции как switch не существует. на самом деле, switch как раз и заменяется на месте виртуальными функциями. что касается if-ов, то 2-3 условных переходов съест больше, чем вызов функции по указателю.

Ну это да, типа экономия на спичках

скорее, как раз, расточительство этих самых спичек

а что не так? Как я понял твой код (вот нет бы на сях написать, с статической типизацией): мы получаем название переменной и делаем выбор одной из веток в зависимости от названия переменной.

В том, что я написал, все переменные храним в массиве, а в роли названия выступает индекс, и делаем свитч по этому индексу.

я ж написал уже Все просто )) (комментарий)

есс-но, предполагается, что getName() возвращает не char а класс-наследник MyLetter из примера.

А как будут выглядеть объявления всех этих MyLetter. Что-бы был полный рабочий код (как в моих примерах).

Не нравится мне идея заводить отдельный класс, спец функцию getName() под этот класс, и кучу инстасов этого класса просто для того что-бы паттерн-матчить аргумент. Я не понимаю, чем эта буква на основе которой мы решаем что делать отличается от обычной буквы настолько чтобы заслужить отдельного представления/типа/класса ? А если мы пишем какой-нибудь парсер и у нас в одном файле будет под пол-сотни таких ветвлений. На каждое заводить отдельный MyLetter?

A еще, я правильно понимаю, что forAllNonDefault() будет копипаститься в каждую реализацию for_letter ?

lambda: None

что это за костыль

Годно!

расточительство этих самых спичек

Реализовал на пыхпыхе http://pastebin.com/gLQ7gwjn и на жс http://pastebin.com/vPbZYe1z - свитчи уделали твоих калбяков и там и там. Если есть желание подправить наскоро написанные тесты, я не против.

сделать лаконичным, без лапши, копипасты

Ты идиот или прикидываешься?

Ну покажи мне ОДИНАКОВЫЕ строки