Re: TTG: Handling Source Locations

* "About the latter, until #15247 is fixed" ---> "About the latter, until #15884 is fixed" On Wed, 13 Feb 2019 at 14:00, Shayan Najd wrote: > > >is there any plan to get rid of all those panics? > > There are two sorts of panics related to TTG: the ones

Re: TTG: Handling Source Locations

>is there any plan to get rid of all those panics? There are two sorts of panics related to TTG: the ones due to #15247 (i.e. unused extension constructors), and the ones due to #15884 (i.e. issues with view patterns). About the former, I believe we all agree. Moreover, using Solution A

Re: TTG: Handling Source Locations

no way to guarantee a complete > pattern-match short of a catch-all. So it doesn't seem to me that the > pattern-match checker is really helping us achieve what we want here. > > Richard > > > On Feb 12, 2019, at 9:30 AM, Shayan Najd wrote: > > > >> My pr

Re: TTG: Handling Source Locations

yan On Tue, 12 Feb 2019 at 15:30, Shayan Najd wrote: > > > My problem, though, is that this is just a convention -- no one checks it. > > It would be easy to forget. > > I am not sure if I understand: shouldn't the totality checker warn if > there is no pattern for the wra

Re: TTG: Handling Source Locations

ichard Eisenberg wrote: > > > > > On Feb 12, 2019, at 5:19 AM, Shayan Najd wrote: > > > > About the new code, the convention is straightforward: anytime you > > destruct an AST node, assume a wrapper node inside (add an extra > > case), or use the smart co

Re: TTG: Handling Source Locations

e, assume a wrapper node inside (add an extra case), or use the smart constructors/pattern synonyms. I'd be happy to rediscuss the design space here. It would be great to have everyone fully on board as it is not a trivial change. /Shayan [0] https://github.com/shayan-najd/HsAST/blob/master/Paper

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

I also realised the COMPLETE pragmas are even less helpful (at least for my case mentioned above) as they cannot be used when orphaned. For example, I tried to follow the partial solution of introducing multiple COMPLETE pragmas, one per a concrete instance of `HasSrcSpan`. I defined the pattern

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

> [Ryan Scott:] > In other words, this would work provided that you'd be willing to list > every single instance of `HasSrcSpan` in its own COMPLETE set. It's > tedious, but possible. Yes, for the cases where `LL` is used monomorphically, we can use the per-instance COMPLETE pragma, but it does

Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

Dear GHC hackers, On our work on the new front-end AST for GHC [0] based on TTG [1], we would like to use a pattern synonym like the following [2]: {{{ pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a pattern LL s m <- (decomposeSrcSpan -> (m , s)) where LL s m =

Re: Availability of Coercible Instances at TH Runtime

> I think this may be waiting for the trees-that-grow work to be completed, and > as far as I know, no one is actively working on this. We've just got a new Google SoC project accepted to push this forward :) /Shayan On Mon, May 7, 2018 at 3:14 PM, Richard Eisenberg

Re: True multi stage Haskell

Hi Tim, About using GHC as a library module, have you see the ongoing work on "native metaprogramming" in GHC at https://ghc.haskell.org/trac/ghc/wiki/NativeMetaprogramming and a child project at https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow There, online code generation

Re: Trees that Grow and constraints

Isn't the solution always if generic programming makes things complicated, avoid it! Here generic programming is where you define instances parametric on the phase index. Why not defining three instances of the type class, one per each phase? Yes, we get code duplication (which in this case is

Re: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

; the code harder to understand. > > > Can you give an example function or two, and what it would look like under > the different approaches. > > > > (1)-(3) appears to be three different approaches, but I don’t think that’s > what you intend. I think there are only

Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

In this thread, I am going to raise a topic for discussion. Please share your opinions and related experiences. Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*. However, when programming with

Failing Test Cases in HEAD

"GHC panic bug" when validating. (In my repo[1], I can successfully build with steps (2)-(7) above but `./validate` (and `make test TEST="T13780c T13822"`) fails) Thanks, Shayan [1] https://github.com/shayan-najd/GrowableGHC ___ ghc-dev

Restructuring hsSyn

Currently AST declarations, their relate utilities, and `Outputable` instances are defined in the same files. Does anyone object to moving `Outputable` instances to separate files? The purpose is to gradually identify reusable functionalities, group them together, polish them (e.g., remove some

Re: Operating on HsSyn

xp Outputable x a `. Is this encoding faster, in comparison? Does it help? /Shayan On Fri, Jul 28, 2017 at 10:11 PM, Shayan Najd <sh.n...@gmail.com> wrote: > MarLinn, >Thanks for correcting me, and spelling this out. >I did mean what Alan mentioned: "re-parsi

Re: Operating on HsSyn

MarLinn, Thanks for correcting me, and spelling this out. I did mean what Alan mentioned: "re-parsing a pretty printed parse tree gives you back a parse tree identical to the original (ignoring SrcSpans)". As I recall, we had to go a bit further to give 'Something' some more structure to

Re: Operating on HsSyn

by (parser . prettyPrint . parser) = id I meant (prettyPrint . parser . prettyPrint) = id for a valid input. On Fri, Jul 28, 2017 at 4:32 PM, Shayan Najd <sh.n...@gmail.com> wrote: > On the contrary, inside GHC I /do/ want to print them. Otherwise how can I >> see what

Re: Operating on HsSyn

com> wrote: > I have been under the impression that we don't even want to print those. > > On the contrary, inside GHC I /do/ want to print them. Otherwise how can I > see what the renamer has done? > > > > Simon > > > > *From:* Shayan Najd [mailto:sh.n...@g

Re: Operating on HsSyn

Before all this, we may need to discuss a bit about the intended semantics of `Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out` suffixed constructors? If not, then we only need to write a set of instances for the base growable AST, once and for all. Such instances will

Re: Trees that Grow in the hsSyn AST

you disagree. > > Simon > > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & > Kim Zimmerman > Sent: 24 May 2017 22:52 > To: ghc-devs@haskell.org > Subject: Trees that Grow in the hsSyn AST > > Hi all > > You may be aware that Shayan

Re: Request for feedback: deriving strategies syntax

give a talk on this in Haskell Implementors' Workshop in Japan. But since then, for further information, you may be brave enough to read our sketchy notes / pieces of code: - An example using the extensible encoding (a bit outdated variant though): https://github.com/shayan-najd/NativeMetaprogrammin