Навеяно http://fsharppowerpack.codeplex.com/

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

По идее там есть очень востребованные фичи, которыми сейчас сложновато воспользоваться.

• ComputationExpressions
  
• aop
  
• designpatt
  
• peg-parser
  
• ObjectExpressions

Вот бы все это из коробки.

Только не надо говорить "возьми да сделай" , я серьезно думал над этим, не вижу возможности выкроить время.

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

Z>Навеяно http://fsharppowerpack.codeplex.com/

Z>В снипетах лежит гораздо больше полезного кода. Не найдется ли желающий причесать это все в одну длл (либо 2, макросы и библиотека)?

Могу заняться.

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

Z>По идее там есть очень востребованные фичи, которыми сейчас сложновато воспользоваться.

Z>

Z>
• ComputationExpressions
  Z>
• aop
  Z>
• designpatt
  Z>
• peg-parser
  Z>
• ObjectExpressions
  Z>

Z>Вот бы все это из коробки.

Хорошая идея. Я давно удивлялся тому, сколько в сниппетах интересных вещей зарыто, но идея сделать отдельный проект для них мне как-то в голову не приходила. Кроме того, есть такие вещи, как http://www.rsdn.ru/forum/src/1824747.aspx

Автор: CrystaX
Дата: 06.04.06

, которые в сниппетах не найдутся. Их тоже можно в пауер-пак положить (с согласия автора, конечно).

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

Z>В снипетах лежит гораздо больше полезного кода. Не найдется ли желающий причесать это все в одну длл (либо 2, макросы и библиотека)?

Может быть организовать процесс таким образом, что компилировать оригинальные проекты и уже потом их артефакты склеивать ilmerge-ем?

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

H>Может быть организовать процесс таким образом, что компилировать оригинальные проекты и уже потом их артефакты склеивать ilmerge-ем?

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

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

H>>Может быть организовать процесс таким образом, что компилировать оригинальные проекты и уже потом их артефакты склеивать ilmerge-ем?

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

Семантической разницы между двумя подходами, по-моему, нету. Какая разница, кто склеит разные проекты — компилятор или отдельная программа? Разве что вариант с ILMerge-м позволит быстрее пересобирать сборку при изменении одного из компонентов.

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

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

Z>По идее там есть очень востребованные фичи, которыми сейчас сложновато воспользоваться.

Z>

Z>
• ComputationExpressions
  Z>
• aop
  Z>
• designpatt
  Z>
• peg-parser
  Z>
• ObjectExpressions
  Z>

К сожалению, все вышеперечисленное не релизного качества. За ComputationExpressions не скажу, а скажем aop не тестировался очень давно. Меж тем на его работу под интеграцией было много нареканий. ObjectExpressions вроде как не дописан. peg-parser так же еще до ума не доведен.

Z>Вот бы все это из коробки.

При достижении релизного качества общеупотребимые проекты из снипетов нужно просто переводить в стандартную библиотеку. В прочем, создать вторую библиотеку (расширений) можно. Только этим нужно кому-то заниматься.

Z>Только не надо говорить "возьми да сделай" , я серьезно думал над этим, не вижу возможности выкроить время.

Дык у всех так.

Идей можно накидать много. А вот на их реализации времени не остается. Был бы комьюнити по больше — этой проблемы бы не было. А пока...

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

H>Может быть организовать процесс таким образом, что компилировать оригинальные проекты и уже потом их артефакты склеивать ilmerge-ем?

А зачем их склеивать? Мне кажется для начала было бы лучше просто поместить их в инсталлятор.

К тому же намного важнее довести их до ума нежели запихнуть их в одну ДЛЛ.

В том же PEG-парсере нужно еще многое доделать. Но энтузиазм загас.

ЗЫ

Вообще, огромная проблема открытых проектов без реального финансирования заключается в том, что в них все делается до тех пор пока не станет ясно реализуема ли концепция на практике или нет. Как только автор получает ответ на этот вопрос (причем положительный ответ), так тотчас же ему становится не интересен этот прок. Правильно! Ведь в проекте еще нужно проделать много нудной работы. Это не интересно.

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

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

H>>Может быть организовать процесс таким образом, что компилировать оригинальные проекты и уже потом их артефакты склеивать ilmerge-ем?

VD>А зачем их склеивать? Мне кажется для начала было бы лучше просто поместить их в инсталлятор.

ОК.

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

VD> За ComputationExpressions не скажу

Я думаю, что надо бы вернуть старую версию до async. То есть, сам макрос comp, а также list, array и enumerable comprehension. Желательно в виде тех трех простых файлов с исходниками. В общем, все должно работать, хотя много не тестировал. Там очень простая архитектура, ломаться почти нечему, и все работает через единый общий механизм макроса comp, который я в свое время тщательно протестировал на enumerable comprehension. То есть, тестами были охвачены общий случай comp и enumerable comp. List comp и array comp тривиальны, поскольку хардкордно оптимизированы. Тестировал их, но значительно меньше.

Считаю, что в таком виде Сomputation Expressions имели бы товарный вид уже сейчас.

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

Что касается async, то мне кажется, что там еще надо устаканить API. Сложная очень тема, где я не во всем согласен с автором. Вообще, async я бы отделил от макроса comp. По сути, там не нужно никакое другое встраивание, кроме одной добавленной строки в конструкцию if. Думаю, что довести async до конечного вида можно и потом в случае необходимости.

VD>Вообще, огромная проблема открытых проектов без реального финансирования заключается в том, что в них все делается до тех пор пока не станет ясно реализуема ли концепция на практике или нет. Как только автор получает ответ на этот вопрос (причем положительный ответ), так тотчас же ему становится не интересен этот прок. Правильно! Ведь в проекте еще нужно проделать много нудной работы. Это не интересно.

Это очевидная проблема, которая, казалось бы, должна убивать открытые проекты. Да ведь и в успехе Линукса в последние годы наверняка немалую роль сыграло привлечение людей, работающих за деньги (Red Hat, Canonical). Действительно ведь, существенная часть работы практически в любом проекте представляет собой унылую рутину, которую обычно люди могут делать только за деньги.

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

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Это очевидная проблема, которая, казалось бы, должна убивать открытые проекты. Да ведь и в успехе Линукса в последние годы наверняка немалую роль сыграло привлечение людей, работающих за деньги (Red Hat, Canonical).

Именно Линукс уже давно коммерческий проект.

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

Ага.

ТЗИ>Взять ту же документацию, которую всем лень писать.

Если бы дело было только в документации — это было бы пол беды. Но ведь и код до конца не доводят.

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

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

VD>> За ComputationExpressions не скажу

D>Я думаю, что надо бы вернуть старую версию до async.

А что с текущей какие-то проблемы?

И что с этим async?

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

VD>>> За ComputationExpressions не скажу

D>>Я думаю, что надо бы вернуть старую версию до async.

VD>А что с текущей какие-то проблемы?

Да та же самая версия, только сейчас добавлена проверка на "comp async" из одной строки. Просто мне прежняя организация файлов (всего три исходника) нравилась больше. Их легче проверять, поддерживать, обозревать и прочее. Другими словами, личные предпочтения

VD>И что с этим async?

Сейчас постараюсь вспомнить. Мне не нравится, что собственно запуск (инициация) вычисления (так называемый monad runner) не отделен от остального. Остальное может подразумевать начало асинхронной ветки вычислений, но как части уже существующего вычисления. Для последнего есть compdef, т.е. монадический bind, плюс необходимые комбинаторы типа Parallel. Инициация же, вообще, должна означать начало асинхронного вычисления с нуля, с внешнего источника. Короче говоря, есть уже устоявшиеся шаблоны в такого рода API, которые пришли из хаскеля (ведь async — это монада, хотя внутри и императивная, но внешний интерфейс вполне ФП). Реализация async в f# этим шаблонам следует. Здесь дело не в конкретных языках. Это широко используемый и ожидаемый шаблон. Нет ничего зазорного в том, чтобы скопировать его.

Сейчас же получается (если не забыл), что Start можно использовать и как инициацию, и внутри compdef, т.е. в двух совершенно разных юз-кейсах. По-моему это неправильно. Мы уже переписывались с автором. У него мнение было другое.

Думаю, что сам comp можно вывести в релиз отдельно и уже сейчас. Async же довольно таки независим, и его всегда можно включить в релиз либо отдельным пакетом, либо изменив всего одну строку внутри comp. Сам по себе comp достаточно аппетитный уже хотя бы своим enumerable comprehension.

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

Z>Навеяно http://fsharppowerpack.codeplex.com/

Z>В снипетах лежит гораздо больше полезного кода. Не найдется ли желающий причесать это все в одну длл (либо 2, макросы и библиотека)?

Z>По идее там есть очень востребованные фичи, которыми сейчас сложновато воспользоваться.

Z>

Z>
• ComputationExpressions
  Z>
• aop
  Z>
• designpatt
  Z>
• peg-parser
  Z>
• ObjectExpressions
  Z>

Z>Вот бы все это из коробки.

Паверпак добавил инсталлятор: r8948.
Сейчас там PEG parser, ComputationExpressions и WPF-ный dependency property.

Про остальное я просто забыл, позже добавлю.

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

D>Да та же самая версия, только сейчас добавлена проверка на "comp async" из одной строки. Просто мне прежняя организация файлов (всего три исходника) нравилась больше. Их легче проверять, поддерживать, обозревать и прочее. Другими словами, личные предпочтения

Я так понимаю теперь типы разложены по файлам? Это как раз правильная практика. С ростом объема исходников это позволяет не закапываться в них.

VD>>И что с этим async?

D>Сейчас постараюсь вспомнить. Мне не нравится, что собственно запуск (инициация) вычисления (так называемый monad runner) не отделен от остального. Остальное может подразумевать начало асинхронной ветки вычислений, но как части уже существующего вычисления. Для последнего есть compdef, т.е. монадический bind, плюс необходимые комбинаторы типа Parallel. Инициация же, вообще, должна означать начало асинхронного вычисления с нуля, с внешнего источника. Короче говоря, есть уже устоявшиеся шаблоны в такого рода API, которые пришли из хаскеля (ведь async — это монада, хотя внутри и императивная, но внешний интерфейс вполне ФП). Реализация async в f# этим шаблонам следует. Здесь дело не в конкретных языках. Это широко используемый и ожидаемый шаблон. Нет ничего зазорного в том, чтобы скопировать его.

Мне трудно судить, так как в проблему не вникал. Хорошо бы привести примеры обоих вариантов (как сейчас и как было бы в хаскелевом стиле).

Однако сама идея апелляции к общепринятым подходам в Хаскеле и F# мне не нравится. Не зря многие многие не любят или не воспринимают эти языки. В них многое (для простых смертных) сделано через ухо.

D>Сейчас же получается (если не забыл), что Start можно использовать и как инициацию, и внутри compdef, т.е. в двух совершенно разных юз-кейсах. По-моему это неправильно. Мы уже переписывались с автором. У него мнение было другое.

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

D>Думаю, что сам comp можно вывести в релиз отдельно и уже сейчас. Async же довольно таки независим, и его всегда можно включить в релиз либо отдельным пакетом, либо изменив всего одну строку внутри comp. Сам по себе comp достаточно аппетитный уже хотя бы своим enumerable comprehension.

Ну, так выделите Async в отдельный проект.

ЗЫ

Я так и не понял... Async сыр? Или все претензии к нему сводятся к спорам о вкусах?

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

VD>Мне трудно судить, так как в проблему не вникал. Хорошо бы привести примеры обоих вариантов (как сейчас и как было бы в хаскелевом стиле).

Старое обсуждение с WolfHound: http://rsdn.ru/forum/nemerle/3814156.flat.aspx. Самый первый пример. Метод Start используется в двух разных смыслах. В обсуждении это указано.

В так называемом "хаскелевском" стиле (когда по сигнатуре ф-ции можно понять, что она делает) метод Start не возвращал бы (новое ??) вычисление типа Async[T], а инициировал (запускал — run) бы его и затем возвращал уже вычисленное значение типа T вроде того же void. Более того, тогда Start не должен был бы появляться в правой части defcomp. Если мы хотим сделать асинхронное вычисление каким-то особенным, например, запустить в отдельном пуле, то для этого придумали комбинаторы. Вывод: Start перегружен.

В общем, я предлагаю делегировать часть ф-ций, которые сейчас выполняет Start, на комбинаторы типа Parallel. Например, для ответвления асинхронного вычисления с использованием заданного контекста создать комбинатор Async[T].WithContext : ExecutionContext -> Async[T] или что-то типа того. Это было бы логичнее на мой взгляд.

VD>Однако сама идея апелляции к общепринятым подходам в Хаскеле и F# мне не нравится. Не зря многие многие не любят или не воспринимают эти языки. В них многое (для простых смертных) сделано через ухо.

Имею совершенно противоположное мнение. К тому же, async — это монада.

VD>Я так и не понял... Async сыр? Или все претензии к нему сводятся к спорам о вкусах?

Я считаю, что Start очень важен, и что он в существующем виде не продуман. Претензия к API. Впрочем, это всего лишь мое частное мнение, которое вы можете запросто проигнорировать. Реализацию легко исправить в случае чего, а, вот, API будет исправлять труднее.

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

H>Паверпак добавил инсталлятор: r8948.
H>Сейчас там PEG parser, ComputationExpressions и WPF-ный dependency property.

H>Про остальное я просто забыл, позже добавлю.


Доцепил в инсталлятор Aop (пришлось уговорить его собраться) и ObjectExpressions. Смотрите.
А вообще по хорошему надобы покрыть функционал макросов тестами.

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

D>Старое обсуждение с WolfHound: http://rsdn.ru/forum/nemerle/3814156.aspx. Самый первый пример. Метод Start используется в двух разных смыслах. В обсуждении это указано.

D>В так называемом "хаскелевском" стиле (когда по сигнатуре ф-ции можно понять, что она делает) метод Start не возвращал бы (новое ??) вычисление типа Async[T], а инициировал (запускал — run) бы его и затем возвращал уже вычисленное значение типа T вроде того же void. Более того, тогда Start не должен был бы появляться в правой части defcomp. Если мы хотим сделать асинхронное вычисление каким-то особенным, например, запустить в отдельном пуле, то для этого придумали комбинаторы. Вывод: Start перегружен.

D>В общем, я предлагаю делегировать часть ф-ций, которые сейчас выполняет Start, на комбинаторы типа Parallel. Например, для ответвления асинхронного вычисления с использованием заданного контекста создать комбинатор Async[T].WithContext : ExecutionContext -> Async[T] или что-то типа того. Это было бы логичнее на мой взгляд.

Ты не мудри, ты пальцем покажи (с). Как в твоем представлении должен выглядеть пример приведенный по ссылке?

VD>>Однако сама идея апелляции к общепринятым подходам в Хаскеле и F# мне не нравится. Не зря многие многие не любят или не воспринимают эти языки. В них многое (для простых смертных) сделано через ухо.

D>Имею совершенно противоположное мнение.

Ну, что поделать? Это все чертов плюрализм .

D>К тому же, async — это монада.

Да назови это хоть горшком. Только в печку не ставь.

VD>>Я так и не понял... Async сыр? Или все претензии к нему сводятся к спорам о вкусах?

D>Я считаю, что Start очень важен, и что он в существующем виде не продуман.

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

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

Так что не так с API? Все дело в Start-те? Ну, так покажи как будет выглядеть код в случае твоего решения. Сравним...

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

VD>Так что не так с API? Все дело в Start-те? Ну, так покажи как будет выглядеть код в случае твоего решения. Сравним...

Опять писать по новой?

Для запуска вычисления взять Start и RunSynchronously из f#. Для остального создать комбинаторы. WolfHound хотел что-то для ответвления вычисления на другом пуле потоков, так для этого сделать отдельный комбинатор, который бы не выходил за рамки монады:

// асинхронное ответвление через другой пул потоков
// (формальность не проверял - если не пойдет, то переписать 
//  через метод модуля Async, отказавшись от ненужного здесь ООП)
Async[T].WithContext: ExecutionContext -> Async[T] where T : FakeVoid 

// синхронное ответвление через другой пул потоков
Async[T].WithContextSynchronously: ExecutionContext -> Async[T]

То есть, монаду "понижают" до вычисленного значения вышеназванные методы запуска Start и RunSynchronously (можно еще добавить похожие методы — там я писал о монадных трансформерах как еще одном взгляде на методы запуска). Все остальное возвращает монаду, но не запускает!

private button1_Click (_sender : object,  _e : System.EventArgs) : void
    {
      responceBox.Text = "";
      def receive(url)
      {
        comp async
        {
          def url = url.Trim();
          when (url != "")
          {
            def time = System.Diagnostics.Stopwatch.StartNew();
            try
            {
              defcomp content = HttpGet(url); // здесь больше нет Start!
              // вместо: defcomp content = HttpGet(url).Start()
              responceBox.Text += $"$url\nTime: $(time.Elapsed)\nContent-Length: $(content.Length)\n\n\n\n";
            }
            catch
            {
              | ex is Exception =>
                responceBox.Text += $"$url\nTime: $(time.Elapsed)\nException: $(ex.Message)\n\n\n\n";
            }
          }
        }
      }

      Async.Parallel (urlBox.Lines.Map (receive)).WithContext (guiCtx).Start();
      // вместо:
      // foreach (url in urlBox.Lines)
      //  _ = receive(url).Start(guiCtx);//Запуск в контексте gui.
    }

Start вычисляет void. Поэтому этот void может быть возвращен немедленно, а само вычисление запущено асинхронно. От этого результат не меняется совершенно, поскольку есть всего один void. RunSynchronously вычисляет все остальное, поэтому запущен асинхронно быть не может, хотя комбинаторы типа Parallel и WithContext могут создавать асинхронные ответвления, но уже внутри вычисления. Это "но" принципиально.

Если же f# и хаскель для тебя неавторитетны, то, собственно, я даже не знаю, как развивать эту тему... Тут дело не во вкусах, а в строгости концепции.