freepascal.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;


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

а чем хуже так

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

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

...
end;


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

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

module test;
import std.types.*;

...

var i:int;
begin
end;


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

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

MSElang = 75% Pascal + 25% Java

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

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

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

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

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

PS ivankob4mse2 Ваш ник?

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

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

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

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

ivankob4mse2 Ваш ник?

Ага

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

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

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

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