типизация

[Vadim]

utkin
А может сделать два типа - числа и нечисла?

[utkin]

Возможно, но все же нужны уточнения. Нечисла это кто? А числа какие? Я за комплексные. Чтобы можно было указывать и без мнимой части (все равно, что умноженная на нуль). Опять же глупые ограчения вроде корни из отрицательных чисел. Зачем корни? Просто возведение любого числа в любую степень. Ну прочие полезные мелочи.

[alexs]

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

Если по алгоритму - это не обязательный процес - зачем вы это делаете?
на самом деле все преобразования между типами начинаются в 99% при выдаче информации пользователю. А внутри самого алгоритма - это не нужно делать. Если иначе - то скорее всего - что то при проектировании не ладно.

[perlpunk]

Нет, человек просто не совсем ясно выразил свою мысль. Тип на самом деле один - тип без типа. Или "один главный тип". А всё остальное - образовано от него.

Мне кажется это более удачной идеей. В Паскале же изначально типы не совместимы.

Хоть один пример, где это может пригодится? Веть обабатывать данные все равно приходится исходя из их типа.

[Vadim]

Хоть один пример, где это может пригодится?

Да пожалуйста.
Все знают про такой компонент, как TDataSet. Чтобы прибавить значение одного поля к другому, мы вынуждены писать:
DataSet.FieldByName('поле').AsInteger
А чтобы вывести значения поля в в HTML документ приходится писать так:
DataSet.FieldByName('поле').AsString
Ну и тому подобное.
А в случае концепции единого типа данных, всякие там AsТыры-Пыры писать не надо. Сколько времени экономится...

[utkin]

Еще пример, вывод даты на экран (я имею ввиду стандартные средства). Еще пример, Boolean и Integer. На самом деле примеров много. Возьмите свою собственную программу с большим числом строк и посмотрите, сколько раз проводилось явное преобразование типов. Почему программист должен обращать на это внимание? Для самоконтроля? Часть таких операций можно автоматизировать.

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

Если по алгоритму - это не обязательный процес - зачем вы это делаете?

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

[perlpunk]

Хоть один пример, где это может пригодится?

Да пожалуйста.
Все знают про такой компонент, как TDataSet. Чтобы прибавить значение одного поля к другому, мы вынуждены писать:
DataSet.FieldByName('поле').AsInteger
А чтобы вывести значения поля в в HTML документ приходится писать так:
DataSet.FieldByName('поле').AsString
Ну и тому подобное.
А в случае концепции единого типа данных, всякие там AsТыры-Пыры писать не надо. Сколько времени экономится...

Получается вам нужно просто неявное преобразование типов. Для этого и есть Variant.
Пишете тогда что то типа DataSet.Field['поле'] и ваша проблема решена в большинстве случаев

Добавлено спустя 5 минут 23 секунды:

Еще пример, вывод даты на экран (я имею ввиду стандартные средства). Еще пример, Boolean и Integer. На самом деле примеров много. Возьмите свою собственную программу с большим числом строк и посмотрите, сколько раз проводилось явное преобразование типов. Почему программист должен обращать на это внимание? Для самоконтроля? Часть таких операций можно автоматизировать.

Вот пример с датой - в каком бы виде вы хотели чтоб дата выводилаcь? А если мне в разных случаях нужно выводить эту дату поразному - все равно возвращаемся к использованию процедуры форматирования даты при выводе.
тоже с булеан - когда то надо вывести в виде True : False, а когда то и в другом виде Есть/Нет, On/Off - и тут опять нужна явная проверка значения и подстановка соответствующей строки.

[utkin]

Это вопрос стандартизации, а не преобразования типов. Это уже отдельная тема.

Добавлено спустя 4 минуты 50 секунд:
Проблема все равно не решенная. И дело в ни неявном преобразовании типов. Можно использовать такой тип(ы) при работе с которыми у программиста не возникло бы вообще мысли о преобразовании. Тот же Boolean и Integer. Можно же в качестве Boolean использовать Integer? Пусть False это нуль, все остальное true. Или по-другому, не важно. Смысл в том, что при компиляции преобразования типов проходить не будет.

[Vadim]

Получается вам нужно просто неявное преобразование типов.

Да не нужно нам неявного преобразования типов. Нам вообще не нужно преобразования типов. В принципе. Пускай процессор лучше занимается более полезными вещами. Например, моделирует эффект Марангони.

[utkin]

В общих чертах так, если отбросить иронию в сторону. Я не говорю конечно, что можно избежать полного преобразования типов, но часть вопросов таким образом вполне решаема.

[shade]

А вот к примеру во многих (если не всех) функциональных языках тип выводиться компилятором
Так например языке caml

[AbakAngelSoft]

Типизация это метод уменьшающий возможность выстрелить себе в ногу. И должен максимально эффективно применяться самими программистами.
Если рассматривать исходные коды delphi и тем более лазарус видно, что многие не понимают что такое тип. тип это не только Integer!
Если у нас есть размеры прямоугольной области width и height каких они должны быть типов? Integer? нет! Иначе возможна операция width := height; Это явная ошибка!
Если сделать Width: TWidth и Height: THeight. Все отлично компилятор нам подскажет где мы ошиблись.
Когда мы поворачиваем этот прямоугольник то указываем явно что куда надо преобразовать. Мы рассчитываем по некоторой формуле и знаем что мы делаем если произойдет ошибка мы в курсе где ее искать.

Существует интересная идея применять в языках программирования для числовых данных те же правила что и в физике (2кг/см2 + 3кг/см2)*5см2 = 25кг, а 2кг+3см - недопустимая операция

[Max Rusov]

Если сделать Width: TWidth и Height: THeight. Все отлично компилятор нам подскажет где мы ошиблись.

А во FreePascal так можно? Описать 2 числовых типа, которые будут между собой несовместимы?

[Sergei I. Gorelkin]

Можно сделать числа полями записей, тогда типы записей будут несовместимы.
Следующим шагом переопределяем для записей операторы присваивания и оказываемся там же, откуда пытались уйти.

[AbakAngelSoft]

На FreePascal к сожалению нельзя (или я не знаю как - кто знает подскажите - очень надо!!!) но мы вроде обсуждаем типизацию вообще