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

FDS>> Есть ли язык программирования, в котором есть следующие фичи:
·>Да любой интерпретируемый или managed, например java

FDS>> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
·>java.lang.SecurityManager

Нет. Насколько я понимаю, это не то.
Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций.

Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
Все остальные модули компилятор сам проверяет, что в них ничего такого нет.

Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.


FDS>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции
·>Запрет на уровне класса.

Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода.
то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.

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

В принципе, это можно делать строковым поиском по шаблону, но это нужно писать отдельный инструмент. И никто не знает, насколько он будет верен.


FDS>> 3. Помечать код как неизменяющий состояние программы
·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли?

У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией.
Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.


FDS>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
·>А чем просто типы не устраивают? class RedString {private final String content;}

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

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


FDS>> 5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
·>Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны.
·>Все остальные кастомные состояния контролируются кодом публичных методов.


А если я ошибся или не написал контроль?
В этом-то и смысл. Я не хочу это делать руками. Я хочу, чтобы это было автоматизированно.

Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.