I have placed an ordering on it so that D426 comes first, then D438 and
finally D412, there was a very minor merge update required for D412.
On Tue, Nov 4, 2014 at 11:41 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
Hi all
Hopefully I will be able to stop harassing everyone on this topic
As part of my ongoing efforts to round-trip source code, I have bumped into
an issue around file header pragmas, e.g.
{-# LANGUAGE PatternSynonyms #-}
{-# Language DeriveFoldable #-}
{-# options_ghc -w #-}
In normal mode, when not called from headerInfo, the file header pragmas
are
29, 2014 at 9:04 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
As part of my ongoing efforts to round-trip source code, I have bumped
into an issue around file header pragmas, e.g.
{-# LANGUAGE PatternSynonyms #-}
{-# Language DeriveFoldable #-}
{-# options_ghc -w
cabal has changed for HEAD, you need to install 1.21.1.0
On Thu, Oct 23, 2014 at 2:40 PM, Sven Panne svenpa...@gmail.com wrote:
2014-10-22 15:16 GMT+02:00 Sven Panne svenpa...@gmail.com:
Does anybody have a clue what's going wrong at the sdist step here?
For the review process I updated the phabricator summary to capture the
current implementation, I will move it on to the wiki too.
The ExtraCommas have been removed as unworkable, they are an abandoned
point in the design space. The lessons learned are being transferred to
Alexander Berntsen for
All you have to do is edit out /edit/ in the URL,..
On Mon, Oct 20, 2014 at 4:24 PM, Brandon Allbery allber...@gmail.com
wrote:
On Mon, Oct 20, 2014 at 10:22 AM, Austin Seipp aus...@well-typed.com
wrote:
https://ghc.haskell.org/trac/ghc/blog/edit/weekly20141020
You might want to provide
I think there is currently a more general interest in this, and the ghc-mod
guys are thinking on similar lines, see
https://github.com/kazu-yamamoto/ghc-mod/issues/349
Alan
On Sat, Oct 18, 2014 at 5:48 PM, Christopher Done chrisd...@gmail.com
wrote:
Good evening,
So I’ve been working on
Ok, will do.
An integer can potentially have any number of leading zeros, and I will
have to check what escaping exists in the others.
On Mon, Oct 13, 2014 at 11:33 AM, GHC ghc-devs@haskell.org wrote:
#9628: Add Annotations to the AST to simplify source to source conversions
:07 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
It is a structure proposed to capture extra commas in record declarations,
which I have abused for use here.
I have subsequently realised that I am using it to capture EVERY comma,
and sometimes semicolons, so its naming is even worse
Ok, then I think the middle ground is keyword-specific annotations, as
proposed by Neil.
What should happen is that the raw annotations are used by a tool layer
such as ghc-exactprint or HaRe, and other more casual users will not have
to worry about the internal detail.
On Fri, Oct 10, 2014 at
Yes, I was thinking last night I need to update the GhcAstAnnotations wiki
page. Will do so and clean up.
On Thu, Oct 9, 2014 at 5:20 PM, GHC ghc-devs@haskell.org wrote:
#9628: Add Annotations to the AST to simplify source to source conversions
?
On Oct 8, 2014 12:33 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
I am currently working annotations into the parser, provided them as a
separate structure at the end of the parse, indexed to the original by
SrcSpan and AST element type.
The question I have is how to capture commas
I am not sure how to report bugs against the current development version of
GHC.
Should this go into Trac?
The current HEAD gives a spurious unused declaration when deriving
Typable/Traversable
Details
Compiling against current HEAD (0ed9a2779a2adf0347088134fdb9f60ae9f2735b)
Adding
Ok, so stage2 is in fact behaving correctly, the stage1 code needs to have
CPP directives around it.
In other words this is not actually a bug.
Thanks
Alan
On Wed, Oct 8, 2014 at 2:05 PM, Nicolas Trangez nico...@incubaid.com
wrote:
On Wed, 2014-10-08 at 14:00 +0200, Alan Kim Zimmerman
I am currently working annotations into the parser, provided them as a
separate structure at the end of the parse, indexed to the original by
SrcSpan and AST element type.
The question I have is how to capture commas and semicolons in lists of
items.
There are at least three ways of doing this
Is there any reason I can't put in a diff request to replace the derived
Show instance for SrcSpan with a handcrafted one that does not exhausively
list the constructors, making it more readable?
Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
/06/2014 01:59 PM, Alan Kim Zimmerman wrote:
Is there any reason I can't put in a diff request to replace the derived
Show instance for SrcSpan with a handcrafted one that does not
exhausively
list the constructors, making it more readable?
Alan
Why? If you're looking for pretty
, Alan Kim Zimmerman wrote:
Date: Mon, 6 Oct 2014 14:59:03 +0200
From: Alan Kim Zimmerman alan.z...@gmail.com
To: ghc-devs@haskell.org ghc-devs@haskell.org
Subject: Show instance for SrcSpan
Is there any reason I can't put in a diff request to replace the derived
Show instance
+0200, Alan Kim Zimmerman wrote:
Date: Mon, 6 Oct 2014 15:27:49 +0200
From: Alan Kim Zimmerman alan.z...@gmail.com
To: Matthias Fischmann m...@zerobuzz.net
Cc: ghc-devs@haskell.org ghc-devs@haskell.org
Subject: Re: Show instance for SrcSpan
Not at all, just show as e.g.
SrcSpan
and
implementation effort in facilities that may not meet the need.
If they end up acclaiming the node-key idea, then we should surely simply
make the key an abstract type, simply an instance of Hashable, Ord, etc.
Simon
From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent
:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
*Sent:* 01 October 2014 16:13
*To:* Simon Peyton Jones
*Cc:* Richard Eisenberg; Edward Z. Yang; ghc-devs@haskell.org
*Subject:* Re: Feedback request for #9628 AST Annotations
I have put up a new diff at https://phabricator.haskell.org/D297
I have put up a new diff at https://phabricator.haskell.org/D297
It is just a proof of concept at this point, to check if the approach is
acceptable.
This is much less intrusive, and only affects the lexer/parser, in what
should be a transparent way.
The new module ApiAnnotation was introduced
.
This technique can also potentially be backported to support older GHC
versions via a modification to ghc-parser.
https://hackage.haskell.org/package/ghc-parser
Regards
Alan
On Tue, Sep 30, 2014 at 2:04 PM, Alan Kim Zimmerman
alan.z...@gmail.com
wrote:
I tend
the node-key idea, then we should surely simply
make the key an abstract type, simply an instance of Hashable, Ord, etc.
Simon
From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 30 September 2014 19:48
To: Simon Peyton Jones
Cc: Richard Eisenberg; Edward Z. Yang; ghc-devs
I tend to agree that this change is much too intrusive for what it attempts
to do.
I think the concept of a node key could be workable, and ties in to the
approach I am taking in ghc-exactprint [1], which uses a SrcSpan together
with node type as the annotation key.
[1]
.
This technique can also potentially be backported to support older GHC
versions via a modification to ghc-parser.
https://hackage.haskell.org/package/ghc-parser
Regards
Alan
On Tue, Sep 30, 2014 at 2:04 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
I tend to agree that this change is much
I am trying to avoid having a type parameter for DynFlags, and so far the
only thing that needs it is the hooks. I am currently working it through
without hooks in DynFlags, and when I have something concrete I will ask
againfor suggestions.
I just wanted an initial test of the waters to make
Something else to throw into the mix, once the Located replacement by
Genlocated is done for hsSyn I intend to capture the locations of all
non-captured syntactic elements, such as commas.
So this proposed mechanism would help, provided the location of each comma
is also tracked.
Alan
On Fri,
as the first type parameter, and is called r
2. It gets added as the first field of the syntax element
3. It is always called ann
Before undertaking this particular change, I would appreciate some feedback.
Regards
Alan
On Thu, Aug 28, 2014 at 8:34 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote
If this is done right it can enable this sort of thing :
http://www.davidchristiansen.dk/2014/09/06/pretty-printing-idris/
On Fri, Sep 5, 2014 at 5:11 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
Hi Neil
Thanks for the feedback.
I am going to start putting together a proof of concept
:: [ExprLStmt id]
, hsdo_type:: PostTcType }
Simon
*From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
*Sent:* 28 August 2014 19:35
*To:* Richard Eisenberg
*Cc:* Simon Peyton Jones; ghc-devs@haskell.org
*Subject:* Re: GHC AST Annotations
This does have the advantage
Now that the landmines have hopefully been cleared from the AST via [1] I
would like to propose changing the location information in the AST.
Right now the locations of syntactic markers such as do/let/where/in/of in
the source are discarded from the AST, although they are retained in the
rich
the
syntactic keywords) that do not show up as children in the syntax tree?
Anyway do by all means create a GHC Trac wiki page to describe your
proposed design, concretely.
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan
Kim Zimmerman
Sent: 28 August 2014 15:00
I have started capturing the discussion here
https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations.
On Thu, Aug 28, 2014 at 8:34 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
This does have the advantage of being explicit. I modelled the initial
proposal on HSE as a proven solution
Ok thanks.
I am travelling at the moment, will try this in a few days.
Alan
On 26 Aug 2014 11:23 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:
On 08/25/2014 01:21 PM, Alan Kim Zimmerman wrote:
What happens in the case of a change to the dev branch of ghc that
requires
a patch
like a sledgehammer to crack a nut. What
is wrong with the type-function approach?
Simon
*From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
*Sent:* 13 August 2014 07:50
*To:* Philip K.F. Hölzenspies
*Cc:* Simon Peyton Jones; Edward Kmett; ghc-devs@haskell.org
*Subject:* Re: Broken
And I dipped my toes into the phabricator water, and uploaded a diff to
https://phabricator.haskell.org/D153
I left the lines long for now, so that it is clear that I simply added
parameters to existing type signatures.
On Tue, Aug 12, 2014 at 10:51 PM, Alan Kim Zimmerman alan.z...@gmail.com
preserve the code
for you. (Example: Convert.void)
Regards,
Philip
*From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
*Sent:* woensdag 13 augustus 2014 8:50
*To:* Holzenspies, P.K.F. (EWI)
*Cc:* Simon Peyton Jones; Edward Kmett; ghc-devs@haskell.org
*Subject:* Re
at 5:45 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
FYI I edited the paste at http://lpaste.net/108262 to show the problem
On Mon, Jul 28, 2014 at 5:41 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
I already tried that, the syntax does not seem to allow it.
I suspect some higher
:* Alan Kim Zimmerman [alan.z...@gmail.com]
*Verzonden:* vrijdag 25 juli 2014 13:44
*Aan:* Simon Peyton Jones
*CC:* Holzenspies, P.K.F. (EWI); ghc-devs@haskell.org
*Onderwerp:* Re: Broken Data.Data instances
By the way, I would be happy to attempt this task, if the concept is
viable.
On Thu
,
Philip
*From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
*Sent:* maandag 28 juli 2014 14:10
*To:* Holzenspies, P.K.F. (EWI)
*Cc:* Simon Peyton Jones; Edward Kmett; ghc-devs@haskell.org
*Subject:* Re: Broken Data.Data instances
Philip
I think the main reason
FYI I edited the paste at http://lpaste.net/108262 to show the problem
On Mon, Jul 28, 2014 at 5:41 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
I already tried that, the syntax does not seem to allow it.
I suspect some higher form of sorcery will be required, as alluded to here
http
of these files (Name.lhs, for example) are really stable through
the repo-history. It would be nice to have one bigger refactoring all in
one go (some of the code could use a polish, a lot of code seems removable).
Regards,
Philip
--
*Van:* Alan Kim Zimmerman
To my knowledge there is no trac ticket to make the AST safe. Is this
correct? Can I make one?
Alan
On Sun, Jul 27, 2014 at 4:28 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
My intention would be to simply change the placeholders into something
that would not blow up during a normal
all in
one go (some of the code could use a polish, a lot of code seems removable).
Regards,
Philip
--
*Van:* Alan Kim Zimmerman [alan.z...@gmail.com]
*Verzonden:* vrijdag 25 juli 2014 13:44
*Aan:* Simon Peyton Jones
*CC:* Holzenspies, P.K.F. (EWI); ghc-devs
By the way, I would be happy to attempt this task, if the concept is viable.
On Thu, Jul 24, 2014 at 11:23 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
While we are talking about fixing traversals, how about getting rid of the
phase specific panic initialisers for placeHolderType
While we are talking about fixing traversals, how about getting rid of the
phase specific panic initialisers for placeHolderType, placeHolderKind and
friends?
In order to safely traverse with SYB, the following needs to be inserted
into all the SYB schemes (see
201 - 247 of 247 matches
Mail list logo
