Проблема строковых экспрешнов в том, что они упадут в рантайме

@Dolfik То есть у тебя может быть получится сделать интерполяцию примитивных типов в запрос, но не кусков запросов. И уж тем более без compile-time проверок.

Вся беда в том, что printf-like механизм в F# не расширяемый.

Как, например, строковая интерполяция в Scala.

Вся беда в том, что printf-like механизм в F# не расширяемый.

Т.е. нельзя сделать замену так: select * from table where id = %i select * from table where id = @p1 ?

Или в C# :(

Т.е. нельзя сделать замену так: select * from table where id = %i select * from table where id = @p1 ?

Но по той линке, что ты кинул есть такой же пример)

Кстати спасибо

Но по той линке, что ты кинул есть такой же пример)

Я про другое, сшивать запросы тебе все равно придется через строки.

Что прям фу-фу-фу.

А, ты имеешь ввиду писать Sql прямо в коде, это фигово?

Ну да

Нет.

Писать SQL в коде — это офигенно!

@Dolfik Как ты будешь делать составные запросы?

Не ту проблему решаете, походу

Не ту проблему решаете, походу

Просто она другими средствами в F# решается.

@Dolfik Как ты будешь делать составные запросы?

Что-то не пойму, что подразумевается под составным запросом

Типа select * from a select * from b; ?

Что-то не пойму, что подразумевается под составным запросом

http://fsprojects.github.io/SQLProvider/core/composable.html#Generate-composable-queries-from-quotations

Вот пример, когда мы собираем запрос в рантайме. По условию выбираем предикат для where и подставляем его в запрос.

И выше примеры когда части запроса просто в отдельных переменных лежат.

Ну разве что повторять запрос

Хз ещё как

Вот это большая проблема. С printf-like функцией все хорошо, когда запросы простые.

https://github.com/Microsoft/visualfsharp/pull/921

Закрыли. .__.

Вот это большая проблема. С printf-like функцией все хорошо, когда запросы простые.

В любом случае, это лучше, чем dapper онли

Закрыли. .__.

На 4.2 перенесли возможно, как я понял

Воообщем. Создал пару тикетов по asp.net, думаю, кому тоже интересно будет. На F# это же тоже вроде распростроянется. https://youtrack.jetbrains.com/issue/RIDER-8088 https://youtrack.jetbrains.com/issue/RIDER-8087

Update 3 preview знает

Вот за эту подсказку спасибо!

Вот за эту подсказку спасибо!

Проблему с vscode не решил?

Примерно понял причину, но не решил

там ionide-fsharp конфликтует с новым MSBuild идущим в комплекте к VS2017 в итоге какая-то дополнительная утилита улетает с переполнением стэка, а какая-то из конфликтующих DotNet библиотек непонятно что делает вызывая BSOD

там ionide-fsharp конфликтует с новым MSBuild идущим в комплекте к VS2017 в итоге какая-то дополнительная утилита улетает с переполнением стэка, а какая-то из конфликтующих DotNet библиотек непонятно что делает вызывая BSOD

Ишшуй завел?

уже был

без BSOD правда, но уверен что проблема смежная

Ну, ты там тыкни разок, вдруг забыли.

https://github.com/fsharp/FSharp.Compiler.Service/issues/672

я че-то ничего хорошего еще не слышал про 2017 студию. Вечно у кого-то что-то не ладится, рушится и не работает.

я че-то ничего хорошего еще не слышал про 2017 студию. Вечно у кого-то что-то не ладится, рушится и не работает.

У меня нормально работает. :)

ладно бы оно внутри самой студии рушилось, оно всё вокруг рушит

казалось бы не использую ни IDE от неё, ни родной её Фрэймворк, а ведь всё-равно умудряется.

Все это кажется мне довольно странным.

Ещё бонусом иногда мелькание всего экрана при запущеном VScode / Atom при установленом Ionide

В Rider завезут Paket! Уря! https://youtrack.jetbrains.com/issue/RIDER-552

А в целом, почитал всё что завезут в Rider 2017.2 для F# и был очень приятно удивлён.

Акиньшин еще прошлой осенью обешал что завезут, ну наконец то (только я не понимаю зачем он на core clr)

В Rider завезут Paket! Уря! https://youtrack.jetbrains.com/issue/RIDER-552

Пока coreclr не завезли, не вижу смысла особо ставить

Кстати, только у меня ionide после последнего обновления стал хуже работать?

Хотя может он и работал так, но чёт прям много косяков вылазит

Из тех, что щас вспомнил: 1. Не всегда видит новые добавленные пакеты через dotnet add package, фиксится перезапуском 2. Отвалился fsi по Alt+Enter

Из тех, что щас вспомнил: 1. Не всегда видит новые добавленные пакеты через dotnet add package, фиксится перезапуском 2. Отвалился fsi по Alt+Enter

Ишшуи завёл?

Хм, пишу в F# в райдере с появления там онного. Всё нравится.

видеть там Paket очень рад.

Ишшуи завёл?

Неа

Неа

Чего же ты ждёшь?!

Чего же ты ждёшь?!

У меня с FSI уже такое было, потом само пофиксилось

Теперь опять сломалось

А с dotnet add хз, оно не всегда воспроизводится, я пока закономерность не нашёл

Так, я что, не могу запарсить число в функциональном стиле, не плодя мьютейбл?

Так, я что, не могу запарсить число в функциональном стиле, не плодя мьютейбл?

Если речь про TryParse, то out параметры в F# можно получить в виде кортежа.

М, хоть так, не пойму почему не запилили обертки в опшн

М, хоть так, не пойму почему не запилили обертки в опшн

Сложно определить, в какой момент нужно остановиться при составлении стандартной библиотеки.

Например, недавно решили, что не хватает функций для работы со строками. https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1033-extend-string-module.md

Можно распространять вместе с видео. :) https://www.youtube.com/watch?v=KPa8Yw_Navk

Get Started with F# as a C# developer https://blogs.msdn.microsoft.com/dotnet/2017/07/24/get-started-with-f-as-a-c-developer/

То-то в каждом проекте появляется папочка extensions с модулем tools ? (ну или типа того)

split: Should this function take a seq or seq, or both?

@Worldbeater ну, у нас в C# так точно подобное появляется =)

А в F# что ли тоже есть экстеншены как в C# ?

А в F# что ли тоже есть экстеншены как в C# ?

Да.

о как

По факту все методы типа Seq.map являются экстеншнами

По факту все методы типа Seq.map являются экстеншнами

а модули — статик классами а импорт модулей — юзинг статик ?

По факту все методы типа Seq.map являются экстеншнами

Почему? это же просто модуль с функциями а не экстеншен типа

по факту экстеншн является синтаксическим сахаром

это да, тогда скорее правильнее будет наоброрт. Не функции модуля являются экстеншенами, а экстеншены являются функциями модуля...

Как называть, вообще не важно

ну синтаксис то разный :)

Главное, чтобы не было такого - жопа есть, а слова нет

https://github.com/Microsoft/visualfsharp/pull/3365#pullrequestreview-52050222 Посаны, мой PR апрувнул Сайм ❤️

https://github.com/Microsoft/visualfsharp/pull/3365#pullrequestreview-52050222 Посаны, мой PR апрувнул Сайм ❤️

Бывает,чо

https://github.com/Microsoft/visualfsharp/pull/3365#pullrequestreview-52050222 Посаны, мой PR апрувнул Сайм ❤️

Молодец!

https://github.com/Microsoft/visualfsharp/pull/3365#pullrequestreview-52050222 Посаны, мой PR апрувнул Сайм ❤️

?

https://github.com/NuGet/NuGetGallery/pull/4437

Зачем нужен Paket?

Зачем нужен Paket?

https://fsprojects.github.io/Paket/faq.html

Первый вопрос. :)

Имхо, недостатки нугета — это стимул фокусироваться на доработке нугета, а не на создании еще одного пакетного менеджера...

tl;dr lock-файл, кеширование, solution-wide пакеты

Имхо, недостатки нугета — это стимул фокусироваться на доработке нугета, а не на создании еще одного пакетного менеджера...

Это сложно сделать, потому что разработкой NuGet управляет MSFT.

это как yarn vs npm. Проще сделать правильно, чем пытаться сделать конфетку из непонятного

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

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

В чём это выражается? На .NETCore/.NETStandard зависимости всех проектов независимы друг от друга. packages.config это немножко легаси же.

В Неткоре проектах пакет не пробовал, не скажу. Чем в обычных проектах отличается рассказать? ?

В Неткоре проектах пакет не пробовал, не скажу. Чем в обычных проектах отличается рассказать? ?

Давай. Помню много боли с транзитивными зависимостями при попытках скрестить NETStandard с тестами на F# .NETFramework. Может быть, было бы проще, узнай я раньше о Paket :)

Давай. Помню много боли с транзитивными зависимостями при попытках скрестить NETStandard с тестами на F# .NETFramework. Может быть, было бы проще, узнай я раньше о Paket :)

Да, именно они - транзитивные зависимости. Пакет все зависимости всех проектов анализирует вместе, поэтому все проекты будут согласованно подключать, скажем, newtonsoft.json 8.0, а не так выводится из референсов каждого проекта по-отдельности

упомянутый лок-файл опять же, его надо добавлять в VCS, тогда результат "вытягивания сборок" не будет зависеть от времени, порядка проектов и пр.