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

Припустимо, що ми маємо справу з мовою програмування, яка має підтримку лінійних типів (терміни лінійного типу можуть бути використані не більше одного разу, так би мовити). Це дозволяє обробляти деякі обчислювальні ефекти (такі як мутація, навіть зміна типу операнду) таким чином, що є проблематичним для мов, системи типів яких функціонують лише на "вічних істинах".

Багато структур даних можна охарактеризувати за допомогою індуктивних типів (списки та дерева - канонічні приклади). Якщо додати до суміші лінійні індуктивні типи, ми можемо також обробляти зміни даних, що змінюються.

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

Найпопулярніший приклад, який я знайшов поки що, - це подвійно пов'язаний список. Є інші приклади?

pl.programming-languages type-theory linear-logic

— Bjørn Kjos-Hanssen
джерело

Лінійність не є достатнім обмеженням для закріплення унікального репрезентативного стану, тому відповідь на ваше запитання залежить від того, як ви інтерпретуєте лінійну логіку з точки зору стану. Це, як правило , відбивається в тому , як ви повинні інтерпретувати модальність. $!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$

Більшість практичних реалізацій лінійних типів не використовують жодної з цих двох інтерпретацій. Натомість посилання розглядаються як вільно дублюються об'єкти, і те, що ми відстежуємо лінійно, насправді є можливостями . Можливості не є значеннями виконання; вони суто концептуальні утворення, які призначені для представлення дозволу на доступ до посилання. Ідея полягає в тому, що ви програмуєте в стилі передачі дозволу, і тому навіть якщо є багато посилань на один і той же об'єкт, читання або зміна фрагмента стану може відбуватися лише в тому випадку, якщо ви також маєте можливість отримати доступ до нього. А оскільки здатність лінійна, ви знаєте, що змінити її можете лише ви.

\begin{matrix} n e w & : & \forall α . α ⊸ \exists c : ι . c a p (c) \otimes r e f (α, c) \\ g e t & : & \forall α, c : ι . c a p (c) \otimes r e f (α, c) ⊸ α \otimes c a p (c) \otimes r e f (α, c) \\ s e t & : & \forall α, c : ι . c a p (c) \otimes r e f (α, c) \otimes α ⊸ c a p (c) \otimes r e f (α, c) \\ c o p y & : & \forall α, c : ι . r e f (α, c) ⊸ r e f (α, c) \otimes r e f (α, c) \end{matrix}

$\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}$ -введення посилання не вимагає доступу до будь-яких можливостей, тому кожен може скопіювати посилання до тих пір, поки не загляне всередину.

— Ніл Кришнасвамі
джерело

Дякую за продуману відповідь. Мене все ж цікавить, чи існує (технічна) відмінність між псевдонімом та спільним доступом? Чи є які-небудь системи, які можуть поступово переходити від лінійних (щонайбільше однієї посилання) до спільних, щонайменше, n посилань, до спільних без обмежень?

1. Згладжування та обмін - синоніми. 2. Так, інтерпретації стилю спроможності, доповнені дробовими дозволами Бойленда, це дозволяють. Дивіться також нещодавню роботу Поттьє з питань розрахунків можливостей для теорії, а також роботи Олдріха та Біргофа над множиною для впровадження.

— Neel Krishnaswami