Во, та же болезнь

эм?

свой парсер

так ведь так и нужно

благодаря этому оно и "интегрированное"

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

Да нет никакого шанса, что какой-нибудь кастомный парсер правильно распарсит все, что и GHC, например

Для Rust может и прокатит, я не знаю какая там грамматика

Но это опять дубликация логики. Компилятор по одному парсит, IDE по-другому.

В итоге имеем что имеем.

падажжи

ты же сам за IDE топил

в IDEA так для всех языков как я понимаю сделано

теперь ты резко переобулся

чёт я не понимаю

Я не знаю как в IDEA сделано. Я знаю, что если я беру Visual Studio и пишу код на C#, то у меня не будет кода, который компилятором принимается, а IDE ломает

И я знаю, что в Haskell такое на каждом шагу, если лепить псевдоIDE из всякого тулинга типа HLint и hasktags

так и в IDEA такое маловероятно в популярном плагине

потому что если такое найдут то сразу пофиксят

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

Или может в архитектуре. Вот будь у GHC парсер отдельным компонентом, который можно в тулинге реюзать, и жили б все хорошо, а не с haskell-src-exts

ну вот опять-таки

практика показывает

я почему-то думал, что ghc-mod или кто там именно так и сделан, как api к ghc, разве нет?

что лучшие IDE используют свои парсеры

я почему-то думал, что ghc-mod или кто там именно так и сделан, как api к ghc, разве нет?

GHC-mod так и сделан, там своих болезней хватает

вот Qt Creator емнип юзает Clang для автокомплита ну и автокомплит там так себе я CLion не пробовал но шо-то мне подсказывает там автокомплит намного круче

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

да и вообще

дублирование логики - не баг, а фича

point @int_index в том, что с IDE можно сделать гораздо лучше, т.к. там каждый компонент может заниматься своим хорошо, с vim и emacs это не реально, но текущее положение вещей такое, что vim и emacs более хорошая альтернатива idea

если я правильно понял

дублирование логики - не баг, а фича

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

если я правильно понял

правильно

> потому что для нормального развития языка полезно чтобы были альтернативные реализации У Хаскеля есть одна реализация и неправильные

кто писать то их будет?

парсер либой конечно было бы прекрасно

а альтернативный парсер - печально

кто писать то их будет?

И если найдется этот человек, то что он будет писать? Стандарта нет

т.е. h-s-e получится

кстати, language extensions типа той же экзистенциальной квантификации - как-то стандартизированы? или это чисто compiler-specific фигня?

это GHC-диалект

вот это кстати тоже очень хуёвая ситуация

это как с GCC

понаделали compiler-specific расширений

написали на нём ядро

Оно еще и implementation-defined, потому что никто ососбо не запарился формально эти фичи описать

(Linux)

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

Есть формализация только для Core, и то не так давно появилась, трудами Эйзенберга

остальной тайпчекер написан методом проб, ошибок, и дискуссий с SPJ

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

потому что всё завязано на нестандартизированные compiler-specific расширения

@KolesnichenkoDS пожалуйста без мата формулируй утверждения

> потому что всё завязано на нестандартизированные compiler-specific расширения Эти расширения не на пустом месте возникают, они решают реальные проблемы. Вот есть в какой-то реализации расширение, которое решит мою проблему — мне его не использовать из соображений чистоты?

ну лучшая ситуация из возможных

стандартизировать их вот пытаются, но не факт что что-то добьются

Я все думал, что когда-нибудь выйдет Haskell20XY, который будет Haskell2010 со смерженными в него самыми частыми расширениями

альтернативные - реализовывали те расширения что нужны

А что тебе с самых частых, если там еще 20 полезных?

вон тот же jhc и hugs умели расширения

> потому что всё завязано на нестандартизированные compiler-specific расширения Эти расширения не на пустом месте возникают, они решают реальные проблемы. Вот есть в какой-то реализации расширение, которое решит мою проблему — мне его не использовать из соображений чистоты?

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

ну делают следующий language report где хотат включить

но там много проблем

Я по-другому на Haskell писать отказываюсь

главное, что это не решит не так и много проблем

(в общем-то ничего почти ничего не решит)

станет ли проще писать альтернативный компилятор?

сомневаюсь, все кто писали обходились без стандарта на расширения

Если добавить GADT-ы, то это уже завязывает на OutsideIn тайпчекер

а еще один GHC никому не нужен, этот бы допилили

ну всякие (a)jhc имеют место быт

их направление ghc не покрывает

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

авторы ajhc вмерджили что смогли в jhc и ушли на ATS

ну тяжело

и не достаточно маргинально было

Давайте конкретно, друзья. вот есть у меня один проект по работе, достаточно небольшой. Прошу прощения, что не про Haskell, с ним у меня пока только игрушечные проекты. какие там есть расширения: 1) .cpp, .hpp - обычные плюсы 2) .cu - Nvidia CUDA 3) .py - Питон 4) .i - интерфейсные файлы SWIG для связывания плюсов и питона 5) .sh - кое-какая внешняя обработка данных делается через GNU утилиты и соотв-но CLI-интерфейс 6) .dat - DSV данные 7) .tex - документация к проекту 8) Makefile 9) .cfg - конфиги Всё это я открываю через vim и редактирую текст абсолютно единообразно, согласно идеологии vim. Очень быстро, уж точно быстрее, чем в ваших IDE. При этом почти для каждого типа файла у меня есть свои плагины или просто настройки vimrc, которые добавляют специфичные для области плюшки. Что в данном ситуации мне предложат адепты integrated? Какой сценарий руления всем этим добром? Интересно выслушать.

#my-faviourite-editor уже создали?

(это не предложение завершаться)

Я ничего не предложу, так как считаю, что хороших IDE мало и они заточены под конкретные языки. Сам я IDE не использую. Но вот понять человека, который C# в Visual Studio писал или Java в whatever-IDE, а потом пытается перейти на Haskell и у него от тулинга кривого просто горит, я отлично могу.