Ü (Programmiersprache) (4 стр)

Panzerschrek[CN]
> Что это?
Да однозначно парсится.

Panzerschrek[CN]
> einige_scheiße[42];
Бессмысленная конструкция.

Panzerschrek[CN]
> А это что? Инстанцирование шаблона типом и вызов конструктора? Доступ к
> функтору в массиве и вызов его?
Доступ к функтору. Конструктор без = смысла не имеет.

1 frag / 2 deaths
> Бессмысленная конструкция.
Отдельно оно конечно может и бессмысленно. Но вот в выражении уже хрен поймёшь.

> Доступ к функтору. Конструктор без = смысла не имеет.
Опять же, представь, что эта конструкция встретилась где-то в выражении.

foo[bar](bazz) может быть как функтором из массива, так и приведением к специализированному типу, печаль
но
foo(bazz) тоже может быть как вызовом функции, так и приведением.
Запретить приведения таким способом, всё.

Panzerschrek[CN]
> Что это? Инстанцирование шаблона с целочисленным параметром? Или это взятие
> элемента массива?
> А это что? Инстанцирование шаблона типом и вызов конструктора? Доступ к
> функтору в массиве и вызов его?
Ну так если шаблон - первое, если переменная - второе.
В случае неоднозначностей дать механизм их разрешения.
Делов то...

Panzerschrek[CN]
Ну так других инновацияй в нем нет.
А вообще, foo!(Template, Parameters)(runtime, parametrs)

Строки, строки в нем будут? В примере из #0 грусть-печаль с нультерминированным массивом из i8.
—-

и чем отличается auto constexpr от auto imut тоже непонятно. Компилятор не может сам определить является ли выражение справа константой времени компиляции?

kipar
> Строки, строки в нем будут? В примере из #0 грусть-печаль с нультерминированным
> массивом из i8.

Строки будут как класс вроде std::string. Также планируется наличие array_view, который в частности будет использоваться для представления строк. Планируется отказ от обязательного завершения строк нулём.

Пример в нульпосте - временный. Он взят из кода теста. В тесте этот код вызывается из C++, а там нужны строки с завершающем нулём.

kipar
> и чем отличается auto constexpr от auto imut тоже непонятно. Компилятор не
> может сам определить является ли выражение справа константой времени
> компиляции?
Сейчас так по факту и есть, imut переменная с константным инициализатором внутри кода считается константной и выражение с нею будет константной.
По сути, слово "constexpr" нужно для того, чтобы генерировалась ошибка, если инициализатор переменной не является константой времени компиляции.

Вот удивительно, в жаве поначалу даже нативным исполнением пожертвовали ради того, чтобы получилась типа-как-кроссплатформенность (потом, правда, запилили прекомпиляцию, но потом).
И всё равно на мобилках своя жаба, особенно на старых, и даже под обычной жабой при другой эндианности половина жабопрог сыплется и так далее.
Ноги промочили, а пива не попили. Контролёра обманули — билет купили и не поехали.

Вот что должен быть за язык (Бейсик не рассматриваем), и особенно какие к нему должны быть стдлибы, чтобы действительно можно было написать, скажем, почтовый клиент под x86 Win. А потом сменить таргет в проекте и сразу собрать рабочий AMD64 .deb.
А потом ещё раз сменить таргет и собрать под мобилу на ARM. И под электронную книжку, чтобы два раза не ходить.
И всё сразу работало.

А если не почтовый клиент (хотя и тот даст горячего: шрифты, курсив/жирный, предпросмотр аттачей с картинками…) А если Hex? http://www.gamedev.ru/projects/forum/?id=209481

Ладно, либы. Либы можно под что угодно сделать. Вопрос, какие апи они должны предоставлять приложению, эти либы?
И каким должен быть сам язык, чтобы страховать от непроверенных умолчаний типа «тут читаем из int только первый байт, всё равно значение меньше 256»? Избегать-то надо, но всего не избежишь. Где-то в файле позиция 32 битами обозначается, где-то 64. Где-то дисплей построчно сканируется, где-то постолбцово. Обо всём думать во время разработки — уууу, если бы это было реально, кроссплатформенным было бы ВСЁ, что пишут люди.

Кто сможет решить эту задачу, наверное, будет великий гений и спаситель человечества. Получаются, правда, только очередные вариации жабы :( Но я всё-таки со смутной надеждой от каждого очередного Ü жду чуда… :(

Panzerschrek[CN]
> Строки будут как класс вроде std::string.
Индексный доступ будет? Если да, то это отказ от УТФ-8 и трахомудия с кодировками. Если послать индексный доступ подальше, то можно работать с православным УТФ-8.

NickDoom, видишь ли: чем сложнее isa (aka набор команд), тем сложнее сделать компилятор. Для risc проблем нет, а вот для cisc - да. Текущие платформы малоядерные и для скорости у них cisc.
Пример сложностей для компиляторов - sse, пока не ввели в базовый набор никто не чесался. Это не учитывая разные архитектуры для одного и того же набора, которые обесценивают(по скорости) часть набора.

MrShoor

P.S.: Почему никто не вспоминает про АПЛ?
Вроде бы давно уж XXI во дворе! Можно использовать полный Unicode-набор и набирать алгоритм хоть китайскими иероглифами:

continue - 续;
return - 回;
break - 断…

язык на смайлах есть

как тут не вспомнить спектрум-клаву

можно создать плагин для автозамены символов на конструкции. Выделить пару символов-скобок под смену режима между рав и автокодом.

лел, выделили для негров отдельные смайлы. Вопрос: для кого предназначены желторотики? Узкоглазых нет. Нетолерантненько.

Panzerschrek[CN]
> Хочется запилить язык программирования навроде крестов, но без недостатков
> крестов и с минимизацией возможности прострела ноги.
> Язык должен быть компилируемым, со статической строгой типизацией. Управление
> памятью - через деструкторы. Никаких говносборщиков мусора.
NickDoom
> Вот что должен быть за язык (Бейсик не рассматриваем), и особенно какие к нему
> должны быть стдлибы, чтобы действительно можно было написать, скажем, почтовый
> клиент под x86 Win. А потом сменить таргет в проекте и сразу собрать рабочий
> AMD64 .deb.
> А потом ещё раз сменить таргет и собрать под мобилу на ARM. И под электронную
> книжку, чтобы два раза не ходить.
> И всё сразу работало.