MSElang : обсуждение фишек

[debi12345]

В ньюс-конфе я один отбиваюсь Мартин хочет чтобы компилятор позволял писать проги, читаемые как письма (то есть легкие в понимании, нетребовательные к знанию архитектурных и т.п. нюансов) - и тут же объявил, что намерен наплодить немерянно типов данных под разные размеры (байт, слово, двойное и четверное слово,..). Я (будучи очарован концпией "проги, читаемые как письма") предлагаю что нужно этих типов остсвить по минимуму (целый со знаком, целый без знака, вещественный) и если надо то вместо размера указывать нужный диапазон значений (что по ходу может объединить в один тип знаковые и беззнаковые целые) - иначе какая нафиг простота ?
Также опять всплыл вопрос реализации юникода с учетом интеграции алфавитов инопланетян...
Кто подписан на конфу - можете внести свою лепту в выработку концепции.

[zub]

Привет OpenGL!
Хочу сообщить тебе что надо нарисовать треугольник вонтам,
И 2 линии тут.
С уважением, програмист.

компилируется?

[debi12345]

компилируется?

Рано ли поздно придем к тому, что скомпилируется

[mse]

@ZUB
"read like a letter" not "write like a letter".

[Mikhail]

Мартин хочет чтобы компилятор позволял писать проги, читаемые как письма

Тогда сущностей должно быть мало.

предлагаю что нужно этих типов остсвить по минимуму (целый со знаком,
целый без знака, вещественный) и если надо то вместо размера указывать нужный диапазон значений

Может так: int, uint, shortint, shortuint, longint, longuint, byte. Базовый тип int зависит от разрядности процессора, byte всегда беззнаковый 8 бит.
С вещественными аналогично.
Типы вида intXX разрешить только в модулях помеченных как unsafe.

Тип строк (встроенный) лучше чтобы был один. Наверное лучше для этого использовать UnicodeString. Работа с остальными типами строк исключительно через соответствующие библиотеки.

[Иван Шихалев]

Я бы посоветовал глянуть систему типов Ruby — не для подражания, а как пример идей — там отвязка от железа полная.

[debi12345]

Может так: int, uint, shortint, shortuint, longint, longuint, byte. Базовый тип int зависит от разрядности процессора, byte всегда беззнаковый 8 бит.
С вещественными аналогично.

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

Добавлено спустя 1 минуту 57 секунд:

Наверное лучше для этого использовать UnicodeString. Работа с остальными типами строк исключительно через соответствующие библиотеки.

А RawString ? Или ByteArray ? С подcчетом ссылок или без ?

[Mikhail]

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

Не думаю что это разумно для кроссплатформенной разработки. Тут нужен слой абстракции, в том числе и по используемым типам. Такой подход используется во многих библиотеках, смотри хотя бы OpenGL или модуль Windows. Иначе придется бегать по всем исходникам исправляя разрядность.

А RawString ? Или ByteArray ? С подcчетом ссылок или без ?

Библиотекой. Устраивать зоопарк строк это плохо для производительности и надежности.

[debi12345]

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

Получается,что например константа для одной архитектуры - одна, она же самая для другой - другое значение ? Все-таки с диапазонами будет гибче, вроде :

Код: Выделить всё

type
  longint = integer from MIN_SINT to MAX_SINT; // зависит от архитектуры
  longword = integer from 0 to MAX_UINT; // зависит от архитектуры

var
  i1: longint; // зависит от архитектуры
  i2: longword; // зависит от архитектуры
  i3: integer from 0; // 0..MAX_UINT; // зависит от архитектуры
  i4: integer from 0 to 100; // всегда BYTE;

[Mikhail]

Получается,что например константа для одной архитектуры - одна, она же самая для другой - другое значение ? Все-таки с диапазонами будет гибче, вроде :

а чем хуже так

Код: Выделить всё

module std.types; unsafe;
type int = int32;
       uint = uint32;
       ...
       byte = uint8;

...
end;

соответственно где-то подключаем

Код: Выделить всё

module test;
import std.types.*;

...

var i:int;
begin
end;

Для каждой платформы своя стандартная библиотека.

[GrayEddy]

Почему бы не взять типы данных из Java (кроссплатформенного и весьма успешного)?
Глядишь, и Java-ты подтянутся (врага надо бить его же оружием).
Оформление кода я бы предпочел в стиле camelCase.
+ very good debugger.

MSElang = 75% Pascal + 25% Java

Используйте принцип бритвы Оккамы. Ничего лишнего.

[debi12345]

Почему бы не взять типы данных из Java (кроссплатформенного и весьма успешного)?

Примерно это и предлагается. Минимум типов. Также Мартину (электронщику по професcии) нужен низкоуровневый код - для работы с ARM-ми. А значит длина регистров важна. Ка совместить минимум типов с заданием длины ?
Через указание диапазона для одного универсального типа...

[Mikhail]

Через указание диапазона для одного универсального типа...

Спорно. Зачем указывать диапазон, если разрядность аргументов выбивается из конечного числа значений?

PS ivankob4mse2 Ваш ник?

[debi12345]

Зачем указывать диапазон, если разрядность аргументов выбивается из конечного числа значени

Можно совместить приятное с полезным - например задать диапазон не до 128, а до 100 - и проверять присвоения уже на этапе компиляции (в рантайме - опционально). Хотя конечно можно задавать диапазон в формате с разрядностью :

type
longint = signed integer:32;
cardinal = unsigned integer:32;

но это не так гибко - придется разделять знаковые и беззнаковые типы...

ivankob4mse2 Ваш ник?

Ага

[Mikhail]

но это не так гибко - придется разделять знаковые и беззнаковые типы...

Их все равно нужно разделять, ведь для работы с ними используются разные машинные команды.
Т.е. нужно сделать примерно, то что декларирует Мартин. Ввести типы вида intXX и uintXX поддерживаемые на уровне железа и, возможно, несколько эмулируемых типов. Например int64 на 32 разрядной машине легко эмулируется.

Насчет функций соглашусь с Вами. Функции нужно делать только в смысле чистых функций или не делать их вообще. Для остального есть процедуры.

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