этот вопрос у меня возник после прочтения статьи тонского

Он про лиспы в первую очередь пишет. А там REPL-driven development совсем иначе выглядит

Позднее связывание же

ну я понимаю - я поэтому и спросил

я маленькие функции часто проверяю в репле

и мне очень не хвататет его в других местах

*языках

*языках

вроде во многих есть реплы

в других - это у меня Го, правда я уже на нем не писал совсем месяца 3-4

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

Репл в хаскеле заменяет 80 юзкейзов дебагера в плюсах

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

но вот чтобы здесь и сейчас написать - конечно с реплом быстрее будет

Один из юзкейзов репла: удобно было структурки данных сериализовать на лету, чтобы затем написать бинарный протокол в документации (на случай если захотят люди на других языках реализовать протокол). А сейчас репл используется, чтобы тестировать Servant-овские хэндлеры, выполняющие SQL запросы. Используется protocol-buffers, поэтому непосредственно эндпоинты потестировать какой-нибудь тулой возможности нет, а вот из репла вызвать функции и посмотреть результат вполне можно. Не то, чтобы это было очень удобно (особенно когда надо всякие сессии создать, прежде чем потестировать), но зато хотя бы как-то возможно.

> Используется protocol-buffers, поэтому непосредственно эндпоинты потестировать какой-нибудь тулой возможности нет любопытно

так в аллегро телеграмм работает, а линкедин нет

хотел бы уметь копировать определения в файл и обратно

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

ну мне кажется что это взлетит, но на практике я не прове?рял

елки палки.. откуда тот смайл :/

Или еще пример. Если руководствоваться только практикой и юзкейсами, можно взять и придумать stack, а потом страдать с его снэпшотами. А можно до последнего добиваться нормального солвера и придумать cabal new-build с nix-style storage

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

то есть если у меня B depends on A v1 C depends on A v2 D depends on B, C то не соберётся?

А раньше могло собраться?

не, я про то когда у A одинаковые версии, а вот версии зависимостей разные

А раньше могло собраться?

емнип в самом первом демо http://blog.ezyang.com/2015/08/help-us-beta-test-no-reinstall-cabal/ это работало, а уж в планах точно было

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

да, речь про один билдплан

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

да, я про то же

т.е. в моем примере выше допустим A=bytestring

Я просто впервые слышу, что это убрали

просто я отдельно оговорил случай когда у A версия одна и та же, но у зависимостей разная потому, что до 7.10 гхц не умел так, но новый кабал в те времена мог построить бтилд план для 7.8 с разными байтстрингами но они должны били быть разных версий, а не просто с разными зависимостями

Может и не убрали вообще, но по умолчанию это вроде не работает теперь

возможно где-то можно включить, но я не знаю где

Джентельмены как нужно индентится в вложенных кейсах

otherwise не надо в этом месте писать, надо _

ужас какой

Ахахаха

Я только учусь

вынеси по частям в обозначения в where

if на входе в функцию можно заменить на гварды convertType t v | "int" `isPrefixOf` t || "uint" `isPrefixOf` t = ... | otherwise = ...

if v == "INVALID_ID" лучше будет в виде case v of "INVALID_ID" ->

Понял

Спасибо большое!

после слова case для меток веток нужен отступ, и ещё один для содержимого case (slice 3 4 t) of "64" -> "64" "32" -> "32"

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

хм, а ведь можно было бы добавить pattern Otherwise = True в прелюдию, чтобы новички не наступали на это через одного

otherwise нужен только для гвардов, то есть чтобы последним гвардом можно было написать | otherwise, и это был бы эквивалент else

не, не надо!

матчинг - всегда захват наматченного. А гарды - нет!

не, не надо!

почему?

матчинг - всегда захват наматченного. А гарды - нет!

матчь наматченное!

матчинг - всегда захват наматченного. А гарды - нет!

это противоречит моим словам?

otherwise -> это capture. Кастомный паттерн здесь только "больше синтаксиса" сделает

otherwise -> это capture. Кастомный паттерн здесь только "больше синтаксиса" сделает

окей, -Wall, в принципе, уже спасает от этой ошибки

Не хочешь матчить, делаешь _. Как везде.

Не хочешь матчить, делаешь _. Как везде.

этого новички не знают

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

tail (_:xs) = xs tail otherwise = [] тут то очевидная дичь

Пусть учатся

tail (_:xs) = xs tail otherwise = [] тут то очевидная дичь

для новичка не очевидная

tail (_:xs) = xs tail otherwise = [] тут то очевидная дичь

главное, что в этом примере ещё и работает правильно

Будет ворнинг. И это правильно

ERROR: S client not available

скорее уж убрать otherwise вообще, пусть будет True

Будет ворнинг. И это правильно

по умолчанию не будет. только если специально включить

скорее уж убрать otherwise вообще, пусть будет True

в лиспах ведь так и делают, кстати, и все живы

Нужно учить новичка всегда делать -Wall

А вообще - новичку тоже нужно думать, ибо полезно

в лиспах ведь так и делают, кстати, и все живы

и мы были бы живы

давайте задепрекейтим otherwise!

+1

из за него ещё и раздвигать порой приходится лишнего!

в смысле раздвигать, зачем?

f | x = "Foo" | otherwise = "Bar" фу!

Ну да, зачем так писать-то

funcname | x = "Foo" | otherwise = "Bar"

не, HECPACUBO

Воу! Тут же не стикерят!

?

сорьки

Если не выравниваете = - не выравнивайте нигде! Ни в рекордах, ли в let!

не, HECPACUBO

1. субъективно, мне кажется никаких проблем 2. при ренейминге не надо перевыравнивать

Если не выравниваете = - не выравнивайте нигде! Ни в рекордах, ли в let!

я и не выравниваю нигде, ни в рекордах, ни в let

Вот! Так норм. Консистентненько!

специально еще в том примере | сбросил на следующую строку, чтобы при переименовании функции не перевыравнивать

это да, тоже так делаю

т.е. у меня правило в том, что whitespace исходника инвариантен под переименованием сущностей

(еще я табами предпочитаю индентировать, потому что их на ноуте можно постаивть в 2 пробела, а на десктопе в 4, но в принципе уже привык к пробелам, ко всему можно привыкнуть)

когда в vim или emacs подвезут elastic tabstops (никогда), то можно будет начать всё табами делать

Отсутствие выравнивания и правда помогает уменьшить diff на гите и необходимость перевыравнивать при переименовывании переменных. Но часто выравнивание (лично для меня) помогает зрительно разделить код, и читать становится проще. Но да, ждем elastic tabstops...

Отсутствие выравнивания и правда помогает уменьшить diff на гите и необходимость перевыравнивать при переименовывании переменных. Но часто выравнивание (лично для меня) помогает зрительно разделить код, и читать становится проще. Но да, ждем elastic tabstops...

git diff -w, и нет проблем с диффом