Re: Including libffi as a submodule

John Wiegley writes: >> "BG" == Ben Gamari writes: > > BG> Note that under this scheme it will still be possible to link against the > BG> system's libffi installation using ./configure's --enable-system-libffi > BG> flag. > > Will distributions

Including libffi as a submodule

Hello everyone, As you may know, GHC carries a dependency on the libffi library. Libffi is used on most platforms (notably not x86 and x86-64) for foreign function invocation (see rts/Adjustor.c for details). While libffi works well, it is unfortunately not particularly actively maintained. In

Re: ghc-devs Digest, Vol 169, Issue 57

> I, too, have wished for the ability to have a separator in large number > literals. > > So a strong +1 from me. more +1 here ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Review of CONTRIBUTORS.md

Hey Ben, Looks good to me for the most part! I think that you should include a link to the Newcomers page [1] as a whole, even though it has some overlap with the quick start guide and you’ve included a link to the ‘Finding a Ticket’ subsection therein. I also think that a few more pointers

Review of CONTRIBUTORS.md

Hello everyone, Today I sat down and wrote a CONTRIBUTORS.md document for the ghc repository. This is recommended by GitHub to ensure that contributors can easily discover the first steps to contributing to the project. Moreover, it provided a nice blank slate to summarize the existing

Re: New primitive types?

On Sun, Aug 27, 2017 at 7:49 PM Michal Terepeta wrote: > > On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry wrote: > > Hi, > > > > I also think we should do this but it has a lot of ramifications: > contant folding in Core, codegen, TH, etc. > > > >

Re: RTS changes affect runtime when they shouldn’t

Bardur Arantsson writes: > I may be missing something since I have only quickly skimmed the thread, > but...: Why not track all of these things and correlate them with > individual runs? The Linux 'perf' tool can retrieve a *lot* of > interesting numbers, esp. around cache

Re: Underscore in binary literals

Dear all, Thank you very much for the response and kind explanation. After studying, I will submit to ghc-proposals :) Regards, Takenobu 2017-09-26 22:56 GMT+09:00 Merijn Verstraaten : > I, too, have wished for the ability to have a separator in large number >

Re: Underscore in binary literals

I, too, have wished for the ability to have a separator in large number literals. So a strong +1 from me. Cheers, Merijn > On 26 Sep 2017, at 15:43, Ben Gamari wrote: > > Takenobu Tani writes: > >> Hi Rahul, >> >> Thanks for the explanation.

Re: Underscore in binary literals

Takenobu Tani writes: > Hi Rahul, > > Thanks for the explanation. > Hmm, Is not there much need... > > Thank you code example. > I will also look at lexer for my study [1]. > If you do want to try pursuing a language change do feel free to submit a proposal [1]. I would

Re: Underscore in binary literals

I'd find that quite useful for hex and binary. It's useful for distinguishing e.g. 0x and 0xfff which when confused accidentally and lead to big bugs. Rust has exactly this feature for all numeric literals: https://rustbyexample.com/primitives/literals.html On 26/09/17 14:40,

Re: Underscore in binary literals

Hi, I for one, would like to have this in more than just BinaryLiterals (which I find rather useful as well!) I’d like to see `_` in any numeric literal being simply ignored, as I find it makes writing and reading numbers in source code much easier. let i = 1_000_000 :: Int f =

Re: Underscore in binary literals

Hi Rahul, Thanks for the explanation. Hmm, Is not there much need... Thank you code example. I will also look at lexer for my study [1]. [1]: https://phabricator.haskell.org/D22 Thank you :) , Takenobu 2017-09-26 21:58 GMT+09:00 Rahul Muttineni : > Implementation-wise,

Re: Underscore in binary literals

Implementation-wise, it's no so difficult to include - the lexer needs to be tweaked. But it seems like a specialised use-case that will only affect a minority of users is probably not worthwhile as an extension to the language/compiler. Maybe you can try using OverloadedStrings and implement

Underscore in binary literals

Dear devs, GHC's BinaryLiterals extension is useful. (For example, x = 0b110111000101) Is it difficult to include underscore(_) in the format like Verilog-HDL[1] ? (For example, x = 0b1101_1100_0101) [1]: https://inst.eecs.berkeley.edu/~cs150/fa06/Labs/verilog-ieee.pdf#page=20 Regards,