* "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
>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
discussed
_ (SomeOtherConstructor), then there is 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
)
/Shayan
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 patt
19, Richard 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 sma
an AST node, 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/
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 sy
> [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 no
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 = compose
> 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 wrote:
> Yes: https://ghc.h
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 i
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 s
e 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 two: add the
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 t
"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
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 unn
Outputable x a `.
Is this encoding faster, in comparison? Does it help?
/Shayan
On Fri, Jul 28, 2017 at 10:11 PM, Shayan Najd wrote:
> MarLinn,
>Thanks for correcting me, and spelling this out.
>I did mean what Alan mentioned: "re-parsing a pretty printed parse
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 t
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 wrote:
> On the contrary, inside GHC I /do/ want to print them. Otherwise how can I
>> see what the renamer has done?
>
&
een 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...@gmail.com]
> *Sent:* 28
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 be
ome ways this is quite
> superficial, but it unlocks the Trees That Grow machiney.
>
> Please ask questions etc. Alan and Shayan can record the answers in the
> wiki. I’m inclined to go ahead with this, so yell soon if you disagree.
>
> Simon
>
> From: ghc-devs [mailto:ghc
g to 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/NativeMeta
23 matches
Mail list logo
