Эмулятор фонетических переходов (WTE)

[Алексей Гринь]

DSL для эмуляции фонетических переходов посредством компутера, aka от ПИЕ к прагерманскому, и т.д. Кодовое имя WTE.
Пока — эскиз части синтаксиса; очевидно, что придётся по мере надобности расширять, интересны первые комментарии/мысли.

Пример:

Код Выделить Развернуть

Stage 0
{
public
     ḱ: velar, palatal=true, voiced=false;
     k: velar, palatal=false, voiced=false;
     ǵ: velar, palatal=true, voiced=true;
     g: velar, palatal=false, voiced=true;
     t: dental, voiced=false;
     d: dental, voiced=true;

     macro plain = ~palatal;
}

Stage 1 inherits Stage 0
{
     .Name = "PalatalPlainVelarMerger";

private
     t: stage1_lenitor
     d: stage1_lenitor

public
     for all [velar & palatal] = match (`k+1)
                                        | stage1_lenitor -> `k ^ (`k+1).voiced ^ plain
                                        | _ -> `k ^ plain;
                               
}

В данном примере palatal velars переходят в plain velars; а перед t/d ещё и ассимилируются по звонкости.

Stage 1 inherits Stage 0 {

И так, трансформации (фонетические переходы) группируются в стадии (ключевое слово Stage). Стадия это некая отдельное состояние языка, с описанием новых переходов, новыми звуками и т.д. Стадия может наследовать другую стадию (ключевое слово inherits): т.е., новое состояние языка наследуют существующие звуки, добавляя что-то новое, изменяя или удаляя. При наследовании, команды исполняются последовательно от стадии-родителя к стадии-потомку. Внутри стадии все команды параллельны друг к другу. Любая новая стадия может наследовать любую существующую стадию, поэтому можно будет создавать описания языков-потомков просто указывая файл-описание языка-родителя и номер стадии его развития.

Основным идентификатором стадий я решил сделать числа (Stage 0, Stage 1 etc.), потому что придумывать названия для каждой промежуточной стадии как-то накладно. Но есть возможность добавлять произвольные атрибуты к стадиям, через синтаксис ".Свойство=значение;" как в примере выше.

ǵ: velar, palatal=true, voiced=true;

Далее идёт перечисление звуков через синтаксис "символ: атрибут, атрибут, ..., атрибут". Символом атрибута может быть любой набор Unicode-значений, это всё условности. Атрибут символа это некая абстрактная единица его описания, атрибут можно рассматривать двояко: и как просто свойство, и как название фонетической группы. Напр., звуки k и g могут иметь атрибут "velar". Программе без разницы, что это значит, это просто некая условность. По умолчанию, если значение атрибута не установлено, то подразумевается true.

Когда наследуются стадия, и описание уже имеющегося звука встречается в потомке ещё раз, это значит, что мы должны перезаписать (override) указанные его атрибуты. Это полезно, когда качество звука несколько меняется, но мы всё равно хотим использовать старый символ. Также это полезно для случаев, частных для конкретных переходов. Дело в том, что атрибуты могут быть публичными и приватными, как можно видеть в примере выше. Приватные описания не наследуются и не видны потомкам. Напр., в примере выше t и d получают в Стадии1 новый атрибут stage1_lenitor. Он действителен только для текущего этапа. С его помощью в правилах перехода мы можем обращаться к t и d по атрибуту stage1_lenitor (к любым звукам с таким атрибутом).

for all [velar & palatal] = match (`k+1)
                                        | stage1_lenitor -> `k ^ (`k+1).voiced ^ plain
                                        | _ -> `k ^ plain;

Основная логика стадии.

Синтаксис "for all [velar & palatal]" значит «найти в введённом слове все звуки, которые имеют атрибуты "velar" и атрибут "palatal"».
Далее происходит pattern-matching с помощью ключевого слова match. `k это произвольное название переменной. Переменные должны иметь перед собой знак `, чтобы отличать их от названий атрибутов (p.s. как вариант писать переменные в UPPER-CASE). Pattern-matching здесь как в функциональных языках типа Haskell/OCaml: мы сравниваем то, что в скобках стоит целиком; а значения переменных, встреченных внутри таких скобок, автоматически высчитываются на основе всего выражения в скобках. Т.е., в данном случае мы производим pattern-matching (анализ) выражения (`k+1) что значит "символ во введённом слове, следующий за текущим", при этом значение `k высчитывается как "текущий символ во введённом слове". В теории можно будет ввести больше подобных шаблонов, напр. в отношении ударения в соседних слогах и т.д.

| stage1_lenitor ->

Далее символ, следующий за текущим во введённом слове (если бы имели for loop, то это был бы i+1) сравнивается с stage1_lenitor: есть ли у него такой атрибут? Если есть, то логика идёт дальше направо после оператора ->. Если такого атрибута нет, то логика идёт ниже за оператор |. Т.е. мы смотрим: если следующий звук после любого velar palatal звука является stage1_lenitor (т.е. t или d), то мы идём вправо по текущей ветви, иначе идём вниз и продолжим сравнивать. Знак _ значит «если ни одно сравнение выше не было верно, выполнить тогда это, чё уж поделать».

Внутри ветви мы можем иметь ещё один вложенный мэтчинг, или уже возвращать значение. Возвращённое значение подставляется вместо оригинального звука во введённом слове. Оператор ^ значит «к переменной слева добавить/изменить свойство, указанное справа». Справа может быть или константа типа velar, или же ссылка на другой звук и его свойство. См.:

`k ^ (`k+1).voiced

В данном случае мы говорим, что трансформированный звук во введённом слове есть тот же старый звук, однако мы ещё добавляем (^) к нему атрибут voiced (может быть true или false) у следующего звука (`k+1) Т.е. производим регрессивную ассимиляцию по звонкости. Можно отрицать атрибуты с помощью оператора ~. Т.е. например "`k ^ ~palatal" значит депалатализация.

И последний момент. После махинации с атрибутами, мы имеем набор входных символов, но с изменёнными атрибутами. Программа теперь в глобальном списке звуков ищет подходящие звуки с подобными атрибутами. Поэтому мы в начале сказали, что нельзя иметь звуки с идентичными наборами атрибутов. Т.е. программа берёт во входном слове, скажем, звук ḱ (атрибуты {velar, palatal}), по инструкции удаляет у него атрибут palatal так, что теперь это {velar, not palatal}, и смотрит: какой же звук у нас имеет набор набор атрибутов  {velar, not palatal}? Ах, так это же k! Вот и произошёл фонетический переход.

Мысли? Это только один случай (я просто пока ещё не думал о других), но направление вот такое.

[Bhudh]

(Google) "sound change applier"

[Алексей Гринь]

Другой возможный тип шаблона:

match (X<<K>>Y) | (_, velar, dental & voiced) -> ...

Тогда X, K, Y мэтчатся как предпоследний, текущий и следующий звуки. Каждый элемент матчится в правой части с соответствующим элементом в скобках. Знак _ значит игнорирование.
Варианты: match (K>>Y) или match (Y<<K)

(Google) "sound change applier"

Программа SCA от //zompist.com?
Оно может решать нетривиальные вещи? Алсо cryptic. С таким синтаксисом как у них, можно было уж и сразу вещи на коленке использовать, типа bash или regexp, у меня как-то понагляднее и посерьёзнее... Если сравнивать с языками программирования, то судя по их конвенциям типа:

S=ptc
    Z=bdg

то у меня явно более high-level. С их cryptic/write-only переменными запутаться можно, без сто грамм не разберёшь, что Z это звонкие смычные (определённые через фрикатив!), особенно если правил очень много.
Основной синтаксис x/y/z, типа «изменить этот символ на этот символ перед/после такой вот группы». Сюда каких-то дополнительных сложных условий не вставить без введения кучи непонятных переменных с недопереподвывертом (для примера типа "геминированные дегеминируются после безударных гласных")

Что касается IPA Zounds, то судя по всему он заточен под IPA, при том что большинство реконструкций не используют чистый IPA.

[Bhudh]

Программа SCA от //zompist.com?

Вообще это родовое название таких программ.
Я вот иногда с ASCA играюсь, которая из сети уже выпилилась , и там названия переменных можно задавать любые, да и синтаксис интереснее.

[гранитокерам]

интересненько. подписуюсь