Ну, то есть... в двух словах parse_property тоже не рассчитан на сплайснутые имена. В этом случае имя просто становится пустой строкой, что как ты понимаешь, так же не приемлемо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Довольно красиво)
Однако ещё можно задавать автомат(граф) матрицей смежности
Примерно так:
[StateMachine]
class Sm
{
public States {A, B, C}; //like enumpublic AdjacencyMatrix : bool[,] // извините не знаю, как на немерле двумерный массив объявить
{
{0,1,0};
{0,1,1};
{1,0,0};
};
public DefaultInitialState = State.A;
}
такое можно даже на шарпе написать через дженерики))
Здравствуйте, hardcase, Вы писали:
H>Можно, но только это совершенно не очевидно. H>Для 3-4 состояний может еще и можно разобраться, но вот потом......
Это зависит от контекста использования.
Я в принципе то же самое хотел сказать про список смежных вершин.
Более наглядным является диаграмма (Мура), но и она имеет предел понятности.
Матричная запись, как и диаграмма имеют преимущество перед списком:
Видно не только исходящие, но и входящие дуги.
У нас а инсте был один препод (довольно противный), он говорил так:
Матрицы экономят бумагу, но не экономят мозги.
Я придерживаюсь аналогичного мнения про ФП.
Было бы безобразно, зато однообразно)))
Здравствуйте, hardcase, Вы писали:
H>Можно, но только это совершенно не очевидно. H>Для 3-4 состояний может еще и можно разобраться, но вот потом......
Здравствуйте, para, Вы писали:
P>списком состояний, начальным состоянием и функции перехода, заданной: P>например,
Для людей важно просто и наглядно задать описание автомата. По сему совершенно не важно чем там в теории определяется автомат. Важно иметь язык который наиболее интуитивно позволит описать этот автомат. Я привел один из возможных языков. Описывать автоматы в виде таблиц очень неудобно. Таблицей можно описать только ДКА. А люди мысленно обычно создают НКА, а НКА не возможно описать с помощью простой матрицы. Спорить на эту тему я не хочу (это не тот форум). Но в принципе такие языки как регулярные выражения и грамматики (BNF, PEG) — это идилальные высокооуровневые языки. Почти для любой задачи можно придумать некоторый высокоуровневый язык который будет лучше любого описания КА. Именно по то этому людям обычно не интересны ДСЛ-и описывающие КА. Но если нужно формировать именно КА, то язык вроде приведенного мной (или использованный в БУ) очень удобен для этого. А разные статистические данные можно генерировать в процессе компиляции макросов. Скажем тот же список переходов в некоторое состояние построить не проблема. Можно даже диаграмму нарисовать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, para, Вы писали:
P>>списком состояний, начальным состоянием и функции перехода, заданной: P>>например,
VD>Для людей важно просто и наглядно задать описание автомата. По сему совершенно не важно чем там в теории определяется автомат. Важно иметь язык который наиболее интуитивно позволит описать этот автомат. Я привел один из возможных языков. Описывать автоматы в виде таблиц очень неудобно. Таблицей можно описать только ДКА. А люди мысленно обычно создают НКА, а НКА не возможно описать с помощью простой матрицы. Спорить на эту тему я не хочу (это не тот форум). Но в принципе такие языки как регулярные выражения и грамматики (BNF, PEG) — это идилальные высокооуровневые языки. Почти для любой задачи можно придумать некоторый высокоуровневый язык который будет лучше любого описания КА. Именно по то этому людям обычно не интересны ДСЛ-и описывающие КА. Но если нужно формировать именно КА, то язык вроде приведенного мной (или использованный в БУ) очень удобен для этого. А разные статистические данные можно генерировать в процессе компиляции макросов. Скажем тот же список переходов в некоторое состояние построить не проблема. Можно даже диаграмму нарисовать.
Вообще комплексную логику на иерархических автоматах можно легко нарисовать, тут таблицы наверное усложнять декларируемость описания автомата, вопрос стоит только как проще и быстрее сделать автомат из описания, без лишней работы, вышеприведенный язык DSL мне кажется более подходит для прикладного применения, с помощью макросов на этапе компиляции можно делать и преобразования и анализ как сказал Владислав, мне кажется очень здесь замечательное применение это анализ автомата и генерация, можно сделать компилируемый автомат который генерирует только последовательность вызовов действий с помощью делегатов на основании иерархии и получает наиболее оптимизированный код, тогда никакие внешние библиотеки не будут нужны, описание автомата просто преобразуется в последовательность вызовов функций комплексной логики, как реакцию на события. Само же описание наверное можно получить из диаграммы, в UML редакторах есть функция экспорта XML, которое можно преобразовать в DSL и так далее.
Здравствуйте, CodingUnit, Вы писали:
CU>Само же описание наверное можно получить из диаграммы, в UML редакторах есть функция экспорта XML, которое можно преобразовать в DSL и так далее.
Скажу больше. Можно сделать так, чтобы макрос кроме ДСЛ-я мог бы читать и описание из ХМЛ-я (и писать его в ХМЛ). Надо только грамотно спроектировать такой макрос. Тогда можно будет даже сделать весьма навороченное решение которое будет позволять редактировать автомат визуально и по нему генерировать эффективный код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>"plain_name" вообще не должно быть. Вместо этого нужно генерировать код который сформирует этот самый plain_name динамически (во время компиляции). VD>Сплайс вида "$(name : usesite)" на этапе компиляции квази-цитаты преобразуется в: VD>
VD>Splicable.Expression(<[ name : usesite ]>, GlobalEnv(...))
VD>
VD>Думается, что нужно разобрать выражение <[ name : usesite ]> "на запчасти" и вцепить из него выржение (в данном случае "name"), тип (в данном случае "usesite") и сформировать новые выражение которое будут выглядеть как-то так: VD>
VD><[ ("_N_event_field_of_" + name) : usesite ]> // для имени поля
VD><[ ("add_" + name) : usesite ]> // для имени add-ера
VD><[ ("remove_" + name) : usesite ]> // для имени remove-ра
VD>
VD>ну, и далее сформировать на их основе новые варианты Splicable.Expression() которые и использовать для формирования имен соответствующих сущностный.
1) На данный момент проблема не исправлена, может кто-нибудь из гуру Nemerle ей заняться? Хочется в production коде использовать Nemerle, но с такой багой страшно.
2) Поделитесь, пожалуйста, опытные товарищи наиболее критичными проблемами в компиляторе/интеграции для релизной версии 1.0, которые встречались при использовании Nemerle. Интересуют прежде всего проблемы при написании бизнес-логики, DSL и метапрограммирования (это то, для чего я сейчас пытаюсь использовать Nemerle). Проблемы с GUI (asp, WinForms, WPF) пока меня не волнуют, т.к. для этого буду использовать только C#.
Здравствуйте, humanist-TPV-, Вы писали:
HT>1) На данный момент проблема не исправлена, может кто-нибудь из гуру Nemerle ей заняться? Хочется в production коде использовать Nemerle, но с такой багой страшно.
Какая версия компилятора? Проблему с генерированием евентов еще зимой решили.
VD>><[ ("_N_event_field_of_" + name) : usesite ]> // для имени поля
VD>><[ ("add_" + name) : usesite ]> // для имени add-ера
VD>><[ ("remove_" + name) : usesite ]> // для имени remove-ра
VD>>
VD>>ну, и далее сформировать на их основе новые варианты Splicable.Expression() которые и использовать для формирования имен соответствующих сущностный.
HT>1) На данный момент проблема не исправлена, может кто-нибудь из гуру Nemerle ей заняться? Хочется в production коде использовать Nemerle, но с такой багой страшно.
Вообще-то баг исправляли. Подробностей уже не помню, но точно помню, что исправляли. По позже погляжу в списке тестов.
HT>2) Поделитесь, пожалуйста, опытные товарищи наиболее критичными проблемами в компиляторе/интеграции для релизной версии 1.0, которые встречались при использовании Nemerle. HT>Интересуют прежде всего проблемы при написании бизнес-логики, DSL и метапрограммирования (это то, для чего я сейчас пытаюсь использовать Nemerle). Проблемы с GUI (asp, WinForms, WPF) пока меня не волнуют, т.к. для этого буду использовать только C#.
В основном проблемы есть как раз с указанными дизайнерами ASP и WinForms работают, но глючат, а WPF дизайнеры вообще не поддерживается.
Сам компилятор весьма стабилен. Баги конечно есть, но не критичные. По мере сил они исправляются. Если будет что-то стопорящее работу, то всегда можно обратиться на этот форум. Или предложим обходной маневр, или поправим.
Что касается интеграции, то мелких багов хватает, но они скорее из разряда мелких раздражителей. Опять же если что-то сильно достает, то можно обратиться сюда и мы постараемся поправить. Ну, или (что вообще замечательно) можно поправить самостоятельно и прислать патч.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
HT>2) Поделитесь, пожалуйста, опытные товарищи наиболее критичными проблемами в компиляторе/интеграции для релизной версии 1.0, которые встречались при использовании Nemerle. Интересуют прежде всего проблемы при написании бизнес-логики, DSL и метапрограммирования (это то, для чего я сейчас пытаюсь использовать Nemerle). Проблемы с GUI (asp, WinForms, WPF) пока меня не волнуют, т.к. для этого буду использовать только C#.
Нижеследующий баг мы тщательно обходили , причём он очень многолик, встречается и в присваивании и в подстановке аргумента в функцию, а один раз лочились из-за него на совсем другом обьекте (со всеми вытекающими в рантайме последствиями): 0001052: Compiler loose a generic type, causing a program to crash.
workaround — параноидально указывать точный тип через ':' при использовании подобных иерархий и внимательно разглядывать тултип при передаче в функцию.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, humanist-TPV-, Вы писали:
HT>>1) На данный момент проблема не исправлена, может кто-нибудь из гуру Nemerle ей заняться? Хочется в production коде использовать Nemerle, но с такой багой страшно.
H>Какая версия компилятора? Проблему с генерированием евентов еще зимой решили.
Спасибо, оказывается, стояло 2 версии компилятора Снес обе и инсталлировал билд 8879, проблема не проявляется.
Здравствуйте, hi_octane, Вы писали:
_>Нижеследующий баг мы тщательно обходили , причём он очень многолик, встречается и в присваивании и в подстановке аргумента в функцию, а один раз лочились из-за него на совсем другом обьекте (со всеми вытекающими в рантайме последствиями): _>0001052: Compiler loose a generic type, causing a program to crash. _>workaround — параноидально указывать точный тип через ':' при использовании подобных иерархий и внимательно разглядывать тултип при передаче в функцию.
А можно пример воспроизводящий баг?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, humanist-TPV-, Вы писали:
VD>>>
VD>>><[ ("_N_event_field_of_" + name) : usesite ]> // для имени поля
VD>>><[ ("add_" + name) : usesite ]> // для имени add-ера
VD>>><[ ("remove_" + name) : usesite ]> // для имени remove-ра
VD>>>
VD>>>ну, и далее сформировать на их основе новые варианты Splicable.Expression() которые и использовать для формирования имен соответствующих сущностный.
HT>>1) На данный момент проблема не исправлена, может кто-нибудь из гуру Nemerle ей заняться? Хочется в production коде использовать Nemerle, но с такой багой страшно.
VD>Вообще-то баг исправляли. Подробностей уже не помню, но точно помню, что исправляли. По позже погляжу в списке тестов.
Спасибо, оказывается, стояло 2 версии компилятора Снес обе и инсталлировал билд 8879, проблема не проявляется.
HT>>2) Поделитесь, пожалуйста, опытные товарищи наиболее критичными проблемами в компиляторе/интеграции для релизной версии 1.0, которые встречались при использовании Nemerle. VD>Интересуют прежде всего проблемы при написании бизнес-логики, DSL и метапрограммирования (это то, для чего я сейчас пытаюсь использовать Nemerle). Проблемы с GUI (asp, WinForms, WPF) пока меня не волнуют, т.к. для этого буду использовать только C#.
VD>В основном проблемы есть как раз с указанными дизайнерами ASP и WinForms работают, но глючат, а WPF дизайнеры вообще не поддерживается.
VD>Сам компилятор весьма стабилен. Баги конечно есть, но не критичные. По мере сил они исправляются. Если будет что-то стопорящее работу, то всегда можно обратиться на этот форум. Или предложим обходной маневр, или поправим.
VD>Что касается интеграции, то мелких багов хватает, но они скорее из разряда мелких раздражителей. Опять же если что-то сильно достает, то можно обратиться сюда и мы постараемся поправить. Ну, или (что вообще замечательно) можно поправить самостоятельно и прислать патч.
Спасибо за оперативную реакцию, пойду дальше немерлить Если дело пойдет, попробую баги постить.
Еще пару вопросов до кучи:
1) Какие на данный момент планы по выходу релиза? В форуме ты как-то говорил, что к лету планируешь зарелизиться.
2) Еще раз хочу актуализировать для себя и сочуствующих:
2.1) Баги лучше куда постить на данный момент?
— https://nemerle.org/bugs — этот часто в дауне
— http://nemerle.rsdn.ru/bugs/ —
— http://code.google.com/p/nemerle/issues/list
2.2) Доступ на заведение багов как проще всего получить? Можно центролизовано сразу на всех указанных ресурсах (если конечно все реально используются) ?
Здравствуйте, humanist-TPV-, Вы писали:
HT>Еще пару вопросов до кучи: HT>1) Какие на данный момент планы по выходу релиза? В форуме ты как-то говорил, что к лету планируешь зарелизиться.
Народ только только сделал поддержку ASP и там багов хватает. Так что в ближайшее время, переведем в статус Бэты 2, а там видно будет.
Как я уже говорил компилятор уже более чем устойчив. Так что если дизайнеры не требуются, то использовать его можно смело.
HT>2) Еще раз хочу актуализировать для себя и сочуствующих: HT>2.1) Баги лучше куда постить на данный момент? HT>- https://nemerle.org/bugs — этот часто в дауне
Именно сюда. Только без "s" в протоколе: http://nemerle.org/bugs Возможно в нем и дело.
В дауне он не находился с тех пор как переехал на железо РСДН, то есть не меньше двух месяцев.
Если баг критичный, то имеет смысл еще и сюда сообщение добавить со ссылкой на баг и объяснением на русском.
А вообще, чтобы баг устранить очень важно иметь хороший тест легко повторяемый и воспроизводящий ошибку. Тогда они правятся легко.
HT>- http://code.google.com/p/nemerle/issues/list
Сюда не надо пока. Это вообще какая-то прямая ссылка. По идее на странице Issues стоит редирект на http://nemerle.org/bugs.
HT>2.2) Доступ на заведение багов как проще всего получить? Можно центролизовано сразу на всех указанных ресурсах (если конечно все реально используются) ?
В багтреккере нужно завести логин. Вот если захочется самому баги править, то нужно обратиться ко мне, прислать гуглевый экаунт и я добавляю и поменяю все как надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_>>Нижеследующий баг мы тщательно обходили , причём он очень многолик, встречается и в присваивании и в подстановке аргумента в функцию, а один раз лочились из-за него на совсем другом обьекте (со всеми вытекающими в рантайме последствиями): _>>0001052: Compiler loose a generic type, causing a program to crash. _>>workaround — параноидально указывать точный тип через ':' при использовании подобных иерархий и внимательно разглядывать тултип при передаче в функцию.
VD>А можно пример воспроизводящий баг?
, в том обсуждении есть пара примеров. Но тогда Дмитрий Иванков почему-то заподозрил в нём фичу и оставил на баге пометку — "фича?".
Самые часто встречающиеся проявления этого бага — из-за того что компилятор некорректно выбирает тип AnyCar[CarBase] вместо AnyCar[TDerived], даже там где пользователь указывает желаемый тип. Ну а от этой тайной подмены уже странности пляшут, да такие, что даже с отладчиком часто нихрена непонятно.
Завтра закину в SVN тесты на его проявления, вот например два из них:
using Nemerle.Collections;
using Nemerle.Text;
using Nemerle.Utility;
using System;
using System.Collections.Generic;
using System.Console;
using System.Linq;
module Program
{
public class CarBase //базовый класс
{
private static mutable globalIndex = 0;
public index : int;
public this() { globalIndex++; index = globalIndex; }
}
public class AnyCar[TDerived] : CarBase
where TDerived : CarBase, new()
{
public static Instance : TDerived = TDerived();//типа синглтонpublic static Impossible() : void
{//тут вообще для неискушённого программиста странное творится - судя по коду используем статический item, но в рантайме он почему-то типа CarBase и один на два разных наследника
WriteLine(Instance.GetType().Name + " index = " + Instance.index.ToString());//в этой строке отламывается автодополнение, но компилятор работает
}
}
public class SmallCar : AnyCar[SmallCar] { } //первый наследникpublic class BigCar : AnyCar[BigCar] { } //ещё один
Write(car : CarBase) : void
{
WriteLine(car.GetType().Name);
}
Main() : void
{
//первый баг, хорошо тут write, а у нас lock был :)
Write(SmallCar.Instance);//ожидается SmallCar, получается почему-то CarBase
Write(BigCar.Instance);//ожидается BigCar, получается опять CarBase
//очень странное поведение - вызывается наследник, но реально управление передаётся в метод AnyCar[CarBase].Impossible()
SmallCar.Impossible();
BigCar.Impossible();
}
}
, причём он очень многолик, встречается и в присваивании и в подстановке аргумента в функцию, а один раз лочились из-за него на совсем другом обьекте (со всеми вытекающими в рантайме последствиями):
Снес обе и инсталлировал билд 8879, проблема не проявляется.