например CanThrow 'Bla

ну не важно, например я свой тип ввожу, о котором автор точно не в курсе

типы внутри эндпойнтов не влияют

@chshersh, тут @VividDesires спрашивает про servant-generic, можешь про опыт рассказать

Опыт очень приятный ? По сути, мы разбиваем API по иерархии на большие части, а затем каждую часть уточняем. У нас при этом еще иерархия модулей копирует иерархию API. Да, nested endpoints через вложенные типы данных.

сваггер вроде работает, но надо проверить

Работает без проблем, мы используем swagger

а сервант умеет в рамл?

типы внутри эндпойнтов не влияют

т.е. я могу любое MyFoo :> "bart" :> MYVerb La кодировать?

да

а норм тогда

а сервант умеет в рамл?

сервант расширяемый

при этом пользовательском уровне, в этом фишка

servant-generic отвечает только за преобразование servant types <=> структура

а понял, как оно работает

сколько нужно времени и памяти для servant-generic?

https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests

CC @A64m_qb0 никто не хочет поконтрибьютить с предложениями?

хотя не там просто хотят формат текущей поменять

т.е. останется бестолковым

они хотят, чтоб изменения ничего не значащих измерений было проще анализировать

да

чего-то сегодня бекендсикрета мало

: (

Ну, это я знаю, да. Мне бы хотелось именно на код посмотреть. Вопрос не в синтаксисе все же, а в дизайне интерфейса eDSL (вот этих вот параметров bla-bla, которые передаются обычно в функции, и что возвращается в итоге)

Те же самые, что для функтора фри монады

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

Так тут дело не в выборе фри/фт

Сигнатуры команд одни и те же будут

Ты сначала дизайнишь дсл, а потом пишешь команды во фри или в тайпкласс

Меня в чате вообще понимают? Я выше написал, что синтаксис я и так знаю. Я хочу на практику применения посмотреть.

То есть тебя интересует не мощность ФТ, а разница в скиле людей дизайнить дсл, которые используют ФТ и людей, кто использует ФМ?

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

Скилл людей мне все равно какой. Хоть анонимно, хоть как

Тогда мне не понятно, что ты спрашиваешь, потому что ответ: так же, как и в фри

я просто не знаю какой показательный кусок я могу показать

который поместится в разумные рамки

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

тем более, что как верно сказал kama "Те же самые, что для функтора фри монады"

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

Я просил сделать STM на FT уже. @odomontois , как там с этим дело, кстати?

О, я как к компу доберусь, попробую, если там немного

Не знаю, у меня - не сильно много кода

я не очень понимаю этой задачи, если честно, реализовать stm на уровне библиотеки не используя входящие в язык примитивы?

Конечно

Пусть даже получится тормознутая STM

что можно использовать?

MVar можно

должна ли быть конкрурентность нативной?

IORef можно?

IORef, если хочется

Да все, кроме оригинального STM

Я просил сделать STM на FT уже. @odomontois , как там с этим дело, кстати?

Я как обычно забил и вместо этого занимался чем-то интересным

Потому что иначе задача становится крайне тривиальной

т.е. ты в своём решении не poor man concurrency делал?

Навроде спорить про ЯП в жерке

т.е. ты в своём решении не poor man concurrency делал?

Нет, там совсем даже не poor man concurrency

хорошо

так, ещё вопрос, а зачем там нужно FT решение?

т.е. какие возможности обобщения и дополнительных реализаций предполагаются?

так, ещё вопрос, а зачем там нужно FT решение?

Ну, я думаю, будет полезно для общего развития. Сравнивать оба подхода на одной задаче

т.е. какие возможности обобщения и дополнительных реализаций предполагаются?

Не очень понял вопрос. Обобщение, по сути, не требуется. Минимум - работа с TVar, retry.

я не знаю зачем решать такую задачу, а почему не иметь простую newtype STM = SMT (ST RealWorld a) data TVar readTVar writeTVar

для этого не нужно ни FT ни Free

Интересный вариант

Но про retry я не представляю, что тут должно быть

эти ребята нужны если ты хочешь обобщать и иметь различные имплементации исполнителя

это то, как реализовано STM в RTS

т.е. фишка обощения в том, что ты можешь использовать не STM а Foo

или подменить интерпретатор твоего языка

например он отладку начнет писать автоматом

или поменяет правила разрешения конфликтов

эти ребята нужны если ты хочешь обобщать и иметь различные имплементации исполнителя

Не только. Скажем, мой подход позволяет написать минимальную STM там, где нет нативно подерживаемой, и при этом рантайм будет совсем маленьким. Да, тормознутей в 6 раз, но в том же C++ вообще с STM плохо

Обобщение - это только часть задач FT / Free

я не вижу зачем для этого нужно обобщение

т.е. какие возможности обобщения и дополнительных реализаций предполагаются?

я думал про разные режимы транзакций

Борьба со сложностью ПО - еще одна часть задач. Иной подход к имплементации (не интерфейсу) - третья

И делать часть промежуточных действий Unwrapped

я думал про разные режимы транзакций

В моей библиотеке можно даже разные рантаймы для больших моделей и маленьких

твой интерфейс это твой модуль

твой интерфейс это твой модуль

Мой интерфейс - это далеко не всегда модуль, и утверждать такое - значит, отбрасывать другие способы дизайна

я не согласен с этим утверждением

Вариантов создания функциональных интерфейсов довольно много на текущий момент. FT, Free, ReaderT паттерн

т.к. какой бы способ дизайна ты не предложил он укладывается

И еще есть ряд

т.к. какой бы способ дизайна ты не предложил он укладывается

Не думаю

вышепредложенные укладываются

Оно, может, и укладывается, но это нифига не единственно возможная практика.

возможно неукладывающиеся скрываются в "и другие"№

Я ж говорю, покажи мне свои интерфейсы

@graninas а чем http://hackage.haskell.org/package/concurrency-1.6.1.0/docs/Control-Monad-STM-Class.html не FT?

при том, что тут вот как раз реальная есть задача и применение

в рамках dejafu как минимум

@graninas а чем http://hackage.haskell.org/package/concurrency-1.6.1.0/docs/Control-Monad-STM-Class.html не FT?

Оно, может, и FT, но использует нативную имплементацию, так? Не показатель

это FT

не использует

не использует

Как тогда оно работает?

смысл FT и Free в том, что интерпретатор можно менять

они ничего не говорят про интепретатор и его реализацию

дак тут и есть это

хочешь нативный stm - есть на нём

а в тестах - своя имплементация

смысл FT и Free в том, что интерпретатор можно менять

Смысл совсем в другом. Что можно абстрагировать и убирать сложность. Эффективно разделять на интерфейс и имплементацию. Менять или не менять интерпретатор - дело десятое. У меня может быть только 1 потенциальный интерпретатор, но если мне нужно разделить мой код на интерфейс и имплементацию, я все равно буду это использовать

http://hackage.haskell.org/package/dejafu-1.11.0.3/docs/Test-DejaFu-Conc-Internal-STM.html