Это первый из серии постов, которые я хочу написать как о создании Ceptr, так и о кодировании в Ceptr.
Я хочу начать с нескольких ключевых моментов того, как Ceptr может выглядеть для вас с точки зрения программиста. :

  1. В Ceptr вы не должны думать о себе как о программировании компьютера, а скорее о сети из группы простых компьютеров, некоторые из которых встроены друг в друга. Мы называем эти простые компьютеры рецепторами.
  2. Фундаментальная единица данных в Ceptr не является 32- или 64-битным словом; это семантическое дерево. Это может показаться странным, но это создает важный сдвиг в сознании. Думайте о каждом рецепторе как о компьютере, ЦП которого работает, оценивая древовидные структуры, а не линейные последовательности битов. Счетчик программ не перемещается вперед по линейному пространству памяти, загружая следующую инструкцию в регистр для оценки, а скорее проходит по пространству памяти с древовидной структурой, рекурсивно сокращая ветви до их результата.
  3. Неудивительно, что программы Ceptr — это всего лишь еще один тип семантического дерева. Это означает, что принципиально среда программирования Ceptr является гомеоконической.
  4. Ceptr использует расширенную версию регулярных выражений для сопоставления с образцом, которую мы называем SemTrex (регулярные выражения SEMantic Tree). Регулярные выражения предназначены для сканирования линейной последовательности символов, но выражения SemTrex работают с деревьями и могут совпадать как по семантике, так и по значению.
  5. Ceptr предоставляет вам собственную сигнальную систему для отправки сообщений между этими рецепторами. Большая часть программирования Ceptr связана с кодом, который запускается при поступлении сигналов, основываясь как на явном сопоставлении с образцом содержимого поступающего сигнала (с использованием SemTrex), так и на основе пути входа сигнала (вроде известных номеров портов в TCP). /ИП). Таким образом, «набор инструкций» Ceptr включает в себя поддержку многофункционального взаимодействия между рецепторами, включая отправку одного сообщения, шаблоны запроса-ответа и «разговоры» на основе постоянного соединения, а также, что наиболее важно, шаблоны для определения протоколов с несколькими рецепторами.
  6. Эти протоколы могут быть определены как абстракции, вроде классов шаблонов. Таким образом, большая часть программирования Ceptr включает в себя размышления о том, какие агенты и что делают в данном протоколе, и каковы взаимодействия этого протокола, и, наконец, создание более сложных протоколов из более простых.

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

  • Семантические деревья, семантическое чередование и, особенно, каково это кодировать, когда вы не можете использовать данные, не задумываясь о том, каково семантическое использование этих данных.
  • Гомоиконичность и то, как в Ceptr, как и в некоторых других языках программирования, представление и структура программы точно совпадают, что значительно упрощает метапрограммирование.
  • Шаблоны, слоты, грамматики и параметры: сочетание известного и неизвестного и основа компонуемости.
  • Транскодирование: семантическая версия приведения или преобразования типа.
  • Фенотип против генотипа, или, как сказали бы программисты: класс/тип/прототип против экземпляра.
  • Контексты согласованности: за пределами пространств имен.
  • Протоколы как реализуемый код, а не как спецификации для кодирования.
  • Передача сигналов между рецепторами: Несущая/Сигнал/Протокол т.е. наш вариант расчета многоагентных систем или модель актора
  • Системы строительных лесов, или, как выразился Алан Перлис в своих эпиграммах: Все должно строиться сверху вниз, кроме первого раза. и как это относится к Ceptr.

Так что, если что-то из этого звучит особенно интересно, сообщите мне в комментариях, и я подниму это выше в своем списке приоритетов.