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.)
ide 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 development devices. In other words th
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
ening 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, <monkle...@gmail.com
<mailto:monkle...@gmail.com>> wrote:
> Here's what I use:
>
ent
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 mailing list
ghc-dev
re'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,
MarLinn
On 2017-10-15 02:30, Daniel Gröber wrote:
Hi,
I think y
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 <monkle...@gmail.com
<mailto:monkle...@gmail.com>> wrote:
So the "actual" package name seems to be
"Plugin-0.0
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-14
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
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
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
itectures, 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
___
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 this.
Cheers,
MarLinn
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 processes of the whole syste
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
15 matches
Mail list logo
