Структуры данных в языке программирования с линейными типами

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

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

Однако мне не ясно, как представлять структуры данных, которые демонстрируют совместное использование и циклические ссылки в языке программирования с линейными типами (примерами таких структур данных являются DAG и другие графы, представленные списками смежности или чем-то еще, циклическими списками). Можем ли мы сделать это? Если это невозможно, каким образом мы должны расширить язык, чтобы приспособить такие структуры данных?

Наиболее сложный пример, который я нашел до сих пор, это двусвязный список. Есть ли другие примеры?

Линейность не является достаточным ограничением для определения уникального представления с сохранением состояния, поэтому ответ на ваш вопрос зависит от того, как вы интерпретируете линейную логику в терминах состояния. Это обычно отражается в том, как вы должны интерпретировать модальность$!A$

Если ваша предполагаемая семантика ссылок говорит о том, что все указатели являются уникальными значениями (т. Е. Существует не более одной ссылки на объект), тогда дагы и графовые структуры не могут быть выражены по той тавтологической причине, что даг может содержать несколько ссылок на тот же объект. В этом случае Должен быть вычисление , которое создает новое значение типа , так как вы хотите MAPS И .$!A$$A$$\delta_A : !A \multimap !A \otimes !A$$\epsilon_A : !A \multimap A$

Тем не менее, предположим, что вы хотите представлять обмен . Затем объекты можно собирать с помощью подсчета ссылок с помощью карт и могут быть реализованы как операции, которые просто увеличивают количество ссылок. В этом случае вы не можете использовать линейность, чтобы предположить, что всегда безопасно изменять значения, так как существует совместное использование. Но вы можете убедиться, что все выделение памяти в вашей программе явное и что в куче нет циклов.$!A$$\delta_A : !A \multimap !A \otimes !A$$\epsilon_A : !A \multimap A$

Большинство практических реализаций линейных типов не используют ни одну из этих двух интерпретаций. Вместо этого ссылки рассматриваются как свободно дублирующиеся объекты, а то, что мы отслеживаем линейно, фактически является возможностями . Возможности не являются значениями времени выполнения; они являются чисто концептуальными объектами, предназначенными для представления разрешения на доступ к ссылке. Идея состоит в том, что вы программируете в стиле передачи разрешений, и поэтому даже если имеется много ссылок на один и тот же объект, чтение или изменение фрагмента состояния может происходить только в том случае, если у вас также есть возможность доступа к нему. А поскольку возможности линейны, вы знаете, что только вы можете изменить их.

$$\array{ \mathsf{new} & : & \forall \alpha. \;\alpha \multimap \exists c : \iota. \mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \\ \mathsf{get} & : & \forall \alpha, c:\iota. \;\mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \multimap \alpha \otimes \mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \\ \mathsf{set} & : & \forall \alpha, c:\iota. \;\mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \otimes \alpha \multimap \mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \\ \mathsf{copy} & : & \forall \alpha, c:\iota.\; \mathsf{ref}(\alpha,c) \multimap \mathsf{ref}(\alpha,c) \otimes \mathsf{ref}(\alpha,c) }$$

В приведенном выше API-интерфейсе находится диапазоне , некоторый домен индексов времени компиляции и диапазоны в зависимости от типов. У нас есть тип который является возможностью, индексированной , и тип , который является типом ссылок на доступ к которым имеет возможность . Вызов и для ссылки требует наличия возможности , а вызов создает новую ссылку и новую возможность с общим индексом. Тем не менее,$c$$\iota$$\alpha$$\mathsf{cap}(c)$$c$$\mathsf{ref}(\alpha, c)$$\alpha$$c$$\mathsf{get}$$\mathsf{set}$$c$$\mathsf{new}$$\mathsf{copy}$- для ссылки не требуется доступ к каким-либо возможностям, поэтому любой может скопировать ссылку, если он не заглядывает внутрь нее.