Dear GHC devs,
The new `BlockArguments` extension has been added to the Cabal library.
I'm sending out this notification because the Note [Adding a language
extension] in compiler/main/DynFlags.hs asks me to do so.
Regards,
Takano Akio
___
ghc-devs mai
Thank you, but let me clarify that a significant portion of my patch
was simply copied from Andrew Gibiansky's differential revision:
https://phabricator.haskell.org/D1219
- Akio
On 22 August 2016 at 05:35, Index Int wrote:
> Thank you for making this effort! I am glad someone has finally implem
I have put up an implementation:
https://github.com/takano-akio/ghc/commits/argumentdo
Shall I submit the patch on the Phabricator, or should this go through
the new proposal submission process?
Regards,
Takano Akio
On 4 July 2016 at 07:50, Akio Takano wrote:
> Hi Simon,
>
> I'
[1]
> https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121217.html
> [2] https://ghc.haskell.org/trac/ghc/ticket/10843
> [3] https://github.com/gibiansky/ghc-reskin
>
> Best,
> Andrew
>
> On Wed, Jun 1, 2016 at 3:26 PM Akio Takano wrote:
>>
>
Hi Simon,
I'm sorry about the late reply.
On 2 June 2016 at 07:19, Simon Peyton Jones wrote:
> Akio
>
> Thanks for bringing back the ArgumentsDo question.
>
> My personal take on it is similar to Bardur:
>
>> AFAICT at best it's a *very* small improvement[1] and fractures
>> Haskell syntax even
Hi Bardur,
On 2 June 2016 at 00:09, Bardur Arantsson wrote:
> On 06/01/2016 01:48 PM, Akio Takano wrote:
>> Hi,
>>
>> Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would
>> love to see in GHC. It's a small syntactic extension that allows do,
Hi,
Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would
love to see in GHC. It's a small syntactic extension that allows do,
case, if and lambda blocks as function arguments, without parentheses.
However, its differential revision [1] has been abandoned, citing a
mixed response fro
Hi,
On Tue, May 5, 2015 at 8:16 PM, Simon Peyton Jones
wrote:
> Just to be clear, the issue is this
>
> * For whom is 7.10.2 mission-critical?
I'd like to bring attention to the ticket
https://ghc.haskell.org/trac/ghc/ticket/10380, because I imagine it
affects a lot of people who use sockets. Sp
On Thu, Mar 13, 2014 at 3:36 AM, Joachim Breitner
wrote:
> Dear Akio,
>
> Am Dienstag, den 11.02.2014, 08:04 +0900 schrieb Akio Takano:
>> I modified the base library to use foldrW/buildW, with no changes to
>> foldl yet. nofib showed a very big regression in cryptarithm2, s
I modified the base library to use foldrW/buildW, with no changes to
foldl yet. nofib showed a very big regression in cryptarithm2, so I'm
looking into it.
Thank you for your help,
Akio
On Mon, Feb 10, 2014 at 7:50 PM, Joachim Breitner
wrote:
> Dear Takano,
>
> did you manage to apply fold/build
On Fri, Jan 31, 2014 at 6:18 PM, Joachim Breitner
wrote:
> Dear Akio,
>
> Am Freitag, den 31.01.2014, 16:54 +0900 schrieb Akio Takano:
>> > Can you implement build via buildW, so that existing code like
>> > "map" [~1] forall f xs. map f xs = build
On Sat, Feb 1, 2014 at 12:17 AM, Joachim Breitner
wrote:
> Dar Akio,
>
> I just noticed that even with your approach, the code for foldl-as-foldr
> is not automatically beautiful. Consider this:
>
> I modified the eft function to do to some heavy work at each step (or at
> least to look like that)
Hi Joachim,
On Wed, Jan 29, 2014 at 3:06 AM, Joachim Breitner
wrote:
> Dear Akio,
>
> Am Freitag, den 03.01.2014, 23:20 +0900 schrieb Akio Takano:
>> I have been thinking about how foldl' can be turned into a good
>> consumer, and I came up with something that I tho
On Thu, Jan 16, 2014 at 4:20 AM, Simon Peyton Jones
wrote:
>
> Akio
>
>
>
> Aha! So you are really talking about replacing the *entire* foldr/build
> story with a new one, namely a foldW/buildW story. Presumably all producers
> and consumers (map, filter, take, drop etc) must be redefined usin
1 (Bin x y) n = go1 y (go1 x n)
And this is what we get if we define foldl' and toList in terms of foldrW
and buildW.
I think a similar problem arises whenever you define a good consumer that
traverses a tree-like structure, and you want to use a strict fold to
consume a list produced by
Any input on this is appreciated. In particular, I'd like to know: if I
implement the idea as a patch to the base package, is there a chance it is
considered for merge?
-- Takano Akio
On Fri, Jan 3, 2014 at 11:20 PM, Akio Takano wrote:
> Hi,
>
> I have been thinking about how
Hi,
I have been thinking about how foldl' can be turned into a good consumer,
and I came up with something that I thought would work. So I'd like to ask
for opinions from the ghc devs: if this idea looks good, if it is a known
bad idea, if there is a better way to do it, etc.
The main idea is to
Hi,
On Sat, Nov 16, 2013 at 6:59 AM, Duncan Coutts wrote:
> Hi possibly-interested souls,
>
> In this patch to System.Process.readProcess from last year:
>
>
> https://ghc.haskell.org/trac/ghc/changeset/b5ee908863882d18e4110d96b43ccc1bb5068ceb/process
>
> Bas changed things so that if an async
I'm going to try to make a small test case today (probably after 08:00
UTC), but feel free to try it. If my guess is correct, reverting the patch
should fix the problem.
On Fri, Sep 6, 2013 at 7:38 AM, Kazu Yamamoto wrote:
> Hi Takano-san,
>
> > It looks like after the commit, addCFinalizerToWea
Hi,
On Thu, Sep 5, 2013 at 9:10 PM, Kazu Yamamoto wrote:
> Hi,
>
> > If you need two Ctrl-Cs to kill the program, it probably means that it
> > deadlocked somewhere, maybe in the RTS. Kazu: if you can attach to
> > the deadlocked process with gdb and get stack traces of all the
> > threads, tha
Thank you for your comments.
On Mon, May 6, 2013 at 4:32 AM, Simon Marlow wrote:
> Akio, I looked at your first patch, which mostly seems good. The sequence
> at the beginning of deRefWeak certainly looks strange - I think it's ok,
> but it needs a comment.
>
I update my patches and added a c
Thank you for your comments, I updated the patches on the ticket (comment
changes only).
http://hackage.haskell.org/trac/ghc/ticket/7847
On Sun, May 5, 2013 at 7:50 PM, Edward Z. Yang wrote:
> > The purpose of the fix was to prevent a sequence like this:
> >
> > - w is a dead weak pointer.
> >
On Sat, May 4, 2013 at 8:50 AM, Edward Z. Yang wrote:
> Akio, your derefWeak WHITEHOLE fix looks really weird. I don't
> know what the right pattern is, but it seems like asking for trouble
> when there are multiple concurrent derefs:
>
> if (info == stg_WHITEHOLE_info) {
> ("ptr" info)
> > > Edward
> > >
> > > Excerpts from Akio Takano's message of Fri Apr 19 02:58:50 -0700 2013:
> > > > I removed the invariant by adding a new primop,
> addCFinalizerToWeak#. I
> > > > opened a ticket for the issue.
> &
a new primop, addCFinalizerToWeak#. I
> > opened a ticket for the issue.
> >
> > http://hackage.haskell.org/trac/ghc/ticket/7847
> >
> > - Akio
> >
> > On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow
> wrote:
> >
> > > On 11/03/13 03:17, Akio Tak
I removed the invariant by adding a new primop, addCFinalizerToWeak#. I
opened a ticket for the issue.
http://hackage.haskell.org/trac/ghc/ticket/7847
- Akio
On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow wrote:
> On 11/03/13 03:17, Akio Takano wrote:
>
>> Hi,
>>
Hi Edward,
Thank you for your reply!
On Mon, Mar 11, 2013 at 8:17 PM, Edward Z. Yang wrote:
> I was under the impression that foreign pointers finalizers were only
> ordered with respect to multiple finalizers on a single object. So if
> you can show your implementation preserves same-object or
Hi,
I'm working on implementing per-generation lists of weak pointers to
speed up garbage collection in programs that allocate a lot of weak
pointers. I have a patch [1] that validates and gives a 3x speed up on
a benchmark. However I'd like to ask for some advise before finishing
and submitting t
28 matches
Mail list logo
