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

DM>Есть лямбды и передача первоклассных функций-замыканий туда-сюда, данные иммутабельны, if-else возвращает значение, есть литералы для массивов и "объектов" (хэш-таблиц со строковыми ключами), ряд операций вроде map ленивые, возвращают рэнджи (в терминологии Ди), поэтому композиция из нескольких map/filter не создает промежуточных массивов. Все сводится к функциям (раскинутым по модулям) и выражениям, никаких циклов, никаких записей в массивы. Типы пока что проверяются в рантайме, но скоро добавлю их вывод и статическую проверку. Реализован в виде довольно тупого интерпретатора на D. Благодаря статической интроспекции в D, подключать нативный код очень легко, все поля и методы нативных структур и объектов автоматически становятся видны из интерпретатора, и там тоже есть своя интроспекция, можно видеть содержимое модулей и объектов, имена и типы полей/методов.
DM>Я занимаюсь сердцем интерпретатора, еще несколько человек добавляют "конечности" — то, через что он общается с экселем, БД и другими системами и кодобазами.

с первого взгляда от F# не отличиш

в конвейерном операторе, например
x |> byEPS(ent, pfolio, subPfolio)
куда результат от предвыражения подставляется? в 1-й параметр функции? или последний?
это такая замена каррирования?

вообще идеи интересные, у нас в команде примерно подобные роятся в умах.. и примерно назначение схожее — прикладникам (аналитики и тп) дать инструмент для запросов к данным, тк sql они не любят.
а вот ФП понимают гораздо проще. и я их понимаю и согласен)