by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    nponeccop
    @nponeccop

    Привет! Тут возник вопрос, почему

    readArray :: (MArray a e m, Ix i) => a i e -> i -> m e

    а не

    readArray :: (MArray a e m, Ix i) => m (a i e -> i -> e)
    Yuriy Syrovetskiy
    @cblp
    кодирование эффектов стрелками Кляйсли a -> m b работает, а второе, скорей всего, нет
    в первой записи очевидно, что эффект m зависит от индекса i на уровне значений, но от типа не зависит
    nponeccop
    @nponeccop
    Можно написать функцию из второго в первое, но не наоборот, то есть второе более универсальное. В качестве причины выбора первого мне приходит в голову только удобство работы с liftA2 и некий дебилизм конструирования чистых функций. Кроме того в первом случае у нас код первого порядка, то есть не содержит ФВП, а во втором содержит.
    Yuriy Syrovetskiy
    @cblp
    более универсальное = менее выразительное?

    написать функцию из второго в первое

    правда? напишите

    nponeccop
    @nponeccop
    более универсальное = имея второй интерфейс можно реализовать первый
    nponeccop
    @nponeccop
    foo :: Monad m => m (a -> b) -> a -> m b
    foo mf a  = do
       f <- mf
       return $ f a
    nponeccop
    @nponeccop

    Для обратного есть контрпример в случае Maybe:

    quux :: (a -> Maybe b) -> Maybe (a -> b)

    Это функция, проверяющая другую функцию на тотальность, чего нельзя сделать из-за того что это эквивалентно задаче останова

    Ну и по более приземлённым причинам нельзя
    nponeccop
    @nponeccop
    (ну и не считая вырожденного случая const Nothing)
    Yuriy Syrovetskiy
    @cblp
    вы в do-нотации неявно использовали (>>=) :: m a -> (a -> m b) -> m b, то есть первую нотацию, так что не считается

    более универсальное = имея второй интерфейс можно реализовать первый

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

    nponeccop
    @nponeccop
    Не, речь не идет о том чтобы полностью заменить везде a -> m b на m (a -> b). Речь конкретно о readArray. Имея монады, то есть композицию и юнит для a -> m b, можно сделать любую из двух сигнатур, см. моё первое сообщение с двумя сигнатурами readArray, но выбрали первую сигнатуру . Вопрос почему. И не поломается ли что-то (например, какие-то инварианты или производительность или удобство) в библиотеке массивов , если использовать второй.
    Yuriy Syrovetskiy
    @cblp
    а, в таком контексте. для конкретной задачи первая сигнатура выглядит проще и удобнее, потому что её можно частично применить в чистом контексте
    по-моему, readArray :: (MArray a e m, Ix i) => m (a i e -> i -> e) вообще невозможно реализовать. некое действие должно сконструировать чистую функцию, которая вернёт e для любого i и любого массива? а если индекс выходит за границы массива?
    ладно, выход за границы, возможно, запрещён по конструкции этим a i e
    но что делать, если в два вызова этой чистой функции подсунуть один массив в разные моменты времени? или детерминированность нарушится, или мы получим не то значение из массива
    Aleksey Danilevsky
    @alexd1971

    Добрый день! Не знаю в какой раздел обратиться, но поскольку я пока в Haskell полный чайник, задам вопрос здесь.
    Пытаюсь следовать описанным quick start шагам, описанным здесь: http://haskell.vacationlabs.com/en/latest/docs/reflex/getting-started.html. Но получаю ошибку при компиляции пакета happy. Пытаюсь установить happy через stack install happy и получаю такое:

    happy> Configuring happy-1.19.5...
    happy> build
    happy> Building happy-1.19.5...
    happy> Preprocessing executable 'happy' for happy-1.19.5...
    happy> setup: The program 'happy' is required but it could not be found

    То есть получается, что установить happy нельзя, потому что не установлен happy. Что я делаю не так?

    Yuriy Syrovetskiy
    @cblp
    собрать happy нельзя, потому что не установлен happy
    хотя у меня собирается свежий happy без готового себя
    попробуйте stack --resolver=lts-14.20 install happy
    Aleksey Danilevsky
    @alexd1971
    Вроде бы так сработало. Спасибо
    Yuriy Syrovetskiy
    @cblp
    значит, у вас в глобальном проекте ~/.stack/global-project/stack.yaml слишком старый резолвер. советую поменять на свежий, например lts-14.20
    Aleksey Danilevsky
    @alexd1971
    А когда я запускаю stack install в каталоге проекта, то он использует какой резолвер? Который прописан глобально или, который прописан в stack.yaml проекта?
    Yuriy Syrovetskiy
    @cblp
    ого, у вас lts <= 9.2, Published on 2017-08-27
    когда запускаете stack в проекте, используется резолвер проекта, написанный явно в его конфиге. stack-проекта без явного резолвера не может быть
    Aleksey Danilevsky
    @alexd1971
    Я взял проект по ссылке http://haskell.vacationlabs.com/en/latest/docs/reflex/getting-started.html и пытаюсь его собрать. В нем вот что:
    resolver: lts-7.8
    
    packages:
    - .
    
    extra-deps:
    - ghcjs-dom-0.7.0.3
    - ghcjs-dom-jsaddle-0.7.0.3
    - jsaddle-0.7.0.0
    - jsaddle-dom-0.7.0.3
    - jsaddle-warp-0.7.0.0
    - prim-uniq-0.1.0.1
    - ref-tf-0.4.0.1
    - zenc-0.1.1
    - git: https://github.com/reflex-frp/reflex
      commit: 91299fce0bb2caddfba35af6608df57dd31e3690
      # Latest develop comment at the time of writing
    - git: https://github.com/hamishmack/reflex-dom
      commit: d9842742183a800cf1f98f89d42d849d52dd2d67
      # Latest develop comment at the time of writing
    
    flags: {}
    
    extra-package-dbs: []
    Aleksey Danilevsky
    @alexd1971
    Будет ли ошибкой, если я в stack.yaml проекта подниму версию резолвера?
    Yuriy Syrovetskiy
    @cblp
    если у вас есть проект с resolver: lts-7.8, то глобально установленный happy поможет собрать happy в проекте
    Aleksey Danilevsky
    @alexd1971
    Да так и получилось
    Yuriy Syrovetskiy
    @cblp

    Будет ли ошибкой, если я в stack.yaml проекта подниму версию резолвера?

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

    Aleksey Danilevsky
    @alexd1971
    Этот файл все равно пришлось править, так как в нем был устаревший формат указания зависимостей
    Yuriy Syrovetskiy
    @cblp
    ну, это не проблема
    а если поднимете резолвер, это будет означать поднятие версий многих зависимостей
    а у них мог измениться API за это время
    или даже исчезнуть фичи, используемые в этом проекте
    Aleksey Danilevsky
    @alexd1971
    Ок, понял, спасибо.
    Yuriy Syrovetskiy
    @cblp
    это редко случается, но возможно