Panzerschrek[CN]
> import "std/vector.ü"
üдобненько
Panzerschrek[CN]
> STL буду писать, без этого никак
Что насчет обратной совместимости с плюсами?
romgerman
> Что насчет обратной совместимости с плюсами?
Не нужно. Абсолютно не нужно.
Любые поползновения в сторону обратной совместимости с чем-то приведут к порождению нагромождения костылей.
"STL" я имел в виду не в виде кресто-STL, а именно что свою - выполняющую схожие функции, но заточенную под этот язык.
Совместимость с крестами я планирую оставить в виде возможности звать некоторые C++ функции.
Уже реализована совместимость на уровне кодирования имён для нешаблонных функций. Есть частичная совместимость на уровне ABI - можно вызывать в обе стороны функции с значениями фундаментальных типов и ссылочными значениями в сигнатурах.
Планируется возможность создания бинарно-идентичных с крестовыми структур.
Panzerschrek[CN]
> Сначала компилируется a.ü, потом b.ü.
А должно быть a.ъ и b.ъ. Иначе не взлетит, вангую.
Когда я запиливал шаблоны классов, то реализовал очень хитрую специализацию шаблонов.
Выглядит это примерно так:
Шаблон с простой сигнатурой:
template</ type T /> stuct Box</ T /> {}
Шаблон с конкретной специализацией:
template<//> stuct Box</ i32 /> {}
Шаблон со сложной специализацией и выводом типа:
template</ type T /> stuct Box</ std::vector</ T /> /> {}
Шаблон с ещё более сложной специализацией и выводом типа:
template</ type T /> stuct Box</ std::vector</ std::pair< / T, T /> /> /> {}
Убервывод типов:
template</ type T, type Q, type V, type W /> stuct Box</ A</ T />::B::C</ Q />::D</ V, W />::RRR /> {}
Весь этот хитрый вывод работал примерно так:
Брался данный тип и строилась его родословная - набор пространств, в котором он находится. Дальше этот набор сравнивался с фактической сигнатурой и происходил вывод параметров шаблона.
Но теперь я запилил псевдонимы типов а также собираюсь запилить псевдонимы пространств имён. Из-за этого тип теперь не имеет единой родословной, а в общем случае имеет граф родительских связей, сходящихся на корневом пространстве имён. Из-за этого вывод параметров шаблонов как в последнем примере становится невозможен, если в сигнатуре шаблона используются псевдонимы.
Придётся из-за этого выпилить последний вариант. Придётся оставить только или простые параметры, или конкретные типы, или шаблоны вида
A::B</O/>::C</P/>::D</Q, R/>
Запилил тут короткую форму шаблонов. Вкратце расскажу, что это такое.
Обычно шаблон класса выглядит как-то так:
template</ type A, type B /> class Pair</ A, B /> { A a; B b; }
Казалось бы, зачем нужно дублирование параметров? А примерно вот зачем:
Но вот беда - такая запись всё-эе слишком многословна.
Теперь я добавил упрощёную запись:
template</ type T /> struct Box { T t; }
В ней параметры шаблона интерпретируются так же, как параметры сигнатуры. Этого вполне достаточно для 90% шаблонов, для остальных же случаев по-прежнему остаётся полная форма.
Panzerschrek[CN] в графе "цель" вы не указали назначение Ü, но я догадываюсь что на Ü не возлагаются большие надежды.
По какой причине не поставлена цель: "простота программирования"?
bialand
> По какой причине не поставлена цель: "простота программирования"?
Простота - вещь относительная.
Относительно C++, например, "Ü" простой, относительно Java, или С90 - сложный.
У меня есть цель не переусложнить язык лишними сущностями и понятиями. Но я не уверен, что её удастся достигнуть.
> цветами , черточками и другими инструментами IDE программист понимал бы что
> pair это шаблон
Ну, это не ко мне. Язык, хоть "Ü", хоть какой-либо другой должен быть читаем хоть с глиняной таблички - иметь простую и понятную текстовую форму. А уж перевести эту форму в цветасто-графический вид это забота всяких IDE, плагинов. Есть ли такое - ХЗ, гугли, если оно тебе надо.
Я за квадратные скобки для шаблонов. Причём с сахаром - последний параметр шаблона можно выносить за скобки через предлог of.
Суть такова:
// без сахара std::vector[int] std::array[5, int] std::map[std::string, int] rawMemoryUsing::pointer[int] rawMemoryUsing::pointer[const[int]] // с сахаром std::vector of int std::array[5] of int // как знакомо и привычно выглядит! std::map[std::string] of int rawMemoryUsing::pointer of int rawMemoryUsing::pointer[const of int]] // или rawMemoryUsing::pointer of const[int] // или rawMemoryUsing::pointer of const of int
1 frag / 2 deaths
> Я за квадратные скобки для шаблонов.
Не подходит, т. к. квадратные скобки используются для доступа к элементам массива.
> Причём с сахаром - последний параметр шаблона можно выносить за скобки через
> предлог of.
Сахара не надо, от его переизбытка диабет может случиться.
Вообще, ненавижу хипстерков, которые добавляют в язык узкоспециализированные конструкции для решения частных задач.
В Ü я стараюсь не воротить лишнего.
Panzerschrek[CN]
> Не подходит, т. к. квадратные скобки используются для доступа к элементам
> массива.
Приведи пример, где это приведёт к нечитаемости/неоднозначности.
Пока что от </ /> текут глаза.
1 frag / 2 deaths
> Приведи пример, где это приведёт к нечитаемости/неоднозначности.
einige_scheiße[42];
oderer_scheiße[müll]();
Короче, это неоднозначно, а значит так не будет.
> Пока что от </ /> текут глаза.
Ты погоди. Я скоро добавлю синтаксис для указания времён жизни ссылок, там ещё одну пару скобок добавить придётся. Вот тогда у тебя не только глаза течь начнут.