типизация

Проектирование и разработка идеального средства программирования.

Модератор: Модераторы

типизация

Сообщение ev » 07.10.2007 23:11:57

какая же должна быть типизация у идеала?
и почему ;)
ev
долгожитель
 
Сообщения: 1763
Зарегистрирован: 27.04.2005 23:19:06
Откуда: Москва

Сообщение e-moe » 08.10.2007 00:13:15

Хотелось бы видеть базовые типы, ну те что и сейчас реализованы во всех языках (для унификации, обмена данными между модулями от разных авторов и т.д.) и что-то очень "гибкое" но так же нативно поддерживаемое - т.е. я бы хотел при объявлении целочисленной переменной указывать нужную именно мне разрядность(не обязательно степень двойки), для вещественных хотел бы отдельно задавать размеры мантиссы и порядка.. ну думаю я понятно описал
e-moe
новенький
 
Сообщения: 31
Зарегистрирован: 27.09.2007 17:00:39

Сообщение Deepthroat » 08.10.2007 00:50:10

Для разных языков разные требования. Есть языки с жесткой типизацией, как C++ или Pascal, а есть языки с более мягкой типизацией и возможностью преобразования типов в зависимости от контекста, такие, как Perl или PHP.

Неудобно бывает и там, и там. Паскалю не хватает простого преобразования типов друг в друга, тогда как в PHP иногда приходится принудительно указывать тип, чтобы не отдавать преобразование на милость транслятору.

Generic решает часть проблем, но лишь для сходных типов и в compile-time. А хотелось бы простого преобразования не только чисел друг в друга, но и чисел в строки и наоборот, записей в строки и т.п.

Например, так:
Код: Выделить всё
program cast;
var
  s: string;
  i: integer;
  r: real;
begin
  s := '578'; //комментарии излишни
  (string) r := s + '.5'; //r = 578.5
  i := 10 + (integer) s; //i = 588
  i := (integer) (r + i + 0.5); //i = 579 + 588, посчитайте, мне влом, но там целое число
end.
Аватара пользователя
Deepthroat
постоялец
 
Сообщения: 144
Зарегистрирован: 06.09.2007 00:21:34
Откуда: Outer Heaven

Сообщение bw » 08.10.2007 01:24:48

Я считаю что и простые типы должны быть объектами, т.е. иметь набор методов. Тогда реализуя метод __convert__(toType) (подчеркивания я взял из Python) можно описать преобразование любого типа в любой. Что касается синтаксиса преобразования, то S := String(1 + 2), я считаю более приемлемым. Что бы переопределить методы стандарных типов, должны присутствовать механизмы динамичекского переопределения, либо статического, но тогда потребуются дополнительные директивы. Возможно тут помогут метаклассы (метатипы :-).

..bw
Аватара пользователя
bw
постоялец
 
Сообщения: 359
Зарегистрирован: 01.12.2005 11:36:23
Откуда: Усть-Илимск

Сообщение ev » 08.10.2007 13:36:57

а что это никто не предлагает вообще убрать объявление переменных? :)
неужели нет поклонников такого подхода?

ведь пхп-шники и подобные очень защищают подобных подход - удобство, скорость разработки и т.п.
но стоит заметить, что ошибки искать гораздо сложнее
ev
долгожитель
 
Сообщения: 1763
Зарегистрирован: 27.04.2005 23:19:06
Откуда: Москва

Сообщение alexs » 08.10.2007 13:45:13

насчёт типизации
я периодически пинаю рзработчика IBExpert-а
он реализовал своё подмножество диалекта языка в IBEblock - очень не хватает именно таких мелких зашит от дурака. Он сопротиваляется :-(
также предлагал ему сделать эелементарнийшую проверку - нельзя использовать не проинициализированную переменную - тоже не подержал :-(
хотя 2 этих органичения очень сильно облегчают отладку и поиск глюков.
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4053
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Сообщение bw » 08.10.2007 21:10:41

> а что это никто не предлагает вообще убрать объявление переменных?
Я как питонозаводчик, конечно бы предложил.
Но так как у меня богатый опыт работы с этим языком, именно по этому предлагать не буду :-).

> но стоит заметить, что ошибки искать гораздо сложнее
Это не проблема.

..bw
Аватара пользователя
bw
постоялец
 
Сообщения: 359
Зарегистрирован: 01.12.2005 11:36:23
Откуда: Усть-Илимск

Сообщение Deepthroat » 09.10.2007 00:27:55

Я считаю что и простые типы должны быть объектами, т.е. иметь набор методов. Тогда реализуя метод __convert__(toType) (подчеркивания я взял из Python) можно описать преобразование любого типа в любой.

Удобно, согласен. Но есть недостатки. Мы тогда лишимся низкоуровневых типов, в которых нужно хранить биты и данные, структуру которых мы знаем, по крайней мере, для данной машины. Паскаль, все-таки, не настолько высокоуровневый язык. Даже в Яве, помимо классов-типов, оставили примитивные типы. А тут паскаль - компилируемый язык, который должен подходить и для системного программирования, где нам нужен полный контроль за структурой, вплоть до бита.

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

Что касается синтаксиса преобразования, то S := String(1 + 2), я считаю более приемлемым.

Согласен, паскаль, все ж таки. Это я по аналогии с РНР так скобки расставил, для примера. А вообще, тут я согласен с тобой.

а что это никто не предлагает вообще убрать объявление переменных?

В РНР есть область видимости и существования, регулируемая вплоть до блока операторов. Если я создал переменную в цикле, я могу быть уверен, что за пределами цикла переменной не будет.

Более того, есть конкретные рекомендации, которые, при их несоблюдении выливаются в Warning'и, говорящие о том, что перед использованием любая переменная должна быть объявлена путем присвоения ей начального значения.

Примерно такой же подход реализован в С++, но там переменные объявляются с указанием типа.

Так что переменные надо объявлять везде. Разница в том, как это делается, с указанием типа или без такового. Но это уже не вопрос объявления, это вопрос типизации.
Аватара пользователя
Deepthroat
постоялец
 
Сообщения: 144
Зарегистрирован: 06.09.2007 00:21:34
Откуда: Outer Heaven

Сообщение ev » 09.10.2007 00:40:16

В РНР есть область видимости и существования, регулируемая вплоть до блока операторов. Если я создал переменную в цикле, я могу быть уверен, что за пределами цикла переменной не будет.

ух... мнеб такую уверенность... сколько косяков именно из-за глюков в интерпретаторе при видимости переменных... хотя это конечно претензии именно к разработчикам интерпретатора...
ev
долгожитель
 
Сообщения: 1763
Зарегистрирован: 27.04.2005 23:19:06
Откуда: Москва

Сообщение bw » 09.10.2007 00:49:54

> Мы тогда лишимся низкоуровневых типов
Не лишимся. Сейчас все операции над встроенными (простыми) типами тоже выполняется машинным кодом (размещенным непосредственно в потоке кода или вынесенным в функции). Та же самая __convert__ будет выполнять операции конвертации из простого типа с которым она "сопоставленна". Возможно в Run-Time потребуются дополнительные структуры, которые будут описывать этот тип, хотя это не обязательно. А вот экземпляр этот простого типа останется точно таким же (RTTI и прочего не будет), т.е. все операции над типом предопределяются во время компиляции. SizeOf же безболезненно используется над типом Integer и размер переменной Integer от существования такой функции не изменился. Точно так же размер Integer не изменится, если компилятор в нужном месте подставит вызов (и заменит его на машинный код):
Код: Выделить всё
var
  I: Integer;
  S: String;
begin
  I := 12;
  S := '__' + I + '__'; {S := '__' + I.__convert__(String) + '__';}


..bw
Аватара пользователя
bw
постоялец
 
Сообщения: 359
Зарегистрирован: 01.12.2005 11:36:23
Откуда: Усть-Илимск

Сообщение Vadim » 09.10.2007 06:03:27

По поводу "убрать объявления переменных" история показала, что это путь ведущий к ошибкам. Вспомните Basic, ведь там именно так и было, точнее объявления были неявными. Но впоследствии пришлось ввести дополнительную опция, требующую явно объявлять переменные.
И ошибки вследствии неявного объявления хоть и детские, но как ни странно их совершают не только начинающие, но и матёрые зубры программирования. :) А уж для тех кто начинает программировать, особенно самостоятельно, это и вообще иногда неразрешимая проблема.
А типизация больше нужна компилятору и, как ни странно, пользователю, чем программисту. Программисту проще использовать один универсальный тип без заморочки с его преобразованием. Но, есть как всегда но... :) Если компилятор (или run-time блок) начнёт сам преобразовывать типы к нужному виду, то не всегда он выдаёт то, что нужно. Да и время лишнее затрачивается.
Вот если бы изобрести универсальный тип, который вообще не нужно было бы никуда конвертировать... :)
Vadim
долгожитель
 
Сообщения: 4112
Зарегистрирован: 05.10.2006 08:52:59
Откуда: Красноярск

Сообщение alexs » 09.10.2007 07:21:22

Vadim писал(а):Вот если бы изобрести универсальный тип, который вообще не нужно было бы никуда конвертировать...

строки :-)
набор процедур для выполнения арифметики без преобразования к цичслам уже сейчас есть :-)
PS
типизация нужна - однозначно
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4053
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Сообщение Vadim » 09.10.2007 09:14:01

alexs
Это я понимаю, что строки. :)
Ведь мы сами читаем абстрагированиое изложение информации именно в виде строк. А вот как потом происходят вычисления - никто не знает. :)
набор процедур для выполнения арифметики без преобразования к цичслам уже сейчас есть

Я полагаю, что преобразование идёт внутри интерпретатора или добавляется компилятором в виде run-time кода. :)
А вот когда компьютер будет хранить у себя и обрабатывать информацию именно как строки, вот тогда да...
Vadim
долгожитель
 
Сообщения: 4112
Зарегистрирован: 05.10.2006 08:52:59
Откуда: Красноярск

Сообщение alexs » 09.10.2007 09:17:44

Vadim писал(а):А вот когда компьютер

Ты хотел сказать процессор?
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4053
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Сообщение Vadim » 09.10.2007 09:28:41

alexs
Нет, именно компьютер. :)
Ведь процессор без остальных запчастей, работающих так же как и процессор, нам не нужен? Или я ошибаюсь? :)
Vadim
долгожитель
 
Сообщения: 4112
Зарегистрирован: 05.10.2006 08:52:59
Откуда: Красноярск

След.

Вернуться в Компилятор / язык программирования

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4

Рейтинг@Mail.ru