Это во многом можно даже в Обероне, например, тип может называться "задача", а процедура "создайЗадачу". И чтобы такой код можно было поддерживать,
нужно, чтобы можно было искать слово "задача" в любых формах. Если технологии, описанные Павиа, для этого подходят, то работы русских лингвистов не нужны, а кириллический ЯП у нас уже есть.

Это полезно, но не строго обязательно. Я имею в виду, при моём подходе, когда мы стараемся поддерживать словоформы, но без фанатизма, и на смысл кода они не влияют. Без поиска по словоформам совсем уж туго. Чтобы сделать именно учёт падежей и их влияние на смысл кода, нужно менять язык программирования. Таких ресурсов у меня нет и не предвидится, скорее всего, никогда, если никто денег не даст, конечно. Даже если денег дадут, то разработка ЯП - это отдельное, длительное и очень рискованное мероприятие. Т.е. это должна быть боковая ветка разработки, и не в коем случае не один из её этапов. Введение разработки ЯП как этапа отодвигает завершение проекта лет на 10 вперёд. Сейчас в мире всё гораздо быстрее крутится. Даже просто сделать перевод A2 - это проект, безнадёжно отстающий от времени.

Отредактировано БудДен (2021-03-31 19:39:37)

В англоязычных ЯП жесткий порядок параметров, если его оставить, добавив падежи, они будут лишь синтаксическим сахаром, а должны нести вполне определенные возможности.

Уже писал, что если при этом не проверять соответствие падежа порядку, будет дыра для внедрения хитрых уязвимостей, когда мозг читает не то, что делается.
Поэтому, если писать окончания, то их надо обрабатывать, а не просто отбрасывать.

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

Отредактировано MihalNik (2021-04-01 00:42:40)

Мое замечание не совсем по теме, но я бы для такого ЯП выбрал более подходящий пример. Записывать в текстовой форме математические операции в школе не учат. Второй вариант с падежами выглядит понятнее первого, но к стыду своему вынужден признать, что без чтения описания языка я не понял, что там закодировано. Похоже на проверку ряда методом перебора делителей, но смутило деление пополам вместо квадратного корня. На всякий случай накидал наивный вариант по Эратосфену на диалекте Рефал-5 (язык не ориентирован на вычисления, однако позволяет свести задачу к обработке последовательностей, таким образом "навязывая" более эффективное решение).

#!/bin/refal -w

начало = <натуральные <решето (<ряд от 2 до 10000>)>>;

решето {
  (0    …) = 0    <решето (…)>;
  (?шаг …) = ?шаг <решето (<кратные ?шаг ?шаг (…)>)>; 
  () = ;
}

кратные {
  ?шаг 1     (? .вход) .выход  = <кратные ?шаг ?шаг        (.вход) .выход 0>;
  ?шаг ?счёт (? .вход) .выход  = <кратные ?шаг <?счёт - 1> (.вход) .выход ?>;
  … () .готово = .готово;
}

ряд {
  от ?    до ?     .ряд = .ряд ?;
  от ?мин до ?макс .ряд = <ряд от <1 + ?мин> до ?макс .ряд ?мин>;
}

натуральные {
  0 … =   <натуральные …>;
  ? … = ? <натуральные …>;
  = ;
}

Отредактировано С.Т. (2021-04-03 06:07:18)

В Рефале нет массивов. Функция получает на вход последовательность (т.н. Поле Зрения), далее происходит попытка сопоставить её с образцом (левая часть, до знака =). Если сопоставление успешно, формируется результат (правой частью, после знака =). Иначе повторяется для следующего предложения и т.п. Язык разрабатывался как раз для решения задач из названия темы.

Придётся переводить. Помимо ограничений на имена идентификаторов есть и другие отличия. В классическом Рефал-5 тип переменных (это не "целое" или "строка", как обычно, а количество вмещаемых переменной символов) определяется буквенным префиксом. Прежде всего, придётся заменить . и … на e. а ? на s.
Плюс поле зрения у меня выводится "само", без функции Prout. Вот готовый вариант:

* Refal5-PZ & Refal-05 compatible

$EXTERN Add, Sub; 

* syntactic sugar
*$ENUM From, To;

$ENTRY Go {
  = <Prout <Naturals <Sieve (<Series From 2 To 10000>)>>>;
}

Sieve {
  (0      e.Tail) = 0      <Sieve (e.Tail)>;
  (s.Mesh e.Tail) = s.Mesh <Sieve (<Aliquots s.Mesh s.Mesh (e.Tail)>)>; 
  () = ;
}

Aliquots {
  s.Mesh 1     (s.Cur e.In) e.Out = <Aliquots s.Mesh s.Mesh        (e.In) e.Out 0>;
  s.Mesh s.Cnt (s.Cur e.In) e.Out = <Aliquots s.Mesh <Sub s.Cnt 1> (e.In) e.Out s.Cur>;
  e.Stuff () e.Result = e.Result;
}

Series {
  From s.End To s.End e.Series = e.Series s.End;
  From s.Min To s.Max e.Series = <Series From <Add 1 s.Min> To s.Max e.Series s.Min>;
}

Naturals {
  0         e.Tail = <Naturals e.Tail>;
  s.Natural e.Tail = s.Natural <Naturals e.Tail>;
  = ;
}

Учтите, что транслятор Турчина (4,6 сек *) не развивается. Если заинтересовал язык, стоит обратить внимание на живые проекты Рефала-5λ (3,5 сек *) и лёгкий компилятор Refal-05 (4,6 сек *) того же автора. Правда, мой интерпретатор (включая трансляцию, 1,1 сек *) почему-то их обогнал. Если есть к нему интерес и он не запускается в WSL, могу попробовать адаптировать его под WinNT (но быстро не обещаю, немного отвык от той ОС).

*) время выполнения Решета на Ryzen 3,7ГГц

Отредактировано С.Т. (2021-04-05 13:31:51)

Рек. вызов функций делает это неявно.

предложение оборвалось, не завершившись,
а хочется интригующего продолжения