Создайте объект до входа в функцию.

Вам не угодишь. Когда говоришь, что есть разница, Вас не устраивает и Вы ищите общие черты. Когда находятся расхождение, Вам опять не то . В функциональном программировании как-то живут с таким положением дел и никто не жалуется. Я не вижу проблем в создании объекта раньше функции.
создать подсистему х
х=какая_то_функция_типа_фабрика()

В функциональном программировании так делают. Наверно тоже есть причина. А причина как мне видится в свободном манипулировании ссылками. Когда ссылка может указывать на объект, а может на другой, а может на третий и т.д. Генерировать ссылки это одно. Генерировать объекты это другое.

Почему нет? Во-первых, функции системы и соответственно в них можно добавлять функции. Во-вторых, анонимных функций нет, но внутри функций на этапе написания программы также можно объявлять функции. То есть Вы просто на время выполнения функции добавляете в нее новую.  С точки зрения реализации такой модели функция будет иметь список ссылок, доступных для поиска вложенных функций. Я обдумываю как это должно выглядеть синтаксически, там ниже по тексту еще не дописано, но есть раздел "Спецификаторы функций" (или как-то так) - это такие вот метапараметры, которые будут описывать характер параметров функции. Ну грубый пример:
функция Сумма( Параметр1 как ряд) Ряд указывает, что Параметр1 это последовательность аргументов, то есть функцию можно будет вызвать так: сумма(х, у, z)

Или функция Сортировка(сравнение как функция, данные).  То есть на время исполнения в область видимости Сортировки будет добавлена функция сравнение. Я еще сам не до конца продумал, но в целом будет выглядеть как-то так. Вообще Вы сильно далеко в глубь копаете. Вопрос хранения данных это проблема реализации языка, а не проблема алгоритма. Иными словами как реально располагаются данные внутри модели это не дело программиста. Все что ему нужно знать, это то как описать дерево систем, чтобы достигнуть результата. Все остальное должен делать интерпретатор (и если повезет, то и компилятор).

Сильно сомневаюсь    Основное правило в языке - максимально общие правила для всех и минимум индивидуальных костылей. Поэтому и типов данных всего два - строки и системы.

Это тоже копание в реализации, а не в языке. Я уже привел пример - Вы можете заранее создать систему, а потом натравливать на нее свои паттерны. Эффект будет абсолютно одинаковый. В чем проблема? Вы создаете на фабрике объект. Я предлагаю его на фабрике модифицировать.

О чем это Вы? Дайте условный пример, какой-нибудь, чтобы понять.

Новая версия: https://yadi.sk/i/UOoaULEi3L9nsu

Да видите, еще решение. Но опять же это реализация возможностей языка, а не сами возможности.

Немного дополнил описание: https://yadi.sk/i/jz_xqnKy3Lhejc

Немного дополнил описание: https://yadi.sk/i/1Ihhc6Lq3MC7by

1. Попробуйте это написать и поддерживать.
    а) Это долго
    б) Это медленно при разработке
    в) Это медленно при работе
2. Типы в языке не автоматические (это значит, что их контроль не проводится), вместо этого используются пост и предусловия. В описании про функции и спецификаторы это написано. Типы играют очень слабую роль, так как фактически типов всего два - это строки и системы, остальное их вариации.
3. Да это можно представить как тип, но этот тип не для хранения данных, а для проверки функций. Потому что для другой функции вполне может быть допустим такой интервал (ей например, нужно чтобы система в принципе содержало число, а какое для нее не важно - пример, организация какого-нибудь списка, массива и пр. кортежей). Или та же арифметика. Имеется два вызова функции для одной системы. В одной происходит сложение, а в другой деление (ну хоть бы и калькулятор ). И? Для одной ноль можно, а для другой функции ноль нельзя. Заводить два типа? Выполнять преобразование типов? Типы удобны для примитивов, но более сложные вещи поддерживать типами становится сложно. И посмотрите на с++ или на паскаль. Вывод сообщения на экран уже может требовать преобразование одного типа в другой. А вот возьмите большой проект (более 1000 строк кода) и просто посчитайте сколько раз и зачем выполняются явные и неявные преобразования типов. Разве они нужны для решения задачи? Это просто дань компьютеру, организации процесса, а не описание алгоритма.

Ну вот вызов функции:

Вводим указанные условия проверки, допустим имеется операция "соответствие" - ::

Громоздко получается, и это при том, что функция получает параметры и возвращает результат имеющих один вид (тут уже наверно термин тип не совсем подходит). Представьте, что все параметры различны - функция станет абсолютно не читаема.
А здесь мы просто сокращаем запись немного:

И потом вызов функции: а=какая_то_функция(б, в, г, д :: Диапазон) :: Диапазон
Уже более лаконично, потом можно писать различные короткие тесты, просто меняя предикаты (или содержимое предиката в одном только месте, а не в пяти вызовах функций, разбросанных по коду).
Это только размышления пока - синтаксис условный.

Ну вот я об этом и думаю, может просто немного кривовато, но пришел к какому-то похожему решению. И потом эти функции (предикаты) можно еще использовать в обычных условиях тип if-then-else.

Нет конечно - это контракты. Типы для данных, я там даже выделил жирным специально в чем разница. Типы навсегда - Int не может быть строкой. Контракт нужен только для отладки. Когда функция исправна в контракте нет нужды и в релизе проверку условий можно исключить тем самым сделав код быстрей.

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

Разница в том, что диапазон он для данных. И там вообще может быть не диапазон. Диапазон он в примере представлен. Одни и те же данные для разных функций должны удовлетворять разным условиям. Точней не всегда должны, а могут вообще говоря. Снова вспомним арифметику - функция для сложения например принимает целые числа. Для деления не включат ноль. Данные остались прежние, что тип поменялся? А здесь перед вызовом функции идет проверка предусловия, что деление не может иметь аргументом ноль (сами данные нулем могут быть для других функций).
Вот пример две функции в калькуляторе:
1) Function Adder(x, y: Integer): Integer;
2) Function Divider(x, y: Integer): Integer;
Очевидно что тип Integer совершенно не решает проблему Divider  для аргумента у. Ваши предложения? Завести еще один тип? Integer без нуля? То есть потенциально Integer в данном примере источник ошибок и контроль типов не решает проблему деления на нуль. И второй косяк в печатании:

Разве в алгоритме калькулятора где-то есть преобразование типа? Нет, это особенность реализации. Я понимаю, что и мое видение не решает многих проблем, но оно должно уменьшить количество преобразований.

В смысле? Я не совсем понял вопроса, дайте пример как Вы хотите. Диапазон в примере это и есть имя функции-предиката, не ключевое слово. Назовите по-другому. Или Вы хотите косвенную адресацию? Я думал об этом вскользь. Для функций такая фишка должна быть, типа вызвать функцию по содержимому строки. Так как предикат это разновидность функции, на нее должны распространяться эти правила. И второе - функция это система, а системы можно переименовывать. Следовательно, Вы можете поступить так - передать в функцию более высокого уровня параметром предикат, переименовать его так как Вам нужно и скормить его для вызова.
Ну например, есть функции а, б, в и предикат г.
В функции б требуется отследить работу функции в (допустим, что бы результат в соответствовал условиям г). Тогда функция а, в зависимости от каких-то условий передает предикат д (а может е, а может ё) в функцию б. Функция б переименовывает ё в г и отслеживает вызов функции в. Функция в исполняется и ее результат сравнивается с в. При этом в может быть и д и е и ё и т.д.
Я не знаю насколько это практично само по себе. Просто такая возможность есть, она предоставляется системам. При добавлении некоторых простейших механизмов можно даже сделать так, что в ряде случаев даже порядок расположения параметров будет не важен. Можно будет сравнивать по типу. Например, через foreach пройтись по параметрам и если он предикат, переименовать его в г (а если нет, значит генерить ошибку или использовать какой-то свой, может пустой предикат, который всегда True. Ну или что-то типа того.
Конечно, когда нужно два предиката, отличить их будет сложней. Но если предикат один, а остальное прочие данные, то в принципе все равно каким он передан в функцию в качестве первого параметра или второго. То есть при правильном проектировании сам порядок расположении входящих параметров в функции теряет смысл.
Есть такая простая идея - при старте функции она получает две подсистемы параметры и результат. Так как это будет использоваться очень часто можно обозвать их как-нибудь. Допустим минус это параметры (удобно - не нужно переключать раскладку и всего один символ), а плюс это результат функции.
В параметры копируется все что туда передали в качестве подсистем в том порядке в каком они там следуют. Соответственно для их пакетной обработки нужен только foreach. Дальше определяем природу системы и работаем. Смысл в том, что если точно известно что перед нами, то не важно как оно располагается в аргументах. Пока коряво, но как-то так.
Это также открывает ряд мелких плюшек - например, написать функцию по лисповски с произвольным числом параметров (тут только нужно очень тщательно проработать синтаксис). Типа Сложить (1, 2) или Сложить (1, 2, 3, 4). Если передавать параметры как описано выше тем же Foreach можно без проблем одним кодом складывать хоть один аргумент, хоть тысячу (правда в этом тоже нет особого смысла - ведь все параметры можно просто засунуть в одну надсистему и передавать  уже ее).

Это функции для:
- проверки входящих параметров;
- проверки результата функции;
- использования в логических условиях блоков if-then-else.
В принципе наверно их можно и в обычных выражениях использовать, я просто еще не продумал как это будет выглядеть.

Ну да об этом просто надо написать в описании языка.

Ну синтаксиса пока нет вообще никакого - просто наметки. Можно и + для аргументов, - для результата.

И вот сейчас, когда пришло время тестов и сборки интерпретатора из основных кусков возник вопрос диалектов. Нечто подобное рассматривал Юрий на своем сайте.  Суть проблемы в том, чтобы дать возможность использовать в одной программы код из разных диалектов. А для этого в начале исходника нужно как-то указать на каком диалекте написан текст программы. Ну для основного диалекта, используемого по умолчанию достаточно будет ничего не указывать и интерпретатор "поймет" что работает по умолчанию (причем интерпретатор должен уметь выбирать из двух вариантов - краткая форма для записи или подробная форма для чтения исходных текстов). А вот для самописных синтаксисов нужна какая-то команда, которая будет встречаться раньше остальных и указывать интерпретатору на какой язык переключиться.
Вторая грабля всплыла только в момент реализации. Суть беды следующая - в одном исходнике теоретически могут быть такие правила, которые не позволят вызвать функцию из другого исходника. Например, если токеном объявлен символ ? (знак вопроса), то нельзя будет вызвать функцию равно_нулю?, так как такая функция просто не увидится интерпретатором. Он вместо функции равно_нулю? будет видеть две лексемы отдельно равно_нулю и ?. Вероятность такого исхода мала, но она в принципе существует. Можно конечно придумать костыль типа написать обертку над функцией, так чтобы она была без экзотических символов, чтобы корректно читалась по правилам вызывающего юнита. Можно вызывать косвенно (например, символьно имя функции хранить в переменной).
У кого какие идеи, есть специалисты по "диалектизму" ? Уже сейчас понятно, что надо готовить какое-то пособие по составлению диалектов языка и описывать момент с отдельными токенами.