Здравствуйте, netch80

Вот информация по поводу назначения кси, и про типизацию.

Про остальное темы — отдельным ответом напишу

--

Типизация в кси зависит от выбранного режима
Всего их три:

• - case 1 —

Режим ksi-pl
Тут только строгая типизация
Указывать тип ячейки обязательно как ограничение

some_fn = #fn ($int: x y, $float: factor) : result_type {}

Ещё допустимо ячейку ограничить не типом, а категорией

some_fn = #fn (_any: param) : result_type {}
other_fn = #fn (_struct: param) : result_type {}

К системной категории _any относятся все типы.
А системная _struct назначена только на типы, которые сформированы командой #struct
Ячейка с функцией other_fn в примере выше может принимать только структурные значения как параметр.

Как будет фактически работать у ячейки ограничение по категориии — это уже вопрос реализации
Это может быть специальная динамическая run-time обёртка,
Или некий compile-time аналог шаблонов c++

• - case 2 —

Режим ksi-script не допускает накладывать ограничения на тип ячейки

some_fn = #fn (x y factor) {}

Динамическая типизация в нём позволяет устанавливать для ячейки значения любых типов
Эти типы могут быть отличны от типа начального значения, конечно же

• - case 0 —

И наконец режим ksi-lang — это микс из (script + pl)
Тип ячейки можно указывать
Но если не указать, то ограничение типа ячейки будет по категории _any

Надо бы решить какой case реализовать приоритетнее в первую очередь.
Что перед этим ещё надо сделать.

Это были три режима обработчика
Хотя по необходимости можно сделать и отделные, более компактные, обработчики для некоторых case -ов

Вид обработки может быть: интерпретация, компиляция, трансляция
Думаю стоит начать с чего-то одного

	о парсере
	Парсер неплохо бы сделать через общую библиотеку, которая независит от режима обработчика Я начал писать свой парсер таким образом, чтобы правила разбора писались в самом си++ декларативно Для AST нодов я сделал свой pool, который освобождает ноды пачками сразу. Ноды аст с тривиальными деструкторами. В этом пуле Нет возможности ноды возвращать по одному в пул как свободные, ведь это бы усложнило код в либе пула. Думаю не так важно привязан нод к дереву, или нет. Главное чтобы деструктор пула был вызван после деструктора всего AST -- Я пробовал разобраться в ANTLR, который вроде был кодогенератором на java Есть моменты, что мне не понравились: — придётся тратить время на изучения структур, которые оно генерит, как обходить их аст, как они там устроены — при написании термов придётся тратить время на тесты и исправления недочётов, исходя из особенностей синтаксиса описания АНТЛР термов — зависить от изменений в новых версиях внешней чужой тулзы, не особо охота

--

1. Общая направленность — системный, прикладной на какой-то класс задач.

Назначение языка — для любых задач.

Уже не бывает. Надо определиться.

Хорошо, вот примерные цели применения (таргеты)

ksi-script:

• web аналог php
  
• скриптовый игровой движок
  
• простенькие desktop проги
  
• maybe ~ для ui разметки

ksi-pl:

• компиляция
  
• научные расчёты
  
• maybe ~ аналог си плюс плюс

--

Ещё немного инфы про обработчик.

Вот в интерпретаторе php есть расширения (extensions)
Они добавляют системные функции, системные типы, константы, интерфейсы, и пр.
Некоторые примеры расширений php:

• для работы с СУБД mySQL
  
• для работы с изображениями GD
  
• для работы с http запросами CURL

Неплохо бы в обработчик ksi добавить систему расширений.
На чём писать эти расширения — на плюсах, или даже на самом кси
Почему бы не помечтать

Какие именно понадобятся расширения обработчика — отдельный вопрос
Я не призывааю как либо повторять путь php

Здравствуйте, netch80

Вот информация по поводу назначения кси, и про типизацию.

Про остальное темы — отдельным ответом напишу

--

Типизация в кси зависит от выбранного режима
Всего их три:

— case 1 —

Режим ksi-pl
Тут только строгая типизация
Указывать тип ячейки обязательно как ограничение

some_fn = #fn ($int: x y, $float: factor) : result_type {}

Ещё допустимо ячейку ограничить не типом, а категорией

some_fn = #fn (_any: param) : result_type {}
other_fn = #fn (_struct: param) : result_type {}

К системной категории _any относятся все типы.
А системная _struct назначена только на типы, которые сформированы командой #struct
Ячейка с функцией other_fn в примере выше может принимать только структурные значения как параметр.

Как будет фактически работать у ячейки ограничение по категориии — это уже вопрос реализации
Это может быть специальная динамическая run-time обёртка,
Или некий compile-time аналог шаблонов c++

— case 2 —

Режим ksi-script не допускает накладывать ограничения на тип ячейки

some_fn = #fn (x y factor) {}

Динамическая типизация в нём позволяет устанавливать для ячейки значения любых типов
Эти типы могут быть отличны от типа начального значения, конечно же

— case 0 —

И наконец режим ksi-lang — это микс из (script + pl)
Тип ячейки можно указывать
Но если не указать, то ограничение типа ячейки будет по категории _any

Надо бы решить какой case реализовать приоритетнее в первую очередь.
Что перед этим ещё надо сделать.

Это были три режима обработчика
Хотя по необходимости можно сделать и отделные, более компактные, обработчики для некоторых case -ов

Вид обработки может быть: интерпретация, компиляция, трансляция
Думаю стоит начать с чего-то одного

	о парсере
	Парсер неплохо бы сделать через общую библиотеку, которая независит от режима обработчика Я начал писать свой парсер таким образом, чтобы правила разбора писались в самом си++ декларативно Для AST нодов я сделал свой pool, который освобождает ноды пачками сразу. Ноды аст с тривиальными деструкторами. В этом пуле Нет возможности ноды возвращать по одному в пул как свободные, ведь это бы усложнило код в либе пула. Думаю не так важно привязан нод к дереву, или нет. Главное чтобы деструктор пула был вызван после деструктора всего AST -- Я пробовал разобраться в ANTLR, который вроде был кодогенератором на java Есть моменты, что мне не понравились: — придётся тратить время на изучения структур, которые оно генерит, как обходить их аст, как они там устроены — при написании термов придётся тратить время на тесты и исправления недочётов, исходя из особенностей синтаксиса описания АНТЛР термов — зависить от изменений в новых версиях внешней чужой тулзы, не особо охота

--

1. Общая направленность — системный, прикладной на какой-то класс задач.

Назначение языка — для любых задач.

Уже не бывает. Надо определиться.

Хорошо, вот примерные цели применения (таргеты)

ksi-script:

• web аналог php
  
• скриптовый игровой движок
  
• простенькие desktop проги
  
• maybe ~ для ui разметки

ksi-pl:

• компиляция
  
• научные расчёты
  
• maybe ~ аналог си плюс плюс

--

Ещё немного инфы про обработчик.

Вот в интерпретаторе php есть расширения (extensions)
Они добавляют системные функции, системные типы, константы, интерфейсы, и пр.
Некоторые примеры расширений php:

• для работы с СУБД mySQL
  
• для работы с изображениями GD
  
• для работы с http запросами CURL

Неплохо бы в обработчик ksi добавить систему расширений.
На чём писать эти расширения — на плюсах, или даже на самом кси
Почему бы не помечтать

Какие именно понадобятся расширения обработчика — отдельный вопрос
Я не призывааю как либо повторять путь php