Флейм
GameDev.ru / Флейм / Форум / Ü (Programmiersprache) (22 стр)

Ü (Programmiersprache) (22 стр)

Страницы: 118 19 20 21 22 23 Следующая »
Panzerschrek[CN]Участникwww24 июня 201812:23#315
Adler
> окажется что-то типа вот такого и нужно будет сгенерировать внятное сообщение
> об ошибке
Можно при детектировании цикла перечислить элементы, входящие в цикл. Конкретно в твоём примере написать "обнаружена циклическая зависимость: A требует полноты B, B требует полноты C, C требует полноты A".
Panzerschrek[CN]Участникwww2 июля 201816:36#316
Реализовал (в некотором виде) constexpr функции


Чтобы фунция была constexpr, надо это явно указать:

fn constexpr Twice( i32 x ) : i32 { return x * 2; }

При вызове такой функции, если все аргументы - constexpr, то результат тоже будет constexpr.


constexpr функции имеют ряд ограничений, по сравнению с обычными:
• Тело должно сразу присутствовать. Опережающие объявления недопустимы.
• Аргументы могут быть только неизменяемыми (сторонних эффектов быть не должно).
• Аргументы и возвращаемые значения должны быть иметь constexpr-friendly тип.
• Нельзя внутри объявлять переменные не constexpr-friendly типов.
• Нельзя unsafe.
• Нельзя virtual.
• Нельзя звать не constexpr функции.
• Нельзя звать функцию по указателю, т. к. в общем нельзя узнать, не смотрит ли указатель на не-constexpr функцию.
• Пока что нельзя вообще даже оперировать указателями на функции.
• Нельзя возвращать ссылки или значения со ссылками внутри. Пока что я не придумал, как сопоставлять входные и выходные ссылки в вычислителе constexpr функций.
• Нельзя звать никакие конструкторы, т. к. конструктор есть функция со сторонним эффектом.

Тем не менее, всё ещё можно в constexpr функциях применять:
• Изменяемые локальные переменные.
• Циклы.
• Ветвления.

Даже в таком виде constexpr функции весьма полезны. Но возможны улучшения:
• Проблема с отсутствием конструкторов решается через написание функций-создателей, типа, вместо fn Type::constructor( mut this, i32 a, i32 b );, будет fn get( i32 a, i32 b ) : Type.
• Невозможность оперирования указателями на функции, кажется, можно некоторыми хаками обойти. Глобальных теоретических проблемы в этом нету.
• Возврат ссылок можно попытаться решить через построение словаря входных ссылок и адресов в адресном простанстве вычислителя. Но есть неоднозначности с совпадением адресов агрегатов и кастом в void&.

DelfigamerПостоялецwww2 июля 201818:06#317
Panzerschrek[CN]
> • Нельзя звать функцию по указателю, т. к. в общем нельзя узнать, не смотрит ли
> указатель на не-constexpr функцию.
А если значение указателя - constexpr?
Скорее не "нельзя узнать", а "дюже неудобно, а польза сомнительна".

Panzerschrek[CN]
> • Нельзя звать никакие конструкторы, т. к. конструктор есть функция со
> сторонним эффектом.
А вот это уже немного сомнительное ограничение. По сути - запрещается использование в constexpr любых нетривиальных объектов, даже, например, таких.
Замена конструктора на функцию - это скорее костыль, чем решение, поскольку меняет семантику типа. Тогда как конструкторами можно обеспечить определённые гарантии о состоянии объекта, с переносом их кода в отдельные функции эта гарантия теряется - достаточно лишь получить дефолт-сконструированный объект этого типа; или ещё лучше - агрегат-инициализацией поставить объект в гарантированно невалидное состояние.
Мне кажется, для языка, сутью которого является безопасность за счёт статических проверок, - это очень серьёзное упущение.

Panzerschrek[CN]Участникwww2 июля 201818:28#318
Delfigamer
> А вот это уже немного сомнительное ограничение.
Ну да, костыль.

Есть ещё такая идея - разрешить некоторым constexpr функциям изменять входные значения. Такие фунции нельзя будет применять как начальную точку constexpr вычисления, но в процессе применять можно будет. Такое усовершенствование позволит использовать конструкторы.


> с переносом их кода в отдельные функции эта гарантия теряется - достаточно лишь
> получить дефолт-сконструированный объект этого типа
В Ü проблем таких нету. В Ü нельзя забыть инициализацию переменной или поля.

> агрегат-инициализацией
А этой ереси так вообще, нету в Ü. Вместо этого есть struct named intitializer, в котором явно надо указать инициализаторы для всех полей, которые не умеют инициализироваться по-умолчанию.

Panzerschrek[CN]Участникwww12 июля 201816:09#319
Реализовал char типы и строковые литералы

Введены три типа - char8, char16, char32.
Значения этих типов можно только перекладывать и сравнивать, но к ним нельзя применять арифметические и побитовые операции. В остальном же эти типы похожи на целые числа, какими они и являются во внутреннем представлении. Также возможны явные преобразования между char-типами и целыми. При сравнении между собой и при межтиповых преобразованиях char-типы ведут себя как беззнаковые.

Введены строковые литералы.
Строковые литералы - это массивы из char значений. В отличии от всяких сишек и крестов строковые литералы не имеют завершающего нуля.
Для задания тип строкового литерала применяются суффиксы  - "u8" для char8 в кодировке UTF-8, "u16" для char16 в кодировке UTF-16, "u32" для char32 в кодировке UTF-32. Если суффикс не указан, то строка будет в char8.

+ пример строк и char-ов


Пока что не реализованы односимвольные литералы, типа 'x' из плюсов.
Также нужны ещё полноценные строки, но это будет позже через библиотечный класс.

ХаусПостоялецwww12 июля 201818:45#320
Panzerschrek[CN]

как жена относится к этому языку?

Panzerschrek[CN]Участникwww13 июля 20185:50#321
Хаус
> как жена относится к этому языку?
Нету жены, так что разработке языка никто не мешает.
DelfigamerПостоялецwww13 июля 20185:58#322
Panzerschrek[CN]
Не лучше будет ввести абстрактные типы "byte", "word16", "word32" и "word64"; а кодировку текста считать свойством целой строки, а не отдельного байта?
Panzerschrek[CN]Участникwww13 июля 201813:54#323
Delfigamer
> Не лучше будет ввести абстрактные типы "byte", "word16", "word32" и "word64"
Есть "абстрактные" типы u8, u16, u32, u64. С ними можешь делать что угодно, хоть арифметические операции, хоть побитовые.
Есть char8, char16, char32. Это уже не разу не абстрактные байты, а значит не все операции с ними разрешены, разрешены только сравнения.

> а кодировку текста считать свойством целой строки, а не отдельного байта
Кодировка пока что остаётся исключительно на совести программиста. Ты можешь в массиве char8 хранить символы в windows1251, тебе никто не запрещает.
Существующие суффиксы u8, u16, u32 это всего лишь способ передачи строкового литерала в программу из исходного текста. Ты вполне можешь написать что-то вроде

auto my_struct= ToWindows1251( "моя строка"u8 );

DelfigamerПостоялецwww13 июля 201814:06#324
Panzerschrek[CN]
> Существующие суффиксы u8, u16, u32 это всего лишь способ передачи строкового
> литерала в программу из исходного текста.
А почему нельзя перевести литерал один-в-один, как он записан в исходном тексте?
А что произойдёт, если в литерале будет невалидный utf-8? Как поведут себя u8, u16 и u32?
А что будет, если я наберу "\x00\xFF\xF0"u8? Для справки - с 0xF0 начинаются 4-байтовые коды.
А если я захочу залить в литерал какой-нибудь почти текстовый чанк с небольшими двоичными вставками? Например, у меня велосипедная консоль и "\x1Bc\0xFF\x00\x00This is red!" устанавливает цвет вывода. Каким литералом мне такое вставлять?
Ну и наконец, почему u8 - это и беззнаковое целое, и utf-8?

Panzerschrek[CN]
> Это уже не разу не абстрактные байты, а значит не все операции с ними
> разрешены, разрешены только сравнения.
Обычно, математика работает наоборот - чем меньшим количеством свойств обладает вещь, тем более она абстрактна; а определения арифметических операций, взаимного порядка и равенства/неравенства - это частные случаи свойств. Логика в том, что более абстрактные концепции подходят под больше ситуаций, потому что у них меньше критериев - тех самых свойств - которым должна удовлетворять конкретная ситуация.

Правка: 13 июля 2018 14:11

Panzerschrek[CN]Участникwww13 июля 201815:00#325
Delfigamer
> А почему нельзя перевести литерал один-в-один, как он записан в исходном
> тексте?
Пока что компилятор умеет работать только с utf-8 кодировкой исходников. Если бы он умел другие кодировки, то не мешало бы.
Но пока что я сильно сомневаюсь, что нужно что-то кроме utf-8.

> А что будет, если я наберу "\x00\xFF\xF0"u8
invalid escape sequence
Код символов вводится как-то так "\uFFF0".

> А что произойдёт, если в литерале будет невалидный utf-8
Ничего хорошего не будет. Надо, чтобы исходники программы были валидны.

> Для справки - с 0xF0 начинаются 4-байтовые коды.
А в чём проблема? 4-хбайтовый код закодируется же в utf-8.

> А если я захочу залить в литерал какой-нибудь почти текстовый чанк с небольшими
> двоичными вставками
Что значит "залить в литерал"? Состряпать соответствующий исходник?

> Например, у меня велосипедная консоль и "\x1Bc\0xFF\x00\x00This is red!"
Компилятор тебе подсунет UTF-8, а дальше раскодирую его как тебе надо.


> Ну и наконец, почему u8 - это и беззнаковое целое, и utf-8?
А вот это действительно, недочёт, что имя типа и суффикс строкового литерала совпадают. Но это не страшно, т. к. эти сущности применяюся в разном контексте.


> Обычно, математика работает наоборот - чем меньшим количеством свойств обладает
> вещь, тем более она абстрактна
Я употребил "абстрактность" в том смысле, что на основе целых типов ты можешь много чего реализовать, т. к. целые типы много чего умеют. Это некий "кирпич" из которого можно построить что угодно.

f1ufx_Постоялецwww13 июля 201815:11#326
прочитал тописк старт.
ещё раз пожалел что меня разбанили.
DelfigamerПостоялецwww13 июля 201815:33#327
Panzerschrek[CN]
> Пока что компилятор умеет работать только с utf-8 кодировкой исходников.
Что означает "умеет работать" и зачем это нужно? Он сломается на невалидном исходнике? Он разрешает китайские иероглифы в идентификаторах?

Panzerschrek[CN]
> А в чём проблема? 4-хбайтовый код закодируется же в utf-8.
Проблема в том, что после первого байта литерал заканчивается. Если декодер не учтёт границу литерала, то на последнем символе он полезет за пределы буфера. У тебя эта ситуация учитывается?

Panzerschrek[CN]
> Что значит "залить в литерал"? Состряпать соответствующий исходник?
> Компилятор тебе подсунет UTF-8, а дальше раскодирую его как тебе надо.
Так нельзя. Цветная консоль лежит в отдельной dll, скомпилирована каким-то дядей из исходников то ли на фортране, то ли на сях, и цвет текста обозначается серией байтов [0x1b 0x63 r-color g-color b-color]. Как мне закодировать такую серию в литерал?

Panzerschrek[CN]Участникwww13 июля 201815:52#328
f1ufx_
> прочитал тописк старт.
> ещё раз пожалел что меня разбанили.
Отпишись и не читай.

Delfigamer
> Что означает "умеет работать" и зачем это нужно? Он сломается на невалидном
> исходнике?
Будет воспринимать всё как utf-8, так что да, сломается. Нефиг исходники непонятно в чём кодировать.

> Проблема в том, что после первого байта литерал заканчивается.
Нет никакой проблемы, ты что-то не так понял.

> Как мне закодировать такую серию в литерал
constexpr-функцией.

DelfigamerПостоялецwww13 июля 201816:15#329
Ну окей, вроде понял - ты хочешь чисто текстовые строки, типа как в Пайтоне.
Я так понимаю, для абстрактных двоичных данных будут отдельные классы строк и литералов? Какого типа будут элементы таких строк?

Правка: 13 июля 2018 16:16

Страницы: 118 19 20 21 22 23 Следующая »

/ Форум / Флейм / ПроЭкты

2001—2018 © GameDev.ru — Разработка игр