Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может, я неправильно понял, но я полагал, что под статическим контролем компилятора ты имеешь в виду контроль в дизайн-тайме. А файлы компилируются независимо.
Верно. Каждый кусок кода будет получать свою ссылку на состояние объекта, с которого он должен "стартовать" и дальше будет иметь возможность работать только с теми, состояниями, которые он через это получит.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Может, я неправильно понял, но я полагал, что под статическим контролем компилятора ты имеешь в виду контроль в дизайн-тайме. А файлы компилируются независимо. WH>А тебя не удивляет статический контроль за типами функций описанных в разных файлах?
Нет. Это элемент времени компиляции. Если функция требует int, то нечего ей передавать что-то иное. А вот порядок вызова функций — дело не времени компиляции, а именно рантайма.
Представь себе, что первым делом надо вызывать только First. А вот дальше в зависимости от того, что получилось — то ли Second, то ли сразу Third, а может быть, и First еще раз, с другими параметрами. А после Second , может быть, надо вызвать не Third, а опять же First, потому что не получилось, и надо начать все сначала, с иными параметрами. И т.д. Как это контролировать в complile-time , я не понимаю, а главное — не понимаю зачем.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Может, я неправильно понял, но я полагал, что под статическим контролем компилятора ты имеешь в виду контроль в дизайн-тайме. А файлы компилируются независимо. 0>Верно. Каждый кусок кода будет получать свою ссылку на состояние объекта, с которого он должен "стартовать" и дальше будет иметь возможность работать только с теми, состояниями, которые он через это получит.
Все равно идею не понимаю. Перенести в compile-time логику работы программы... Так ведь, если доводить до предела, можно потребовать в compile-time определение правильной последовательности всех действий программы. А это означает, что эта последовательность должна быть жестко фиксированной и не зависеть от данных — от них зависимость в compile-time не проверишь же...
Здравствуйте, 0x7be, Вы писали:
0>В более масштабном варианте я свою идею не тестировал. Подозреваю, что Nemerle тут бы мог помочь с синтаксическим сахаром описания этих состояний. Если Nemerle поддерживает макросы, которые могут верифицировать код, то, может, и проблему с линейным типом решить можно.
Nemerle тут может помочь только тем, что его код открыт и можно реализовать нужную функциональность в компиляторе. Но синтаксические навороты тут мало что дадут. Эта фича требует вмешательства в типизатор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет. Это элемент времени компиляции. Если функция требует int, то нечего ей передавать что-то иное. А вот порядок вызова функций — дело не времени компиляции, а именно рантайма.
Твое воинственное невежество уже даже не смешно.
В этом форуме было столько ссылок на работы в которых описано как контролировать на этапе компиляции значения которые известны только во время исполнения... а ты до сих пор ничего не понял. Да даже в этой ветке дана ссылка на работу в которой описан весьма остроумный способ контролировать уникальность ссылки на объект, а ты все еще ничего не знаешь.
А самое плохое в твоем поведении то что ты уперто утверждаешь что это все не нужно.
Это как "Пастернака не читал но осуждаю"
PD>Усложню и сделаю более абстрактным пример ТС.
Да хоть заусложняйся.
PD>Как это контролировать в complile-time ,
Вот так:
interface ISomething
{
state S1 S2 S3;
void First @ S1 -> S2 | S3(...);
void Second @ S2 -> S1 | S3(...);
void Third @ S3 -> S1(...);
}
ISomething @ S2 Foo(ISomething @ S1 some)
{
some.First(...);//После этого вызова нас some меняет тип
//на ISomething @ S2 | S3
//это значит что some может находится в одном из двух состояний
match (some)//Проверяем тип some
{//На ISomething @ S1 компилятор ругнется ибо этого варианта быть не может.
| ISomething @ S2 =>
return some;
| ISomething @ S3 =>
some.Thrid(...)
//Тут компилятор знает что some имеет тип ISomething @ S1return Foo(some);//Хвостовые вызовы стек не едят
}
}
...
//Безопасно вызываем Second
Foo(...).Second(...);
Вот таким образом этот код будет крутиться пока не попадет в состояние S2
PD>я не понимаю,
Это из-за твоего невежества.
PD>а главное — не понимаю зачем.
Ровно за тем же за чем контролировать чтобы вместо int string не воткнули.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Nemerle тут может помочь только тем, что его код открыт и можно реализовать нужную функциональность в компиляторе. Но синтаксические навороты тут мало что дадут. Эта фича требует вмешательства в типизатор.
В скале проверка уникальности идет после того как отработал основной типизатор.
Так что если сделать возможность вставлять свои анализаторы которые работают после основного вывода типов то эту фичу можно будет прикрутить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
PD>>а главное — не понимаю зачем. WH>Ровно за тем же за чем контролировать чтобы вместо int string не воткнули.
Давай я тебя спущу на землю. Напиши руками (никаких PEG/Antlr/CoCoR) парсер HTML, самый примитивный и с упрощениями. А потом мы поговрим как это круто описывать НКА руками в коде.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Все равно идею не понимаю. Перенести в compile-time логику работы программы... Так ведь, если доводить до предела, можно потребовать в compile-time определение правильной последовательности всех действий программы. А это означает, что эта последовательность должна быть жестко фиксированной и не зависеть от данных — от них зависимость в compile-time не проверишь же...
Сколько еще лет тебе показывать эту ссылку?
In computer science and logic, a dependent type is a type that depends on a value.
Здравствуйте, WolfHound, Вы писали:
WH>В скале проверка уникальности идет после того как отработал основной типизатор. WH>Так что если сделать возможность вставлять свои анализаторы которые работают после основного вывода типов то эту фичу можно будет прикрутить.
Можно тупо влепить событие которое вызывать после Tx-шагов.
Событию передавать номер шага и TExpt тела метода. Ну, и если событие возвращает не null а другой TExpt, заменять им тело метода.
Но ведь типы как-то надо будет помечать. Иначе не ясно для каких переменных анализ делать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Давай я тебя спущу на землю. Напиши руками (никаких PEG/Antlr/CoCoR) парсер HTML, самый примитивный и с упрощениями. А потом мы поговрим как это круто описывать НКА руками в коде.
А давай ты пойдешь читать сырци сингулярити. Там полно работы с протоколами.
Кстати то что ты упорно повторяешь НКА тоже кое что говорит о тебе. Ибо тут ДКА. Разница огромна.
Вот простой пример:
public contract CalculatorContract : ServiceContract {
out message Success();
in message AddInteger(int first, int second);
out message IntegerResult(int answer);
in message SubtractInteger(int first, int second);
override state Start: one {
Success! -> Ready;
}
state Ready: one {
AddInteger? -> IntegerResult! -> Ready;
SubtractInteger? -> IntegerResult! -> Ready;
}
}
public class BounceBackServer
{
public static int Main(String[] args)
{
DirectoryServiceContract.Imp! dirImp;
dirImp = DirectoryService.NewClientEndpoint();
ServiceProviderContract.Imp! nsImp;
ServiceProviderContract.Exp! nsExp;
ServiceProviderContract.NewChannel(out nsImp, out nsExp);
string location = "/BounceBackServer";
ErrorCode error;
if (!SdsUtils.Register(location, dirImp, nsImp, out error)) {
DebugStub.WriteLine("Failed to register in BSP namespace error {0}\n",
__arglist(SdsUtils.ErrorCodeToString(error)));
delete nsExp;
delete dirImp;
return -1;
}
// Here is the set of client channels we service
ESet<CalculatorContract.Exp:Ready> epSet = new ESet<CalculatorContract.Exp:Ready>();
while (true) {
switch receive {
case nsExp.Connect(ServiceContract.Exp:Start! exp) :
CalculatorContract.Exp calculatorExp = exp as CalculatorContract.Exp;
if(calculatorExp == null) {
nsExp.SendNackConnect(exp);
}
else {
DebugStub.Print("Received new ServerControl\n");
calculatorExp.SendSuccess();
epSet.Add(calculatorExp);
nsExp.SendAckConnect();
}
break;
case ep.AddInteger(int first, int second) in epSet :
DebugStub.Print("Server received add integer request\n");
int result = first + second;
ep.SendIntegerResult(result);
epSet.Add(ep);
break;
case ep.SubtractInteger(int first, int second) in epSet :
DebugStub.Print("Server received subtract integer request\n");
int result = first - second;
ep.SendIntegerResult(result);
epSet.Add(ep);
break;
case ep.ChannelClosed() in epSet :
delete ep;
break;
case epSet.Empty() && nsExp.ChannelClosed() :
delete nsExp;
epSet.Dispose();
delete dirImp;
return -1;
break;
case unsatisfiable :
DebugStub.Break();
break;
}
}
delete dirImp;
return 0;
}
}
delete тут конечно лишние но все остальное ты короче ни на чем не напишешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Кстати то что ты упорно повторяешь НКА тоже кое что говорит о тебе. Ибо тут ДКА. Разница огромна.
С какой стати тут ДКА? Прос Open можно вызвать Read или Write. Close можно вызвать после Open, Read или Write. Любой НКА можно свести к ДКА, но обсуждаемая предметная область это именно НКА.
WH>Вот простой пример: WH>delete тут конечно лишние но все остальное ты короче ни на чем не напишешь.
Это всё работает потому что примитивно. Заставь его учитывать приоритеты операций, скобки и сразу поплохеет.
Здравствуйте, VladD2, Вы писали:
VD>Можно тупо влепить событие которое вызывать после Tx-шагов.
Tx-шагов чего?
Типизатора?
Нафиг.
Я тебе еще раз говорю в скале это совершенно независимый от основного типизатора процесс который работает после того как отработал основной типизатор. После основного типизатора можно на самом деле очень много чего делать.
Например можно прикрутить type refiments. Котрые почти такие же крутые как depended types.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>С какой стати тут ДКА? Прос Open можно вызвать Read или Write. Close можно вызвать после Open, Read или Write. Любой НКА можно свести к ДКА, но обсуждаемая предметная область это именно НКА.
Полный звиздец.
Про автоматы ты вообще ничего не знаешь.
Read и Write это не состояния. Это сообщения.
A>Это всё работает потому что примитивно. Заставь его учитывать приоритеты операций, скобки и сразу поплохеет.
Ни НКА ни ДКА не может распознать рекурсивную структуру.
Это азы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>С какой стати тут ДКА? Прос Open можно вызвать Read или Write. Close можно вызвать после Open, Read или Write. Любой НКА можно свести к ДКА, но обсуждаемая предметная область это именно НКА. WH>Полный звиздец. WH>Про автоматы ты вообще ничего не знаешь. WH>Read и Write это не состояния. Это сообщения.
Давай без перехода на личности, тем более что ты не прав. Есть состояния CanExecute{X}. Изначально автомат в состоянии CanExecuteOpen. Потом он переходит сразу в три состояния (НКА, однако): CanExecuteRead, CanExecuteWrite, CanExecuteClose. Ну и т.д. Причём переход между состояниями может определяться не только типом сообщения, но и его содержимым, так что метод либо невозможно будет применить, либо он искуственно породит кучу лишних типов.
A>>Это всё работает потому что примитивно. Заставь его учитывать приоритеты операций, скобки и сразу поплохеет. WH>Ни НКА ни ДКА не может распознать рекурсивную структуру. WH>Это азы.
Хорошо, что ты только что сам признался, что описанный метод не подходит для решения реальных задач. Я это с самого начала и говорил.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>Можно тупо влепить событие которое вызывать после Tx-шагов. WH>Tx-шагов чего?
T2, T3, T4. Шаги Т3-Т4 в интеграции не осуществляются (только в компиляторе).
WH>Типизатора? WH>Нафиг. WH>Я тебе еще раз говорю в скале это совершенно независимый от основного типизатора процесс который работает после того как отработал основной типизатор.
Эти шаги и выполняются после окончания работы основного типизатора (T1).
На каждом из этих шагов производится некоторая трасформация. Например, генерируются замыкания и обвязка для них.
Если делать универсальный механизм, то надо позволять вставить собственную обработку между любыми шагами.
WH>После основного типизатора можно на самом деле очень много чего делать.
Я в курсе. Не раз сам делал. Только у меня код компилятора под рукой и мне плагины не нужны .
WH>Например можно прикрутить type refiments. Котрые почти такие же крутые как depended types.
Остается только пара вопросов. Зачем оно надо? и Как помечать типы? Ведь после Т1 можно только трансформировать результат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Давай без перехода на личности, тем более что ты не прав.
Ой Рама... лол.
Я по уши в автоматах. Так шта...
A>Есть состояния CanExecute{X}. Изначально автомат в состоянии CanExecuteOpen. Потом он переходит сразу в три состояния (НКА, однако): CanExecuteRead, CanExecuteWrite, CanExecuteClose. Ну и т.д.
Есть состояние Closed из которого можно вызвать только Open.
Есть состояние Ready из которого можно вызвать Read, Write, Close.
Closed -> Open -> Ready
Ready -> Write -> Ready
Ready -> Read -> Ready
Ready -> Close -> Closed
Вот реальное состояние дел.
И где тут НКА?
A>Причём переход между состояниями может определяться не только типом сообщения, но и его содержимым, так что метод либо невозможно будет применить, либо он искуственно породит кучу лишних типов.
Ты пример РЕАЛЬНОГО кода который я тебе показал посмотри.
A>Хорошо, что ты только что сам признался, что описанный метод не подходит для решения реальных задач. Я это с самого начала и говорил.
Это как "отверткой нельзя забивать гвозди". А ты "Я же говорил что отвертки для реальной работы не подходят.".
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Остается только пара вопросов. Зачем оно надо? и Как помечать типы? Ведь после Т1 можно только трансформировать результат. Статью прочитай.
Здравствуйте, WolfHound, Вы писали:
A>>Давай без перехода на личности, тем более что ты не прав. WH>Ой Рама... лол. WH>Я по уши в автоматах. Так шта...
Увы, тебе не удалось произвести на меня впечатления.
A>>Есть состояния CanExecute{X}. Изначально автомат в состоянии CanExecuteOpen. Потом он переходит сразу в три состояния (НКА, однако): CanExecuteRead, CanExecuteWrite, CanExecuteClose. Ну и т.д. WH>Есть состояние Closed из которого можно вызвать только Open. WH>Есть состояние Ready из которого можно вызвать Read, Write, Close. WH>Closed -> Open -> Ready WH>Ready -> Write -> Ready WH>Ready -> Read -> Ready WH>Ready -> Close -> Closed WH>Вот реальное состояние дел. WH>И где тут НКА?
Ты "в уме" создал для НКА соответствующий ДКА, а теперь пытаешься меня убедить что так и было? Нет, не выйдет. Давай немножечко усложним задачу. После Open можно вызвать Read или Write, но потом их надо чередовать.
Получим НКА
CanOpen -{Open}-> CanRead,CanWrite,CanClose
CanRead -{Read}-> CanWrite,CanClose
CanWrite -{Write}-> CanRead,CanClose
CanClose -{Close} -> nil (пустое множество)
А вот у ДКА будет уже аж три разных состояния — вариации изначального Ready. Так что не путай предметную область и метод реализации. Конечно же, никто не реализует НКА как есть, это просто медленно, но задаётся здесь именно НКА.
A>>Причём переход между состояниями может определяться не только типом сообщения, но и его содержимым, так что метод либо невозможно будет применить, либо он искуственно породит кучу лишних типов. WH>Ты пример РЕАЛЬНОГО кода который я тебе показал посмотри.
Посмотрел. Примитивизм, подогнанный под инструмент. Зато я тебе могу дать действительно реальный пример. Реализовываем сетевой протокол (практически любой). Надо прочитать запрос клиента до конца прежде чем ответить. То есть можно ли после очередного Read выполнять Read или Write определяется прочитанными данными. То есть, цитируя себя самого, "переход между состояниями может определяться не только типом сообщения, но и его содержимым". Естественно, описать это на уровне типов не получится.
A>>Хорошо, что ты только что сам признался, что описанный метод не подходит для решения реальных задач. Я это с самого начала и говорил. WH>Это как "отверткой нельзя забивать гвозди". А ты "Я же говорил что отвертки для реальной работы не подходят.".
Совсем даже не так, потому что гвозди всё же весьма распространены, а КА с фиксированным и малым числом возможных переходов — нет.
Здравствуйте, WolfHound, Вы писали:
VD>>Остается только пара вопросов. Зачем оно надо? и Как помечать типы? Ведь после Т1 можно только трансформировать результат. WH>Статью прочитай.
Статью я с горем пополам распечатал. Будет время, почитаю.
Но на вопрос "зачем оно надо?" она вряд ли даст ответ. Тут нужен опыт реального применения.
Да и на второй вопрос ответ интересен в разрезе немерлового компилятора, а не общей теории.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Если честно, не понял, что ты хотел сказать и что из твоих слов должно следовать.
VD>То и говорю. Наличие состояния и контроль за ним еще не означает, что это КА.
В общем случае — может быть (хотя математически сам компьютер — это КА, и соответственно все, что на нем работает, тоже КА), но вот в этом конкретном обсуждаемом случае я вижу КА в чистом и незамутненном виде. Объясни, почему то, о чем говорит 0x7be — это не КА.
J>>Явно описываемые состояния у 0x7be есть — "можно позвать метод1", "нельзя позвать метод2", и т.д. Что ты понимаешь под инкапсуляцией здесь, я тоже не понял.
VD>КА — это реализация. А оных может быть много. С монадами знаком?
Знаком. Чем КА-то не угодил, если он укладывается в требования 0x7be? И КА — это в первую очередь математическая абстракция объекта с состоянием и графом разрешенных переходов: http://en.wikipedia.org/wiki/Finite-state_machine. Так что это не КА — реализация, а КА допускает много реализаций.
J>>В общем, можешь по предложениям развернуть свою мысль?
VD>Мысль проста. Не все что связывает вычисления является КА.
Замечательно. Конструктивная мысль будет? или все ограничится сотрясанием воздуха в стиле "совы не то, чем кажутся"? И, главное, чем плох КА? Тем, что на свете есть еще что-то, кроме КА?
VD>У тебя просто проявляется классическая болезнь — "когда в руках молоток, все кажется гвоздями".
Ахтунг, психиатры в форуме!
VD>В данном случае состояние и его изменение выражается через типы и объекты. На самом деле для тех же файлов все состояние будет заключаться в хранении дескриптора файла и позиции смещения внутри файла. Выражать это в виде КА никому даже в голову не придет.
Да ну? А если файл открыть не удалось, много тебе скажут дескриптор и смещение? А после закрытия файла они тебе о чем скажут? Так что извини, файл (как его описал 0x7be) представляет собой КА с как минимум двумя состояниями: "Открыт" и "Не открыт". Далее, когда ты доехал до конца файла, больше ты читать из него не можешь. Так что в рамках "Открыт" есть еще два состояния: "Можно читать" и "Нельзя читать".
Я не знаю, что ты имеешь в виду под "Выражать это в виде КА", но любой флаг, который заводишь в объекте и который влияет на его поведение, автоматом вводит множество состояний, соответствующее значению этого флага. Скажем, тот же дескриптор — допустим, он в данной ОС не может быть нулевым для открытого файла. Значит, он у нас, помимо хранения собственно дескриптора, играет дополнительно еще роль флага благодаря специальному нулевому значению, обеспечивая переходы из состояния "не открыт" в состояние "открыт" (метод Open) и обратно (метод Close). И только так! Нельзя из состояния "открыт" перейти снова в состояние "открыт" при помощи Open, потому что будет утечка открытого дескриптора. Точно так же позиция играет роль индикатора состояния "можно читать"/"нельзя читать", только выделенное значение будет не нулевое, а соответствующее концу файла. Все еще считаешь, что файл — это не КА?
