- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Split the IsList class for OverloadedLists
by Olaf Klinke 31 Oct '20

31 Oct '20

> Hello Café, > > Right now the IsList class used by the OverloadedLists extension > requires both fromList, to construct something using list syntax, > and > toList, to pattern-match on something using list syntax. > > So types implementing that class are expected to be isomorphic to > lists. > This is a very strong restriction. In particular, this gets in the > way > of implementing IsList for aeson's Value type[1], since there's no > sensible total implementation of toList. > > [1]: That is a recently proposed idea > https://github.com/bos/aeson/issues/813 For constructing values from list syntax, I can understand that only fromList is used and Aeson's Value indeed contains lists. But if both fromList and toList are required, I would expect that fromList.toList=id and I can not see how that can ever be achieved with Aeson Values. Maybe a lightweight quasi-quoter can be syntactically almost as convenient for construction? MonoFoldable and MonoTraversable instances for Value might also be helpful: MonoFoldable gives you a toList function. > > > Proposal: split toList and fromList in two separate classes. > > (And modify the OverloadedLists extension accordingly.) > > Since they rely on an associated type family Item, it would be made > a > standalone family. > > > type family Item (l :: Type) :: Type > > class ToList l where > toList :: l -> [Item l] > > class FromList l where > fromList :: [Item l] -> l > fromListN :: Int -> [Item l] -> l > > > (Note: we can't just replace ToList with Foldable, because these > classes > have different kinds.) > > > - Any objections? An obvious concern is backwards compatibility. Is > that > a deal breaker? Are there other issues with this idea? You would lose the pattern matching functionality, it seems. It reminds me very much of OverloadedStrings and that is not always as convenient as you might think. The issue is that a previously monomorphic piece of syntax suddenly is polymorphic, so in some places with OveroadedStrings one must provide type annotations. And that destroys the brevity one was after. > > - Should that be a GHC proposal[2]? > > - Has this been discussed before? > > [2]: https://github.com/ghc-proposals/ghc-proposals > > > One alternative is to use RebindableSyntax, which already allows > users > to redefine toList and fromList however they want. The issue is it > might > also mess with all other kinds of syntactic sugar just enough that > the > unpleasantness is not worth the trouble. > > For example, if you wanted to use multiple list-like types in one > module, you would want an overloaded version of fromList/fromListN. > You > either roll your own or find a suitable dependency. Either way it's > overhead you might not be willing to pay for, as opposed to > something > that's already in base and Just Works. > > So even with some existing workarounds in mind, the above proposal > seems > a net improvement over the status quo. > > Maybe some day we'll also get to take fromInteger out of Num. > > Regards, > Li-yao >

2 1

[CFP]Agile and Functional Data Pipelines workshop
by mgajda＠mimuw.edu.pl 31 Oct '20

31 Oct '20

Dear Friends, The emerging interest in the rigorous and agile data science and functional ETL pipelines has driven the developments of many new libraries, frameworks and methodologies. We invite industry practitioners and academics to present their latest work on agile functional data pipelines as a workshop at the EDI'2021 conference. Call for papers =============== The following would be accepted: - Exposures of methodologies for building agile functional data pipelines - Presentations of frameworks used for data pipelines in industry and academia - Experience reports from building of data pipelines in industry and academia - Benchmarks and optimization of agile data pipeline frameworks - Solutions to data integration and exchange problems within ETL pipelines. In particular, we encourage: - Agile functional data methodologists - Authors of ETL frameworks, streaming libraries and databases, reactive streaming, streaming benchmarks, high-performance workflow engines - Position papers on the use of agile and functional data methodologies - Descriptions of environments for interactive and live programming with data - Benchmarks of state-of-the-art solutions for agile functional data pipelines. Details at https://afdp.github.io Important dates =============== Abstract registration deadline : December 15th, 2020 Submission deadline : December 22nd, 2020 Acceptance notification : January 12th 2021 Final manuscripts : January 23rd, 2021 Presentation at the conference : March 23rd-26th 2021 Submission instructions ======================= Original, unpublished papers are solicited for presentation at the AFDP workshop. Prospective authors are invited to submit papers (electronically, PDF only) that are no longer than 6 pages for full papers, including all figures and references. For work-in-progress, we also solicit extended abstracts for presentations. The submitted paper must be formatted according to the guidelines of Procedia Computer Science. All accepted papers will be published in Procedia Computer Science. Location ======== This workshop will be held as a part of [The 4th International Conference on Emerging Data and Industry 4.0 (EDI40)](http://cs-conferences.acadiau.ca/EDI40-21/) held on March 23 - 26, 2021 in Warsaw, Poland. -- Best regards MichaB

1 0

Re: [Haskell-cafe] Panmusic?
by Johannes Waldmann 30 Oct '20

30 Oct '20

> Is anyone working on the universal music notation > converter in Haskell? https://github.com/music-suite/music-suite http://music-suite.github.io/docs/ref/ I think this intends to be "the pandoc of music". I was looking into lilypond parsing for that, see my fork https://github.com/jwaldmann/lilypond-parse#goals but I'm currently stalled on this, for lack of time - and for the thorough mess that lilypond makes of mixing lexing, parsing, and semantics. It's as bad as TeX ... - J.

2 2

Split the IsList class for OverloadedLists
by Li-yao Xia 30 Oct '20

30 Oct '20

Hello Café, Right now the IsList class used by the OverloadedLists extension requires both fromList, to construct something using list syntax, and toList, to pattern-match on something using list syntax. So types implementing that class are expected to be isomorphic to lists. This is a very strong restriction. In particular, this gets in the way of implementing IsList for aeson's Value type[1], since there's no sensible total implementation of toList. [1]: That is a recently proposed idea https://github.com/bos/aeson/issues/813 Proposal: split toList and fromList in two separate classes. (And modify the OverloadedLists extension accordingly.) Since they rely on an associated type family Item, it would be made a standalone family. type family Item (l :: Type) :: Type class ToList l where toList :: l -> [Item l] class FromList l where fromList :: [Item l] -> l fromListN :: Int -> [Item l] -> l (Note: we can't just replace ToList with Foldable, because these classes have different kinds.) - Any objections? An obvious concern is backwards compatibility. Is that a deal breaker? Are there other issues with this idea? - Should that be a GHC proposal[2]? - Has this been discussed before? [2]: https://github.com/ghc-proposals/ghc-proposals One alternative is to use RebindableSyntax, which already allows users to redefine toList and fromList however they want. The issue is it might also mess with all other kinds of syntactic sugar just enough that the unpleasantness is not worth the trouble. For example, if you wanted to use multiple list-like types in one module, you would want an overloaded version of fromList/fromListN. You either roll your own or find a suitable dependency. Either way it's overhead you might not be willing to pay for, as opposed to something that's already in base and Just Works. So even with some existing workarounds in mind, the above proposal seems a net improvement over the status quo. Maybe some day we'll also get to take fromInteger out of Num. Regards, Li-yao

1 0

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 29 Oct '20

29 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 29 Oct '20

29 Oct '20

UNSUBSCRIBE

1 0

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

29 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