- Haskell-Cafe - Haskell.org

2nd Call for Contributions: BOB 2021 [Feb 26, Deadline Nov 13]
by Stefan Wehr 30 Oct '20

30 Oct '20

BOB Conference 2021 "What happens when we use what's best for a change?" http://bobkonf.de/2021/cfc.html Berlin, February 26 Call for Contributions Deadline: November 13, 2020 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Online or Onsite We do know yet whether BOB will happen onsite in Berlin or as an online event. Should BOB happen online, we will likely ask for pre-recorded talks to make room for questions and social interactions during the actual conference day. (Of course, we'll provide assistance making those recordings.) Tutorials will likely happen as a live-session. Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, and speakers who are not be able to attend the conference for financial reasons. Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions. Specifically: - advice on structure and presentation - review of talk slides - assistance with recording - review of recording, if applicable Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) - Don't be confused: The system calls a submission event. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: November 13, 2020 - Notification: November 27, 2020 - Program: December 6, 2020 Submit here: https://bobcfc.active-group.de/en/bob2021/cfp Program Committee ----------------- (more information here: https://bobkonf.de/2020/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 206, Issue 17
by Michal J Gajda 30 Oct '20

30 Oct '20

Hi Ly-Xia, Compl, I would argue that `Maybe` does not scale well to debugging issues in big files. When parsing a large dataset you want: 1. Get precise coordinates and description of each fault so you can fix it. 1. Be able to parse it as far as possible to get overview of entire dataset before it can be handled in error-free way. Because of this I suggest adding resilience at the level of collections: 1. Each list of declarations, record fields etc, can be parsed with resilient version of `listOf` or `sepBy` combinators and return valid entries. In context where it replaces `forM` or `mapM` I named it `forData`: 2. Invalid entries should be put into logging monad (`WriterT [Error]` that keeps a list of errors and their coordinates). This approach can be used in monad that processes a list of records, as well as in the parser: ``` forData :: (a -> m (Either Error b)) -> WriterT [Error] m [b] type Parser e -- error type m -- monad a -- result = WriterT [e] m b parseList :: (a -> Parser m b) -> Parser m [b] ``` Argument is expanded in my Haskell.Love presentation: https://www.youtube.com/watch?v=KY27LsV11Rg&t=1281s When you want to gradually expand information on errors you can also use contravariant logging operator: ``` withErrorInfo :: (e -> f) -> Parser e m a -> Parser f m a data InFile e = InFile FilePath e parseFile filename = do addErrorInfo (InFile filename) $ do input <- liftIO (readFile filename) parseFile input ``` This gradual enrichment of error messages is frequently seen in IOHK project's state machines if you enjoy reading their source code. (If you want to make it more efficient by immediately processing errors instead of tagging them along in alist, please look at contravariant logging, But I usually recommend error aggregation as a last stage of processing to discover the most serious issues.) -- Cheers Michał ________________________________ Hi Compl, At least, for the example you gave on this list, it can be fixed by returning Nothing instead of using the facility for failure baked into (mega)parsec. (Proposed diff for reference: https://github.com/complyue/dcp/pull/3) "Returning Nothing" can be seen as adding a new channel for errors, turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is how `empty` is defined by `MaybeT`, allowing that error to be caught and recovered from at the point where it was thrown, no backtracking. (And the original failure mode of Parser becomes `lift empty`.) Does that address your problem? Cheers, Li-yao On 10/28/2020 5:18 AM, Compl Yue wrote: > > I'm still not fully clear about the confusion regarding megaparsec's > behavior that I posted lately here. But now comes to my mind that it may > have some problem rooted in the lacking of recoverability semantic with > respect to parser combinators, some quoting from > http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… > > The *A note on backtracking* section > > > Combinators in this module are defined in terms Applicative and > Alternative operations. > > And `empty`'s doc: > > > This parser fails unconditionally without providing any information > about the cause of the failure. > > Clearly `empty` is used to express failure, but there is seemingly no > device to explicitly express whether a failure is recoverable. Then I > observed megaparsec's implicit rule as currently implemented is like: > > *) a failure with no input consumed can be recovered by rest parsers > *) a failure with some input consumed can not be recovered by rest parsers > > This works to great extent, but I would think the expressiveness can be > further extended for a parser from the application, to tell the library > that some input induces recoverable failure. > > I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` > are suitable devices to be considered, but as megaparsec has implemented > instances for them, I do feel some tweaks would be possible and meaningful. On Thu, Oct 29, 2020 at 1:01 PM <haskell-cafe-request(a)haskell.org> wrote: > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > Today's Topics: > > 1. Re: Consider adding recoverability to the vocabulary of > parser combinators (Li-yao Xia) > 2. Re: Consider adding recoverability to the vocabulary of > parser combinators (Compl Yue) > 3. Re: Consider adding recoverability to the vocabulary of > parser combinators (Compl Yue) > > > > ---------- Forwarded message ---------- > From: Li-yao Xia <lysxia(a)gmail.com> > To: Compl Yue <compl.yue(a)gmail.com> > Cc: "Haskell Café" <haskell-cafe(a)haskell.org> > Bcc: > Date: Wed, 28 Oct 2020 08:19:52 -0400 > Subject: Re: [Haskell-cafe] Consider adding recoverability to the vocabulary of parser combinators > Hi Compl, > > At least, for the example you gave on this list, it can be fixed by > returning Nothing instead of using the facility for failure baked into > (mega)parsec. (Proposed diff for reference: > https://github.com/complyue/dcp/pull/3) > > "Returning Nothing" can be seen as adding a new channel for errors, > turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is > how `empty` is defined by `MaybeT`, allowing that error to be caught and > recovered from at the point where it was thrown, no backtracking. (And > the original failure mode of Parser becomes `lift empty`.) > > Does that address your problem? > > Cheers, > Li-yao > > On 10/28/2020 5:18 AM, Compl Yue wrote: > > (sorry for repost, seems GMail's html processing on my last email has > > rendered it barely readable, so again with plain text here) > > > > Dear Cafe, > > > > I'm still not fully clear about the confusion regarding megaparsec's > > behavior that I posted lately here. But now comes to my mind that it may > > have some problem rooted in the lacking of recoverability semantic with > > respect to parser combinators, some quoting from > > http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… > > > > The *A note on backtracking* section > > > > > Combinators in this module are defined in terms Applicative and > > Alternative operations. > > > > And `empty`'s doc: > > > > > This parser fails unconditionally without providing any information > > about the cause of the failure. > > > > Clearly `empty` is used to express failure, but there is seemingly no > > device to explicitly express whether a failure is recoverable. Then I > > observed megaparsec's implicit rule as currently implemented is like: > > > > *) a failure with no input consumed can be recovered by rest parsers > > *) a failure with some input consumed can not be recovered by rest parsers > > > > This works to great extent, but I would think the expressiveness can be > > further extended for a parser from the application, to tell the library > > that some input induces recoverable failure. > > > > I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` > > are suitable devices to be considered, but as megaparsec has implemented > > instances for them, I do feel some tweaks would be possible and meaningful. > > > > Best regards, > > Compl > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > > > > ---------- Forwarded message ---------- > From: Compl Yue <compl.yue(a)gmail.com> > To: Li-yao Xia <lysxia(a)gmail.com> > Cc: "Haskell Café" <haskell-cafe(a)haskell.org> > Bcc: > Date: Wed, 28 Oct 2020 21:37:11 +0800 > Subject: Re: [Haskell-cafe] Consider adding recoverability to the vocabulary of parser combinators > Hi Li-yao, > > I appreciate your help especially the PR as a working fix. > > But personally I don't like the overall method of your solution, I can see Monad Transformers are powerful enough to tackle similar problems, but I'm not satisfied by the ergonomics in composing monads with transformers. `ParsecT` had already caused me much pain to get started in the beginning, and I'm still not fluent (comfortable) in transforming monads, especially I'm afraid I will have to transform much of the standard combinator functions, in order to get the real case parser working, as its resulting AST is much more complex. > > I still have faith in the improvement of megaparsec as a well known parser combinator library (I regard it as the best for engineering needs among other libraries), and I must admit megaparsec already elegantly works 99% out of my current use cases, and the very issue we are talking about is a nice-to-have rather than must-to-have, so I would think we still have time to anticipate more options to come out. > > And I particularly like to see parser combinators have this issue addressed in its own design space. > > Thanks again with best regards, > Compl > > > On Wed, Oct 28, 2020 at 8:19 PM Li-yao Xia <lysxia(a)gmail.com> wrote: >> >> Hi Compl, >> >> At least, for the example you gave on this list, it can be fixed by >> returning Nothing instead of using the facility for failure baked into >> (mega)parsec. (Proposed diff for reference: >> https://github.com/complyue/dcp/pull/3) >> >> "Returning Nothing" can be seen as adding a new channel for errors, >> turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is >> how `empty` is defined by `MaybeT`, allowing that error to be caught and >> recovered from at the point where it was thrown, no backtracking. (And >> the original failure mode of Parser becomes `lift empty`.) >> >> Does that address your problem? >> >> Cheers, >> Li-yao >> >> On 10/28/2020 5:18 AM, Compl Yue wrote: >> > (sorry for repost, seems GMail's html processing on my last email has >> > rendered it barely readable, so again with plain text here) >> > >> > Dear Cafe, >> > >> > I'm still not fully clear about the confusion regarding megaparsec's >> > behavior that I posted lately here. But now comes to my mind that it may >> > have some problem rooted in the lacking of recoverability semantic with >> > respect to parser combinators, some quoting from >> > http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… >> > >> > The *A note on backtracking* section >> > >> > > Combinators in this module are defined in terms Applicative and >> > Alternative operations. >> > >> > And `empty`'s doc: >> > >> > > This parser fails unconditionally without providing any information >> > about the cause of the failure. >> > >> > Clearly `empty` is used to express failure, but there is seemingly no >> > device to explicitly express whether a failure is recoverable. Then I >> > observed megaparsec's implicit rule as currently implemented is like: >> > >> > *) a failure with no input consumed can be recovered by rest parsers >> > *) a failure with some input consumed can not be recovered by rest parsers >> > >> > This works to great extent, but I would think the expressiveness can be >> > further extended for a parser from the application, to tell the library >> > that some input induces recoverable failure. >> > >> > I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` >> > are suitable devices to be considered, but as megaparsec has implemented >> > instances for them, I do feel some tweaks would be possible and meaningful. >> > >> > Best regards, >> > Compl >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> > > > > > > ---------- Forwarded message ---------- > From: Compl Yue <compl.yue(a)gmail.com> > To: Li-yao Xia <lysxia(a)gmail.com> > Cc: "Haskell Café" <haskell-cafe(a)haskell.org> > Bcc: > Date: Wed, 28 Oct 2020 21:48:37 +0800 > Subject: Re: [Haskell-cafe] Consider adding recoverability to the vocabulary of parser combinators > (sorry I forgot the text color again, maybe https://darkreader.org is > to blame, anyway plain text mode I should use) > > Hi Li-yao, > > I appreciate your help especially the PR as a working fix. > > But personally I don't like the overall method of your solution, I can > see Monad Transformers are powerful enough to tackle similar problems, > but I'm not satisfied by the ergonomics in composing monads with > transformers. `ParsecT` had already caused me much pain to get started > in the beginning, and I'm still not fluent (comfortable) in > transforming monads, especially I'm afraid I will have to transform > much of the standard combinator functions, in order to get the real > case parser working, as its resulting AST is much more complex. > > I still have faith in the improvement of megaparsec as a well known > parser combinator library (I regard it as the best for engineering > needs among other libraries), and I must admit megaparsec already > elegantly works 99% out of my current use cases, and the very issue we > are talking about is a nice-to-have rather than must-to-have, so I > would think we still have time to anticipate more options to come out. > > And I particularly like to see parser combinators have this issue > addressed in its own design space. > > Thanks again with best regards, > Compl > > On Wed, Oct 28, 2020 at 8:19 PM Li-yao Xia <lysxia(a)gmail.com> wrote: > > > > Hi Compl, > > > > At least, for the example you gave on this list, it can be fixed by > > returning Nothing instead of using the facility for failure baked into > > (mega)parsec. (Proposed diff for reference: > > https://github.com/complyue/dcp/pull/3) > > > > "Returning Nothing" can be seen as adding a new channel for errors, > > turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is > > how `empty` is defined by `MaybeT`, allowing that error to be caught and > > recovered from at the point where it was thrown, no backtracking. (And > > the original failure mode of Parser becomes `lift empty`.) > > > > Does that address your problem? > > > > Cheers, > > Li-yao > > > > On 10/28/2020 5:18 AM, Compl Yue wrote: > > > (sorry for repost, seems GMail's html processing on my last email has > > > rendered it barely readable, so again with plain text here) > > > > > > Dear Cafe, > > > > > > I'm still not fully clear about the confusion regarding megaparsec's > > > behavior that I posted lately here. But now comes to my mind that it may > > > have some problem rooted in the lacking of recoverability semantic with > > > respect to parser combinators, some quoting from > > > http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… > > > > > > The *A note on backtracking* section > > > > > > > Combinators in this module are defined in terms Applicative and > > > Alternative operations. > > > > > > And `empty`'s doc: > > > > > > > This parser fails unconditionally without providing any information > > > about the cause of the failure. > > > > > > Clearly `empty` is used to express failure, but there is seemingly no > > > device to explicitly express whether a failure is recoverable. Then I > > > observed megaparsec's implicit rule as currently implemented is like: > > > > > > *) a failure with no input consumed can be recovered by rest parsers > > > *) a failure with some input consumed can not be recovered by rest parsers > > > > > > This works to great extent, but I would think the expressiveness can be > > > further extended for a parser from the application, to tell the library > > > that some input induces recoverable failure. > > > > > > I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` > > > are suitable devices to be considered, but as megaparsec has implemented > > > instances for them, I do feel some tweaks would be possible and meaningful. > > > > > > Best regards, > > > Compl > > > > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > To (un)subscribe, modify options or view archives go to: > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > Only members subscribed via the mailman list are allowed to post. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Pozdrawiam Michał

4 4

Panmusic?
by Mario Lang 30 Oct '20

30 Oct '20

Hi. With all this recent talk of parsing, and me being in the process of redoing my homepage with Hakyll (read, Pandoc) I can not help but think of a long-term project of mine. I've written two different programs to handle braille music code. FreeDots[1] (Java) which converts MusicXML to Braille Music Code, and BMC[2] (C++) which converts Braille Music Code to LilyPond and MusicXML. Combining the insight that Haskell is perfect for writing compilers, and Pandoc being one of the most successful Haskell applications, I can not help but wonder: Maybe I am after Panmusic? Before another wasted attempt of stupidly reinventing the wheel, I need to ask: Is anyone working on the universal music notation converter in Haskell? If not yet, would you be interested to? The colest thing I know to a versatile format converter right now is music21[3]. However, I'd much rather see this job done in Haskell then in any other language. [1] https://github.com/mlang/freedots [2] https://github.com/mlang/bmc [3] https://github.com/cuthbertLab/music21 -- CYa, ⡍⠁⠗⠊⠕

1 0

UNSUBSCRIBE
by Elan-Mentholer 30 Oct '20

30 Oct '20

UNSUBSCRIBE

1 0

Consider adding recoverability to the vocabulary of parser combinators
by Compl Yue 30 Oct '20

30 Oct '20

Dear Cafe, I'm still not fully clear about the confusion regarding megaparsec's behavior that I posted lately here. But now comes to my mind that it may have some problem rooted in the lacking of recoverability semantic with respect to parser combinators, some quoting from http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… The *A note on backtracking* section > Combinators in this module are defined in terms Applicative <http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.h…> and Alternative <http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.h…> operations. And `empty`'s doc: > This parser fails unconditionally without providing any information about the cause of the failure. Clearly `empty` is used to express failure, but there is seemingly no device to explicitly express whether a failure is recoverable. Then I observed megaparsec's implicit rule as currently implemented is like: *) a failure with no input consumed can be recovered by rest parsers *) a failure with some input consumed can not be recovered by rest parsers This works to great extent, but I would think the expressiveness can be further extended for a parser from the application, to tell the library that some input induces recoverable failure. I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` are suitable devices to be considered, but as megaparsec has implemented instances for them, I do feel some tweaks would be possible and meaningful. Best regards, Compl

2 1

Consider adding recoverability to the vocabulary of parser combinators
by Compl Yue 28 Oct '20

28 Oct '20

(sorry for repost, seems GMail's html processing on my last email has rendered it barely readable, so again with plain text here) Dear Cafe, I'm still not fully clear about the confusion regarding megaparsec's behavior that I posted lately here. But now comes to my mind that it may have some problem rooted in the lacking of recoverability semantic with respect to parser combinators, some quoting from http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… The *A note on backtracking* section > Combinators in this module are defined in terms Applicative and Alternative operations. And `empty`'s doc: > This parser fails unconditionally without providing any information about the cause of the failure. Clearly `empty` is used to express failure, but there is seemingly no device to explicitly express whether a failure is recoverable. Then I observed megaparsec's implicit rule as currently implemented is like: *) a failure with no input consumed can be recovered by rest parsers *) a failure with some input consumed can not be recovered by rest parsers This works to great extent, but I would think the expressiveness can be further extended for a parser from the application, to tell the library that some input induces recoverable failure. I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` are suitable devices to be considered, but as megaparsec has implemented instances for them, I do feel some tweaks would be possible and meaningful. Best regards, Compl

2 3

Does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus?
by Olaf Klinke 28 Oct '20

28 Oct '20

I used to think that an Alternative is just an Applicative which is also a Monoid but apparently there is no consensus about this [1,2]. Actually it kind of makes sense to make the 'empty' parser fail: Consider the parser combinator choice = Data.Foldable.asum = foldr (<|>) empty which folds over a list of Alternatives. Its semantics can be regarded analogous to 'any' for a list of Booleans, and in the latter the empty list evaluates to False. Put differently: The parser (p <|> q) matches at least as many inputs than either p or q. Hence the neutral element for <|> ought to be the parser that matches the least amount of inputs, but a parser that succeeds on the empty string _does_ match some input. It would be the neutral element for the monoid operation that concatenates parsers. Olaf [1] https://en.wikibooks.org/wiki/Haskell/Alternative_and_MonadPlus [2] https://wiki.haskell.org/MonadPlus

4 10

[Job] Cross Compass is hiring Haskell developers
by Ramin Honary 27 Oct '20

27 Oct '20

Cross Compass ( https://www.cross-compass.com/ ) is a data science and machine learning consultancy located in Tokyo, Japan. We are hiring Haskellers to work on a machine learning platform. We are mainly looking for people skilled in either web programming, machine learning, or embedded development. Technical skills used on our team ================================= Our machine learning platform has quite a few moving parts: - two web frontends (one written in PureScript, and one written in TypeScript) - two backends (one written in Haskell, and one written in Ruby) - a deep learning engine (written in Haskell, calling out to Caffe2) - a library for running models on embedded devices (written in C, C++ and CUDA calling out to oneDNN and cuDNN) Given these various parts, we end up touching a lot of different technologies: - Haskell, including the following libraries: - conduit - JuicyPixels - lens - servant - PureScript, including the following libraries: - affjax - argonaut - protobuf - react-basic - Nix (and a little Docker) - Ruby - TypeScript - C (and a little C++ and CUDA) - machine learning (we are currently mostly focused on deep learning) We have long-term plans to move away from Ruby and TypeScript (and towards Haskell and PureScript), but no concrete time-frame for when this will happen. What sort of developers are we looking for? =========================================== In the short term, we are planning on hiring two developers. We want to hire developers who know some combination of the above technologies, or would be interested in learning. We imagine hiring one developer who is familiar with Ruby, TypeScript, and Haskell. Machine learning experience wouldn't be necessary, but helpful. They would start out with web development in Ruby and Typescript, along with some Haskell work. Over time they would probably move more towards doing web development in Haskell and PureScript. We imagine hiring one other developer who is familiar with machine learning, Haskell, and possibly embedded development. They would help with the Haskell deep learning engine, as well as the C-based embedded library. They would probably also have the chance to help with the Haskel web backend and PureScript web frontend. We are also interested in any other candidates that have unique combinations of the above skills, or interesting backgrounds. Please don't hesitate to apply based on your background or skills. Previous working experience with Haskell or any of the other technologies listed above is not a requirement. Non-technical requirements ========================== We would prefer to hire developers that can work locally from Tokyo. We sponsor visas for developers who want to move to Japan. If we don't find anyone who is willing to relocate to Japan, we will considering hiring remote-only candidates. Most of our meetings take place in the afternoon in JST (UTC+9), which is around 5 AM UTC. Although we are flexible on this point. https://www.timeanddate.com/worldclock/converter.html?iso=20201104T050000&p… We prefer to hire developers who want to work full time (40 hours per week). Pay ==================== The salary range for this position is 6 to 8 million yen (about USD $57,000 to $75,000). Application and hiring process ============================== If this sounds interesting, please feel free to email us at recruit(a)cross-compass.com . We are not too big on standard resumes, but you are welcome to send us any information that you think would catch our attention, including things like: - relevant work history (e.g. work somewhere before using Haskell? Or maybe doing frontend development with TypeScript?) - relevant education history (e.g. took a class on machine learning?) - open-source software links (e.g. author any interesting libraries? have a cool machine learning project?) - papers, articles, blog posts, social media, or anything else which reflects well on you We'd also like to know your situation regarding on-premise work vs. remote, including whether or not you would be interested in moving to Japan. There will be one interview to learn more about you and for you to ask us questions. We will invite promising candidates to a part-time, one-month paid trial period. During this trial period we see what it is like working with you, and you get to see how we work as a team. Ideally, you'd be able to work at least a couple hours a week (so we both have an idea what is it like to work with each other when the month is over), but we are flexible with the details here. We would make you an offer after the trial-period. Haskellers at Cross Compass =========================== There are already a few Haskellers at Cross Compass. You may have interacted with us online or at various meetups and conferences. - Viktor Kronvall ( https://github.com/considerate ) - Jonas Carpay ( https://github.com/jonascarpay ) - Ramin Honary ( https://github.com/RaminHAL9001 ) - James Brock ( https://github.com/jamesdbrock ) - Dennis Gosnell ( https://functor.tokyo/ ) Other Considerations ==================== - We would consider hiring someone part-time with a lot of experience, although we would probably only do this if we don't find someone willing to work full time. - Being able to speak Japanese is not a requirement. - HR will often help employees new to Japan with things like finding an apartment, opening a bank account, getting a cell phone, etc. - We don't particularly have any requirements regarding years of experience. Coronavirus =========== - It is currently possible for people to get a work visa and come to Japan. (At one point foreigners weren't able to enter Japan, but this restriction has been relaxed and now people can enter with a work visa.) - Over the last few months, there are on average a couple hundred cases per day in Tokyo. - Most people in Cross Compass have been working remotely since Coronavirus became a problem in Tokyo. Some people go in to the office once or twice a week. I imagine this will continue until cases of Coronavirus start to drop. I don't know what the plans for what the remote working situation will be like when Coronavirus is no longer a problem. If you're concerned about this, please make sure to ask about this in your application email.

1 0

error when running stack
by Dennis Raddle 26 Oct '20

26 Oct '20

I get this error when running stack: Downloading lts- xxxx building plan aesonException "Error in $['system-info']: key \"os\" not present" running "stack update" didn't help. I'm very confused because I don't remember what I did that provoked this error. Anyone know what's going on? Dennis

3 4

Does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus?
by Compl Yue 26 Oct '20

26 Oct '20

Dear Cafe, Regarding the Alternative instance of ParsecT from Megaparsec here: https://github.com/mrkkrp/megaparsec/blob/ccf314b0b940bdbfec3820b18f42d241e… (https://link.getmailspring.com/link/34AABC73-FAC8-4126-8356-62E7FE0DA273@ge…) -- | 'empty' is a parser that __fails__ without consuming input. instance (Ord e, Stream s) => Alternative (ParsecT e s m) where empty = mzero (<|>) = mplus I come to this question, does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus? First of all, can I somehow regard Alternative as a repurposed Monoid? So this question applies similarly to Monoid as well? Then I think the lack of failure semantic in Alternative/Monoid might have two different interpretations: 1) It must NOT fail 2) Whether it can fail or not is not cared Which one is correct? I feel 1) is in spirit of purism, that pure code should not fail, but it's a monad, then 2) may in monad's spirit to be effectful and composable with other effects including failing. I'd think it violates the law when interpretation 1) is taken. Background about my confusion: https://github.com/mrkkrp/megaparsec/issues/429#issuecomment-716170935 (https://link.getmailspring.com/link/34AABC73-FAC8-4126-8356-62E7FE0DA273@ge…) The parsing of whitespaces is so handled in Megaparsec's idiom that every lexeme should consume (discard) all whitespaces following it. But after tinkered around with some related issues, I by now would think a silent, joinable empty / mempty might be more sense making for each whitespace block to be parsed individually, i.e. without association with any lexeme while neither will fail the overall parsing. The demand comes in that I'd like the doc comment parser to evaulate to empty and contribute nothing to an enclosing many , in case all following it is whtespaces till eof; while in case it's followed by some artifact definition, the doc comment parser should evaluate to a syntactic doc node assoicated with that artifact. empty seems an ideal device for that purpose, but in the fact it is implemented with mzero, the overall parsing will fail, which makes it infeasible. Best regards, Compl

1 0