Создать — это лишь меньшая часть дела. При этом не умаляю сложности, объемности и дороговизны этой задачи.

Но дальше в силу вступает несколько факторов, чтобы этот язык имел популярность: PR/маркетинг, спрос на язык (то есть ниша) и удача. Все!

Посмотри на свежие популярные языки: за всеми стоят гиганты. А это, соотвественно, деньги и пиар. Конечно люди начнут пользоваться. И техническая составляющая тут будет вторична. Go, Swift, Dart, Flutter, не говоря уже про C# и Джаву. Да тот же Котлин.

То есть ЯП — тот же продукт. Впаривают его и пипл хавает.

Здравствуйте, 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

Здравствуйте, DiPaolo, Вы писали:

DP>Посмотри на свежие популярные языки: за всеми стоят гиганты. А это, соотвественно, деньги и пиар. Конечно люди начнут пользоваться. И техническая составляющая тут будет вторична. Go, Swift, Dart, Flutter, не говоря уже про C# и Джаву. Да тот же Котлин.

Так есть же исключения
php к примеру

Мне кажется, что первоочередное — это качество продукта. Тут по аналогии магазина)
Когда в магазине вкусные и красивые фрукты на полках, то покупатель доволен. И он вернётся к вам снова. И может даже друзей приведёт.

А если на полках всё лежит и лежит, и мало кто это покупает, то может стоит задуматься о смене поставщика?
Или даже воскресить производство товаров, на которых был больше спрос?

	o_o
	Дорогой директор супермаркета, спроси у аналитиков конкретно скажем про "сушилку одежды" от такой то фирмы: Как давно была покупка вот этого товара? Сколько было таких продаж за прошлый месяц? А за год? Сделайте ка мне выборку: каких товаров продано меньше N за последние пол года!

Маркетологи скажут: вложись в рекламу чувак, мы тебе поднимем оборот! Это пару раз сработает, а дальше?
Позиция: бери что дают, всё равно аналогов нет — немного адочек...

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

Возвращаясь к теме про ЯП:
сделать на своём яп крутую приложуху, чтобы её раскрутить
её фрагмент показать исходным кодом
выложить документацию в открытый доступ
определиться с чего монетки — казалось бы сперва, да?

p/s
самая востребованная приложуха — это...

Здравствуйте, Sm0ke, Вы писали:

DP>>Посмотри на свежие популярные языки: за всеми стоят гиганты. А это, соотвественно, деньги и пиар. Конечно люди начнут пользоваться. И техническая составляющая тут будет вторична. Go, Swift, Dart, Flutter, не говоря уже про C# и Джаву. Да тот же Котлин.

S>Так есть же исключения
S>php к примеру

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

S>Мне кажется, что первоочередное — это качество продукта. Тут по аналогии магазина)

Особенно смешно это про PHP (ну, условно, до 7-й версии).
Конечно, спасибо за то, что это дерьмо времён 4.x-5.1-5.2 стало главной причиной развития высококачественной контейнеризации, но это было больно.

S>Я лучше куплю один фрукт, и получу удовольствие. Но вернусь к вам за новой порцией, чтобы угостить маму.

Ну вот есть фрукт, а есть овощ, а есть мясо, а есть приправы.
Обобщить их в одном продукте на все случаи — как-то нереально.

S>p/s
S>самая востребованная приложуха — это...

Ну?

Здравствуйте, vsb, Вы писали:

vsb>По сути рисуешь грамматику на каком-нибудь antlr, он тебе даёт на выходе AST. Дальше по этому AST надо проверить типы, вот тут я автоматизацию не знаю, вероятно тут основной код и будет сидеть. Возможно сгенерить ещё какие-нибудь AST (если есть макросы). И потом сдампить всё это дело в конечный байткод, который и скормить бэкэнду.
все так. а вот если скажем запрашиваемый синтаксис языка будет изобиловать контекстно зависимыми выражениями ? здается прогулка может оказаться не такой легкой.

Здравствуйте, ребусоид, Вы писали:

Р> все так. а вот если скажем запрашиваемый синтаксис языка будет изобиловать контекстно зависимыми выражениями ? здается прогулка может оказаться не такой легкой.

А вот этого надо избегать до последнего.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, ребусоид, Вы писали:

Р>> все так. а вот если скажем запрашиваемый синтаксис языка будет изобиловать контекстно зависимыми выражениями ? здается прогулка может оказаться не такой легкой.

N>А вот этого надо избегать до последнего.
Ага, это вы скажете заказчику. Причем, вероятно, что требование избегать бэктрекинга прозвучит также ))

about langs

by: DiPaolo

Посмотри на свежие популярные языки: за всеми стоят гиганты. А это, соотвественно, деньги и пиар.

by: me

Так есть же исключения
php к примеру

Вы писали:
N>Особенно смешно это про PHP (ну, условно, до 7-й версии).

Я php упомянул в том плане, что за ним не стоят корпорации, которые его пиарят.
Он нишу свою занял, до сих пор пользуется спросом.
И продолжает развиваться (хоть неспешно, так как видимо уже довольно самодостаточен для своих задач)

--
N>Много ты сейчас найдёшь неоткрытых ниш?

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

by: me

p/s
самая востребованная приложуха — это...

N>Ну?

. Операционная система .
это же очевидно

Возможно сперва придётся обкатать синтаксис языка на прикладных задачах, отполировать, чтобы потом разработать в нём low-level режим.
И попутно монетку бы сколлекционировать)

change topic: -- Продуктовый магазин --

by: me

Я лучше куплю один фрукт, и получу удовольствие.

	(без подтекста, без параллелей, без аналогий)
	А десять невкусных с сомнительной формой — лучше бы вообще не клали на прилавки (И даже не привозили на склады). Думаю лучше не стоит поднимать урожайность овощей/фруктов непроверенными удобрениями в ущерб интересов конечного покупателя. Выращивайте так, чтобы вы сами хотели вкусить)

N>Ну вот есть фрукт, а есть овощ, а есть мясо, а есть приправы.
N>Обобщить их в одном продукте на все случаи — как-то нереально.

Я же не предлагаю их обобщать. Я бы даже сузил случай именно фрукта до яблок.
Помню в 2016-м были офигенные с сортом роял гала. Где такие сейчас найдёшь в моём городе, а? Сейчас они не такие, увы ;( хотя сорт указан тот-же

Здравствуйте, Sm0ke, Вы писали:

S>Вы писали:
N>>Особенно смешно это про PHP (ну, условно, до 7-й версии).
S>Я php упомянул в том плане, что за ним не стоят корпорации, которые его пиарят.

Вы это серьёзно???
Zend — с 1998.
Facebook — с основания и до сейчас! У них серверная сторона на PHP. Сильно компилированном, но на нём.

И да, пиара от Facebook для него достаточно.

S>Он нишу свою занял, до сих пор пользуется спросом.

Он её сформировал. Это более существенно. И да, таки пользуется спросом, мягко говоря.

S>Не обязательно находить новые ниши. Можно же упростить разработку в уже имеющихся нишах. И в тех, которые появились недавно, где делаются первые шаги.

Это должно быть суперупрощение. Или очень мягкий совместимый переход.

S>by: me
S>

S>p/s
S>самая востребованная приложуха — это...

N>>Ну?

S>. Операционная система .
S>это же очевидно

Нет, если считать по количеству человеко-времени потраченного на разработку.
Сейчас 60-70% это веб во всех видах.
А что там стоит внутри за доступным API, знают только фрики вроде нас, которые ещё помнят, сколько бит в байте.

N>>Ну вот есть фрукт, а есть овощ, а есть мясо, а есть приправы.
N>>Обобщить их в одном продукте на все случаи — как-то нереально.

S>Я же не предлагаю их обобщать. Я бы даже сузил случай именно фрукта до яблок.

Это, наверно, чрезмерно.
А обобщать вы таки предлагали. Один и тот же язык и для системного уровня (где можно лезть в регистры внешних устройств и писать напрямую обработчики прерываний) и для скриптов это как-то странно.

S>Помню в 2016-м были офигенные с сортом роял гала. Где такие сейчас найдёшь в моём городе, а? Сейчас они не такие, увы ;( хотя сорт указан тот-же

Такого не видел, просто Гала у нас на каждом углу.

S>>Я php упомянул в том плане, что за ним не стоят корпорации, которые его пиарят.

N>Вы это серьёзно???
N>Zend — с 1998.
N>Facebook — с основания и до сейчас! У них серверная сторона на PHP. Сильно компилированном, но на нём.

N>И да, пиара от Facebook для него достаточно.

Выходит, что я сделал ошибочное суждение за недостатком просвящённости по историческим событиям ...
чтож

--

S>>. Операционная система .

N>Нет, если считать по количеству человеко-времени потраченного на разработку.
N>Сейчас 60-70% это веб во всех видах.

Это вы с поизции разработки правы.

Но с позиции пользователей — первоочередное — это OS.
Независимо от устройств (мобльники, пк, консоли, ноуты, планшеты)

N>А обобщать вы таки предлагали.
Да по lang, Нет — по продуктам)
N>Один и тот же язык и для системного уровня (где можно лезть в регистры внешних устройств и писать напрямую обработчики прерываний) и для скриптов это как-то странно.

Для меня lang — это синтаксис в первую очередь, чтобы на нём писать. На данный момент по краней мере.
Чтобы для кода OS её исходник, написанный на каком_бы_то_ни_было языке, превратить в исполняемые электроникой байты — нужен что? Компилятор, так?

* Значит для нового языка делается соответствующий extension компилятора, который добавляет специальные встроенные типы и функции, по работе в low level режиме.

* Без включения этого -OS режима я бы хотел, чтобы новый ЯП был полностью safe и вообще без UB.
(даже без raw pointers / или с некоторым целочисленным представлением для raw pointers без возможности по ним лезть в память)

* Для -OS режима может появится модуль анализатора кода.

	some tips
	-- line-comment var = 5 -- получить тип у значения в ячейке var: var$ -- сравнить типы: var$ == $int

Здравствуйте, netch80
Наконец появилась "минутка", чтобы ответить по вопросу namespace

| В си++ можно в разных местах открыть начало пространства имён, что-то в нём определить, а потом закрыть.
| И так несколько раз для того-же имени namespace -а можно повторно открывать в разных файлах.

В кси всё лежит в ячейках. У ячейки есть имя, и принадлежность.
К примеру ячейка модуля принадлежит модулю
Имя модуля начинается с собачки

| На примере ui либы это может выглядить так:

В модуле @main ячейка нэймспэйса с именем ui

-- file: ui-colors.ksi

@main

ui = #nest (
  colors
)

ui.colors = #nest (
  red   = 0h_ff_00_00
  white = 0h_ff_ff_ff
)

do = {
  &write_line( ui.colors.red )
}

Команда #nest формирует и возвращает новый тип, со статическими свойствами.
Это можно использовать как пространство имён.

Вы писали:

Если хочется чего-то выше уровня песочницы — понадобятся, иерархические.

Конечно они могут быть вложенными.

Вначале был указан список ячеек в нэсте ui
В этом списке пока только colors
Который тоже nest
Начальное значение для colors вынесено отделньно за скобку
Но могло быть и внутри, как у ячейки ui.colors.red

--

Добавим в nest ui ещё типы: coords, color
Через команду #add_nest

-- file: ui-types.ksi

@main

ui #add_nest (
  coords
  color
)

ui.coords = #struct ( x y )
ui.color = #struct ( r g b )

-- usage:

test_types = {
  pos = ui.coords(2, 2)
  clr = ui.color(200, 200, 200)
}

В том-же файле, или в отдельном — не так важно.

--

Через #add_nest можно статики добавлять и к структуре тоже

-- file: ui-color-actions.ksi

@main

ui.color #add_nest (
  from_code
)

ui.color.from_code = #fn ($int: code)
{
  #ret = ui.color(/* битовые вычисления */)
}

-- usage:

test_color = {
  clr = ui.color.from_code( ui.colors.white )

  clr_code = (
    clr !to_code
  )

  ( clr_code <> ui.colors.white ) #then { /* log: test_failed */ }
}

Метод to_code для типа ui.color в этом примере не определён.
Синтаксис для добавления методов — в отдельном reply запланирован)

	вы спрашивали
	Я не понял, к чему '!' впереди "!as". Через восклицательный знак — это вызов метода cell !method cell !method(params) Через точку — доступ к свойству cell.property Через стрелочку — доступ к атрибуту cell->attr так имена у метода, свойства и атрибута могут совпадать, и не возникнет ambiguity

--

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

do {
  -- attempt to make nest instance:
  var = ui.colors()

  -- type of nest instance:
  type = var$

  -- ... and nest itself
  ( type == ui.colors ) #then { &write("same") }
  -- is the same thing

  -- but type of nest:
  ui.colors$ == $type -- ui.colors is type
  -- is $type
}

Тут var$ — это способ узнать тип

--

На случай если разработчик кси библиотеки захочет запретить добавлять в свой nest дополнительные статик свойства через #add_nest,
то можно ввести команду #nest_once (или как её лучше назвать?)

@some_lib

my_nest = #nest_once ( a b c )

my_nest #add_nest () -- ошибка!

Но может быть вы предложите вообще запретить через #add_nest добавлять статики именно в #nest ?
Чтобы весь перечень статик ячеек был всегда в одном месте ... И не пришлось бы их искать по разным файлам

Как считаете, добавлять статики в структуру, в перечисление, и даже в функцию — хорошая идея?
* всё той-же командой #add_nest

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

По фрагменту моего коммента

x !as[type]

Вы писали:

Я не понял, к чему '!' впереди "!as".

Это применение метода (действия) к результату предыдущего выражения.
Но сперва я бы хотел пояснить про вызовы обычных функций.

# fn call

В кси есть два способа вызова функции:
Обычный, и по цепочке

angle = math.pi

// обычный вызов функции
x = math.sinus(angle)

// chain call
x = (angle |math.sinus)

	пояснение
	Вертикальная палка означает: применить функцию к значению слева. Идея повзаимствована из библиотеки шаблонов Smarty. Я думаю, что на уровне парсера надо проверять, чтобы после | не было пробела при chain-call.

Так можно вместо вложенных скобок писать вызовы слева-направо.

param = "size"

// обычный вызов функции
x = math.sinus( config.get_value(param) )

// chain call
x = (param |config.get_value |math.sinus)

* Предполагается, что функции math.sinus и config.get_value где-то определены.

# Способы передачи параметров

--
При обычном fn-call и когда функция принимет один параметр — круглые скобки можно не писать, заменив их спец-символом:

// альтернативный способ передать первый параметр
std.loop! { /* тело цикла */ }

// простой способ
param = { /* тело цикла */ }
std.loop(param)

Символ восклицательный знак ! после функции (без пробела между ними) — означает вызови функцию, а как первый параметр возьми результат последующего выражения.
Может быть есть более походящий для этого символ, чтобы задать его в парсере?

Функция std.loop — это вечный цикл. Она принимает один параметр — sequence.
Где именно она определена? Может быть в библиотеке, а может и системная — вопрос не решённый.

Пока рассказываю про синтаксис вызова и передачи параметров.
С набором стандартных/системных функций ещё предстоит определиться.
Выбрать им имена)

--
При chain-call для функции с двумя параметрами — этот второй параметр тоже можно по разному пассить.

map = [1:"one" 2:"two" 3:"three"]

key = array |key_of("two")
key = array |key_of: "two"
// key == 2

Символ двоеточие для второго параметра при chain-call тоже задаётся в парсере.
Меня немного смущает, что смысл символа зависит от контекста.
Выписать бы контексто-зависимые символы отдельно.

Пример с циклами:

{
  /* pre condition */
} |std.while_do: {
  /* loop body */
}

{
  /* loop body */
} |std.do_while: {
  /* post condition */
}

# методы (actions)

Напомню, что ! перед именем (без пробелов между ними) — это вызов метода.
Для поиска методов — у обработчика свои правила разрешения имён, отличные от случая с функцией.

Про методы у типов напишу немного позднее / возможно / И про шаблоны тоже.
Но мне кажется интерес других программистов на RSDN к разработке нового ЯП поугас.

Однако я замечаю, что есть нюансы, по которым ругают Си++.
Так вот бы создать новый better language и сделать как мы хотим

Касательно темы функций — вопрос открыт про variadic параметры, нужны ли они ? Или взять fixed size массив / sequence
И про передачу параметров по имени. В php это есть, в других яп тоже. Но я бы предложил через отдельную команду #options ()