Re: re-engineering overloading and rebindable syntax

Hi, On 05/12/2019 10.53, Richard Eisenberg wrote: Con: - worse error messages, which would now refer to the desugared code instead of the user-written code. I can think of several major parts that seem useful to solve this. (Please excuse the very abstract and imprecise descriptions.) 1.

Re: Treatment of unknown pragmas

gmas could be added outside the ghc source. Cheers, MarLinn PS: * Why would I want to annotate imports? Because many of my experiments aren't bigger than one file. It would be nice if I could make them self-contained and "portable" between dev

Re: Proposal: Professionalizing GHC Development

Could you clarify? I see two promising proposals in this: A) Redefining proof-of-work to mean one has to compile a GHC instead of computing some obscure hashes only nerds care about B) GHC will be compiled via contracts in the blockchain, to make sure all mistake remain attributable I like bo

Re: Long standing annoying issue in ghci

Would you mind reopening the issue and providing a buggy example? Amd alerting haskeline maintainers? How does it work on a 1 line prompt that is so long it wraps? On Thu, 7 Dec 2017 23:11 MarLinn, <mailto:monkle...@gmail.com>> wrote: > Here's what I use: > >

Re: Long standing annoying issue in ghci

be different again. I don't know what the rules are, but I found that if I put \STX on any but the last line of prompts I get weird characters. The same goes for any \SOH you might want to add for some reason. Cheers, MarLinn ___ ghc-devs maili

Re: Can I get the internal name of a package at runtime?

e feeling there is no good non-hacky way. Somewhere there's always some extra c code or something. I'm just glad my current goal is to just load object files, not compile user-supplied "scripts" into a running project or something. So thanks again to you all! Cheers, M

Re: Can I get the internal name of a package at runtime?

around it. Good to know. Thanks for helping out! Cheers, MarLinn On 2017-10-14 20:11, Brandon Allbery wrote: On Sat, Oct 14, 2017 at 12:48 PM, MarLinn <mailto:monkle...@gmail.com>> wrote: So the "actual" package name seems to be "Plugin-0.0.0.0-2QaFQQzYhnKJSPRXA

Re: Can I get the internal name of a package at runtime?

But at least now I can exploit the fact that a "libHSPlugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe.a" file is generated. So if I don't find the complete answer I still have a more portable way for discovery than inspecting headers. That's quite useful. Cheers, MarLinn On 2017-10

Can I get the internal name of a package at runtime?

l). I'm asking this question here rather than on café as I feel that if there is a solution, it's probably buried in the details of GHC. Thanks for any suggestions, MarLinn ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Operating on HsSyn

retty printer to the parser. Thus 4 looks like the best candidate for a criterion. Possibly with 3 as a secondary target. Cheers, MarLinn ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

te to this effort. But again, my understanding of each and every component is fleeting at best. MarLinn On 2016-12-21 06:15, Edward Kmett wrote: Arrows haven't seen much love for a while. In part this is because many of the original applications for arrows have been shown to be perfectly suit

Re: Telemetry

ly: I like that idea, but I might just have proven it fruitless anyway. Cheers, MarLinn ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Telemetry (WAS: Attempt at a real world benchmark)

built regularly, on different architectures, with sources that can be inspected and with an easy way to get diffs. In other words, projects that live on github and travis anyway. Their maintainers should be easy to convince to set that little switch to "on". Regards, MarLinn

Re: Separating typechecking and type error reporting in two passes?

n would be even more conversational. Of course the benefits are debatable and this is not something that's going to be happening soon anyway. But for me the idea alone is an argument for the proposed new separation, because it would give us the flexibility to think of features like thi

Re: Making (useful subsets of) bytecode portable between targets

what Pandoc is doing for documents. And while Pandoc's architecture and history make it a bit static, GHC can still learn from it. Maybe, someday, there could even be a bigger, even more over-arching build language that describes the program, the documentation, and the deployment pro

Re: Request for feedback: deriving strategies syntax

error messages. ;) I agree that "stock" is an acceptable alternative. MarLinn ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs