Общий Язык Описания Структуры Данных

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

другой, немного более абстрактный вопрос: существует ли реальная разница между нормативной спецификацией структуры данных (что она делает) и ее реализацией (как она это делает)? Более конкретно, следует отделить реализации тот же требования считаться разными структуры?

6
data-structures declarative programming-languages

4 ответов

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

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

3

вас могут заинтересовать языки спецификации обмена сообщениями / сериализации данных, такие как буферы протоколов Google, а также ASN.1. Это немного другой наклон, чем вы ищете, но в том же духе.

оба способа объявления общих сообщений для связи. Спецификации сообщений буферов протокола "компилируются" на разные языки, но центральный протокол согласован. АСН.1 имеет несколько различных утилит компиляции, а также другой протокол представления, остающиеся логически совместимыми с различными литеральными реализациями. Посмотрите на XER, PER против BER, например.

Я хотел бы язык спецификации, который просто сосредоточится на простой упакованной двоичной компоновке против логической структуры памяти. Возможно, простые структуры C являются самым простым общим способом выражения этого. Я надеялся на АСН.У меня был какой-то способ добраться до этого, но, посмотрев на него немного, ASN.1 PER близко, но не совсем.

изменить: Apache Бережливость и Capn ' Proto также может быть интересным.

3

в динамической логике есть подходы к такого рода вещам, которые пытаются захватить семантику программ. Однако смысл с точки зрения динамической логики заключается в предпосылках и постусловиях и является агностическим в отношении фактического осуществления перечня.

эти структуры данных по своей сути связаны с реализацией, так как единственное различие между связанным списком и массивом-это то, как он выложен в памяти.

для это, есть общий язык определения данных - - - любой язык программирования высокого уровня - C, C++, java-который определяет это. Любой из них является таким же общим, как и другой, поскольку в этом контексте любой из них может быть скомпилирован с другим.

2

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

он может автоматически генерировать реализацию (на Java или C++, на момент написания этой статьи) из спецификации структуры данных, написанной на его собственном языке. Спецификация описывает абстрактное государство, операции обновления и операции запроса структуры данных, а также инвариантов, которые должны поддерживаться и предположений, которые могут быть использованы решателем для оптимизации реализации. Например, вот частичная спецификация для структуры данных графика:

Graph:
    handletype Node = { id : Int }
    handletype Edge = { src : Int, dst : Int }

    state nodes : Bag<Node>
    state edges : Bag<Edge>

    // Invariant: disallow self-edges.
    invariant (sum [ 1 | e <- edges, e.val.src == e.val.dst ]) == 0;

    op addNode(n : Node)
        nodes.add(n);

    op addEdge(e : Edge)
        assume e.val.src != e.val.dst;
        edges.add(e);

    query out_degree(nodeId : Int)
        sum [ 1 | e <- edges, e.val.src == nodeId ]

    // …

его реализация описана в быстрый синтез быстрых коллекций и Обобщенный Синтез Структуры Данных от Calvin Loncaric, Эмина Торлака, и Майкл Д. Эрнст.

0