Высокий/низкий уровень, ручное/автоматическое управление

← →
Anatoly Podgoretsky © (2010-11-12 14:26) [240]

> Какой кыашмар (12.11.2010 14:17:59) [239]

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

← →
oxffff © (2010-11-12 14:53) [241]

> Mystic © (12.11.10 13:02) [238]
>
> > oxffff © (12.11.10 12:52) [237]
>
>
>
> generic
> type X is private;
> type Y is private;
> package Unicomparer
> procedure Something(Arg_X: X; Arg_Y: Y);
> -- .......
>
>
> Далее
>
>
> generic
> type X is private;
> type Y is private;
> with procedure Something(Arg_X: X; Arg_Y: Y);
> package DifficultCase
> -- ...
>
>
> Ну и в коде
>
>
> package ComparerForm is new Unicomparer(X => TControl,
> Y => TForm);
> package ExtraDifficultCase is new DifficultCase(X => TControl,
> Y => TForm; Something = ComparerForm.Something);

Не принимается. :)

Хех. Насколько я понял из этого кода это специализация конкретных типов конкретным comparerом. Причем для каждой пары все это делается ручками программистом, а не компилятором.
Это извините совершенно не обобщенное программирование, а сплошное "специализирование".

← →
Какой кыашмар (2010-11-12 15:14) [242]

> Anatoly Podgoretsky © (12.11.10 14:26) [240]

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

Или наоборот. Не, ну в ядре процессора - однозначно квази-RISK. А вот снаружи запросто что-то высокоуровневое может встрять. Плюс отдельное ядро для сборщика мусора - и goodbye, unmanaged :)

← →
Какой кыашмар (2010-11-12 15:18) [243]

> С выхода P4, ага.

Это я конечно просвистел. По факту в первом пентюхе уже мало что от x86 осталось.

← →
Mystic © (2010-11-12 16:03) [244]

> Хех. Насколько я понял из этого кода это специализация конкретных
> типов конкретным comparerом. Причем для каждой пары все
> это делается ручками программистом, а не компилятором.
> Это извините совершенно не обобщенное программирование,
> а сплошное "специализирование".

По мощности тоже самое, только надо чуть больше уточнений прописывать руками. 90% основных потребностей в шаблонах это накрывает. А если говорить об оставшихся экзотических 10%, то это можно сделать руками. Хуже, когда основное внимание уделяется экзотическим 10% случаев, из-за которых страдают 90% остальных (например, невозможность проверить шаблон на этапе компиляции, дикие ошибки при инстанцировании в несколько строчек со всеми кишками). А тут все просто: имеет процедура Something неправильную сигнатуру, тут же в строке
package ExtraDifficultCase is new DifficultCase(X => TControl, > Y => TForm; Something = ComparerForm.Something);
это выяснится, да еще и с указанием, где конкретно что не так :)

← →
oxffff © (2010-11-12 16:15) [245]

> Mystic © (12.11.10 16:03) [244]

С возрастанием числа параметров сложность возрастает. Но тем не менее удобство generics неспорно.
:)

Я кстати долго вспоминал С++ космический код из

template<typename X>
class Y
{
X x;
public:
Y(): x() { x.init(); }
}

Никак не воспринимается эта конструкция. Хотя дело привычки.
Язык неплохой, но синтаксис ....

← →
Mystic © (2010-11-12 17:04) [246]

> С возрастанием числа параметров сложность возрастает.

Что-то мне подсказывает, что с таким возрастанием параметров приближается пушной зверек. Скажем так, эта штука не для массового злоупотребления.

← →
_oxffff (2010-11-12 19:09) [247]

> Mystic © (12.11.10 17:04) [246]

Тем не менее template позволяют сделать работу за программиста, в то время как с generics специалисту придется выполнять работу самому.
Поэтому возможности template шире generics. Мы еще не рассматривали в качестве параметров константы. :)

← →
Mystic © (2010-11-12 19:15) [248]

> Мы еще не рассматривали в качестве параметров константы.
> :)

Легко:

generic type Element is private; Size: Positive := 200; package Stacks is -- ...

Вот что допустимо в Ada из классов:

type T is limited private -- тип T - любой тип type T is private -- тип T - любой не лимитированный тип type T is (<>) -- тип T любой дискретный тип -- (целочисленный или перечислимый) type T is range <> -- тип T любой целочисленный тип type T is mod <> -- тип T любой модульный целочисленный тип type T is digits <> -- тип T любой вещественный тип с плавающей точкой type T is delta <> -- тип T любой вещественный тип с фиксированной точкой type T is delta <> digits <> -- тип T любой вещественный децимальный тип type T is access Y; -- тип T любой ссылающийся на Y ссылочный тип type T is access all Y; -- тип T любой "access all Y" ссылочный тип type T is access constant Y; -- тип T любой "access constant Y" ссылочный тип -- примечание: тип Y может быть предварительно описанным -- настраиваемым параметром type T is array(Y range <>) of Z; -- тип T любой неограниченный массив элементов типа Z -- у которого Y - подтип индекса type T is array(Y) of Z; -- тип T любой ограниченный массив элементов типа Z -- у которого Y - подтип индекса type T is new Y; -- тип T любой производный от Y тип type T is new Y with private; -- тип T любой не абстрактный тэговый тип -- производный от Y type T is abstract new Y with private; -- тип T любой тэговый тип производный от Y type T is tagged private; -- тип T любой не абстрактный не лимитированый -- тэговый тип type T is tagged limited private; -- тип T любой не абстрактный тэговый тип type T is abstract tagged private; -- тип T любой не лимитированый тэговый тип type T is abstract tagged limited private; -- тип T любой тэговый тип

← →
_oxffff (2010-11-12 19:22) [249]

> Mystic © (12.11.10 19:15) [248]

То есть ты продолжаешь считать, что выразительность generics наравне c templates?

← →
_oxffff (2010-11-12 19:26) [250]

> Mystic © (12.11.10 19:15) [248]

И тебя совершенно не смущает, что c generics тебе придется часть обобщать вручную сложные вещи.

2 года назад я дискутировал на эту тему в комментариях у Craig Stuntz

http://blogs.teamb.com/craigstuntz/2008/08/29/37832

Представь себе обобщенное выражение

(U+T*Z-V*10*(cast to V) (U.Stuff(Z*E)))/U

С generics программисту придется разобрать это выражение и задать все ограничения и все обобщенные операторы самому. С template этого делать не нужно. Хочешь разобрать его вручную?

← →
_oxffff (2010-11-12 19:39) [251]

> Mystic © (12.11.10 19:15) [248]

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

:)

← →
Mystic © (2010-11-12 19:46) [252]

> То есть ты продолжаешь считать, что выразительность generics
> наравне c templates?

Мне больше импонирует строгий адский синтаксис, чем C++ ный. Пусть там и больше букв :) По возможностям они менее-более одинаковы. В Ada больше тавтологии в том, что надо все прописать руками. В C++ больше тавтологии в том, что generic в Ada относится к пакету (package, модуль, аналог Delphi-йского uint), а в C++ template относится к классу или функции (ибо модулей нет), поэтому иногда приходится дублировать описания типов в каждом классе. Например, если у меня есть шаблонный параметр типа T, то я могу в самом пакете один раз определить массив объектов типа T, и потом его юзать во всем коде модуля. А в C++ мне надо будет писать template<typename T> буквально перед каждым классом и шаблоном. Например, в хидере <vector> от M$ строка "typedef typename _Alloc::difference_type " встречается четыре раза. Два раза (vector const iterator и vector iterator) встречается

_Myt& operator-=(difference_type _Off) { // decrement by integer return (*this += -_Off); }

← →
Mystic © (2010-11-12 19:55) [253]

> Представь себе обобщенное выражение
>
> (U+T*Z-V*10*(cast to V) (U.Stuff(Z*E)))/U
>
> С generics программисту придется разобрать это выражение
> и задать все ограничения и все обобщенные операторы самому.
> С template этого делать не нужно. Хочешь разобрать его
> вручную?

Я не вижу смысла в этом выражении. Это некая абстракция. Более того, как это происходит в C++? Я в таких выражениях я как минимум в половине случаев допускаю опечатки, ошибки, мне выдает компилятор сообщение об ошибке на пару экранов. Я матерюсь, и все равно разбираю все вручную. Точнее, любуюсь на текст вроде

typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, typename _Alloc::rebind<std::pair<const _Key, _Tp> >::other>::iterator std::map<_Key, _Tp, _Compare, _Alloc>::find(const _Key&) [with _Key = unsigned int, _Tp = phrase_info_t, _Compare = std::less<unsigned int>, _Alloc = std::allocator<std::pair<const unsigned int, phrase_info_t> >]

потом копирую текст ошибки в notepad, там его привожу к нормальному виду, смотрю чего не хватает, исправляю, иду дальше. И мне кажется, это занимает куда больше времени, чем описать вручную, что откуда надо брать, да и вероятность ошибки при этом меньше. А если приходится возвращаться к написанному ранее коду, то это сразу вгоняет меня в состояние вселенской тоски и депрессии :)

← →
Игорь Шевченко © (2010-11-12 19:55) [254]

Какой кыашмар (12.11.10 15:18) [243]

Как бы ни Пентиум, ни Пентиум 4 не IA-64 ни разу.
Потому трындеть про "давно отсутствует архитектура x86" можно, но бессмысленно.

← →
Какой кыашмар (2010-11-12 21:40) [255]

> Как бы ни Пентиум, ни Пентиум 4 не IA-64 ни разу.

Сам-то понял, чё сказал?

> Потому трындеть про "давно отсутствует архитектура x86"
> можно, но бессмысленно.

Ну дык и не трынди.

← →
DiamondShark © (2010-11-12 21:44) [256]

> Я поклонник обобщенного программирования

Есть языки, на которые обобщённое программирование ложится более естественно.

Например, в функциональных языках с автоматическим выводом типов обобщённое программирование получается "даром", т.е. вообще без каких-либо специальных синтаксических примочек.

← →
_oxffff (2010-11-12 21:58) [257]

> Mystic © (12.11.10 19:46) [252]
>
> > То есть ты продолжаешь считать, что выразительность generics
>
> > наравне c templates?
>
>
> Мне больше импонирует строгий адский синтаксис, чем C++
> ный. Пусть там и больше букв :) По возможностям они менее-
> более одинаковы.

Тогда и с машинными кодами по возможностям одинаковые. Букв чуть больше.
:)

← →
TUser © (2010-11-12 22:00) [258]

Читаю тут:
М.В.Мозговой. Алгоритмы, языки, автоматы, компиляторы. 2006.

С. 101: "на любую хорошую идею найдется неприятность в виде слишком рьяных последователей"

Это автор про парадигмы программирования, струтурное, объектно-ориентированное, автоматное ...

Нуи до кучи
- всякий овощ ...
- любую идею можно довести до состояния абсолютного идиотизма
- и т.д.

← →
DiamondShark © (2010-11-12 22:11) [259]

> - любую идею можно довести до состояния абсолютного идиотизма

Интересно, можно ли довести до состояния абсолютного идиотизма идею о том, что любую идею можно довести до состояния абсолютного идиотизма?

← →
_oxffff (2010-11-12 22:26) [260]

> DiamondShark © (12.11.10 22:11) [259]
>
> > - любую идею можно довести до состояния абсолютного идиотизма
>
> Интересно, можно ли довести до состояния абсолютного идиотизма
> идею о том, что любую идею можно довести до состояния абсолютного
> идиотизма?

Есть в теории типов "Про рекурсивные типы". Это туда.

← →
Игорь Шевченко © (2010-11-12 22:33) [261]

Какой кыашмар (12.11.10 21:40) [255]

Я тут ссылку давал на интеловскую доку, читай, воздастся и тебе

← →
Дмитрий Белькевич (2010-11-13 00:47) [262]

> Система команд x86 эмулируется

Ну, вообще, это для меня не новость, токо не с P4, а уже давно.

> Не за горами момент когда эту обузу - поддержку x86-совместимости
> - отправят на свалку истории.

Оптимистично, но не реалистично.

>Это я конечно просвистел. По факту в первом пентюхе уже мало что от x86 осталось.

А наружу всё равно торчит х86, странно, да?

>С. 101: "на любую хорошую идею найдется неприятность в виде слишком рьяных последователей"

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

← →
Какой кыашмар (2010-11-13 06:05) [263]

> Игорь Шевченко © (12.11.10 22:33) [261]

> Я тут ссылку давал на интеловскую доку, читай, воздастся
> и тебе

Я тех доков начитался по немогу, так что сам почитай.
Во-первых, пальцем покажи, гдя я говорил что IA-64 это пентиум.
Дальче, пентиум - суперскаляр, хоть и с покоцанной суперскалярностью. Какое нафиг отношение к этому имеет x86, кроме сэмулированной системы команд? Разница в архитектуре между IA-64 и пеннтюхом куда меньше, чем между пентюхом и 386-486. По архитектуре она скорее количественная, чем качественная - больше конвейеров, больше одинаковых функциональных блоков, собственная более развитая система команд - и благодаря отказу от прямой поддержки опкодов x86 тоже.

← →
Какой кыашмар (2010-11-13 06:12) [264]

> А наружу всё равно торчит х86, странно, да?

Ты лучше вспомни, когда он вышел, и странно не будет. А потом подумай, почему в IA-64 эта эмуляция сбоку, и какой следующий шаг.

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

← →
Дмитрий Белькевич (2010-11-13 12:23) [265]

> Ты лучше вспомни, когда он вышел, и странно не будет

Так для меня этот как раз таки не странно. Всё логично и объяснимо. Удивиться должен ты, ведь это ты утверждаешь, что x86 скоро умрёт. Однако его давно и упорно эмулируют.

> А потом подумай, почему в IA-64 эта эмуляция сбоку

Да. И где этот IA 64? Загляни на свалку истории - там много интересного.

> Производители давно считают опкоды x86 тормозом. Да для
> этого и не надо быть разработчиком процессоров, чтобы понять
> что в суперскалярность x86 хреново вписывается.

Ну так я же не спорю с тем, что х86 морально устарел уже тогда, когда его начали эмулировать. Да, тормоз, да хреново вписывается. Но - так уж случилось, и это изменить очень сложно, читай - дорого. Но и делать с этим, уже имеющимся, "счастьем" что-то нужно.

← →
euru © (2010-11-13 12:47) [266]

> oxffff © (12.11.10 14:53) [241]
> Не принимается.
> :)Хех. Насколько я понял из этого кода это
> специализация конкретных типов конкретным comparerом. Причем
> для каждой пары все это делается ручками программистом,
> а не компилятором. Это извините совершенно не обобщенное
> программирование, а сплошное "специализирование".

Значит, в случае сборки мусора вы не доверяете ЯП и среде выполнения и настаиваете на сборке руками программиста, что не гарантирует корректности работы программы.
А в случае с шаблонами вы требуете от ЯП того, что и программист-то не сможет выполнить.
Странно как-то это.

← →
DiamondShark © (2010-11-13 14:01) [267]

> Ну так я же не спорю с тем, что х86 морально устарел уже
> тогда, когда его начали эмулировать.

х86 морально устарел уже тогда, когда его только начали выпускать.

← →
oxffff © (2010-11-13 14:21) [268]

> euru © (13.11.10 12:47) [266]
>
> > oxffff © (12.11.10 14:53) [241]
> > Не принимается.
> > :)Хех. Насколько я понял из этого кода это
> > специализация конкретных типов конкретным comparerом.
> Причем
> > для каждой пары все это делается ручками программистом,
>
> > а не компилятором. Это извините совершенно не обобщенное
>
> > программирование, а сплошное "специализирование".
>
> Значит, в случае сборки мусора вы не доверяете ЯП и среде
> выполнения и настаиваете на сборке руками программиста,
> что не гарантирует корректности работы программы.
> А в случае с шаблонами вы требуете от ЯП того, что и программист-
> то не сможет выполнить.
> Странно как-то это.

Разве я где-то требовал? :)

1. Мне было бы интересно использовать гибридный способ управления ссылками на объекты кучи в одном языке.
Есть конечно Microsoft C++ /mixed.
Но он мне бы хотелось больше удобства и Паскалеподобности

2. Также бы мне хотелось совместить безопасность generics с мощностью templates. Например, чтобы ограничения (отношения между типами выводились автоматически, а не налагались программистом). Как вам?

Хотеть конечно не вредно. Но и не хотеть тоже.

А какое имеют отношение детали реализации процессоров к ЯВУ?

> euru © (13.11.10 15:40) [269]
> А какое имеют отношение детали реализации процессоров к
> ЯВУ?

Есть мнение, что архитектура вычислительных систем должна проектироваться комплексно.

← →
Дмитрий Белькевич (2010-11-13 18:52) [271]

> х86 морально устарел уже тогда, когда его только начали
> выпускать.

Тогда было что-то лучшее за те же деньги?

> DiamondShark © (13.11.10 17:41) [270]
> Есть мнение, что архитектура вычислительных систем должна
> проектироваться комплексно.

Т.е. "серебряная пуля" всё-таки существует? И можно создать идеальный процессор, для которого можно создать универсальный идеальный язык программирования?

Или предполагается для каждого ЯВУ использовать специально для него разработанный процессор, учитывающий все особенности языка?

> oxffff © (13.11.10 14:21) [268]

> 1. Мне было бы интересно использовать гибридный способ управления
> ссылками на объекты кучи в одном языке.

А какие явные преимущества даёт такой способ управления? Мне также до сих пор непонятно назначение выражения a := nil;, если оно всё равно ничего не делает.

> 2. Также бы мне хотелось совместить безопасность generics
> с мощностью templates.

Есть предложения, как это можно сделать?

> euru © (15.11.10 10:23) [273]
>
> > oxffff © (13.11.10 14:21) [268]
>
> > 1. Мне было бы интересно использовать гибридный способ
> управления
> > ссылками на объекты кучи в одном языке.
>
> А какие явные преимущества даёт такой способ управления?
> Мне также до сих пор непонятно назначение выражения a :
> = nil;, если оно всё равно ничего не делает.
>

Это откуда a:=nil?

>
> > 2. Также бы мне хотелось совместить безопасность generics
>
> > с мощностью templates.
>
> Есть предложения, как это можно сделать?

В том или ином виде такой вывод делается программистом. Поэтому существует некий алгоритм как это делает человек.
Осталось его только формализовать и закодировать. По сути type checker при проверки типов, может устанавливать выводить отношения между левой и правой части при которых это выраженеи корректно. Например

U:=T; => T подтип U, либо есть ImplicitCast(T):U. вот Два ограничения.
Вы же это делаете явно для generics.

> oxffff © (15.11.10 10:50) [274]
> Это откуда a:=nil?

Если вкратце, то [121] [169] [171] [177].

> U:=T; => T подтип U, либо есть ImplicitCast(T):U. вот Два ограничения.

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

> euru © (16.11.10 14:01) [275]
>
> > oxffff © (15.11.10 10:50) [274]
> > Это откуда a:=nil?
>
> Если вкратце, то [121] [169] [171] [177].

Там был пример не мой. Я лишь пытался выяснить причину "паразита".
Как оказалось причины нет. Во всяком случае для меня нет сложности переписать код нормально в рамках обычной кучи.
Вопрос ко мне я не понял. Если можно повторить подробно и точно, чтобы не было раpночтений. Повторю, что мне интересен гибридный вариант управления кучами.

> > U:=T; => T подтип U, либо есть ImplicitCast(T):U. вот
> Два ограничения.
>
> В принципе, я согласен, что в данном случае это можно было
> бы делать автоматически. Но, возможно, есть ситуации, когда
> такой вывод будет некорректен.

Аналогично такую информацию можно вывести из примера.
T+U*Z-U.ABC(U,T).
То есть действительно это не будет тривиальная информация об отношениях в generics. Однако позволила бы выдать более понятную информацию. Например Отсутствует компонент abc у Tmytype принимающий integer и integer и возвращающий тип который бы удовлетворял оператору - принимающего этот тип и double и т.д. Хотя возможно оставить и ручное ограничение и автоматическое. Смысл в том, что информация об ошибке была понятна.

> Аналогично такую информацию можно вывести из примера.
> T+U*Z-U.ABC(U,T).
> То есть действительно это не будет тривиальная информация
> об отношениях в generics. Однако позволила бы выдать более
> понятную информацию. Например Отсутствует компонент abc
> у Tmytype принимающий integer и integer и возвращающий тип
> который бы удовлетворял оператору - принимающего этот тип
> и double и т.д. Хотя возможно оставить и ручное ограничение
> и автоматическое. Смысл в том, что информация об ошибке
> была понятна.

То есть по сути это был даг отношений между типами и их компонентами соответствующий обобщенному выражению.

> oxffff © (16.11.10 14:24) [276]
> Повторю, что мне интересен гибридный вариант управления
> кучами.

>Какие преимущества даёт такой вариант? Чем плох вариант, когда в языке вообще нет понятия кучи?

> > U:=T; => T подтип U, либо есть ImplicitCast(T):U. вот
> Два ограничения.
>
> В принципе, я согласен, что в данном случае это можно было
> бы делать автоматически. Но, возможно, есть ситуации, когда
> такой вывод будет некорректен.

Это невозможно делать автоматически. Ограничения "T подтип U" и "есть ImplicitCast(T):U" -- семантически очень разные.
Компилятор не долен заниматься телепатией (из этого ничего хорошего не получается).

> Аналогично такую информацию можно вывести из примера.
> T+U*Z-U.ABC(U,T).

Здесь вообще туши свет.
В С++ любая часть этого выражения может означать ВООБЩЕ ВСЁ ЧТО УГОДНО. Да ещё и разные вещи в разных контекстах! Потому что "+", "*", "-", "( )" -- это всё перегружаемые операции. Из лексического анализа этого выражения ВООБЩЕ НЕЛЬЗЯ извлечь никакой информации, кроме того, что тут в данном месте стоят вот эти вот лексемы. Семантика этого выражения будет разной в разных контекстах, а контекст может быть в стопицотом по вложенности инклюде.

Плюсные шаблоны -- это ТЕКСТОВЫЕ макросы, в шаблоне вне контекста НЕТ СЕМАНТИКИ языка С++.
Шаблон -- это не код, не алгоритм. Это правило преобразования текста.
Шаблоны С++ -- это не часть языка С++, это погружённый в С++ ДРУГОЙ ЯЗЫК, язык описания преобразований исходных текстов С++.

Я же говорю: С++ проектировали шизофреники.

Генирики -- это, наоборот, семантически определённые, независимые, логически завершённые единцы кода. Они могут быть независимо скомпилированы, их семантика не зависит от контекста.

← →
_oxffff (2010-11-23 18:37) [280]

> euru © (23.11.10 17:36) [278]
>
> > oxffff © (16.11.10 14:24) [276]
> > Повторю, что мне интересен гибридный вариант управления
>
> > кучами.
>
> >Какие преимущества даёт такой вариант? Чем плох вариант,
> когда в языке вообще нет понятия кучи?

А что есть?

Высокий/низкий уровень, ручное/автоматическое управление Найти похожие ветки