А>Может ли кто-нибудь подсказать, что выбрать для реализации библиотеки лексического/синтаксического анализа ? А>Важна скорость и удобство.Собственно интересует пока только прототипирование,но если скорость будет приличной можно и остановиться на выборе,по сему важны привязки к C(++) .
А>Причина выбора этих языков — изучение ФЯ . А>Об OCaml слышал — хорошая скорость, жуткий синтаксис. А>О LISP слышал много чего хорошего,причём использовать/реализовать можно любую парадигму программирования.Но вот о скорости не нашёл ни чего.Скобки и префиксную запись не считаю проблемой.
Скорость чего? Если прототипирования, то лучше любой язык, позволяющий сделать комбинаторы разбора. Тогда ты сможешь проверять грамматику пошагово: описал правило и тут же его проверил на тестовом примере.
Итак, здесь два требования: выразительность (легкость создания библиотеки) и REPL.
Я думаю, что в этом случае OCaml удобней потому, что у него есть строгая система типов и при построении комбинаторов ты просто-напросто будешь допускать меньше ошибок. Напрямую по обеим пунктам, я думаю, оба языка одинаковы.
Если важна скорость исполнения, то снова начинает лидировать OCaml потому, что есть компилятор. Точнее, он просто более доступен.
Иными словами, OCaml получается лучше.
Ещё лучше, конечно, Хаскель, но я и так уже прослыл его рекламным агентом. Поэтому от описания совершенного изящного синтаксиса Хаскеля, его выразительнейшей системы типов с типами классов и возможностью более точно выражать инварианты с помощью GADT, великолепного REPL, удивительно эффективного и мощного компилятора, а также уникального в своём роде ленивого порядка вычислений, что заставит тебя сильнее всего почувствовать всю мощь функционального программирования, я воздержусь.
Я воздержусь от описания всех этих невероятно полезных вещей и даже не буду намекать на выгоду от их использования.
Да я вообще о них не буду упоминать.
Вот.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>На фотографии под штангой — я. Ну, чтобы ты знал, если что. ;)
В этом никто и не сомневался, Сергей, потому что ты настолько часто упоминал свою штангу в аргументации, что решительно каждый узнает её в лицо.
Кроме того, в статье перечислены чуть менее чем все существующие в мире программисты на Хаскеле, так что требуемое можно было умозаключить простым исключением.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, thesz, Вы писали:
T>>Grown up check failed for not following the discussion in time.
T>>Plase, try again later.
Q>Засчитан.
Думаю из этой беседы будут сделаны правильные выводы и выбран Ocaml
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>В упомянутом мной Slime это делается на раз. Пишешь код, жмешь shortcut и он выполнился. Результат выполнения виден. Не нравится — подправил, проверил снова. А из REPL вытащить когда-то определенную там ф-цию или структуру почти невозможно.
Так это тот же REPL, разве нет?
Ещё — про haskell-mode для Emacs или для vim знаете?
RD>Точно никак не обобщаются? Я допускаю, что может быть какая-то суровая причина на то. Особенно в случае с Map. Но глядя на singleton в Seq и Set я вижу следующие типы:
Можно сделать Set монадой, тогда это будет простой return. И вообще — это проблема библиотек
Такие проблемы есть, да. Слишком большой Num, например. Или то, что Bool — не класс типов.
RD>"Не осилили ф-ций с переменным числом аргументов" в данном случае значит само описание типа функций предполагает что число аргументов фиксировано. Думаю, на это есть какая-то причина. Например, что если это число не фиксировано, то type inference работать не будет.
Ну, printf же как то работает.
Там всё просто на самом деле
class Glue g where
glue :: String -> g
instance Glue String where
glue = id
instance Glue g => Glue (String -> g) where
glue s1 = \s2 -> glue (s1 ++ s2)
И затем просто
main = putStrLn $ glue
"В пустыне чахлой и скупой,\n"
"На почве, зноем раскаленной,\n"
"Анчар, как грозный часовой,\n"
"Стоит - один во всей вселенной.\n"
Правда, это ограниченный круг функций с переменным числом аргументов.
RD>Обратно же, если у софта out of memory, то желательно чтобы сдохла не более чем одна нить, и было ясно где она умерла. Но этого, насколько я понимаю, от GHC добиться не получится.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>не может. в ghc есть ключик, включающий/выключающий использование gcc BZ>на окамле у тебя просто нет удобных монад, поэтому тебе не придёт в голову их использовать как это сделано в ghc. окамл — строгий язык, в нём нет еype classes, а это основные источники замедления haskell. наконец, многоаргументные функции в нём не каррируются — это тоже источник замедления хаскела BZ>не может. в ghc есть ключик, включающий/выключающий использование gcc BZ>а в каком по-твоему стиле ghc написан? тот код, который всего в несколько раз медленней сишного — пишется на низком уровне, и это ещё сложнее чем просто писать на C BZ>ghc же, как и любые джругие программы на хаскеле, написан высокоуровнево, и это означает применение ленивости, монад и всех прочих кунштюков.это и делает его таким медленным в сравнении с хагсом, который реализует сравнимую с ghci функциональность
Вот ты сам не поленился новые ghc с -fvia-C погонять и сам открыл, что все работало в 5 раз (ну, у тебя — в 3) медленнее *только* потому, что вместо нативной компиляции запускался сначала perl, а потом — gcc, т.е., проблема была чисто инженерная, а Хаскелл как язык тут вообще никаким боком. После этого ты буквально тут же начинаешь атрибутировать все проблемы со скоростью работы ghc тому, что он написан на "меделенном" Хаскелле. Еще для примера: был, например, глюк GHC с экспоненциальным временем компиляции type synonyms. Пока с этим не сталкивались, никого это особенно не интересовало, когда начало мешать — поправили и скорость компиляции некоторых программ с практической точки зрения выросла бесконечно. Про другие неоптимальные куски SPJ несколько раз упоминал, но оно работает и пока та или иная проблема не окажется критической — вряд ли кто-нибудь будет особенно чесаться.
Потом, GHC уже много лет, так куча legacy кода. С тех пор стали лучше понимать как работает GHC и как на *идиоматическом* Хаскелле писать намного более быстрые программы. Но никто не кинется переписывать половину GHC, чтобы оно работало быстрее. Или вот, например, компилятор mingw gcc в несколько раз медленнее microsoft c при примерно одинаковом качестве генерируемого кода. Почему?
Обычные расчеты на Хаскелле пишутся на обычном уровне и, условно говоря, оно получается в 1,5-5 раз медленнее сишного. Кое-какой код, написанный на низком уровне, после переписывания на идиоматический становится *быстрее*.
Предмет обсуждения стал расплывчатым и постоянно меняется местами язык и реализация, например, твоя любимая тема что type classes — зло для производительности, поскольку приходится в runtime таскать за собой словари, относится на 90% к существующим имплементациям, а не к Хаскеллу как таковому, да и GHC кое-что умеет optimize away. Поэтому я сформулирую свою позицию более конкретно — подавляющее большинство программ можно написать на идиоматическом Хаскелле (ghc), оставаясь в порядке производительности идиоматического C (gcc), те, что нельзя — лечатся точечными инъекциями C.
Здравствуйте, Mr.Cat, Вы писали:
L>>Однако, в Haskell её монадой не сделаешь. MC>А почему?
Если без ТК, то вот пример, как сделать в Хаскеле множества почти монадами:
{-# LANGUAGE NoImplicitPrelude #-}import qualified Data.Set as Set
import Prelude(Int, ($), fromInteger, (+), Ord)
import Data.Set(Set)
return = Set.singleton
m >>= k = Set.unions $ Set.toList $ Set.map k m
fail = Set.empty
test = do x <- Set.fromList [1..3]
y <- Set.fromList [1..3]
return (x+y)
Операция (>>=) здесь имеет тип (Ord a, Ord b) => Set a -> (a -> Set b) -> Set b. Другими словами, ее тип практически совпадает с типом (>>=) из класса Monad, но контекст (Ord a, Ord b) все портит.
T>Ещё лучше, конечно, Хаскель, но я и так уже прослыл его рекламным агентом. Поэтому от описания совершенного изящного синтаксиса Хаскеля, его выразительнейшей системы типов с типами классов и возможностью более точно выражать инварианты с помощью GADT, великолепного REPL, удивительно эффективного и мощного компилятора, а также уникального в своём роде ленивого порядка вычислений, что заставит тебя сильнее всего почувствовать всю мощь функционального программирования, я воздержусь.
Ну если REPL — образец великолепия... Впрочем, я достаточно либерален и спокойно отношусть к мазохизму. Это ж надо, ловить кайф от того, что софтина пишется в одном месте (скажем, в текстовом редакторе), а проверка типов, разного рода экспериментирование и т.д. — в другом (REPL).
Конечно, реализовать REPL проще чем приличный IDE где все то же самое было бы прямо в редактируемом модуле. Кстати, нечто подобное Common LISPеры сделали в своем Slime. Для языков типа Haskell это было бы еще удобнее. Но "Emacs это наше все" и нет света в конце тоннеля. Разве что может Leksah?
GADT это сила, сомнений нет. Одна из тех вещей, что подчеркивают убожество языков типа Java. Вот только разве нет их в том же Ocaml? В хаскель, конечно, через GADT все делается. Прямо как в одном бородатом анекдоте. Даже records. И никого не смущает ни мусор из-за валяющихся под ногами функций доступа к полям, ни бредовый синтаксис этих самых records, ни прочие прелести. Впрочем, тут я преувеличиваю. Были какие-то предложения это исправить, но воз и ныне там.
Увидительно эффективный и мощный компилятор. Когда глядел на него последний раз, то результат непосредственной компиляции в native был в разы тормознее окольного пути генерации Cшного кода и потом компиления оного. Далее, пробовал чисто формально обернуть в монаду фнкцию что проходит по строке и выбрасывает символы удовлетворяющие простенькому условию. Результат удручающий — скорость упала в 10 (десять) раз. Видимо это так сей компилятор умеет выбрасывать ненужные ветви исполнения и именно так в хаскеле демонстрируется мощь ленивых вычислений.
Изящество синтаксиса. Хочешь передать функции foo пару отрицательных чисел — будь добр обернуть их в скобки.
foo (-1) (-2)
Сравниваем с LISP:
(foo -1 -2)
Да, конечно это не часто нужно. Но я что слышал это имено в LISP сильно много скобок.
Система типов. Да, typeclassы это хорошо. Действительно удобная штука. Вот только почему-то в стандартных библиотеках начхать всем на них. Вот что мешало сделать штуки типа "null", "empty", "singleton" методами абстрактных TypeClass'ов? А так импортнешь IntSet и Seq и сразу же каша получается.
Вещи типа unzip7, наверное, тоже следствие выразительности системы типов. Функций с переменным числом агрументов в haskell не осилили?
Поддержка Unicode... Эх, не будем о грустном и вечном.
Но особенно радует runtime. Если ни дай Бог программа съест много памяти — бах, и лежит труп с out of memory. Понять, из-за чего она сдохла почти не реально. Тем более, что она вся такая модная и ленивая и на такие мелочи как нормальный мониторинг потребления ресурсов и экономное расходование памяти не отвлекается. Да, я в курсе что есть такая штука как нагрузочное тестирование. Вот только лишь для самых простых случаев это потребление памяти можно им надежно отследить. На все остальное самый действенный способ — неистовая молитва.
P.S. И несмотря на все вышеперечисленное, Haskell действительно (не, я серьезно) один из самых лучших языков на данных момент. Прямо как Unix: "Unix — паршивая ОС, но лучше пока ничего не придумали".
Здравствуйте, awson, Вы писали:
BZ>>путаешь. раза в три в 6.8 просто потому, что перестали использовать gcc. плюс код стал быстрее на 10-20% A>Ты прав про 6.8, действительно — это был переход от 6.6 к 6.8. Я таки поискал, вот — про 5 раз. По поводу gcc — для *не* -O2 и до 6.8 gcc не использовался, однако оно все равно компилировалось в разы медленней. Я, откровенно говоря, сходу не нашел ссылки на тот баг в ghc < 6.8, который я имел в виду, притом, что я не помню в чем он конкретно состоял. Но, даже и устранение gcc и perl'а — разве это не свидетельство именно *технических* проблем?
BZ>>а тормозит он потому, что написан на хаскеле — ленивом fp языке A>Ну да — в том смысле, что его никто специально не оптимизировал в конкретно этом смысле. Да, на сегодняшем уровне GHC без специальных костылей и без учета качества рантайма (который примерно сопоставим) — только по качеству генерируемого кода проиграет ocaml'у раза в полтора, максимум два. Но *не больше*. Однако, с моей точки зрения, на 90% это — инженерная задача, а не проблема с ленивостью как таковой. Остальное (в смысле времени компиляции) обусловлено тем, что Хаскелл, очевидно, более сложный язык.
слушай, ты рассказываешь о вкусе устриц профессиональному дегустатору
6.8 на моей проге раза в 3 быстрее. без -O большой разницы нет, думаю как раз те самые 10-20%, которые обусловлены улучшением кодогенерации (ghc ведь компилируется сам собой)
далее — winhugs загружает прогу раз в 10 быстрее, чем ghci. твоя вера в то, что ленивость (и ещё монады, широко используемые в реализации ghc) замедляют программы всего в 1.5 раза, а не в 10 или к примеру 100 — опять же прелположение из воздуха. реально разница в 1.5-2-3 раза идёт только если написать программу в императивном низкоуровневом стиле, без всякой ленивости и связанных с ней типов данных — списков, к примеру. при написании же в нативном стиле разница достигает сотен раз — смотри к примеру статьи:
Здравствуйте, FR, Вы писали:
FR>Даже на малюсеньких примерах которые я компилирую хаскель (последняя версия) намного тормозней Ocaml'а
Да, это так. Но сейчас это уже не пропасть. GHC — очень большой и там есть просто неоптимально сделанные места, причем многие давно известны, но не хватает manpower, чтобы этим заниматься. Например, скорость компиляции выросла в 5 раз при переходе (если я правильно помню) от 6.4 к 6.6 просто потому, что пофиксили баг производительности.
Здравствуйте, awson, Вы писали:
A>Да, это так. Но сейчас это уже не пропасть. GHC — очень большой и там есть просто неоптимально сделанные места, причем многие давно известны, но не хватает manpower, чтобы этим заниматься. Например, скорость компиляции выросла в 5 раз при переходе (если я правильно помню) от 6.4 к 6.6 просто потому, что пофиксили баг производительности.
путаешь. раза в три в 6.8 просто потому, что перестали использовать gcc. плюс код стал быстрее на 10-20%
а тормозит он потому, что написан на хаскеле — ленивом fp языке
Здравствуйте, BulatZiganshin, Вы писали:
BZ>путаешь. раза в три в 6.8 просто потому, что перестали использовать gcc. плюс код стал быстрее на 10-20%
Ты прав про 6.8, действительно — это был переход от 6.6 к 6.8. Я таки поискал, вот — про 5 раз. По поводу gcc — для *не* -O2 и до 6.8 gcc не использовался, однако оно все равно компилировалось в разы медленней. Я, откровенно говоря, сходу не нашел ссылки на тот баг в ghc < 6.8, который я имел в виду, притом, что я не помню в чем он конкретно состоял. Но, даже и устранение gcc и perl'а — разве это не свидетельство именно *технических* проблем?
BZ>а тормозит он потому, что написан на хаскеле — ленивом fp языке
Ну да — в том смысле, что его никто специально не оптимизировал в конкретно этом смысле. Да, на сегодняшем уровне GHC без специальных костылей и без учета качества рантайма (который примерно сопоставим) — только по качеству генерируемого кода проиграет ocaml'у раза в полтора, максимум два. Но *не больше*. Однако, с моей точки зрения, на 90% это — инженерная задача, а не проблема с ленивостью как таковой. Остальное (в смысле времени компиляции) обусловлено тем, что Хаскелл, очевидно, более сложный язык.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Аноним, Вы писали: А>>Спасибо,но интересуют только реализации в нативный код
MC>Кстати, можете и haskell попробовать.
Синтаксически мне он понравился после беглого прочтения статьи на этом сайте,но насколько я понял со скоростью у него не очень,плюс подводные камни ленивости,монады — ваще чёто не понятное.Думаю для начала это будет слишком круто.
Здравствуйте, thesz, Вы писали:
T>>>Сколько раз я её упоминал? Q>>Я, право, сбился со счёта. T>То есть, ты не собираешься отвечать за свои слова.
Нет, Сергей Зефиров, я могу ответить за свои слова. Вот только станет ли тебе от этого легче? Я просто добродушно подшутил над твоим хвастовством, не со зла. Конкретизировать я не хотел, просто чтобы не выставить тебя в неприглядном свете. Но ты всё тянешь и тянешь меня за язык, при том обидеть норовишь. Раз уж ты настаиваешь...
1) В давней дискуссии с zabivator'ом твоё ораторское мастерство проявилось во всей красе:
На фотографии под штангой — я. Ну, чтобы ты знал, если что.
T>То есть, ты не собираешься отвечать за свои слова. T>Что ж, Qbit86, grown up indication set to off. For a longer time now.
Что ж, таким вот нехитрым приёмом ты и поставил меня в дурацкое положение, вынудив кому-то что-то доказывать, откапывать твои нелицеприятные высказывания. Ты доволен?
T>>>>Сколько раз я её упоминал? Q>>>Я, право, сбился со счёта. T>>То есть, ты не собираешься отвечать за свои слова.
Q>Нет, Сергей Зефиров, я могу ответить за свои слова. Вот только станет ли тебе от этого легче? Я просто добродушно подшутил над твоим хвастовством, не со зла. Конкретизировать я не хотел, просто чтобы не выставить тебя в неприглядном свете. Но ты всё тянешь и тянешь меня за язык, при том обидеть норовишь. Раз уж ты настаиваешь...
Q>1) В давней дискуссии с zabivator'ом твоё ораторское мастерство проявилось во всей красе: Q>
FR>I cannot emphasize this enough. GHC takes 2-3-4 minutes to rebuild my project whenever I touch the parser. Ocaml takes 1-2-3 seconds. I use a 2Ghz Core Duo MacBook Pro and Topdog is decidedly not a large project which makes the difference all the more glaring. With Haskell I was loath to touch the parser or my syntax tree definition, with OCaml I look forward to tweaking things to my hearts content. Normal recompilation time of Topdog is so far as to be almost unnoticeable.
FR>Интересно неужели за два года GHC смог ускорится на порядок.
Тут про сборку написано а не про время работы собранного софта. Так что все логично и GHC не ускорялся.
А воообще-то 2-4 минуты на сборку это нехило. И легко объясняет приверженность REPLу. Т.к. "на безрыбье и рак — рыба".
Здравствуйте, Rtveliashvili Denys, Вы писали:
T>>Сразу после проверки типов ты проверяешь функциональность. И это нормально,
RD>Да, конечно это нормально. Просто если пользуешься REPL то это зверски неудобно. Разве Вам не кажется, что проще делать это прямо в IDE и не возиться с постоянным перебрасыванием кода в REPL (что еще более-менее приемлемо) и обратно (что уже совсем изврат)?
Если хорошо сделано (как в Smalltalk ) то вполне удобно.
OCaml или LISP ?
От:
Аноним
Дата:
15.02.09 16:05
Оценка:
Может ли кто-нибудь подсказать, что выбрать для реализации библиотеки лексического/синтаксического анализа ?
Важна скорость и удобство.Собственно интересует пока только прототипирование,но если скорость будет приличной можно и остановиться на выборе,по сему важны привязки к C(++) .
Причина выбора этих языков — изучение ФЯ .
Об OCaml слышал — хорошая скорость, жуткий синтаксис.
О LISP слышал много чего хорошего,причём использовать/реализовать можно любую парадигму программирования.Но вот о скорости не нашёл ни чего.Скобки и префиксную запись не считаю проблемой.
Здравствуйте, Аноним, Вы писали:
А>Может ли кто-нибудь подсказать, что выбрать для реализации библиотеки лексического/синтаксического анализа ? А>OCaml или LISP ?
Попробуй F# (OCaml для .NET). Можно программировать как в режиме совместимости с OCaml'ом, так и в более удобном синтаксисе (опция #light). Вместе с компилятором и интерпретатором поставляются утилиты FsLex и FsYacc — генераторы лексических и синтаксических анализаторов.
Здравствуйте, Аноним, Вы писали:
А>Может ли кто-нибудь подсказать, что выбрать для реализации библиотеки лексического/синтаксического анализа ?
Тут вопрос личного предпочтения. Семейства ml и lisp довольно сильно отличаются — так что лучше потратить вечер-другой и бегло ознакомиться с обоими.
А>важны привязки к C(++).
Тут, я полагаю, возможности будут примерно равны. Сам имел дело со связкой chicken scheme и C — ничего сложного.
А>Причина выбора этих языков — изучение ФЯ . А>Об OCaml слышал — хорошая скорость, жуткий синтаксис.
На синтетических тестах ocaml неплох — да. Синтаксис — вполне себе нормальный.
А>О LISP слышал много чего хорошего,причём использовать/реализовать можно любую парадигму программирования.Но вот о скорости не нашёл ни чего.Скобки и префиксную запись не считаю проблемой.
Если цель — ФП, то лучше scheme. Common lisp отличается повышенной императивностью.
По перфомансу cl (например, sbcl) и ocaml близки, а вот scheme серьезно отстает (впрочем, нигде не фигурируют бенчмарки коммерческого компилятора chez — но не думаю, что он кардинально изменит ситуацию).
Здравствуйте, Qbit86, Вы писали:
Q>Попробуй F# (OCaml для .NET). Можно программировать как в режиме совместимости с OCaml'ом, так и в более удобном синтаксисе (опция #light). Вместе с компилятором и интерпретатором поставляются утилиты FsLex и FsYacc — генераторы лексических и синтаксических анализаторов.
Спасибо,но интересуют только реализации в нативный код , лексы и яки тоже не нужны , поскольку хочется "ручками" .
С LISP не понятно как у него со скоростью и с pattern matching'ом , и как бы простота синтаксиса не вышла боком .
Ну и конкретно какой компилятор получше не ясно.Можно и так спросить — "Какова скорость/потребление памяти последних CLISP и SBCL?".
Можно конечно всё попробовать,просто если что-то уж сильно медленно или как-то по другому криво ,то лучше заранее отвергнуть.
Re[2]: OCaml или LISP ?
От:
Аноним
Дата:
15.02.09 16:55
Оценка:
Здравствуйте, Mr.Cat, Вы писали:
MC>Если цель — ФП, то лучше scheme. Common lisp отличается повышенной императивностью.
А как у Common lisp с pattern matching ?
Re: OCaml или LISP ?
От:
Аноним
Дата:
15.02.09 17:07
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Может ли кто-нибудь подсказать, что выбрать для реализации библиотеки лексического/синтаксического анализа ?
ANTLR уже есть. Parsec уже есть. Даже yacc — и тот тридцать лет как есть. Всё есть. Не надо делать N+1-ю библиотеку, пожалуйста.
А>Причина выбора этих языков — изучение ФЯ .
IMHO, не та задача, чтоб ФЯ изучать.
А>Об OCaml слышал — хорошая скорость, жуткий синтаксис.
Зря. Хороший синтаксис, уж всяко лучше чем фигурные скобки.
А>О LISP слышал много чего хорошего,причём использовать/реализовать можно любую парадигму программирования.Но вот о скорости не нашёл ни чего.Скобки и префиксную запись не считаю проблемой.
Здравствуйте, Аноним, Вы писали: А>А как у Common lisp с pattern matching ?
Хз, я cl особо не знаю. В стандарте матчинга, насколько я помню, нет, но вроде есть отдельные либы (в scheme ровным счетом такая же ситуация) — ибо матчинг вполне посильная задача для макросов.
Re[2]: OCaml или LISP ?
От:
Аноним
Дата:
15.02.09 17:18
Оценка:
Здравствуйте, Аноним, Вы писали: А> ANTLR уже есть. Parsec уже есть. Даже yacc — и тот тридцать лет как есть. Всё есть. Не надо делать N+1-ю библиотеку, пожалуйста.
Интересует теория синтаксического анализа,автоматы и т.д. и т.п. .Просто интересует.Посему не интересуют,сторонние решения.Хотя если что то остановил бы выбор на Coco/R(хвалят).
А>>Причина выбора этих языков — изучение ФЯ . А> IMHO, не та задача, чтоб ФЯ изучать.
Хочу убить двух зайцев.А какую задачку посоветуете вы?
Помоему "сопоставление с образцом" это самое оно,хотя наверное частично и ликвидирует задачку создания собственных автоматов.
Здравствуйте, Аноним, Вы писали: А> ANTLR уже есть. Parsec уже есть. Даже yacc — и тот тридцать лет как есть. Всё есть. Не надо делать N+1-ю библиотеку, пожалуйста.
Здравствуйте, Аноним, Вы писали:
А>Синтаксически мне он понравился после беглого прочтения статьи на этом сайте,но насколько я понял со скоростью у него не очень
Хз. На синтетике вполне неплох. http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ghc&lang2=ocaml&box=1
А>,плюс подводные камни ленивости,монады — ваще чёто не понятное.Думаю для начала это будет слишком круто.
При желании на практическом уровне это все можно довольно быстро освоить.
MC>>Кстати, можете и haskell попробовать.
А>Синтаксически мне он понравился после беглого прочтения статьи на этом сайте,но насколько я понял со скоростью у него не очень,плюс подводные камни ленивости,монады — ваще чёто не понятное.Думаю для начала это будет слишком круто.
The design patterns of Brian Hurt circa 2008 are radically different than the design patterns of Brian Hurt circa 2003. For example, were I to redo extlib now, it’s be purely applicative, heavily functorized, lots of monads, and a fair bit of lazy evaluation, as opposed to the code I wrote in 2003.
Brian Hurt — это автор, опытный программист на ОКамле.
Переводим с расшифровкой: чем опытней программист на Камле, тем ближе его код к коду программиста на Хаскеле. Даже неопытного, выучившего только монады.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: OCaml или LISP ?
От:
Аноним
Дата:
15.02.09 19:24
Оценка:
Здравствуйте, Аноним, Вы писали:
А>> ANTLR уже есть. Parsec уже есть. Даже yacc — и тот тридцать лет как есть. Всё есть. Не надо делать N+1-ю библиотеку, пожалуйста.
А>Интересует теория синтаксического анализа,автоматы и т.д. и т.п. .Просто интересует.
Если автоматы — то это или внешний генератор, или метапрограммирование (то есть, Лисп). Если PEGи или recursive descent — тогда и функциональщина сгодится. Сейчас в моде Packrat, а он вообще по природе своей сугубо императивен.
А>>>Причина выбора этих языков — изучение ФЯ . А>> IMHO, не та задача, чтоб ФЯ изучать. А>Хочу убить двух зайцев.А какую задачку посоветуете вы?
Компилятор какого либо языка написать, например.
А>Помоему "сопоставление с образцом" это самое оно,хотя наверное частично и ликвидирует задачку создания собственных автоматов.
Здравствуйте, Qbit86, Вы писали: Q>Кроме того, в статье перечислены чуть менее чем все существующие в мире программисты на Хаскеле, так что требуемое можно было умозаключить простым исключением.
T>>На фотографии под штангой — я. Ну, чтобы ты знал, если что. Q>В этом никто и не сомневался, Сергей, потому что ты настолько часто упоминал свою штангу в аргументации, что решительно каждый узнает её в лицо.
Сколько раз я её упоминал?
Здесь, на RSDN. И где угодно ещё.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: OCaml или LISP ?
От:
Аноним
Дата:
15.02.09 19:48
Оценка:
Здравствуйте, thesz, Вы писали:
T>Ещё лучше, конечно, Хаскель, но я и так уже прослыл его рекламным агентом. Поэтому от описания совершенного изящного синтаксиса Хаскеля, его выразительнейшей системы типов с типами классов и возможностью более точно выражать инварианты с помощью GADT, великолепного REPL, удивительно эффективного и мощного компилятора, а также уникального в своём роде ленивого порядка вычислений, что заставит тебя сильнее всего почувствовать всю мощь функционального программирования, я воздержусь. T>Я воздержусь от описания всех этих невероятно полезных вещей и даже не буду намекать на выгоду от их использования. T>Да я вообще о них не буду упоминать. T>Вот.
Уломали)
Поставил GHC.Купился исключительно из-за синтаксиса,больно нравится.Производительность вроде схожая с Ocaml в синтетических тестах.
Будем смотреть.
Всем спасибо за советы.
T>>Да я вообще о них не буду упоминать. T>>Вот. А>Уломали) А>Поставил GHC.Купился исключительно из-за синтаксиса,больно нравится.Производительность вроде схожая с Ocaml в синтетических тестах. А>Будем смотреть. А>Всем спасибо за советы.
Прошу высокое жюри учесть, что я вообще не делал попыток хоть как-то рекламировать Хаскель.
Ну, если что, спрашивай.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
I cannot emphasize this enough. GHC takes 2-3-4 minutes to rebuild my project whenever I touch the parser. Ocaml takes 1-2-3 seconds. I use a 2Ghz Core Duo MacBook Pro and Topdog is decidedly not a large project which makes the difference all the more glaring. With Haskell I was loath to touch the parser or my syntax tree definition, with OCaml I look forward to tweaking things to my hearts content. Normal recompilation time of Topdog is so far as to be almost unnoticeable.
Интересно неужели за два года GHC смог ускорится на порядок.
Здравствуйте, Rtveliashvili Denys, Вы писали:
FR>>Интересно неужели за два года GHC смог ускорится на порядок.
RD>Тут про сборку написано а не про время работы собранного софта. Так что все логично и GHC не ускорялся.
Да что-то меня прерклинило
RD>А воообще-то 2-4 минуты на сборку это нехило. И легко объясняет приверженность REPLу. Т.к. "на безрыбье и рак — рыба".
T>>Ещё лучше, конечно, Хаскель, но я и так уже прослыл его рекламным агентом. Поэтому от описания совершенного изящного синтаксиса Хаскеля, его выразительнейшей системы типов с типами классов и возможностью более точно выражать инварианты с помощью GADT, великолепного REPL, удивительно эффективного и мощного компилятора, а также уникального в своём роде ленивого порядка вычислений, что заставит тебя сильнее всего почувствовать всю мощь функционального программирования, я воздержусь. RD>Ну если REPL — образец великолепия... Впрочем, я достаточно либерален и спокойно отношусть к мазохизму. Это ж надо, ловить кайф от того, что софтина пишется в одном месте (скажем, в текстовом редакторе), а проверка типов, разного рода экспериментирование и т.д. — в другом (REPL). RD>Конечно, реализовать REPL проще чем приличный IDE где все то же самое было бы прямо в редактируемом модуле. Кстати, нечто подобное Common LISPеры сделали в своем Slime. Для языков типа Haskell это было бы еще удобнее. Но "Emacs это наше все" и нет света в конце тоннеля. Разве что может Leksah?
Сразу после проверки типов ты проверяешь функциональность. И это нормально,
RD>GADT это сила, сомнений нет. Одна из тех вещей, что подчеркивают убожество языков типа Java. Вот только разве нет их в том же Ocaml? В хаскель, конечно, через GADT все делается. Прямо как в одном бородатом анекдоте. Даже records. И никого не смущает ни мусор из-за валяющихся под ногами функций доступа к полям, ни бредовый синтаксис этих самых records, ни прочие прелести. Впрочем, тут я преувеличиваю. Были какие-то предложения это исправить, но воз и ныне там.
Синтаксис записей наилучший из возможных в чистом функциональном языке.
RD>Изящество синтаксиса. Хочешь передать функции foo пару отрицательных чисел — будь добр обернуть их в скобки. RD> foo (-1) (-2) RD>Сравниваем с LISP: RD> (foo -1 -2)
Бляха муха!
Я понял, отчего у меня программа-то такая большая! У меня на 2500 строк кода есть строка с отрицательными числами!
Вот она, зараза:
noPos = Pos "<artifical position>" (-1) (-1)
RD> RD>Да, конечно это не часто нужно. Но я что слышал это имено в LISP сильно много скобок.
Перехожу на Liskell или как его там. Сегодня же.
RD>Система типов. Да, typeclassы это хорошо. Действительно удобная штука. Вот только почему-то в стандартных библиотеках начхать всем на них. Вот что мешало сделать штуки типа "null", "empty", "singleton" методами абстрактных TypeClass'ов? А так импортнешь IntSet и Seq и сразу же каша получается.
Дело в том, что они не обобщаются. Map.singleton /= Set.singleton. Твои проблемы, однако, решаются использованием import Data.Map qualified as Map — замени Data.Map на Data.IntMap и разницы не заметишь.
RD>Вещи типа unzip7, наверное, тоже следствие выразительности системы типов. Функций с переменным числом агрументов в haskell не осилили?
Как ты им тип будешь задавать?
Но если ты хочешь, есть вариант.
RD>Но особенно радует runtime. Если ни дай Бог программа съест много памяти — бах, и лежит труп с out of memory. Понять, из-за чего она сдохла почти не реально. Тем более, что она вся такая модная и ленивая и на такие мелочи как нормальный мониторинг потребления ресурсов и экономное расходование памяти не отвлекается. Да, я в курсе что есть такая штука как нагрузочное тестирование. Вот только лишь для самых простых случаев это потребление памяти можно им надежно отследить. На все остальное самый действенный способ — неистовая молитва.
Программист только тогда по настоящему программировал на ЯП, когда он профилировал свои программы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>Grown up check failed for not following the discussion in time. T>>>Plase, try again later. Q>>Засчитан. FR>Думаю из этой беседы будут сделаны правильные выводы и выбран Ocaml
Ты прав.
Нафиг Лискель, перехожу на ОКамл.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>Сразу после проверки типов ты проверяешь функциональность. И это нормально,
Да, конечно это нормально. Просто если пользуешься REPL то это зверски неудобно. Разве Вам не кажется, что проще делать это прямо в IDE и не возиться с постоянным перебрасыванием кода в REPL (что еще более-менее приемлемо) и обратно (что уже совсем изврат)?
В упомянутом мной Slime это делается на раз. Пишешь код, жмешь shortcut и он выполнился. Результат выполнения виден. Не нравится — подправил, проверил снова. А из REPL вытащить когда-то определенную там ф-цию или структуру почти невозможно.
Но все это проблема не языка, конечно, а его инфраструктуры.
T>Бляха муха!
T>Я понял, отчего у меня программа-то такая большая! У меня на 2500 строк кода есть строка с отрицательными числами!
T>Вот она, зараза: T>
T>noPos = Pos "<artifical position>" (-1) (-1)
T>
Я думал заметят, что это — шутка... Ладно, шутить не буду.
T>Дело в том, что они не обобщаются. Map.singleton /= Set.singleton. Твои проблемы, однако, решаются использованием import Data.Map qualified as Map — замени Data.Map на Data.IntMap и разницы не заметишь.
Точно никак не обобщаются? Я допускаю, что может быть какая-то суровая причина на то. Особенно в случае с Map. Но глядя на singleton в Seq и Set я вижу следующие типы:
a -> Set a
a -> Seq a
Неужели type inference в haskell не просечет что если я делаю singleton "1" и дальше пользуюсь им как Set, то я использую singleton из Set а не из Seq? Особенно, если есть некий typeclass Singletonable с этим методом и Set с Seq являются частными случаями.
RD>>Вещи типа unzip7, наверное, тоже следствие выразительности системы типов. Функций с переменным числом агрументов в haskell не осилили?
T>Как ты им тип будешь задавать?
"Не осилили ф-ций с переменным числом аргументов" в данном случае значит само описание типа функций предполагает что число аргументов фиксировано. Думаю, на это есть какая-то причина. Например, что если это число не фиксировано, то type inference работать не будет.
T>Но если ты хочешь, есть вариант.
О! Спасибо за ссылку. Будет интересно почитать.
T>Программист только тогда по настоящему программировал на ЯП, когда он профилировал свои программы.
Как я уже говорил, профилирование не всегда спасает. Если софт достаточно сложный, то можно просто не догадаться о каком-то случае, где пойдет резкий рост потребления ресурсов. Преставьте себе, что речь идет не о программе в 100-1000 строк написанной одним человеком а скажем о софте в 100K, который писали человек 20.
Кроме того, если софт уже работает в продакшн, то желательно иметь возможность следить за тем, сколько он уже отъел. Хотя бы чтобы не произошло неожиданной беды. В Java для мониторинга есть JMX. А есть ли для хаскеля нормальные средства мониторинга? Лично я не видел ни разу. Что весьма прискорбно.
Обратно же, если у софта out of memory, то желательно чтобы сдохла не более чем одна нить, и было ясно где она умерла. Но этого, насколько я понимаю, от GHC добиться не получится.
Аноним 538 пишет:
> Важна скорость и удобство.Собственно интересует пока только > прототипирование,но если скорость будет приличной можно и остановиться > на выборе,по сему важны привязки к C(++) .
На сколько я знаю, вызов лиспового кода из С(++) — проблемы
большие (наоборот — легко, как правило). Т.е. вполне возможно
придётся использовать всякие IPC, доступные с двух сторон.
> О LISP слышал много чего хорошего,причём использовать/реализовать можно > любую парадигму программирования.Но вот о скорости не нашёл ни > чего.
Естественно, как напишешь, и какую реализацию возмёшь (есть компиляторы,
есть даже может быть, если остались, голые интерпретаторы, есть и
a la Java virtual machine.
но в некоторых случаях она достигает С-шную.
Т.е. быстро.
T>>Сразу после проверки типов ты проверяешь функциональность. И это нормально, RD>Да, конечно это нормально. Просто если пользуешься REPL то это зверски неудобно. Разве Вам не кажется, что проще делать это прямо в IDE и не возиться с постоянным перебрасыванием кода в REPL (что еще более-менее приемлемо) и обратно (что уже совсем изврат)?
Я код не бросаю туда-сюда. Я только проверяю, что типы, что выполнение.
T>>GADT в OCaml нет. RD>Убедили, GADT похоже действительно нет в OCaml.
OCaml отстаёт от привычного объёма инструментов лет на десять, по-моему.
T>>Я понял, отчего у меня программа-то такая большая! У меня на 2500 строк кода есть строка с отрицательными числами! T>>Вот она, зараза: T>>
RD>Я думал заметят, что это — шутка... Ладно, шутить не буду.
Мне стало интересно, как часто это встречается. Вот и поделился результатом.
T>>Дело в том, что они не обобщаются. Map.singleton /= Set.singleton. Твои проблемы, однако, решаются использованием import Data.Map qualified as Map — замени Data.Map на Data.IntMap и разницы не заметишь. RD>Точно никак не обобщаются? Я допускаю, что может быть какая-то суровая причина на то. Особенно в случае с Map. Но глядя на singleton в Seq и Set я вижу следующие типы: RD>a -> Set a RD>a -> Seq a RD>Неужели type inference в haskell не просечет что если я делаю singleton "1" и дальше пользуюсь им как Set, то я использую singleton из Set а не из Seq? Особенно, если есть некий typeclass Singletonable с этим методом и Set с Seq являются частными случаями.
Это, по-моему, тоже редко встречающаяся проблема. Усложнять из-за неё компилятор, делая неразрывно связанными этапы анализа окружения и вывода типов, не стоит. По-моему, конечно.
T>>Программист только тогда по настоящему программировал на ЯП, когда он профилировал свои программы. RD>Как я уже говорил, профилирование не всегда спасает. Если софт достаточно сложный, то можно просто не догадаться о каком-то случае, где пойдет резкий рост потребления ресурсов. Преставьте себе, что речь идет не о программе в 100-1000 строк написанной одним человеком а скажем о софте в 100K, который писали человек 20. RD>Кроме того, если софт уже работает в продакшн, то желательно иметь возможность следить за тем, сколько он уже отъел. Хотя бы чтобы не произошло неожиданной беды. В Java для мониторинга есть JMX. А есть ли для хаскеля нормальные средства мониторинга? Лично я не видел ни разу. Что весьма прискорбно. RD>Обратно же, если у софта out of memory, то желательно чтобы сдохла не более чем одна нить, и было ясно где она умерла. Но этого, насколько я понимаю, от GHC добиться не получится.
Тут я спорить не стану.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
RD>>В упомянутом мной Slime это делается на раз. Пишешь код, жмешь shortcut и он выполнился. Результат выполнения виден. Не нравится — подправил, проверил снова. А из REPL вытащить когда-то определенную там ф-цию или структуру почти невозможно.
L>Так это тот же REPL, разве нет?
Нет, это совсем не REPL (хотя Slime включает его, наверное для ценителей антиквара).
REPL = Read-Eval-Print Loop
Т.е. ввел выражение, оно выполнилось, распечаталось. И пошло по новой. Это то, что наблюдается в GHCi и по моему скромному мнению оно ну просто никак не может претендовать на образец удобства и совершенства.
Однажды введенное выражение уже не так просто вытащить из repl и поместить в модуль. Можно, но зверски неудобно.
Slime чуть более удобен. В нем редактируется непосредственно код. И можно делать как минимум следующее:
1. Выполнить любой фрагмент кода и посмотреть результат выполнения.
2. Развернуть любой макрос.
3. Посмотреть на ассемблерный вариант функции.
4. Легко перейти к определению любой ф-ции или переменной.
Вот подобный инструмент для хаскеля не помешал бы. Вместо LISP-специфичных штучек типа разворачивания макросов можно было бы сделать:
1. Тип выражения, на котором находится курсор.
2. Значение выражения, на котором находится курсор (конечно, если его легко отобразить).
Кстати, я как-то видел плагин для Eclipse что часть этих вещей делает для Ocaml. Для Haskell с его функциональной чистотой это должно быть особенно легко.
L>Ещё — про haskell-mode для Emacs или для vim знаете?
Конечно. Но по-моему это тихий ужас.
Пытался пользоваться haskell-mode. Впечатления:
1. Autoindent есть, но выбирает он, как правило, наименее разумную позицию.
2. Нормальный autocomplete отсутствует.
3. Отображение ошибок отсутствует.
4. Навигация по коду отсутсвует.
Вывод — почти что notepad.
RD>>Точно никак не обобщаются? Я допускаю, что может быть какая-то суровая причина на то. Особенно в случае с Map. Но глядя на singleton в Seq и Set я вижу следующие типы:
L>Можно сделать Set монадой, тогда это будет простой return. И вообще — это проблема библиотек L>Такие проблемы есть, да. Слишком большой Num, например. Или то, что Bool — не класс типов.
RD>>"Не осилили ф-ций с переменным числом аргументов" в данном случае значит само описание типа функций предполагает что число аргументов фиксировано. Думаю, на это есть какая-то причина. Например, что если это число не фиксировано, то type inference работать не будет.
L>Ну, printf же как то работает.
L>Там всё просто на самом деле
L>
L>class Glue g where
L> glue :: String -> g
L>instance Glue String where
L> glue = id
L>instance Glue g => Glue (String -> g) where
L> glue s1 = \s2 -> glue (s1 ++ s2)
L>
L>И затем просто
L>
L>main = putStrLn $ glue
L> "В пустыне чахлой и скупой,\n"
L> "На почве, зноем раскаленной,\n"
L> "Анчар, как грозный часовой,\n"
L> "Стоит - один во всей вселенной.\n"
L>
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>Однажды введенное выражение уже не так просто вытащить из repl и поместить в модуль. Можно, но зверски неудобно.
Э... Как так? Мышкой выделил, средней кнопкой вставил, если отдельные окна, а если в редакторе, например, в vim, то можно yank/paste средствами vim.
RD>1. Выполнить любой фрагмент кода и посмотреть результат выполнения.
:GHCi
RD>2. Развернуть любой макрос.
RD>3. Посмотреть на ассемблерный вариант функции.
Не знаю, навряд ли.
RD>4. Легко перейти к определению любой ф-ции или переменной.
Да. Например, по тагам. В emacs это ещё удобнее.
RD>Вот подобный инструмент для хаскеля не помешал бы. Вместо LISP-специфичных штучек типа разворачивания макросов можно было бы сделать: RD>1. Тип выражения, на котором находится курсор.
Есть. _t. _T вставляет тип функции.
RD>2. Значение выражения, на котором находится курсор (конечно, если его легко отобразить).
Не знаю, как это сделать удобно, но сделать это вообще совсем несложно — та же команда :GHCi
RD>Пытался пользоваться haskell-mode. Впечатления:
RD>1. Autoindent есть, но выбирает он, как правило, наименее разумную позицию.
Если про Emacs, то да — поначалу расстраивает. Потом привыкаешь
В vim он проще, возможно, удобнее.
RD>2. Нормальный autocomplete отсутствует.
Э? Да там этих автокомплишнов несколько штук. Пример можно?
RD>3. Отображение ошибок отсутствует.
Как это? а quickfix окошко чем не устраивает?
RD>4. Навигация по коду отсутсвует.
Опять таки — таги для идентификаторов, также бегает по файлам (import Blah — стать на Blah, нажать gf).
Или какой то пример, чего не может?
RD>Вывод — почти что notepad.
Ну, чуть более чем Там очень много удобного, на самом деле — haddock, hpaste, помимо этого есть куча других плагинов для Хаскель.
Здравствуйте, MasterZiv, Вы писали: MZ>Да ну, уже. Ни то, ни другое — не строгий функц. язык.
Как это не строгий? Может, "не чистый"?
MZ>Ну и как ты оцениваешь "повышенную императивность" ?
Например, негарантированная хвостовая рекурсия заставляет использовать циклы, там, где с точки зрения ФЯ должна быть рекурсия.
RD>>А воообще-то 2-4 минуты на сборку это нехило. И легко объясняет приверженность REPLу. Т.к. "на безрыбье и рак — рыба". FR>Ну после C++ 5 минут вполне нормально
Любопытно смотрится болтовня пикейных жилетов. Да, GHC — достаточно тормозной, но со времен написания поста Джоэла скрость *компиляции* выросла чуть ли не на порядок.
RD>>Однажды введенное выражение уже не так просто вытащить из repl и поместить в модуль. Можно, но зверски неудобно.
L>Э... Как так? Мышкой выделил, средней кнопкой вставил, если отдельные окна, а если в редакторе, например, в vim, то можно yank/paste средствами vim.
Вот-вот. Вместо того, чтобы не делать вообще ничего (т.к. код УЖЕ находится в тексте программы), приходится рыскать по истории команд в ghci и копировать это счастье. Чем не обезьянья работа.
RD>>1. Выполнить любой фрагмент кода и посмотреть результат выполнения.
L>:GHCi
Не понял. Предлагается запустить ghci командой из VIM и в нем все выполнить? Спасибо, но как по мне, то нажать один шорткат проще.
RD>>4. Легко перейти к определению любой ф-ции или переменной.
L>Да. Например, по тагам. В emacs это ещё удобнее.
Да неужели..? Может я чего-то упустил, но всегда мне казалось что таги это костыль. Их надо генерить, а значит они в процессе разработки быстро устаревают.
Нормальные средства разработки вообще-то парсят код и хранят в себе актуальные позиции определений. И не только их...
RD>>Вот подобный инструмент для хаскеля не помешал бы. Вместо LISP-специфичных штучек типа разворачивания макросов можно было бы сделать: RD>>1. Тип выражения, на котором находится курсор.
L>Есть. _t. _T вставляет тип функции.
В смысле вставляет? Не надо никуда ничего вставлять. Надо просто взять и показать. Причем желательно так: подводишь курсор к выражению (или выделяешь его) и сразу же видишь и тип и (возможно) значение. Это называется "эргономика".
Я готов даже на вариант-минимум a-la Slime: там по шорткату тип функции показывается в status bar'е.
RD>>2. Значение выражения, на котором находится курсор (конечно, если его легко отобразить).
L>Не знаю, как это сделать удобно, но сделать это вообще совсем несложно — та же команда :GHCi
Все еще не понимаю к чему Вы клоните. :-) Не нужна команда. Надо чтобы было по-нормальному и с минимумом телодвижений. А монумент из кучи тулов и скриптов лишь для того чтобы сделать иллюзию чего-то полезного моей душе принять сложно.
RD>>Пытался пользоваться haskell-mode. Впечатления:
RD>>1. Autoindent есть, но выбирает он, как правило, наименее разумную позицию.
L>Если про Emacs, то да — поначалу расстраивает. Потом привыкаешь :))
Я долго пытался привыкнуть. Решил что лучше вообще без него и в конце-концов перебрался под EclipseFP.
L>В vim он проще, возможно, удобнее.
Возможно. Я не видел, наверное стоит глянуть.
RD>>2. Нормальный autocomplete отсутствует.
L>Э? Да там этих автокомплишнов несколько штук. Пример можно?
Не существует "несколько штук" "нормальных автокомлитов". Это как с добрым, мудрым и вечным. Говорят, все три характеристики вместе не уживаются.
Есть только ОДИН нормальный автокомплит и его ни в одном редакторе для хаскеля я не видел.
Нормальный автокомплит должен:
1. Понимать, что именно находится в области видимости, включая импортированные определения, top-level определения, определения внутри текущей ф-ции и т.д. В общем, надеюсь ясно.
2. Должен ясно понимать систему типов и предлагать только то, что имеет смысл. Если я уже написал foo и у нее тип foo :: Int -> String, то нечего мне предлагать переменные типа Bool.
3. (Особое пожелание) Если написан идентификатор, который не находится в области видимости, но есть среди библиотек (или пользователь пишет import My.Mega.Li..) то autocomplete должен сказать что есть варианты из еще неимпортированных библиотек и автоматически импортнуть когда вариант будет выбран.
А пока что лучшее что я видел — выбор из top-level определений, причем слепой. Еще есть совсем убогий вариант: автокомплит по всем словам что есть в файле. Ну прямо детский сад, ясельная группа. :(
RD>>3. Отображение ошибок отсутствует.
L>Как это? а quickfix окошко чем не устраивает?
Не видел я этот quickfix но попробую догадаться. Надо дать какую-то команду на то, чтобы запустить сборку. И когда она завалится, то будет окошко со списком ошибок и возможностью перейти к нужной строке. Так?
По нормальному это делается так: IDE автоматически проверяет код на ошибки в то время как этот код пишут. И даже не надо запускать билд. Конечно, это надо напрячься и воспользоваться GHC API, но может кто-то на это сподвигнется.
RD>>4. Навигация по коду отсутсвует.
L>Опять таки — таги для идентификаторов, также бегает по файлам (import Blah — стать на Blah, нажать gf). L>Или какой то пример, чего не может?
Насчет тагов — см. выше.
RD>>Вывод — почти что notepad.
L>Ну, чуть более чем :) Там очень много удобного, на самом деле — haddock, hpaste, помимо этого есть куча других плагинов для Хаскель.
Я понимаю, что много чего есть. Но не покидает меня ощущение такой зверской необустроенности. Приблизительно как если из солидной мастерской попадаешь в запущенный сарай. Вроде и инструмент есть неплохой, и почти то же самое сделать можно.. Но надо и пыль повытирать, и навести порядок, и найти болты нужного размера, которых крысы утащили по норам.
Единственное что радует, это что хаскель стает более популярным и может быть ситуация со временем улучшится. Но как говорится, "блажен кто верует".
L>В общем, да. Set нельзя сделать монадой, т.к. у множества ограничение на тип-параметр (Ord a).
L>Поэтому и синглтонами тоже нельзя сделать — типы отличаются — в одном случае a -> Seq a, в другом (Ord a) => a -> Set a.
Я наивно думал, что можно сделать что-то типа такого:
class Singletonable a where
singleton :: a -> Singletonable a
class (Singletonable a) => Seq a where
singleton :: a -> Seq a
class (Singletonable a, Ord a) => Set a where
singleton :: a -> Set a
Ну или типа того. В общем, Set — это тоже Singletonable и singleton ему не чужд, но ограничений чуть больше, потому что "a" должно быть еще и Ord.
Здравствуйте, awson, Вы писали:
A>Любопытно смотрится болтовня пикейных жилетов. Да, GHC — достаточно тормозной, но со времен написания поста Джоэла скрость *компиляции* выросла чуть ли не на порядок.
Даже на малюсеньких примерах которые я компилирую хаскель (последняя версия) намного тормозней Ocaml'а
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>Ну или типа того. В общем, Set — это тоже Singletonable и singleton ему не чужд, но ограничений чуть больше, потому что "a" должно быть еще и Ord.
Стоп! Set — это тип или класс? Я думал, речь идёт о типе.
class Singletonable s where
singleton :: a -> s a
instance Singletonable Seq where
singleton = Seq.singleton
instance Singletonable Set where
singleton = Set.singleton
Но, в общем, Вы правы, его действительно можно сделать синглтоном.
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>>>1. Выполнить любой фрагмент кода и посмотреть результат выполнения.
L>>:GHCi RD>Не понял. Предлагается запустить ghci командой из VIM и в нем все выполнить? Спасибо, но как по мне, то нажать один шорткат проще.
Нет, это команда, вяжешь к ней шоткат, жмёшь и видишь результат в статусе.
RD>>>4. Легко перейти к определению любой ф-ции или переменной.
RD>Да неужели..? Может я чего-то упустил, но всегда мне казалось что таги это костыль. Их надо генерить, а значит они в процессе разработки быстро устаревают.
Да фигли их там генерить, на сохранение, например.
RD>В смысле вставляет? Не надо никуда ничего вставлять. Надо просто взять и показать. Причем желательно так: подводишь курсор к выражению (или выделяешь его) и сразу же видишь и тип и (возможно) значение. Это называется "эргономика". RD>Я готов даже на вариант-минимум a-la Slime: там по шорткату тип функции показывается в status bar'е.
Ну так я же говорю — _t показывает, а _T вставляет тип.
RD>>>2. Значение выражения, на котором находится курсор (конечно, если его легко отобразить). L>>Не знаю, как это сделать удобно, но сделать это вообще совсем несложно — та же команда :GHCi
RD>Все еще не понимаю к чему Вы клоните. Не нужна команда. Надо чтобы было по-нормальному и с минимумом телодвижений. А монумент из кучи тулов и скриптов лишь для того чтобы сделать иллюзию чего-то полезного моей душе принять сложно.
Э... Ни к чему я не клоню. Есть команда, на неё можно повестить шоткат.
RD>>>Пытался пользоваться haskell-mode. Впечатления:
RD>>>1. Autoindent есть, но выбирает он, как правило, наименее разумную позицию. L>>Если про Emacs, то да — поначалу расстраивает. Потом привыкаешь RD>Я долго пытался привыкнуть. Решил что лучше вообще без него и в конце-концов перебрался под EclipseFP.
Кому как, мне удобный редактор важнее.
RD>>>2. Нормальный autocomplete отсутствует. L>>Э? Да там этих автокомплишнов несколько штук. Пример можно? RD>Не существует "несколько штук" "нормальных автокомлитов". Это как с добрым, мудрым и вечным. Говорят, все три характеристики вместе не уживаются.
RD>Есть только ОДИН нормальный автокомплит и его ни в одном редакторе для хаскеля я не видел. RD>Нормальный автокомплит должен: RD>1. Понимать, что именно находится в области видимости, включая импортированные определения, top-level определения, определения внутри текущей ф-ции и т.д. В общем, надеюсь ясно.
omnicompletion
RD>2. Должен ясно понимать систему типов и предлагать только то, что имеет смысл. Если я уже написал foo и у нее тип foo :: Int -> String, то нечего мне предлагать переменные типа Bool.
Этого, вроде, нет.
RD>3. (Особое пожелание) Если написан идентификатор, который не находится в области видимости, но есть среди библиотек (или пользователь пишет import My.Mega.Li..) то autocomplete должен сказать что есть варианты из еще неимпортированных библиотек и автоматически импортнуть когда вариант будет выбран.
Это есть.
RD>А пока что лучшее что я видел — выбор из top-level определений, причем слепой. Еще есть совсем убогий вариант: автокомплит по всем словам что есть в файле. Ну прямо детский сад, ясельная группа.
Такой тоже есть.
RD>>>3. Отображение ошибок отсутствует. L>>Как это? а quickfix окошко чем не устраивает? RD>Не видел я этот quickfix но попробую догадаться. Надо дать какую-то команду на то, чтобы запустить сборку. И когда она завалится, то будет окошко со списком ошибок и возможностью перейти к нужной строке. Так?
Да.
RD>По нормальному это делается так: IDE автоматически проверяет код на ошибки в то время как этот код пишут. И даже не надо запускать билд. Конечно, это надо напрячься и воспользоваться GHC API, но может кто-то на это сподвигнется.
Может.
RD>>>4. Навигация по коду отсутсвует.
L>>Опять таки — таги для идентификаторов, также бегает по файлам (import Blah — стать на Blah, нажать gf). L>>Или какой то пример, чего не может? RD>Насчет тагов — см. выше.
Ну тогда нечестно говорить, что навигация отсутствует — это вводит незнающих в заблуждение. Навигация есть, через таги.
RD>Я понимаю, что много чего есть. Но не покидает меня ощущение такой зверской необустроенности. Приблизительно как если из солидной мастерской попадаешь в запущенный сарай. Вроде и инструмент есть неплохой, и почти то же самое сделать можно.. Но надо и пыль повытирать, и навести порядок, и найти болты нужного размера, которых крысы утащили по норам.
Инструментарий у каждого свой. Вещь всё таки больше субъективная. Мне вот для написания программы важнее удобный редактор.
RD>Единственное что радует, это что хаскель стает более популярным и может быть ситуация со временем улучшится. Но как говорится, "блажен кто верует".
Да надо на Yi глянуть, когда последний раз смотрел, он был не очень.
Здравствуйте, Mr.Cat, Вы писали:
L>>Но, в общем, Вы правы, его действительно можно сделать синглтоном. MC>А надо ли? Этож для каждой функции тип вводить?
Ну, для Set это не имеет значения, но для некоторых типов (функторов) singleton есть функция pure, она же return. А это уже имеет значение, 'a -> f a' есть f-коалгебра (правда, очень специфичная). Значит мы можем использовать её, например, во всяких анаморфизмах.
A>>Любопытно смотрится болтовня пикейных жилетов. Да, GHC — достаточно тормозной, но со времен написания поста Джоэла скрость *компиляции* выросла чуть ли не на порядок.
FR>Даже на малюсеньких примерах которые я компилирую хаскель (последняя версия) намного тормозней Ocaml'а
Да.
Окамл справляется с компиляцией практически мгновенно.
Правда, я подозреваю, что у меня какая-то хакнутая версия ocaml. Она, почему-то, выдаёт странное приветствие:
'ocaml' is not recognized as an internal or external command,
operable program or batch file.
Тут что-то не то.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
A>>Любопытно смотрится болтовня пикейных жилетов. Да, GHC — достаточно тормозной, но со времен написания поста Джоэла скрость *компиляции* выросла чуть ли не на порядок. FR>Даже на малюсеньких примерах которые я компилирую хаскель (последняя версия) намного тормозней Ocaml'а
Если чуть серьёзней, то я больше рад улучшениям в системе типов и семантике, чем скорости компиляции.
(я не использовал guards, поскольку они не проваливались в другую ветвь сравнения с образцом. в районе введения pattern guards это дело исправили.)
К тому же, улучшение семантики ведёт к увеличению скорости. Косвенно, но ведёт.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
MC>Здравствуйте, lomeo, Вы писали: L>>Ну, для Set это не имеет значения, но для некоторых типов (функторов) singleton есть функция pure, она же return. MC>Вот был бы Set монадой... Полагаю, просто разработчик Set'а решил последовать принципу бритвы Оккама для хаскеля: "Не плоди монад сверх необходимого".
Для чего Set должен быть монадой?
Недетерминизм? На списках он лучше.
Для чего ещё?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>слушай, ты рассказываешь о вкусе устриц профессиональному дегустатору
Ну, ты человек публичный, любишь там сям пописать. Я лет 5 читаю все mailing lists, касающиеся Хаскелла, поэтому знаю кому что рассказываю.
BZ>6.8 на моей проге раза в 3 быстрее. без -O большой разницы нет, думаю как раз те самые 10-20%, которые обусловлены улучшением кодогенерации (ghc ведь компилируется сам собой)
И? Если без -O нет большой разницы, а с -O есть, это как-то доказывает теорию об *исключительном влиянии* gcc? Или, может быть, это бага в оптимизаторе, э?
BZ>далее — winhugs загружает прогу раз в 10 быстрее, чем ghci. твоя вера в то, что ленивость (и ещё монады, широко используемые в реализации ghc) замедляют программы всего в 1.5 раза, а не в 10 или к примеру 100 — опять же прелположение из воздуха. реально разница в 1.5-2-3 раза идёт только если написать программу в императивном низкоуровневом стиле, без всякой ленивости и связанных с ней типов данных — списков, к примеру. при написании же в нативном стиле разница достигает сотен раз — смотри к примеру статьи:
Почему "вера"? Ты думаешь, я программ на Хаскелле не писал? Я пишу про качество генерируемого кода в сравнении с окамлом, ты мне про монады и списки. Что такое "нативный" стиль для окамла? Как на окамле обойтись без императивного стиля и без монад одновременно? Ты что с чем сравниваешь?
BZ>Rewriting Haskell Strings [http://www.cse.unsw.edu.au/~dons/papers/fusion.pdf] BZ>An approach to fast arrays in Haskell [http://www.cse.unsw.edu.au/~chak/papers/afp-arrays.ps.gz]
Этим статьям сто лет в обед. Те, кому интересна производительность, давно это все прочитали. Я — в том числе.
Я никак не пойму, чего ты силишься донести до нашего разума? Что *наивный* Хаскелл (пока) не подходит для числодробилок? Да, не подходит. Только дурак будет с этим спорить. Что на С++ можно написать чтоб работало быстрее? Да, можно. Я сам, когда нужна скорость, на C++ пишу. Что-то еще?
Здравствуйте, awson, Вы писали:
BZ>>6.8 на моей проге раза в 3 быстрее. без -O большой разницы нет, думаю как раз те самые 10-20%, которые обусловлены улучшением кодогенерации (ghc ведь компилируется сам собой) A>И? Если без -O нет большой разницы, а с -O есть, это как-то доказывает теорию об *исключительном влиянии* gcc? Или, может быть, это бага в оптимизаторе, э?
не может. в ghc есть ключик, включающий/выключающий использование gcc
BZ>>далее — winhugs загружает прогу раз в 10 быстрее, чем ghci. твоя вера в то, что ленивость (и ещё монады, широко используемые в реализации ghc) замедляют программы всего в 1.5 раза, а не в 10 или к примеру 100 — опять же прелположение из воздуха. реально разница в 1.5-2-3 раза идёт только если написать программу в императивном низкоуровневом стиле, без всякой ленивости и связанных с ней типов данных — списков, к примеру. при написании же в нативном стиле разница достигает сотен раз — смотри к примеру статьи: A>Почему "вера"? Ты думаешь, я программ на Хаскелле не писал? Я пишу про качество генерируемого кода в сравнении с окамлом, ты мне про монады и списки. Что такое "нативный" стиль для окамла? Как на окамле обойтись без императивного стиля и без монад одновременно? Ты что с чем сравниваешь?
на окамле у тебя просто нет удобных монад, поэтому тебе не придёт в голову их использовать как это сделано в ghc. окамл — строгий язык, в нём нет еype classes, а это основные источники замедления haskell. наконец, многоаргументные функции в нём не каррируются — это тоже источник замедления хаскела
BZ>>Rewriting Haskell Strings [http://www.cse.unsw.edu.au/~dons/papers/fusion.pdf] BZ>>An approach to fast arrays in Haskell [http://www.cse.unsw.edu.au/~chak/papers/afp-arrays.ps.gz] A>Этим статьям сто лет в обед. Те, кому интересна производительность, давно это все прочитали. Я — в том числе.
A>Я никак не пойму, чего ты силишься донести до нашего разума? Что *наивный* Хаскелл (пока) не подходит для числодробилок? Да, не подходит. Только дурак будет с этим спорить. Что на С++ можно написать чтоб работало быстрее? Да, можно. Я сам, когда нужна скорость, на C++ пишу. Что-то еще?
а в каком по-твоему стиле ghc написан? тот код, который всего в несколько раз медленней сишного — пишется на низком уровне, и это ещё сложнее чем просто писать на C
ghc же, как и любые джругие программы на хаскеле, написан высокоуровнево, и это означает применение ленивости, монад и всех прочих кунштюков.это и делает его таким медленным в сравнении с хагсом, который реализует сравнимую с ghci функциональность
A>Предмет обсуждения стал расплывчатым и постоянно меняется местами язык и реализация, например, твоя любимая тема что type classes — зло для производительности, поскольку приходится в runtime таскать за собой словари, относится на 90% к существующим имплементациям, а не к Хаскеллу как таковому, да и GHC кое-что умеет optimize away. Поэтому я сформулирую свою позицию более конкретно — подавляющее большинство программ можно написать на идиоматическом Хаскелле (ghc), оставаясь в порядке производительности идиоматического C (gcc), те, что нельзя — лечатся точечными инъекциями C.
Присоединюсь.
Факты (наподобие скорости Language.C, мой опыт) подтверждают эту точку зрения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, FR, Вы писали:
FR>A разве у Хаскеля не одна пригодная для реальной работы реализация?
Для *реальной* работы — одна. Для *микробенчмарков* — не одна.
T>>Дело в том, что они не обобщаются. Map.singleton /= Set.singleton. Твои проблемы, однако, решаются использованием import Data.Map qualified as Map — замени Data.Map на Data.IntMap и разницы не заметишь. RD>Точно никак не обобщаются? Я допускаю, что может быть какая-то суровая причина на то. Особенно в случае с Map. Но глядя на singleton в Seq и Set я вижу следующие типы:
RD>a -> Set a RD>a -> Seq a
RD>Неужели type inference в haskell не просечет что если я делаю singleton "1" и дальше пользуюсь им как Set, то я использую singleton из Set а не из Seq? Особенно, если есть некий typeclass Singletonable с этим методом и Set с Seq являются частными случаями.
Я, собственно, и не предлагал.
