зачем презентация по недо-katip в этом чятике?

А что тут имеется ввиду под "структурностью"? Что вывод строк со значениями и переменными подсвечивается?

то, что логируется json с дополнительной метадатой

по структурным логам потом проше поиск делать в эластиках

https://github.com/ghc-proposals/ghc-proposals/pull/157

Крутое же расширение

Крутое же расширение

Как часто ты его используешь?

Prelude вообще почти всегда используется. Значит ли это, что он крутой? ;)

да

Нуу, ок

Крутое же расширение

напишите об этом в комментариях к пропозалу

Как часто ты его используешь?

Ни разу, лол :)

Как часто ты его используешь?

Не знал про него вообще

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

"Многа синтаксиса" на мой вкус

А зачем убрать хотят, поддержка что ли сложная?

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

(и со мной видимо что-то не так, потому что это буквально все, кроме меня)

Их слишком много.

Я только выборочно читал

Мне больше заходили статейки "24 для расширений GHC" и подобные

Ну и прочитал, не использовал, забыл

А зачем убрать хотят, поддержка что ли сложная?

говорят не особо, но раз никто не использует, то...

А ЗНАЕТЕ, ЧТО ЕЩЕ НИКТО НЕ ИСПОЛЬЗУЕТ? ХАСКЕЛЬ

Нужно убрать -XHaskell

{-# LANGUAGE NoHaskell, Golang #-}

можно ли написать хаскель на го7

Можно. Потом переписать хаскелль на хаскелле и забыть как страшный сон

Недавно в каком-то стриме человек лисп на 1С написал. Думаю, и х-ль на го можно, только вот зачем? Хотя, есть вероятность, что он будет быстрее обычного - ну как с PyPy происходит

хаскель надо на расте

Недавно в каком-то стриме человек лисп на 1С написал. Думаю, и х-ль на го можно, только вот зачем? Хотя, есть вероятность, что он будет быстрее обычного - ну как с PyPy происходит

хаскель на хаскеле-то только один раз написать удалось, а попыток было ~10

(самые удачные из неудачных попыток, правда, были не на хаскеле)

хаскель надо на расте

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

Компилятор надо на хаскеле писать уж

А рантайм на расте :)

Недавно в каком-то стриме человек лисп на 1С написал. Думаю, и х-ль на го можно, только вот зачем? Хотя, есть вероятность, что он будет быстрее обычного - ну как с PyPy происходит

так он вроде интерпретатор написал. а если вопрос про “быстрее” и кимпилятор, то уже критерии языка другие, тот же Хаскель подойдет лучше

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

Так фичи надо осторожно делать, а не наваливать в язык. List comprehensions бы убрать целиком, но на это никогда не согласятся.

Проку от них никакого, частный случай do-нотации

Ну или хотя бы превратить их в альтернативный синтаксис для do-нотации, включив MonadComprehensions по умолчанию. Это не совместимо с другими извращениями вроде -XTransformListComp

А рантайм на расте :)

Двачую!

вот, я об этом и говорю - чистое безумие. даже компрехеншоны ненавидят. вдумайтесь - компрехеншоны - what's not to love?

обычные - любим и пользуем

Двачую!

Довести бы linear haskell до состояния, где можно GC выкинуть (при заданных флагах компиляции), и переписать рантайм Хаскеля на Хаскеле

трансформнутые - слишком странные

Проку от них никакого, частный случай do-нотации

часто сахар меняет отношение к фиче принципиально. это тот случай

Довести бы linear haskell до состояния, где можно GC выкинуть (при заданных флагах компиляции), и переписать рантайм Хаскеля на Хаскеле

Если бы у бабушки была сигара...

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

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

Но ведь фичи убирают не из Хаскеля, а из GHC, не? А зачем? Ну чтобы быть не хуже Оберона.

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

и в случае хаскеля 90% хаскелистов не знают 90% фич

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

кек

Но ведь фичи убирают не из Хаскеля, а из GHC, не? А зачем? Ну чтобы быть не хуже Оберона.

так никакого хаскеля кроме гхц нет

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

90% хаскелистов не читали 90% мануала

Но ведь фичи убирают не из Хаскеля, а из GHC, не? А зачем? Ну чтобы быть не хуже Оберона.

Еще одна причина: чтобы комитету по стандартизации было проще.

90% хаскелистов не читали 90% мануала

плохо, мануал хорошо написан

хаскелисты, почитайте мануал GHC

еще как плохо Ж(((

и в случае хаскеля 90% хаскелистов не знают 90% фич

? Это правда. Хотелось бы знать Хаскель лучше

Еще одна причина: чтобы комитету по стандартизации было проще.

не существует никакого комитета по стандартизации

https://ghc.readthedocs.io/en/latest/lang.html

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

Раньше я ещё и за потенциально новыми следил

(и со мной видимо что-то не так, потому что это буквально все, кроме меня)

не буквально, вот нас двое

Ну или хотя бы превратить их в альтернативный синтаксис для do-нотации, включив MonadComprehensions по умолчанию. Это не совместимо с другими извращениями вроде -XTransformListComp

вроде монад-компрехеншоны же и трансформ копрехеншоны обобщают, нет?

и параллел

Раньше я ещё и за потенциально новыми следил

И даже пейперы на M$ reasearch читал :(

ERROR: S client not available

и параллел

параллел вроде да, для этого MonadZip придумали

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

не буквально, вот нас двое

вы узнали, какие расширения есть, чтоб только их ненавидеть

Так фичи надо осторожно делать, а не наваливать в язык. List comprehensions бы убрать целиком, но на это никогда не согласятся.

пускай Control.Monad в прелюдию внесут сначала. я задолбался гварды импортировать

вы узнали, какие расширения есть, чтоб только их ненавидеть

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

в большей части, конечно, все там хорошо

ну то есть плохо, но иначе было бы еще хуже

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

сейчас посмотрел, да: > The monad comprehensions extension generalises SQL-like list comprehensions to monads. Specifically, it generalises the aforementioned types of transformations to Monad m ⇒ m α → m α and Monad m ⇒ m α → m ( m α ) , respectively.

https://db.inf.uni-tuebingen.de/staticfiles/publications/haskell2011.pdf но MC - это фича которую DSH-ники делали, так что ничего удивительного

пока что в списке ненависти навскидку могу назвать ImplicitParams, всякие попытки row-polymorphism с Symbol для лейблов, и {-# INCOHERENT #-}

СОВСЕМ НЕ УДИВЛЕН

разве что про инкогерент, которое действительно вредное

А Symbol и метки чем не угодили?

разве что про инкогерент, которое действительно вредное

ImplicitParams из той же кучи, оно вводит некогерентный констрейнт. Это попытались сдержать, запретив их в instance contexts, но не получилось, через GADT-ы протекает

А Symbol и метки чем не угодили?

Потому что метки это не строчки

Если у меня две сущности одинаково называются, это не говорит о том, что это одна сущность

А полиморфизм должен быть по концепциям, а не по именам

Разрешаются по типу

Вот типы пусть и служат метками

Концепций в языке нету, только имена, к сожалению

Неправда

ну имплициты в контекстах позволяли делать некогерентные нормальные инстансы (это серьезная проблема), а то что имплициты не нормальные инстансы - ну что поделать - это другая фича, инстансы там только имплементация

Вот типы пусть и служат метками

Синтаксис неудобный

Я тоже люблю больше бойлерплейта

Концепций в языке нету, только имена, к сожалению

если я объявлю data Bool = False | True, то есть имя "Bool", а есть сам тип данных. в другом скоупе имя Bool может ссылаться на что-то другое

Чтобы сущность идентифицировать, нужно знать пакет, модуль, и в нём имя. Ну и особенность системы гарантирует тут уникальность

А если взять именем строчку, и абстрагироваться по строчкам, вот тут-то оно и течёт

ну имплициты в контекстах позволяли делать некогерентные нормальные инстансы (это серьезная проблема), а то что имплициты не нормальные инстансы - ну что поделать - это другая фича, инстансы там только имплементация

так сделали бы эту фичу не на тайпклассовых контекстах, другой был бы разговор

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

И с нормальным скоупингом вместо Symbol для имён опять

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

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