Интерфейс vs. протокол. - Философия программирования

Здравствуйте, ArtDenis, Вы писали:

AD>Идея хорошая. Надо взять на заметку.
AD>Из минусов вижу, что иногда протокол может быть настолько сложным, что его соблюдение невозможно будет контролировать в compile time. Но возможно, что это повод разбить протокол на несколько независимых уровней.
Павел привел ещё хороший пример, где этот подход просто так не применишь: когда шаги в протоколе представляют собой частично упорядоченное множество (здесь).
Решение "в лоб" так, как я предлагаю, приведет к комбинаторному взрыву количества интерфейсов.

Здравствуйте, Pavel Dvorkin, Вы писали:

0>>Твердо убежден, что если за разумную цену можно заставить компилятор что-то за меня контролировать, то это лучше сделать.
PD>Боюсь, что в серьезных задачах цена будет очень высокой.
Ответ на этот вопрос может дать только практическое исследование

Опять же, надо смотреть две ситуации:
1. Что можно получить на "обычном" языке, типа C#.
2. Что можно получить, если ввести в язык поддержку такого стиля.

Здравствуйте, 0x7be, Вы писали:

0>Ответ на этот вопрос может дать только практическое исследование

Он всегда боится. А все по тому что за много лет что тут торчит не прочитал ни одной статьи по теме.

0>Опять же, надо смотреть две ситуации:
0>1. Что можно получить на "обычном" языке, типа C#.
В C# ничего хорошего.

0>2. Что можно получить, если ввести в язык поддержку такого стиля.
Нулевые издержки во время исполнения и около нулевые в исходном коде.
Скажем если это делать на основе этой статьи то чуть менее чем все выведет компилятор по аннотациям.
Все что нужно это расширить capability добавив в них состояние.
Те получится что-то в этом роде:

interface ISomething
{
    state Closed;
    state Opened;

    [Transient(Closed -> Opened)]
    void Open(...);

    [Transient(Opened)]
    void Read(...);
    [Transient(Opened)]
    void Write(...);

    [Transient(Opened -> Closed)]
    void Close(...);
}

Все остальное получится как в той статье.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, 0x7be, Вы писали:

0>Павел привел ещё хороший пример, где этот подход просто так не применишь: когда шаги в протоколе представляют собой частично упорядоченное множество (здесь).
0>Решение "в лоб" так, как я предлагаю, приведет к комбинаторному взрыву количества интерфейсов.
За то это легко решается через капабилити скрещенные с type refinements.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

0>>1. Что можно получить на "обычном" языке, типа C#.
WH>В C# ничего хорошего.
Точно?

Не хотелось бы откладывать праздник жизни до появления в мэйнстриме нормальных языков

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.
И? Если у вас метода возвращает любое число, ну так замечательно, значит ограничений на величину никаких нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:

0>>>Твердо убежден, что если за разумную цену можно заставить компилятор что-то за меня контролировать, то это лучше сделать.
PD>>Боюсь, что в серьезных задачах цена будет очень высокой.
0>Ответ на этот вопрос может дать только практическое исследование

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

Поживем — увидим.

Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.
D>И? Если у вас метода возвращает любое число, ну так замечательно, значит ограничений на величину никаких нет.

Именно. И вся идея накрылась медным тазом. Все исходные вещества эти ограничения имеют каждое по себе, а все вместе — нет, а смеси — тоже. Поэтому если писать программу специально для воды, то что-то можно сделать, а для любого вещества — ничего.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну что же, подождем , когда оно произойдет. Я в этом отношении скептик. Доходов вижу мало, расходы несоразмерны, так что не думаю, что это всерьез где-то появится. А что касается всяких маргинальных языков — может быть, там оно и будет, только надо себе отдавать отчет, что ни один маргинальный язык никогда не попадал в мейнстрим.
Да, но есть другой процесс — мэйнстрим активно заимствует у "маргинальных" языков.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Именно. И вся идея накрылась медным тазом. Все исходные вещества эти ограничения имеют каждое по себе, а все вместе — нет, а смеси — тоже. Поэтому если писать программу специально для воды, то что-то можно сделать, а для любого вещества — ничего.
Да, для каждой задачи свои инструменты, где то работает одно где то другое. Возможно адепты зависимых типов смогут что нибудь придумать и для общего случая.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Ну что же, подождем , когда оно произойдет. Я в этом отношении скептик. Доходов вижу мало, расходы несоразмерны, так что не думаю, что это всерьез где-то появится. А что касается всяких маргинальных языков — может быть, там оно и будет, только надо себе отдавать отчет, что ни один маргинальный язык никогда не попадал в мейнстрим.
0>Да, но есть другой процесс — мэйнстрим активно заимствует у "маргинальных" языков.

Ну что же, посмотрим.

Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Именно. И вся идея накрылась медным тазом. Все исходные вещества эти ограничения имеют каждое по себе, а все вместе — нет, а смеси — тоже. Поэтому если писать программу специально для воды, то что-то можно сделать, а для любого вещества — ничего.
D>Да, для каждой задачи свои инструменты, где то работает одно где то другое. Возможно адепты зависимых типов смогут что нибудь придумать и для общего случая.

Может быть. Повторю — я настроен скептически. Вернемся к этому разговору лет через 5

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, dotneter, Вы писали:

D>>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.
D>>И? Если у вас метода возвращает любое число, ну так замечательно, значит ограничений на величину никаких нет.

PD>Именно. И вся идея накрылась медным тазом. Все исходные вещества эти ограничения имеют каждое по себе, а все вместе — нет, а смеси — тоже. Поэтому если писать программу специально для воды, то что-то можно сделать, а для любого вещества — ничего.

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

Здравствуйте, jazzer, Вы писали:

J>он не покатит в рантайме, а во время компиляции все хорошо будет.
J>А 0x7be хочет, чтобы вторая строчка не компилировалась.
J>Поправь, если не так.

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

Разве на С++ возможно заставить компилятор ругаться на вторую строчку, если первая компилируется в этом выхолощенном примере?

A a1 = f(b);
A a2 = f(b);

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, jazzer, Вы писали:

J>>он не покатит в рантайме, а во время компиляции все хорошо будет.
J>>А 0x7be хочет, чтобы вторая строчка не компилировалась.
J>>Поправь, если не так.

V>Дык, в твоем примере аналогично, из любого "состояния" можно сделать несколько попыток перехода. Понятное дело, что если компилятор явным образом uniqueness не поддерживает, то мы можем лишь эмулировать их с различной степенью приближенности.

Нет, у меня будет ошибка компиляции.
При том что и у тебя, и у меня возвращаемое значение передается дальше правильно, у тебя — ошибка времени исполнения, а у меня — времени компиляции.

V>Разве на С++ возможно заставить компилятор ругаться на вторую строчку, если первая компилируется в этом выхолощенном примере?
V>

V>A a1 = f(b);
V>A a2 = f(b);
V>

В этом — нет, а в таком — можно:

A a0;
auto a1 = f(b, a0);
auto a2 = f(b, a1);

Условие задачи было — предоставить статический контроль. Пусть криво и косо, но чтоб был. Где он у тебя? Нету, только рантайм. А рантайм у нас и сейчас есть в виде исключений и прочих проверок времени выполнения.

Здравствуйте, Pavel Dvorkin, Вы писали:

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

PD>Я в этом отношении скептик. Доходов вижу мало, расходы несоразмерны, так что не думаю, что это всерьез где-то появится.
Ага, конечно.
Вот очередной пример: http://lamp.epfl.ch/~phaller/uniquerefs/capabilities_for_uniqueness_TR.pdf
Доходы: Доказанное отсутствие гонок.
Расходы: В рантайме строго ноль. В исходниках

We have implemented OCT as an extension of the EPFL Scala compiler. In Section 8.1 we show that virtually all methods of common collection classes in Scala's standard library can be annotated with uniqueness information in a simple way without any changes to their implementation.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, jazzer, Вы писали:

V>>Дык, в твоем примере аналогично, из любого "состояния" можно сделать несколько попыток перехода. Понятное дело, что если компилятор явным образом uniqueness не поддерживает, то мы можем лишь эмулировать их с различной степенью приближенности.

J>Нет, у меня будет ошибка компиляции.

Эх, невнимательность...

Покажи тут ошибку компиляции:

auto s4 = f.go( s3, Close()            );
auto s5 = f.go( s3, Close()            );

J>При том что и у тебя, и у меня возвращаемое значение передается дальше правильно, у тебя — ошибка времени исполнения, а у меня — времени компиляции.

Неверно.

V>>Разве на С++ возможно заставить компилятор ругаться на вторую строчку, если первая компилируется в этом выхолощенном примере?
V>>

V>>A a1 = f(b);
V>>A a2 = f(b);
V>>

J>В этом — нет, а в таком — можно:
J>

J>A a0;
J>auto a1 = f(b, a0);
J>auto a2 = f(b, a1);
J>

А такой не решает исходную задачу, ибо не гарантирует протокол.

J>Условие задачи было — предоставить статический контроль. Пусть криво и косо, но чтоб был. Где он у тебя? Нету, только рантайм.

Выше показал в чем суть. Мой пример a1=f(b) — это выхолощенный случай как твоего, та и моего варианта. Чуть присмотрись. В нем и есть слабость твоего и моего решения. Она, эта "слабость", идентична.

J>А рантайм у нас и сейчас есть в виде исключений и прочих проверок времени выполнения.

Э нет, в моем примере, как и в твоем, если удалось отладить "основную ветку", то компилятор ограничивает набор возможных "неосновных". Т.е. отладка здесь ровно идет того же плана, что ловля поданного ошибочного NULL. А от него С++ тоже не спасает, со всей своей типизированностью. И не только С++ тут бессилен.

Здравствуйте, VladD2, Вы писали:

VD>Ром, если у НКА объединить состояния, как это сделал ты, то как раз получится ДКА.
На самом деле тут все еще веселее.
Рома записал не НКА, а ДКА.
У него фактически написано, что при возникновении сигнала A перейти в состояние X.
Полный детерминизм.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, VoidEx, Вы писали:

VE>Ну, для любого вещества точку кипения ты и в рантайме не вычислишь,

Увы, да. Но тут причины химические, а не математико-влгоритмические.

>а если писать специально для воды

То 100 С.

>то и зависимые типы пригодятся. Т.е. идея пригодится в реализации вообще любой полезной программы.

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

	От:	WolfHound
	Дата:	18.04.11 05:25
	Оценка:

	От:	0x7be
	Дата:	18.04.11 05:27
	Оценка:

	От:	0x7be
	Дата:	18.04.11 05:30
	Оценка:

	От:	WolfHound
	Дата:	18.04.11 05:47
	Оценка:

	От:	WolfHound
	Дата:	18.04.11 05:53
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	18.04.11 08:57
Оценка: