Я просто хочу странного

Хочется дополнительного слоя абстракции над пропертями по аналогии с ? <- операторами, но со строгой проверкой типов

Хочется дополнительного слоя абстракции над пропертями по аналогии с ? <- операторами, но со строгой проверкой типов

Почему бы просто не использовать проперти?

Чего-то нстроение не очень тут. Давайте жить дружно

да вроде не происходит ничего)

Почему бы просто не использовать проперти?

Это не всегда возможно

Это не всегда возможно

Давай на примерах тогда.

Я на словах очень плохо понимаю.

Ну смотри

Есть условный билдер

По факту список, какое свойство у объекта какой функции чтения соответствует

Дык вот

Хочется по идее нотации 't->'n где t тип, 'n свойство

Т.е. задавать функции геттеров сеттеров в общем виде, без доступа к инстансу объекта

Условно , если тип 't имеет свойство A, но не имеет свойство B, то условно <'t>?A должно скомпилиться, а <'t>B нет

<'t>?B

Все обозначения, естественно, условны

В c# я это могу решить конструированием лямбды на проперти

Точнее Linq expression

Вопрос, как это сделать в f#

Если я правильно, понимаю, то нужно что-то вроде Expr<A,B> foo = (a) => a.b?

Угу

Причем со строгими констрейнтами

квотейшен же <@ fun a -> a.b @>

а, прочитал выше про DU

Ну квотейшн возможен, конечно

можно в таком случае сделать у DU with и там добавить мембер с нужным значением

реализуюя его, видимо, через match

Квотейшн потом надо как-то вычислять, это раз, и скорее всего он будет untyped, это два

Мрак - в спеке вместо описания квотейшнов ссылка на мсдн...

Мрак - в спеке вместо описания квотейшнов ссылка на мсдн...

Спроси здесь.

Ну перед тем , как спросить, в это надо погрузиться

Нырнуть поглубже, так сказать

Квотейшн потом надо как-то вычислять, это раз, и скорее всего он будет untyped, это два

http://fsprojects.github.io/FSharp.Quotations.Evaluator/

ну и да, почему Untyped?

Мрак - в спеке вместо описания квотейшнов ссылка на мсдн...

А это на какой странице?

Посмотри пункт 6.8

динамические операторы уж точно не вариант

Спасибо, ща гляну

динамические операторы уж точно не вариант

Ну хочется условно строгой типизации, да

Хммм... начал смотреть на Гьялахорн. По виду очень крутая библиотека

Особенно элегантно там решена проблема code behind

Прям аж захотелось ее попробовать

Привет!

5 минут как понеслось! https://channel9.msdn.com )

Чо там есть чо для ф шарпа?

FsharpConf с леночкой ?. Можно наверное передать привет в прямой эфир от f#-russia.

Оно же в записи будет?

Оно же в записи будет?

да. обещали. сейчас про Hopac рассказывают

Ок. Что щас hopca видел, просто времени прямо сейчас смотреть нет.

Хехе, скоро до 1.0.0 доберутся, хехе. https://github.com/gusty/FSharpPlus/commit/1dd1c0b1a5617439c98ad90491922b1b31153458

https://twitter.com/mlusiak/status/985911274612645889

Они туда @terrajobst (.NET PM) притащили. Офигеть. :)

Слева от Лены.

FsharpConf с леночкой ?. Можно наверное передать привет в прямой эфир от f#-russia.

Передал? ?

Я на вас надеялся ? (это был завуалированный призыв к действию)

Они туда @terrajobst (.NET PM) притащили. Офигеть. :)

затролили в твиттере после того слайда от Альфонзо на F# Exchange

https://github.com/Wkalmar/SokkerPlayersCrawler/pull/1

Vasily ?

Привет!

Привет!

Привет, Рыба.

https://github.com/dotnet-websharper/mvu

https://github.com/dotnet-websharper/mvu

Выглядит неплохо.

Интересно, что разработчиков W# не видно на конференциях.

Не хайпят!

Возможно, не успевают ездить

Ну или просто считают, что ещё не время хайпить.))

Выглядит неплохо.

А мне не нравится темплейты. Получается view разбивается на две части: разметка и связывание разметки с моделью. Complexity + boilerplate

А как больше нравится?

А мне не нравится темплейты. Получается view разбивается на две части: разметка и связывание разметки с моделью. Complexity + boilerplate

Можно использовать WebSharper.UI.Html

Вот пример. http://try.websharper.com/snippet/loic.denuziere/0000Kc

Вопрос больше по Net части, если функция inline - она встраивается, и по идее она будет вырезаться (?) как отдельный метод из сборки компоновщиком и её, например, из рефлексии не вызвать в релизе?

Вот пример. http://try.websharper.com/snippet/loic.denuziere/0000Kc

О, это уже по лучше. Спасибо

Вопрос больше по Net части, если функция inline - она встраивается, и по идее она будет вырезаться (?) как отдельный метод из сборки компоновщиком и её, например, из рефлексии не вызвать в релизе?

https://sharplab.io/#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAWAChjgFsUBLJYahFPDAFQFc4yUBDFAIxQF5iKFAApOAGl4BKISmJwATtWxgUAIgCkAQTWjGrdvQBMKAMxSgA=

не вырезается

Много нас осталось?

Напомните плиз есть ли в f# tail rec в каком либо виде?

Напомните плиз есть ли в f# tail rec в каком либо виде?

Есть. https://blogs.msdn.microsoft.com/fsharpteam/2011/07/08/tail-calls-in-f/

Если вычисления до входа в следующий цикл рекурсии - это тейл рек, иначе - обычная рекурсия. Вроде так

А проверять надо дизасемблером?

А проверять надо дизасемблером?

еще стоит понимать что компилятор будет стараться умничать, и если tail rec не очень сложный и понятный компилятору, то в декомпилированном коде будет просто цикл - и это нормально (это значит что tail)

не вырезается

Этот сайт не собирает в релиз. https://sharplab.io/#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAWACgBiASzBQCUBRAGRoEE0bjgFsUylhuEU8GACoBXOOwBMKAIYoARigC8xFCgAU0gDTyAlMRIJgEBGw5cefAcLHsAjPJQBjJSvVztjvaWQATCsTgAJ25sSgAiAFJGMPVBUXEEeykAZh0gA===

Вопрос больше по Net части, если функция inline - она встраивается, и по идее она будет вырезаться (?) как отдельный метод из сборки компоновщиком и её, например, из рефлексии не вызвать в релизе?

Ты говоришь про F# inline или атрибут AgressiveInlining (как его там)?

Ты говоришь про F# inline или атрибут AgressiveInlining (как его там)?

Я не знаю, замещаеся он на агрессив или свой механизм.

Это два совершенно разных случая. У них ничего общего.

Но если например можно на C# агрессить геттеры/сеттеры, то у F# ошибки билда

Это два совершенно разных случая. У них ничего общего.

Вот мне и интересно, будут ли inline функции вырезаны в релизе?

F# inline — это фича языка. Компилятор будет делать специализацию функции для всех случаев её использования. Исходная функция тоже будет, но, вроде бы, только в метаданных (в декомпиляторе ты её, возможно, не увидишь) — чтобы из других сборок юзать. Атрибут AgressiveInlining — это хинт для JIT. Соответственно, на выводе декомпилятора он вообще никак не отражается, а чтобы понять, сработал он или нет — надо читать дизасм.

F#-компилятор сам умеет много чего инлайнить в байткоде (без дополнительных хинтов, совсем самостоятельно). C#-компилятор так никогда не делает.

F# inline — это фича языка. Компилятор будет делать специализацию функции для всех случаев её использования. Исходная функция тоже будет, но, вроде бы, только в метаданных (в декомпиляторе ты её, возможно, не увидишь) — чтобы из других сборок юзать. Атрибут AgressiveInlining — это хинт для JIT. Соответственно, на выводе декомпилятора он вообще никак не отражается, а чтобы понять, сработал он или нет — надо читать дизасм.

Ну это как __forceinline как я понимаю из C++, то есть функция просто встраивается в цепочку вызовов и, например, будет одна большая функция, если собирать её из инлайнов.

Ну это как __forceinline как я понимаю из C++, то есть функция просто встраивается в цепочку вызовов и, например, будет одна большая функция, если собирать её из инлайнов.

Про какой из вариантов ты говоришь?