Полностью заменить внутренний синтаксис в isar?
Я заинтересован в использовании Isar в качестве мета-языка для написания формальных доказательств о J, исполняемой математической нотации и языке программирования, и я хотел бы иметь возможность использовать J в качестве внутреннего синтаксиса.
J состоит из большого числа примитивов и присваивает (несколько!) Значения каждому символу ASCII, включая одинарные и двойные кавычки.
Где я могу найти документацию или пример кода для реализации совершенно нового внутреннего синтаксиса? Или это вообще возможно? (Я искал в src/ каталог, но это несколько подавляющее, и я не совсем уверен, что я ищу.)
2 ответа
Ответ B: построение на HOL с импровизированным J-синтаксисом
Разъяснение это хорошо, но я не люблю делать рукопожатие, необходимое для этого.
Мой первый ответ ниже был в значительной степени основан на вашей фразе "совершенно новый синтаксис", и я думаю, что это половина ответа на такой вопрос:
Предположим, гипотетически, что мне нужен синтаксис, очень близкий к синтаксису J. Что бы это потребовало в отношении Изабель /HOL?
Мой ответ:
- Скорее всего, я бы сказал, что вам придется определить большую часть синтаксиса для констант, функций и классов типов Isabelle/HOL, что потребует от вас обширного редактирования стандартного дистрибутива Isabelle/HOL, чтобы вернуть его обратно за работой. И некоторый синтаксис в Изабель / HOL, вы, скорее всего, не сможете убрать.
- Или вы должны начать все сначала, с импорта
Pureв качестве отправной точки. Пожалуйста, смотрите мой первый ответ ниже.
Просто синтаксис? Теперь мы вернулись в обычное пользовательское пространство
Настройка синтаксиса в Isabelle / HOL делает нас всех потенциальными настоящими артистами.
Существуют расширенные способы использования возможностей определения синтаксиса, такие как parse_translation, с Изабель /ML, но я не использую продвинутые методы. Я использую несколько основных ключевых слов для определения синтаксиса: notation, no_notation, syntax, а также translations, вместе с abbreviation когда я либо хочу изменить входные аргументы функции, либо не хочу испортить нотацию для стандартной функции HOL.
notation, no_notation легкие
Я не пользуюсь no_notation много, но это нужно в вашем арсенале. Например, см. Можно ли перегрузить нотацию для операторов, которые назначены для bool и list?,
Использование notation Это просто, как только вы увидите несколько примеров.
Для инфиксного оператора plus :: 'a => 'a => 'a, вот несколько примеров:
notation plus (infixl "[+]" 65)
notation (input) plus (infixl "[+]" 65)
notation (output) plus (infixl "[+]" 65)
С этим примером я вошел в область возможного испорченного обозначения для plus, который является оператором для стандартного класса HOL.
Строка сверху, которая не испортит выводной экран, является строкой, которая использует (input),
За notation Чтобы найти примеры, выполните greps в THY-файлах или на src/HOL папку, потому что здесь слишком много вариантов, чтобы привести множество примеров.
abbreviation и не портить другие вещи
Предположим, я хочу действительно жесткую привязку для стандарта even сказуемое. Я мог бы сделать что-то вроде этого:
notation (input) even ("even _" [1000] 1000)
notation (output) even ("even _" [1000] 999)
Я говорю "мог", потому что я не знаю, как это испортит стандартное применение функции even Я бы не хотел этого делать.
Почему 999? Это просто из проб и ошибок, а также из опыта, где я знаю, что только эта следующая строка испортит declare[[show_brackets]]:
notation even ("even _" [1000] 1000)
Так обстоит дело с определением синтаксиса. Это комбинация проб и ошибок, поиск примеров для использования в качестве шаблонов, опыт и последующее замечание, что вы что-то напутали.
Я забыл все вещи, которые abbreviation помогает мне с Инновационное использование abbreviation может удержать вас от необходимости использовать более сложные методы.
Вы можете использовать его для перестановки аргументов для некоторых обозначений:
abbreviation list_foo :: "'a list => 'a => 'a list" where
"list_foo xs x == x # xs"
notation
list_foo ("_ +#+ _" [65, 65] 64)
Этот пример является примером нескольких примеров. Я просто пытался сделать быстрый пример, и у меня было что-то вроде (infixl "_ +#+ _" [65, 65] 64), Существует не так много различий в том, как я определяю нотацию, поэтому мне пришлось найти пример в Set.thy чтобы показать мне, что мне нужно было infixl, так как я хотел использовать [65, 65] 64 как вариант того, как вы можете определить синтаксис.
Я правильно расставил приоритеты [65, 65] 64? Я понятия не имею. Это просто для быстрого примера.
syntax а также translations
Вы должны иметь его в своем арсенале, но это вызовет у вас много трудоемкого горя. Делай greps и найди примеры. Попробуйте это и это. Когда вы наткнетесь на что-то, что работает, и думаете, что вам это нужно, тогда сохраните это где-нибудь. Если вы этого не сделаете, и внесете небольшое изменение, которое разрушит то, что у вас было, и вы не сохранили то, что у вас сработало, вы пожалеете, что потратили много времени, пытаясь вернуться к тому, что сработало.
Справочное руководство по Isar, isar-ref.pdF#175 содержит небольшую информацию. Кроме того, вы можете посмотреть использование notation в этом PDF.
Непрошеная часть Ответа Часть B
В своем комментарии вы говорите это:
У меня уже есть "логика программирования", которую я хочу реализовать http://www.cs.utoronto.ca/~hehner/FMSD/, и J - это язык, который особенно хорошо подходит для формальных доказательств. Я просто пытаюсь понять, как повторно использовать логическую инфраструктуру Изабель, а не писать свою собственную.
Короткий, небезопасный ответ от кого-либо на такой вопрос, даже хеджированный, выглядит так:
В Isabelle / HOL вы, скорее всего, не сможете сделать то, что хотите сделать с J.
Более безопасный и короткий ответ:
Скорее всего, у вас возникнут серьезные проблемы при попытке сделать то, что вы хотите сделать с J в Изабель /HOL.
Это короткие, быстрые ответы. Как ответ на такой вопрос может быть коротким, если он действительно пытается ответить на вопрос почему?
В конечном итоге он становится ответом "дано все, что я знаю", потому что часто дело не в том, что это невозможно сделать, а в том, что нужная группа людей, получая достаточно длительный период времени, учитывая правильную технологию, не пока что сделал это.
Мои заголовки ниже становятся моими точками. Я пытаюсь прорваться через все остальное довольно быстро, но все же документирую вещи.
Если вы используете HOL в качестве логики, мой первоначальный ответ по-прежнему применяется, если его немного изменить.
Развитие Isabelle / HOL в том виде, в каком оно сегодня, начиная с Робина Милнера, я называю логикой ракетостроения.
Из всех моих поисков и всех моих слушаний выясняется, что еще много логики в области ракетостроения, которую необходимо разработать, прежде чем помощники по проверке могут быть использованы для формальной проверки любой оле-программы, написанной на любом оле-императивном языке программирования.
У вас есть логика, HOL, но вы намекаете на то, что вы собираетесь реализовать нечто похожее на то, что хотят многие люди, и давно этого хотели.
Что ниже, чтобы поддержать то, что я говорю здесь.
J как язык, хорошо подходящий для формальных доказательств
Там будет традиционная форма анализа алгоритмов, как Введение в алгоритмы, 3-й, по Cormen & Leiserson.
Я буду называть программные доказательства в Изабель / HOL механизированными доказательствами и официально проверенными программами. Я также считаю некоторые карандашные и бумажные доказательства формальными.
В традиционных немеханизированных доказательствах, да, я думаю, J - это язык, который хорошо подходит для формальных доказательств, что я говорю, потому что вы сказали мне, что это так. Но тогда на больших популярных языках программирования, в частности C++ и Java, написаны учебники по формальному анализу алгоритмов. Таким образом, с традиционными немеханизированными доказательствами они также могут быть аргументированы.
J в контексте механизированных доказательств
Нет, этот язык не подходит для формальных механизированных доказательств. Он использует (лучшее слово, чем использует?) Императивное программирование и кажется объектно-ориентированным.
В основном, я просто повторяю то, что читал, говорят другие. Я начну делать заявления как мои личные выводы. Это сделает вещи короче.
Функциональные языки программирования хороши для формальных доказательств. Традиционное программирование включает в себя изменяющиеся переменные, и, возможно, это увеличивает сложность доказательств.
Я искал утверждение об объектно-ориентированных языках в списке рассылки, но если вы слушаете, люди говорят, что они сделали ту или иную особенную вещь, но это никогда не напоминает: "Вот полная разработка и формализация, которая легко позволяет вам проверить программы, написанные на языке программирования общего назначения X".
Формальное доказательство, среди прочего, касается навязываемого набора аксиом, где выбор аксиом является результатом логики ракетостроения в течение ряда лет, потому что нормой является то, что казалось бы желательным набор аксиом не должен быть логически последовательны.
Для формальной проверки вы не можете обойти соблюдение аксиом. В учебниках числовые константы просто появляются и привыкают, и они рассуждают о них.
В формальном доказательстве числовые константы, в частности действительные числа, трудно использовать. Спросите себя: "Что такое натуральное число, целое число, рациональное число и константа действительного числа в Изабель /HOL?" Теперь, если вы ответили на этот вопрос, то спросите себя: "Как мне сделать доказательства, включающие натуральные числа, целые числа, рациональные числа и действительные числа в Изабель /HOL?"
Теперь сопоставьте эти вопросы с тем фактом, что числовые константы просто появляются в большинстве учебников и привыкают. Это не так, как это работает в формальном доказательстве. Там нет волшебного появления систем счисления и констант. Может быть немного магии в автоматизации доказательств с участием чисел, но я почти уверен, что обречен, если мой план когда-нибудь станет зависеть от такой магии.
L4.verified (и AutoCorres)
Есть проект L4.verified NICTA. (Обновление: и на http://sel4.systems/ при совместном кредите, предоставленном General Dynamics C4 Systems. Причастность такой крупной компании, как GD, поддерживает мой тезис о том, что формальная проверка императивных языков программирования давно востребована.)
Цитата:
Мы выбрали ядро операционной системы, чтобы продемонстрировать это: seL4. Это небольшое высокопроизводительное микроядро 3-го поколения, содержащее около 8700 строк кода на языке Си.
Почему так избирательно? Почему не какая-нибудь программа ole C? Я думаю, что проверить C сложно. NICTA, они не маленькая, неопытная, не финансируемая группа.
(Обновление: в NICTA также есть связанный проект AutoCorres с его Руководством по быстрому запуску в формате PDF. Версия выпуска - v1.0, выпущенная 2014-12-16. Это должно означать, что они достигли основной цели, какой бы она ни была они должны были достичь. Когда я читаю их обзор на веб-странице AutoCorres, я воспринимаю это как поддержку того, что я говорю. Мне кажется, что они участвуют в какой-то логике ракетостроения, чтобы привести С в другую форму, по крайней мере немного логики в области ракетостроения. Я не знаю, что такое логика в области ракетостроения. Думаю, я могу с уверенностью сказать, что они используют логику уровня PhD для получения своих результатов.)
Книга Практическая теория программирования: откуда взялись числовые константы?
Я скачал PDF для книги "Практическая теория программирования".
Одна из первых вещей, которые я начал искать в этой книге, это "что такое числа и как они формализуются".
Системы счисления, мы принимаем их как должное, но они представляют все то, что трудно с формальным доказательством.
В книге, когда числовые константы просто появляются и только начинают привыкать, это, скорее всего, означает, что нет реальной формализации соответствующих систем счисления. Зачем? Создание констант системы счисления является чрезвычайно сложным.
Если числовые константы не были построены формально, то там нет никаких реальных формальных доказательств. Если они построены формально, жизнь все еще не легка.
Вот кое-что о сложности работы с настоящими онемями: выступление Ларри Полсона в НАСА в 2014 году.
Книга Практическая теория программирования: циклы пока
Еще одна вещь, которую я сразу начал искать, это пример традиционного цикла, в котором вы неоднократно модифицируете переменную.
Это начинается в Разделе 5.2.0. Во время цикла, aPToP.pdF# 76. Пример приведен на следующей странице, упражнение 265:
while ¬ x = y = 0 do
if y > 0 then y := y - 1
else (x := x - 1. var· y := n)
Вот вам классический пример использования изменяемого состояния (где я выполнял поиск по изменяемому состоянию, чтобы на самом деле проверить, правильно ли я использовал фразу, без четкого заключения).
У вас есть переменная, и вы изменяете ее содержимое. Это, как я слышу, или, таким образом, я делаю вывод, объясняет, почему вы обречены, когда речь заходит о желании проверить программы, которые вы пишете на J.
Я не хочу, чтобы ты был обречен. Когда вы разместите на GitHub "Формализация языка программирования J в Изабель /HOL - со многими демонстрациями, демонстрирующими легкость, с которой J-программы могут быть официально проверены", я буду там.
Coq. Что там для императивного программирования?
У меня есть догадка, что Coq было бы лучше, если бы моим основным приложением было программирование.
Я соблюдаю минимальные требования, выполняя поиск в Google по требованию.
Первая ссылка Ynot.
Поддерживает ли это вашу идею, что вы должны быть в состоянии взять J и реализовать его в Isabelle/HOL?
Не для меня. Это поддерживает мою идею о том, что если кто-то, кто много знает и может принять решение о разработке языка, который он собирается использовать, то он может выполнить формальную проверку обязательных программ в помощнике по проверке.
С другой стороны, вы сначала выбираете язык программирования, а затем собираете вокруг него помощника по проверке.
Мой интерес к J, по шкале от 0 до 10
На данный момент мой интерес к J в основном равен 0, по шкале от 0 до 10.
Предположим, однако, что вы создали веб-сайт "Как дела с этим", и я подписался на него с помощью программы чтения RSS.
Дело не в том, что я не хочу, чтобы вы официально проверяли J-программы в Изабель / HOL, а в том, что я не думаю, что вы сможете это сделать, и поэтому у меня нет причин беспокоиться об этом, так как я не это не нужно
Однако, если я увидел новую активность в своем RSS-ридере для вашего сайта, и она сказала мне, что вы преуспели, и вы разместили свой код на GitHub, то мой интерес переходит к 10. Кто-то делает формализацию для полноценного языка программирования в Изабель / HOL, где доказательства могут быть реализованы достойно, например, для функционального программирования, а не только для небольшого подмножества языка, это то, что может заинтересовать.
Оригинальный ответ
Прошло четыре дня, это праздничный период, и эксперты могут не появиться, поэтому я отвечу.
Я стараюсь найти короткий ответ как можно быстрее, но сначала я скажу несколько вещей (на самом деле, много), чтобы попытаться дать моему быстрому ответу некоторую поддержку.
Я не думаю, что вы используете словарь Изабель совершенно правильно ("внутренний синтаксис"), но я беру две ваши фразы с добавлением моего смелого акцента:
- Я заинтересован в использовании Изара в качестве мета-языка для написания формальных доказательств о J...
- Где я могу найти документацию или пример кода для реализации совершенно нового внутреннего синтаксиса?
Я не из тех, кто хочет тратить время на разъяснения, так что вот что я принимаю в качестве ваших требований, где я добавляю несколько деталей, от слушания экспертов и выяснения некоторых вещей для себя, исходя из того, что они сказал:
- Вы хотите логику, которую можно использовать для рассуждения о программах, которые вы написали на J, где вы используете минимальную логику Isabelle/Pure в качестве отправной точки (потому что вам нужен полный синтаксис J и вы хотите начать все заново).
- Вы хотите определить синтаксис, используя Isabelle/Isar, который реализует (или моделирует) полный синтаксис и функциональность J. (Вы не сказали, что хотели только рассуждать о подмножестве синтаксиса и функциональности J.)
К сожалению, мой короткий ответ не полностью настроен.
Чтобы попытаться понять, о чем вы просите, я приведу цитату с главной веб-страницы J, где акцент сделан на меня:
J - современный высокопроизводительный универсальный высокопроизводительный язык программирования.
Теперь я перефразирую универсальное как полномасштабное, как C, как Pascal, как и многие высокоуровневые языки программирования общего назначения, и напоминаю вам, что вы хотите две вещи:
- Логика в Изабель, которая, безусловно, должна быть сопоставима по изощренности, функциональности и силе с логикой Изабель /HOL.
- Синтаксис и использование (или моделирование?) Полноценного языка программирования J в Изабель, начиная с Изабель / Пьюр, где ваша реализация обязательно должна быть
- немного сопоставимы по сложности и мощности с генератором кода Isabelle/HOL, который может экспортировать код для 5 языков программирования, SML, OCaml, Haskell, Scala и Eval (Isabelle/ML),
- и сопоставимы по мощности с логическим механизмом Изабель / HOL, который реализует (или моделирует) высокоуровневые функциональные программные конструкции, такие как
definition,primrec,datatype, а такжеfun, которые позволяют человеку определять функции и новые типы данных, а также стандартную библиотеку типов Изабель / HOL, таких как пары, списки и т. д.
Теперь, что я утверждаю, как мой личный вывод, заключается в том, что то, что вы хотите реализовать, по крайней мере так же сложно реализовать, как Изабель / HOL, что является результатом большого количества людей, сделанных за многие годы.
Пожалуйста, подумайте, что сказал Питер Ламмич в списке пользователей Изабель: " Мне нужен фиксированный изменяемый массив:
Сам HOL не поддерживает изменяемые массивы.
Однако есть Imperative_HOL, у которого есть куча монад, поддерживающих изменяемые массивы.
Затем есть afp/Collections/Lib/Diff_Array, который обеспечивает реализацию массивов, которая ведет себя чисто функционально, но эффективно, если доступна только последняя версия.
Однако, если вы не стремитесь к эффективной исполняемости, а ищете только абстрактную модель памяти, бессмысленно использовать вышеупомянутые типы, поскольку эффективность достигается ценой дополнительных затрат на формализацию.
Из цитаты я хочу сказать, что Isabelle/HOL, хотя и достаточно мощный, чтобы быть одним из ведущих конкурентов в качестве помощника по проверке, не использует стандартные массивы в основной части своей логики, которую вы получаете при импорте. Complex_Main,
Позволять (L, P) быть парой, где L это логика и P это язык программирования. Я хочу поговорить о двух парах, (Isabelle/HOL, Haskell), и что ты хочешь, (x, J), где x ваша еще не определенная логика
Между Изабель / HOL и Haskell существует очень тесная связь. Например, классы типов Isabelle / HOL объявляются как классы, похожие на Haskell, а также, что Haskell является чисто функциональным языком программирования, а Isabelle /HOL - чистым. Я не хочу идти дальше, потому что, будучи не экспертом, я обязательно скажу что-то неправильное.
Вот что я хочу сделать:
- Haskell - полноценный язык программирования,
- Изабель /HOL - это мощная логика,
- Haskell - один из языков программирования, который можно экспортировать из Isabelle/HOL,
- но все же Изабель / HOL не реализует (или не моделирует?) большую часть Haskell.
Я не хочу говорить как авторитет. Но, послушав, я пришел к выводу: это логика. По-видимому, гораздо проще реализовать языки программирования, чем разрабатывать логику для рассуждения о программах.
Короткий ответ заключается в том, что, на мой взгляд, пример кода, который вы ищете, это Изабель / HOL, потому что, хотя есть несколько примеров в Isabelle2014/src других логик, что я процитировал, что вы говорите и хотите, и что я говорю, что вы говорите и хотите, это то, что вы хотите и нуждаетесь в full blown логика, как у Изабель /HOL.
Отсюда я пытаюсь выбросить несколько быстрых идей.
Мне нравится эта машина, но я действительно хочу жидкий азот для топлива
Это моя шутка.
Вы разговариваете со старшим инженером, который работал в этой отрасли в течение многих лет и приобрел экспертные знания, накопленные в автомобильной промышленности за многие годы, и вы говорите: "Мне нравится эта идея автомобиля, но моя идея - использовать азотный топливный элемент вместо бензина. Как бы я это сделал? "
Больше логики в папке Isabelle2014/src
Ссылки на библиотеки Theory для Isabelle2014 на веб-странице дистрибутива совпадают с папками в Isabelle2014/src папка.
в src папка, вы увидите папки CCL, Cube, CTT, и другие.
Я уверен, что это хорошо для обучения, хотя, вероятно, все еще трудно понять, но это не то, что вы описали. Вы просите о полномасштабной реализации того, что моделирует язык программирования.
Если использование C/C++ настолько велико, то почему для C/C++ не нужно то, что вам нужно?
Я думаю, по крайней мере, что-то вроде C. Я нашел https://vcc.codeplex.com/. Опять же, я не эксперт, поэтому я не хочу говорить точно, что там, а что нет.
Я хочу сказать, что C и C++ существуют уже давно и активно используются, и приведенная выше ссылка показывает, что есть профессионалы, которые долгое время интересовались проверкой программ на C, что имеет большой смысл,
Но после всех этих лет, почему проверка программ не является неотъемлемой частью программирования на C/C++?
От прослушивания тех здесь и там и в списке рассылки, а также от слушания таких людей, как Мартин Одерски, архитектор Scala, они всегда хотят говорить об изменчивом и неизменном состоянии, в котором традиционное программирование, как C, и я предполагаю, что J, будет в категории использования изменяемого состояния, очень много его использования. Со временем я много раз слышал, что изменяемое состояние затрудняет рассуждения о том, что делает программа.
Моя точка зрения снова заключается в том, что проектировать языки программирования намного проще, чем рассуждать о программах.
Наконец, маленький источник
Если бы был какой-то спор по этому вопросу, я мог бы быть менее многословным, хотя, возможно, нет, хотя, возможно, и так, потому что даже не дал ответа.
Мое последнее замечание - это перефокусировка пунктов выше. Это стоит знать немного истории, и я начинаю путь перед Черч и Карри.
Я знаю, что Изабель / HOL является результатом того, что началось в Кембридже, с Робина Милнера, автора ML, затем Майка Гордона из группы HOL, затем Ларри Полсона, автора использования Pure в качестве минимальной логики для определения других логик, и затем Тобиас Нипков объединился с ним, чтобы начать HOL как логику в Изабель, а затем Макарий Венцель наложил на все это синтаксис более высокого уровня, Изар (это больше, чем просто синтаксический сахар; это фундаментально для возможности структурированных доказательств), наряду с внешним интерфейсом PIDE и другими людьми по всему миру внесли большой вклад, многие из большой группы в TUM, в Германии, но есть и CERN в Австралии (обновление: CERN? это не шутка; я на самом деле знаю разница между ЦЕРН и NICTA: мир, о котором говорить нелегко), и обратно в европейское пространство, определенное швейцарское заведение, ETH, и еще больше мест, разбросанных по Германии и Австрии, UIBK, и обратно в Англия? Кого я пропустил? Я, конечно, и многие другие по всему миру.
Бродячий момент? Это то, что вы просите о чем-то, что воплощает в себе опыт отрасли. Это не плохо просить об этом. Это совершенно дерзко, и я могу быть совершенно неправ в том, что говорю, и пропустил эту папку в src, HOWTO по внедрению логики для языков программирования общего назначения, все в десяти простых шагах, отправьте свои 9,95 $ сейчас или евро, если это все, что у вас есть, вы делаете конверсию, я вам доверяю, но подождите, есть еще что-то, сделайте Изменить каталог на Isabelle2014/medicaldoctor и узнать, как стать хирургом мозга, тоже.
Это еще одна шутка, я утверждаю. Просто космический наполнитель, ничего более.
Во всяком случае, рассмотрим здесь строки с 47 по 60 HOL.thy:
setup {* Axclass.class_axiomatization (@{binding type}, []) *}
default_sort type
setup {* Object_Logic.add_base_sort @{sort type} *}
axiomatization where fun_arity: "OFCLASS('a ⇒ 'b, type_class)"
instance "fun" :: (type, type) type by (rule fun_arity)
axiomatization where itself_arity: "OFCLASS('a itself, type_class)"
instance itself :: (type) type by (rule itself_arity)
typedecl bool
judgment
Trueprop :: "bool => prop" ("(_)" 5)
Периодически я стараюсь понять эти несколько строк. Долгое время моей отправной точкой было typedecl bool и я не был обеспокоен попыткой понять, что было до этого, кроме этого HOL.thy импорт Pure,
Недавно, пытаясь выяснить типы и сорта в Изабель, после того, как выслушал экспертов, я наконец-то увидел, что эта линия - то, где мы получаем что-то вроде x::'a::type:
setup {* Object_Logic.add_base_sort @{sort type} *}
Еще один момент? Я вернулся к тому, что сказал ранее. Поскольку вы хотите полноценного, ваш пример - Изабель / HOL, но все же только первые 57 строк HOL.thy не легко понять. Но если вы не начнете с HOL, где вы будете искать? Что ж, если то, что вы обнаружите, окажется легким, есть хороший шанс, что это отчасти потому, что сотни людей на протяжении многих лет не прилагали усилий для того, чтобы все начать.
Или это могли быть только 3 человека, перечисленные в качестве авторов: Нипков, Венцель и Полсон. В любом случае, все еще есть многолетний опыт и образование, несмотря на то, что там, хотя HOL.thy не так долго, только 2019 строк. Конечно, чтобы понять, что в HOL.thy, вы должны по крайней мере иметь смутное понимание того, что Pure является.
Посмотрите на src/Cube папка. Это одна из примеров логики, которую я упомянул выше.
Есть только два файла, Cube.thy а также Example.thy, Это должно быть достаточно легко, но тогда это проблема, это слишком легко. Это не будет отражать изощренность Изабель /HOL.
Твои проблемы не моя проблема. Изабель / HOL хороша для рассуждений о математике, как и ее способность абстрагировать операторы с классами типов. И это хорошо для большего, например, определения функций с помощью функционального программирования, которые можно экспортировать в OCaml, Haskell, SML, Haskell и Eval.
Я просто новичок, вот и все, что я есть. Если есть лучший ответ, то я надеюсь, что он кем-то выдвинут.
Несколько замечаний по первоначальному вопросу:
Внешний синтаксис - это язык теории и доказательства Изара; чтобы изменить его, вы определяете дополнительные команды. Вы подвержены общим типам теоретического содержания, например
theory,local_theory,Proof.context, но эти типы очень гибкие и могут ассимилировать произвольные данные ML, специфичные для вашего приложения.Внутренний синтаксис - это язык типа / термина логики, то есть Pure для платформы и HOL для приложений (или любой другой логики, которую вы предпочитаете, хотя HOL настолько продвинут сегодня, что вы не должны игнорировать ее без веских причин). В конечном итоге вы прописываете простые лямбда-выражения.
Как для внешнего, так и для внутреннего синтаксиса вы должны соблюдать определенные понятия токенов (идентификаторы, строки в кавычках и т. Д.). Ваш язык должен соответствовать этому, если он должен сосуществовать напрямую с существующей синтаксической структурой.
Тем не менее, можно использовать совершенно разные языки во внешнем и внутреннем синтаксисе Изабель, используя цитаты. Например, см. Язык подготовки документа, основанный на LaTeX и ограниченный забавным {* ... *} маркеры для стенографического текста. Использование более основных цитат " ... " синтаксис строки ML Внутри внутреннего синтаксиса, '' ... '' (двойные одинарные кавычки) делают аналогичную работу.
В Isabelle2014 есть новое синтаксическое устройство текстовых картушей, которое делает эту работу более плавной. Например, смотрите примеры в Isabelle2014/src/HOL/ex/Cartouche_Examples.thy которые исследуют немного возможностей.
Другой текущий пример из Isabelle2014 - это язык рельсов в источнике документов Isabelle: он может служить практически автономным примером "предметно-ориентированного формального языка", определенного с нуля. Например, увидеть Isabelle2014/src/Doc/Isar_Ref/Document_Preparation.thy и посмотреть на различные варианты использования @{rail ...} - реализация этого в Isabelle2014/src/Pure/Tools/rail.ML - файл конечного размера, который нужно тщательно изучить, чтобы узнать больше.