Или глобально все поломалось?

Хотя кейс интересный

С резолвом типа операции

Все поломалось глобально. Все инты требует поменять на ActorPath.

Я написал Бартошу (автору), он согласился, что надо бы откатить назад это определение, но пока он выпустит новый релиз, я хочу поставить заглушку, но не получается.

Вообще, выглядит как наркомания

Намерения были благие :-)

Можно ли переопределенный арифметический оператор переопределить назад? Я импортировал новый Akkling, и он, к сожалению, определяет такой оператор: let inline (/) (x:ActorPath) (y:string) = ActorPath.op_Division(x, y) что приводит, конечно же, к тому, что все операции деления в моем коде не работают. Ломаю голову, могу ли я заново определить op_Division, но пока не получается

Интересно. Все зависит от порядка открытия модулей с глобальными операторами.

@VagifAbilov open Operators

Возвращает изначальные определения операторов.

Спасибо, попробую

Намерения были благие :-)

Не надо так делать

Не надо так делать

Не желательно, конечно. Но вот в FSharp.Core так делают для работы с Unchecked.

В любом другом коде это не нужно, конечно. :)

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

Так с inline нигде ничего не ломается.

Тогда непонятно поведение компилятора у Вагифа

Тогда непонятно поведение компилятора у Вагифа

Там глобальный оператор переопределили.

@gsomix Да, open Operators восстановило деление. Теперь все компилируется

Там глобальный оператор переопределили.

Заместо (/) из Operators.

Да, это был глобальный оператор.

Заместо (/) из Operators.

А, ясно

Красавцы

Я ж грю, наркоманы

Предложение что ли кинуть, чтобы запретить так делать?

Или хотя бы ворнинг.

По идее нужен запрет на переопределение на уровне компилятора

Ну вообще с учетом потенциальной опасности хотя бы warning не помешал бы.

Кто на эти варнинги смотрит

У нас ворнинг как ошибка во всем проекте.

Njulf gjvj;tn

Тогда поможет

У разработчиков акклинга может быть не так

Посмотрите, о чем твитнул(а) @tomaspetricek: https://twitter.com/tomaspetricek/status/910516469380866049?s=09

Довольно интересная статья про обучение F#.

https://ravendb.net/docs/article-page/3.5/http/indexes/indexing-hierarchical-data

Вполне допускаю что на этом можно строить сложные надёжные масшатбируемые системы, но для быстрого старта и исследований в области data mining оно вообще ни как не алё. В моём представлении в NoSQL сервере всё должно быть тупо и примитвно, как в CouchDB., а здесь всё очень сложно. Magic everywhere. Очень много опций реализовано через интроспекцию. Постгресс на много менее хардкорный - его функции проще , и от него знаешь что ждать. Надо будет ещё посмотреть это на предмет сравнения с OrientDB, но на первый взгляд Orient тоже на много проще. Как говорится, спсибо автору за ознакомление.

Не собираюсь быть адвокатом RavenDB, но мне кажется, что это вопрос дизайна схемы данных, а не "фич" БД.

Документооринтированные БД сами по себе тупые как пробки. Что положил, то и лежит. Зависимости и отношения изобретай сам.

Документооринтированные БД сами по себе тупые как пробки. Что положил, то и лежит. Зависимости и отношения изобретай сам.

да, вот такое и нужно. Конкурентный view с обходом документов и пар ключ-значение - самая важная "фича" . Но raven как я понял хранит схемы документов и может хранить отношения, то есть пытается быть графовой. Плюс всё это прописывается в функциях на сервере на каком-то непонятном языке

А что нужно? Графы?

А что нужно? Графы?

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

если бы были принципиально нужны графы, я бы взял OrientDB, она очень гут

Про монгу почему-то подумалось..

И на ноде сразу захуячить

если бы были принципиально нужны графы, я бы взял OrientDB, она очень гут

и тоже не про F#

и тоже не про F#

Fable!!! :D

Про монгу почему-то подумалось..

моонга отстой, самое днище практически. Хранит всё в жсон, что идиотизм. На 100 гигов информации в ней будет на 2 порядка меньше, чем у меня в boltdb в двоичном виде. И транзакций у неё нет, то есть на любой update есть не нулевая вероятность, что все данные пропадут на хрен

Транзакции прикрутили, емнип

Транзакции прикрутили, емнип

только в пределах одного документа.

Fable!!! :D

ты о чём?))

Как из F# C#-у сунуть IReadonlyDictionary?

Тип IDictionary несовместим с типом IReadOnlyDictionary (WTF???)

dict[] |> Dictionary<string, string> — а вот так запихивается в IReadOnlyDictionary. Почему Dictionary можно скастить в ридонли, а IDictionary нельзя? Это фича или баг (куда репортить?)?

dict[] |> Dictionary<string, string> — а вот так запихивается в IReadOnlyDictionary. Почему Dictionary можно скастить в ридонли, а IDictionary нельзя? Это фича или баг (куда репортить?)?

Вероятно, это потому, что Dictionary имплементит IReadOnlyCollection, а IDictionary нет

Вернее, IReadOnlyDictionary. Ну и Collection тоже имплементит, офк :)

Тип IDictionary несовместим с типом IReadOnlyDictionary (WTF???)

IList и IReadonlyList тоже в таких же хитрых отношениях, кстати.

у меня, возможно, странный вопрос: можно ли определить функцию, которая возвращала бы себя же? пример: let rec foo input = foo

использоваться это будет примерно следующим образом: let rec foo state inputMsg = (*apply somehow input to state*) foo newState

у меня, возможно, странный вопрос: можно ли определить функцию, которая возвращала бы себя же? пример: let rec foo input = foo

Какую сигнатуру ты себе представляешь в этом случае? :)

вот да, она бесконечна =\

использоваться это будет примерно следующим образом: let rec foo state inputMsg = (*apply somehow input to state*) foo newState

Здесь конечная сигнатура.

Здесь конечная сигнатура.

Предъявите сигнатуру.

ну тип это вообще не скомпилируется, поэтому сигнатуру предъявить не очень получится, не? :)

у того, что хотел я, как мне кажется, должна быть бесконечная сигнатура, т.к. результат функции — функция с таким же результатом

надеялся, что есть какой-то трик, который я не знаю

Предъявите сигнатуру.

obj :3

obj :3

Ой, всё!

у того, что хотел я, как мне кажется, должна быть бесконечная сигнатура, т.к. результат функции — функция с таким же результатом

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

Хотя, честно признаться, я с трудом себе представляю, как ты этот код собираешься потом использовать.

мысль была в том, чтобы делать стейт-машины на этом

есть несколько функций с одинаковой сигнатурой: принимают стейт и сообщение

возвращают очередную функцию с такой же сигнатурой

Хотел стейт инкапсулировать?

Это же Free Monad

В чистом виде

ну не обязательно, можно же возвращать кортеж из очередной функции - обработчика и стейта

Ну все равно фримонадка в чистом виде

И дерево можно нормально построить

У Симана недавно статья на эту тему была

честно говоря, я ламер и ближайшие минут десять буду тупить

а можно ссылку на статью?

ну не обязательно, можно же возвращать кортеж из очередной функции - обработчика и стейта

Не совсем понятно, зачем такие сложности, когда можно сделать просто: update : Msg -> State -> State

Ну да foo : a -> (a -> a)

http://blog.ploeh.dk/2017/07/31/combining-free-monads-in-f/

Не совсем понятно, зачем такие сложности, когда можно сделать просто: update : Msg -> State -> State

потому что такая функция не возвращает очередного обработчика

Ну и далее и ранее по тексту

тип каждый шаг обработчик может быть другим

"очередного обработчика", это континьюэйшн?

Ну фри монадка жеж

data Next a = End a | Cont (a -> Next a)

Ага

судя по сигнатуре очень похоже на то, что хочу

но нифига не поинмаю :D

Это тип-сумма, который имеет два варианта - Конец - возвращаем a - Продолжаем - возвращаем функцию-продолжение