Re: (Failing to) look up names generated by Template Haskell

[Ranjit Jhala]

On further inspection, the problem is not with TH but with family instances.

That is, suppose Library.hs is has the constructors defined in the simple
top-level style:

```
data EntityField typ where
  BlobXVal :: EntityField Int
  BlobYVal :: EntityField Int
```

Then when analyzing Client.hs, the lookup function `hscTcRcLookupName`
WORKS.

However, if instead, Library.hs defines the constructors within an instance:

```
instance PersistEntity Blob where
  data EntityField Blob typ where
BlobXVal :: EntityField Blob Int
BlobYVal :: EntityField Blob Int
```

then, when analyzing Client.hs, the `hscTcRcLookupName` function FAILS.

Clearly there is some difference in how `hscTcRcLookupName` works in these
two cases.

Does someone know what it is?

Thanks in advance!

- Ranjit.


On Thu, Jan 25, 2018 at 4:24 PM, Ranjit Jhala  wrote:

> Hi all,
>
> I am stuck on the following problem.
>
> Suppose you have two module
>
>Lib
>
>Client
>
> where Client "imports" Lib. Now, while analyzing the Core of `Client`
> often I need to resolve the name of a `TyThing` defined inside `Lib`.
> Normally, this is easy enough: I simply use
>
>hscTcRcLookupName :: HscEnv
> 
> -> Name
> 
> -> IO
> 
> (Maybe
> 
> TyThing
> 
> )
>
> defined inside HscMain.
>
> **THE PROBLEM** However, I find that when the
> relevant `Name` corresponds to something generated
> by TemplateHaskell (inside `Lib`) then the above `hscTcRcLookupName` fails
> to return any result!
> Even more oddly, suppose the name was
>
>BlogPostId
>
> If there are TWO `TyThing`s with that name, e.g.
> a type synonym defined
>
>type BlogPostId = ...
>
> and also a data constructor for a data family
> instance, then `hscTcRcLookupName` only returns
> the type synonym, but refuses to return the data constructor.
>
> Does anyone know what may be going on?
>
> Thanks!
>
> - Ranjit Jhala.
>
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

(Failing to) look up names generated by Template Haskell

[Ranjit Jhala]

Hi all,

I am stuck on the following problem.

Suppose you have two module

   Lib

   Client

where Client "imports" Lib. Now, while analyzing the Core of `Client` often
I need to resolve the name of a `TyThing` defined inside `Lib`. Normally,
this is easy enough: I simply use

   hscTcRcLookupName :: HscEnv

-> Name

-> IO

(Maybe

TyThing

)

defined inside HscMain.

**THE PROBLEM** However, I find that when the
relevant `Name` corresponds to something generated
by TemplateHaskell (inside `Lib`) then the above `hscTcRcLookupName` fails
to return any result!
Even more oddly, suppose the name was

   BlogPostId

If there are TWO `TyThing`s with that name, e.g.
a type synonym defined

   type BlogPostId = ...

and also a data constructor for a data family
instance, then `hscTcRcLookupName` only returns
the type synonym, but refuses to return the data constructor.

Does anyone know what may be going on?

Thanks!

- Ranjit Jhala.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RFC: explicit support for GADTs in Template Haskell

[Jan Stolarek]

GHC Users,

I am working on adding proper support for GADTs in Template Haskell. By proper 
I mean that GADTs 
data constructors will no longer be encoded using H98 data constructors, but 
will be represented 
explicity. 

GADTs allow to declare several constructors with the same signature:

data T where
  MkT1, MkT2 :: T

The question is whether to represent such constructors in TH syntax as:

  (1) GadtC [Name] [StrictType] Name [Type]  -- or:
  (2) GadtC  Name  [StrictType] Name [Type]

Note the difference in first field. (1) is closer to the original syntax, as it 
stores the list of 
all names in a single declaration, as was originally written in the source 
code. (2) requires to 
have a separate `GadtC` for each constructor even if constructors were declared 
together, as in 
the example above.

I would like to hear from TH users which of these two representations you 
prefer. At the moment I 
have implemented (1) as it directly represents source syntax. The downside of 
(1) is that 
information whether several data constructors were declared together is not 
recoverable during 
reification, and so reifying T will yield:

data T where
  MkT1 :: T
  MkT2 :: T

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Restricted Template Haskell

[Simon Peyton Jones]

Greg (and everyone else)

The TH documentation is even more woeful than I realised.  At the very least 
there should be a section for typed TH and a section for untyped TH in the 
manual.

If I volunteer to write it, it won’t get done.  I’m in too many inner loops.

But here’s an offer: if someone (or a little group) is willing to play author, 
I will review and correct. It could be a good way to learn the details!

Ideally it would be good to have a compact specification in the user manual, 
with more detail on the Haskell wiki (where it’s easier for people to 
edit/improve).  For the latter there is already a page 
here<https://wiki.haskell.org/Template_Haskell>.

I’d really appreciate help with this.

Simon

From: Greg Weber [mailto:g...@gregweber.info]
Sent: 03 February 2015 03:42
To: Simon Peyton Jones
Cc: ghc-d...@haskell.org; GHC users; David Terei; Maxwell Swadling
Subject: Re: Restricted Template Haskell

I would like to figure out how to improve the state of TTH documentation. The 
GHC wiki is usually for things that are changing, and the page is written in 
that future style, so it makes one wonder if all things are finished or if some 
things remain unfinished. Some "this is how it is" documentation in the user 
guide would seem more useful now.

But I am not sure if the user guide [1] is even correct because it indicates a 
type of `Q (TExp a)` where I would expect just `TExp a` from reading the wiki 
[2].

[1] 
https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/template-haskell.html
[2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges

On Mon, Feb 2, 2015 at 11:31 AM, Greg Weber 
mailto:g...@gregweber.info>> wrote:
Hi Simon,

I am just starting the proposal: gathering interested parties and pointers to 
related information.
Thanks for the pointer to Typed Template Haskell. I was actually unaware of the 
extent to which Typed Template Haskell is restricted. I have not seen any usage 
of Typed Template Haskell in the wild or been able to use it myself 
unfortunately due to backwards compatibility needs (once the next GHC release 
is out libraries will start to consider dropping 7.6 support and we will see 
more usage, although Ubuntu still ships 7.6 by default).
I will study Typed Template Haskell.

Greg Weber

On Mon, Feb 2, 2015 at 9:33 AM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
The new TH is already split into two 
parts<https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal> as 
I’m sure you know

• Typed TH is for expressions only, and doesn’t have reify, nor any Q 
monad.

• Untyped TH is the wild west

Typed TH may get some of what you want?   Certainly you want to acknowledge the 
existing split in your own design.

The proposal could do with examples to illustrate what the difficulties are.  
What bad things happen in the Q monad?  Can you give examples of reasoning that 
would be valid in level 1 but not in level 2.  etc.  More precision please!

Simon

From: Glasgow-haskell-users 
[mailto:glasgow-haskell-users-boun...@haskell.org<mailto:glasgow-haskell-users-boun...@haskell.org>]
 On Behalf Of Greg Weber
Sent: 30 January 2015 23:39
To: ghc-d...@haskell.org<mailto:ghc-d...@haskell.org>; GHC users
Cc: David Terei; Maxwell Swadling
Subject: Restricted Template Haskell

Hello GHC friends!

I am starting up a proposal for variants of Template Haskell that restrict what 
operations are available. The goal is to make TH easier for users to reason 
about and to allow for an easier compilation story.

Here is the proposal page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted

Right now the proposal does not have any details and the goal is to write out a 
clear specification.
If this sounds interesting to you, let me know or leave some feedback on the 
wiki.


Thanks,
Greg Weber




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Restricted Template Haskell

[Greg Weber]

I would like to figure out how to improve the state of TTH documentation.
The GHC wiki is usually for things that are changing, and the page is
written in that future style, so it makes one wonder if all things are
finished or if some things remain unfinished. Some "this is how it is"
documentation in the user guide would seem more useful now.

But I am not sure if the user guide [1] is even correct because it
indicates a type of `Q (TExp a)` where I would expect just `TExp a` from
reading the wiki [2].

[1]
https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/template-haskell.html
[2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges

On Mon, Feb 2, 2015 at 11:31 AM, Greg Weber  wrote:

> Hi Simon,
>
> I am just starting the proposal: gathering interested parties and pointers
> to related information.
> Thanks for the pointer to Typed Template Haskell. I was actually unaware
> of the extent to which Typed Template Haskell is restricted. I have not
> seen any usage of Typed Template Haskell in the wild or been able to use it
> myself unfortunately due to backwards compatibility needs (once the next
> GHC release is out libraries will start to consider dropping 7.6 support
> and we will see more usage, although Ubuntu still ships 7.6 by default).
> I will study Typed Template Haskell.
>
> Greg Weber
>
> On Mon, Feb 2, 2015 at 9:33 AM, Simon Peyton Jones 
> wrote:
>
>>  The new TH is already split into two parts
>> <https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal> as
>> I’m sure you know
>>
>> · Typed TH is for expressions only, and doesn’t have reify, nor
>> any Q monad.
>>
>> · Untyped TH is the wild west
>>
>>
>>
>> Typed TH may get some of what you want?   Certainly you want to
>> acknowledge the existing split in your own design.
>>
>>
>>
>> The proposal could do with examples to illustrate what the difficulties
>> are.  What bad things happen in the Q monad?  Can you give examples of
>> reasoning that would be valid in level 1 but not in level 2.  etc.  More
>> precision please!
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Glasgow-haskell-users [mailto:
>> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Greg Weber
>> *Sent:* 30 January 2015 23:39
>> *To:* ghc-d...@haskell.org; GHC users
>> *Cc:* David Terei; Maxwell Swadling
>> *Subject:* Restricted Template Haskell
>>
>>
>>
>> Hello GHC friends!
>>
>>
>>
>> I am starting up a proposal for variants of Template Haskell that
>> restrict what operations are available. The goal is to make TH easier for
>> users to reason about and to allow for an easier compilation story.
>>
>>
>>
>> Here is the proposal page:
>>
>> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted
>>
>>
>>
>> Right now the proposal does not have any details and the goal is to write
>> out a clear specification.
>>
>> If this sounds interesting to you, let me know or leave some feedback on
>> the wiki.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Greg Weber
>>
>>
>>
>>
>>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Restricted Template Haskell

[Greg Weber]

Hi Simon,

I am just starting the proposal: gathering interested parties and pointers
to related information.
Thanks for the pointer to Typed Template Haskell. I was actually unaware of
the extent to which Typed Template Haskell is restricted. I have not seen
any usage of Typed Template Haskell in the wild or been able to use it
myself unfortunately due to backwards compatibility needs (once the next
GHC release is out libraries will start to consider dropping 7.6 support
and we will see more usage, although Ubuntu still ships 7.6 by default).
I will study Typed Template Haskell.

Greg Weber

On Mon, Feb 2, 2015 at 9:33 AM, Simon Peyton Jones 
wrote:

>  The new TH is already split into two parts
> <https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal> as
> I’m sure you know
>
> · Typed TH is for expressions only, and doesn’t have reify, nor
> any Q monad.
>
> · Untyped TH is the wild west
>
>
>
> Typed TH may get some of what you want?   Certainly you want to
> acknowledge the existing split in your own design.
>
>
>
> The proposal could do with examples to illustrate what the difficulties
> are.  What bad things happen in the Q monad?  Can you give examples of
> reasoning that would be valid in level 1 but not in level 2.  etc.  More
> precision please!
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Greg Weber
> *Sent:* 30 January 2015 23:39
> *To:* ghc-d...@haskell.org; GHC users
> *Cc:* David Terei; Maxwell Swadling
> *Subject:* Restricted Template Haskell
>
>
>
> Hello GHC friends!
>
>
>
> I am starting up a proposal for variants of Template Haskell that restrict
> what operations are available. The goal is to make TH easier for users to
> reason about and to allow for an easier compilation story.
>
>
>
> Here is the proposal page:
>
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted
>
>
>
> Right now the proposal does not have any details and the goal is to write
> out a clear specification.
>
> If this sounds interesting to you, let me know or leave some feedback on
> the wiki.
>
>
>
>
>
> Thanks,
>
> Greg Weber
>
>
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Restricted Template Haskell

[Simon Peyton Jones]

The new TH is already split into two 
parts<https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal> as 
I’m sure you know

· Typed TH is for expressions only, and doesn’t have reify, nor any Q 
monad.

· Untyped TH is the wild west

Typed TH may get some of what you want?   Certainly you want to acknowledge the 
existing split in your own design.

The proposal could do with examples to illustrate what the difficulties are.  
What bad things happen in the Q monad?  Can you give examples of reasoning that 
would be valid in level 1 but not in level 2.  etc.  More precision please!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Greg Weber
Sent: 30 January 2015 23:39
To: ghc-d...@haskell.org; GHC users
Cc: David Terei; Maxwell Swadling
Subject: Restricted Template Haskell

Hello GHC friends!

I am starting up a proposal for variants of Template Haskell that restrict what 
operations are available. The goal is to make TH easier for users to reason 
about and to allow for an easier compilation story.

Here is the proposal page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted

Right now the proposal does not have any details and the goal is to write out a 
clear specification.
If this sounds interesting to you, let me know or leave some feedback on the 
wiki.


Thanks,
Greg Weber


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Restricted Template Haskell

[Greg Weber]

On Fri, Jan 30, 2015 at 7:05 PM, adam vogt  wrote:

> Hi Greg,
>
> Perhaps a less-invasive way to implement the -XSafe part of your
> proposal would be to provide a module like:
>
> module Language.Haskell.TH.Safe (
>   module Language.Haskell.TH,
>   reifyWithoutNameG,
>  )  where
> import Language.Haskell.TH hiding (runIO, reify*)
>
> where reifyWithoutNameG is the same as reify, except definitions that
> are out of scope are either missing or modified such that they use
> NameQ instead of NameG for out-of-scope names.
>

Thanks, I added this concept to the wiki.


> That way there is no new syntax needed, and safe TH can be called by
> unsafe TH without any conversions.
>
> I think defining another monad like Q that can do less is too
> inconvenient because you have to disambiguate between Safe.listE and
> Unsafe.listE, or make those functions more polymorphic (which makes
> type errors worse). Another option would be if there were
>

Oh, you are getting into more concrete details now than I have even thought
about!
For the restricted monad route, we might look into a more capable method of
using capabilities that would end up looking like this:

reify :: Name -> Restrict (TH :+: Reify) Info
runIO :: IO a -> Restrict (TH :+: RunIO) a

There are still a lot of details to work out, thanks for getting things
started.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Restricted Template Haskell

[adam vogt]

Hi Greg,

Perhaps a less-invasive way to implement the -XSafe part of your
proposal would be to provide a module like:

module Language.Haskell.TH.Safe (
  module Language.Haskell.TH,
  reifyWithoutNameG,
 )  where
import Language.Haskell.TH hiding (runIO, reify*)

where reifyWithoutNameG is the same as reify, except definitions that
are out of scope are either missing or modified such that they use
NameQ instead of NameG for out-of-scope names.

That way there is no new syntax needed, and safe TH can be called by
unsafe TH without any conversions.

I think defining another monad like Q that can do less is too
inconvenient because you have to disambiguate between Safe.listE and
Unsafe.listE, or make those functions more polymorphic (which makes
type errors worse). Another option would be if there were

newtype QThat (canIO :: Bool) (canReify :: Bool) (canNewName :: Bool)
   = QThat (TheRealQImplementation)

type Q = QThat True True True

listE :: Monad m => [m Exp] -> m Exp
listE = liftM ListE . sequence

reify :: Name -> QThat a True b Info
runIO :: IO a -> QThat True b c a

runQFFF :: QThat False False False a -> a
runQTFF :: QThat True False False a -> IO a


But I think that design would be a step in the direction of "harder to
reason about"

Regards,
Adam


On Fri, Jan 30, 2015 at 6:39 PM, Greg Weber  wrote:
> Hello GHC friends!
>
> I am starting up a proposal for variants of Template Haskell that restrict
> what operations are available. The goal is to make TH easier for users to
> reason about and to allow for an easier compilation story.
>
> Here is the proposal page:
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted
>
> Right now the proposal does not have any details and the goal is to write
> out a clear specification.
> If this sounds interesting to you, let me know or leave some feedback on the
> wiki.
>
>
> Thanks,
> Greg Weber
>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Restricted Template Haskell

[Greg Weber]

Hello GHC friends!

I am starting up a proposal for variants of Template Haskell that restrict
what operations are available. The goal is to make TH easier for users to
reason about and to allow for an easier compilation story.

Here is the proposal page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted

Right now the proposal does not have any details and the goal is to write
out a clear specification.
If this sounds interesting to you, let me know or leave some feedback on
the wiki.


Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: template haskell vs. -prof

[Evan Laforge]

On Sat, Jan 24, 2015 at 1:29 PM, John Lato  wrote:
> I mean to use a ghc that's been built without dynamic support.

Oh, so if the whole compiler is not dynamic then TH no longer requires
.dyn_o files?  Interesting.

I know they've put a lot of work into this and staging is hard, so I
assume there are good reasons for it :)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: template haskell vs. -prof

[John Lato]

On 21:23, Fri, Jan 23, 2015 Evan Laforge  wrote:

On Sat, Jan 24, 2015 at 2:38 AM, John Lato  wrote:
> I agree that mixing template haskell with -prof can be tricky.  It's
easier if you turn
> off dynamic linking entirely.

But that's the thing, I do turn of dynamic linking because I have to
for -prof, but TH seems to require it.

 I mean to use a ghc that's been built without dynamic support.

 > unlines
>   [ "Line 1"
>   , "Line 2"
>   ]
>
> which ends up being pretty maintainable and easy to read.

Yeah, I use this one too.  It's ok for short things, but it can still
be annoying to edit.  My editor doesn't know how to do line wrapping
for it.  Then you can't just copy paste in and out.  And tabs get
messed up because you're already indented, and probably not in a
tabstop multiple... though I guess I could align it so it was.  And of
course since there's prefix gunk, folding doesn't work inside.

 Yeah, those are all problematic.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: template haskell vs. -prof

[Evan Laforge]

On Sat, Jan 24, 2015 at 2:38 AM, John Lato  wrote:
> I agree that mixing template haskell with -prof can be tricky.  It's easier 
> if you turn
> off dynamic linking entirely.

But that's the thing, I do turn of dynamic linking because I have to
for -prof, but TH seems to require it.

> unlines
>   [ "Line 1"
>   , "Line 2"
>   ]
>
> which ends up being pretty maintainable and easy to read.

Yeah, I use this one too.  It's ok for short things, but it can still
be annoying to edit.  My editor doesn't know how to do line wrapping
for it.  Then you can't just copy paste in and out.  And tabs get
messed up because you're already indented, and probably not in a
tabstop multiple... though I guess I could align it so it was.  And of
course since there's prefix gunk, folding doesn't work inside.

Actually, if anyone knows about a vim hack to make 'gq' handle either
this style or the backslash style, it would be much appreciated...
maybe I should try to create one.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: template haskell vs. -prof

[John Lato]

I agree that mixing template haskell with -prof can be tricky.  It's easier
if you turn off dynamic linking entirely.

As for multi-line string literals, I also think that an explicit syntax
would be nice.  Until then, I usually use:

unlines
  [ "Line 1"
  , "Line 2"
  ]

which ends up being pretty maintainable and easy to read.

On Fri Jan 23 2015 at 6:16:46 AM Evan Laforge  wrote:

> I ran into trouble compiling template haskell with -prof, and came
> across the ghc manual "7.9.4. Using Template Haskell with Profiling".
> Unfortunately I can't use its advice directly since I put profiling
> and non-profiling .o files into different directories.  But in
> principle it seems it should work, I just have to get ghc to load TH
> from the debug build directory, which is built with -dynamic, while
> continuing to load from the profile build directory.
>
> But are there flags to get it to do that?  I'm using "-osuf .hs.o
> -ibuild/profile/obj".  If I put ":build/debug/obj" on the -i line, it
> still seems to find the profiling one.  The ghc manual advice probably
> gets around it by using different -osufs... I guess TH somehow ignores
> -osuf?  Except when I compile the debug version with osuf, if finds
> them fine, so I don't really know how it works.
>
> Is there a way I can directly tell TH where to look?  It seems awkward
> to rely on all these implicit and seemingly undocumented heuristics.
>
> And, this is somewhat beside the point, but shouldn't TH theoretically
> be able to load directly from .hs and compile to bytecode like ghci
> can do if it doesn't find the .o file?
>
> And, even more beside the point, the only reason I'm messing with TH
> is for a really simple (one line) multi-line string literal
> quasiquote.  Surely I'm not the only person who would enjoy a
> -XMultiLineStringLiteral extension?  The alternative seems to be a
> program to add or strip all of the "\n\"s, and when I want to edit,
> copy out, strip, edit, paste back in, add back.  At that point maybe
> it's easier to just get used to all the \s... but then indentation is
> all a bit off due to the leading \.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

template haskell vs. -prof

[Evan Laforge]

I ran into trouble compiling template haskell with -prof, and came
across the ghc manual "7.9.4. Using Template Haskell with Profiling".
Unfortunately I can't use its advice directly since I put profiling
and non-profiling .o files into different directories.  But in
principle it seems it should work, I just have to get ghc to load TH
from the debug build directory, which is built with -dynamic, while
continuing to load from the profile build directory.

But are there flags to get it to do that?  I'm using "-osuf .hs.o
-ibuild/profile/obj".  If I put ":build/debug/obj" on the -i line, it
still seems to find the profiling one.  The ghc manual advice probably
gets around it by using different -osufs... I guess TH somehow ignores
-osuf?  Except when I compile the debug version with osuf, if finds
them fine, so I don't really know how it works.

Is there a way I can directly tell TH where to look?  It seems awkward
to rely on all these implicit and seemingly undocumented heuristics.

And, this is somewhat beside the point, but shouldn't TH theoretically
be able to load directly from .hs and compile to bytecode like ghci
can do if it doesn't find the .o file?

And, even more beside the point, the only reason I'm messing with TH
is for a really simple (one line) multi-line string literal
quasiquote.  Surely I'm not the only person who would enjoy a
-XMultiLineStringLiteral extension?  The alternative seems to be a
program to add or strip all of the "\n\"s, and when I want to edit,
copy out, strip, edit, paste back in, add back.  At that point maybe
it's easier to just get used to all the \s... but then indentation is
all a bit off due to the leading \.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Dominic Steinitz]

Thank you very much everyone. I now have a version of yarr which compiles under 
ghc 7.8.3. I have yet to do the conditional compilation hackery to support back 
versions but then I can make a release.

What a great community :-)

Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuch.wordpress.com
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Francesco Mazzoli]

I forgot to mention that `cpphs' can mimick gcc's cpp, with the flag
`-cpp'.  In Agda we have

ghc-options: -pgmPcpphs -optP--cpp

Francesco

On 24 December 2014 at 10:50, Francesco Mazzoli  wrote:
> You can specify the pre-processor in the `ghc-options' field in the
> cabal file, e.g.
>
> ghc-options: -pgmPcpphs
>
> Francesco
>
> On 23 December 2014 at 17:14, Brandon Allbery  wrote:
>> On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz 
>> wrote:
>>>
>>> How very clever of you and thank you very much. Changing ‘ to 1 does fix
>>> the problem.
>>>
>>> I would have thought this would work
>>>
>>> cabal install --with-gcc=gcc-4.9
>>>
>>>
>>> But sadly I still got the same error.
>>
>>
>> I think that changes the gcc cabal uses to compile C code, but does not
>> affect how ghc invokes cpp. Or put otherwise, there are too many ways that a
>> C compiler can be dragged into the build pipeline (building C code
>> explicitly [via cabal or via ghc foo.c, two different cases], wrapped FFI
>> calls in ghc, -fvia-C, CPP, ...).
>>
>> --
>> brandon s allbery kf8nh   sine nomine associates
>> allber...@gmail.com  ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
>>
>> ___
>> Libraries mailing list
>> librar...@haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Francesco Mazzoli]

You can specify the pre-processor in the `ghc-options' field in the
cabal file, e.g.

ghc-options: -pgmPcpphs

Francesco

On 23 December 2014 at 17:14, Brandon Allbery  wrote:
> On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz 
> wrote:
>>
>> How very clever of you and thank you very much. Changing ‘ to 1 does fix
>> the problem.
>>
>> I would have thought this would work
>>
>> cabal install --with-gcc=gcc-4.9
>>
>>
>> But sadly I still got the same error.
>
>
> I think that changes the gcc cabal uses to compile C code, but does not
> affect how ghc invokes cpp. Or put otherwise, there are too many ways that a
> C compiler can be dragged into the build pipeline (building C code
> explicitly [via cabal or via ghc foo.c, two different cases], wrapped FFI
> calls in ghc, -fvia-C, CPP, ...).
>
> --
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
>
> ___
> Libraries mailing list
> librar...@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Brandon Allbery]

On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz 
wrote:

> How very clever of you and thank you very much. Changing ‘ to 1 does fix
> the problem.
>
> I would have thought this would work
>
> cabal install --with-gcc=gcc-4.9
>
>
> But sadly I still got the same error.
>

I think that changes the gcc cabal uses to compile C code, but does not
affect how ghc invokes cpp. Or put otherwise, there are too many ways that
a C compiler can be dragged into the build pipeline (building C code
explicitly [via cabal or via ghc foo.c, two different cases], wrapped FFI
calls in ghc, -fvia-C, CPP, ...).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Dominic Steinitz]

> $ cabal --version
> cabal-install version 1.19.1
> using version 1.19.1 of the Cabal library 

Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuch.wordpress.com

On 23 Dec 2014, at 15:54, Carter Schonwald  wrote:

> what version of cabal-install are you using?
> 
> On Tue, Dec 23, 2014 at 10:46 AM, Dominic Steinitz  
> wrote:
> Ok I have a cut down version of the problem and am cross posting to 
> glasgow-haskell-users.
> 
> To restate the problem: this is from code that has not been changed for 2 
> years. I get
> 
> > Examples.hs:42:42: Parse error in pattern: con
> > Failed, modules loaded: none.
> 
> Any help would be very gratefully received.
> 
> > {-# LANGUAGE TypeFamilies, MultiParamTypeClasses, 
> > FunctionalDependencies #-}
> > {-# LANGUAGE FlexibleContexts #-}
> > {-# LANGUAGE EmptyDataDecls #-}
> > {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
> > {-# LANGUAGE UndecidableInstances, OverlappingInstances #-}
> > {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-}
> > {-# LANGUAGE RankNTypes, ScopedTypeVariables #-}
> > {-# LANGUAGE MagicHash, BangPatterns, UnboxedTuples #-}
> > {-# LANGUAGE TemplateHaskell, CPP #-}
> >
> > module Examples where
> >
> > import GHC.Prim
> > import GHC.Exts
> > import GHC.Types
> > import GHC.Word
> > import GHC.Int
> >
> > class Touchable a where
> > touch :: a -> IO ()
> >
> > instance Touchable Bool where
> > touch b = IO (\s -> case touch# b s of s' -> (# s', () #))
> > {-# INLINE touch #-}
> >
> > #define TOUCHABLE_INST(ty,con)  \
> > instance Touchable ty where {   \
> > touch (con x#) = IO (\s -> case touch# x# s of s' -> (# s', () #)); \
> > {-# INLINE touch #-};   \
> > }
> >
> > TOUCHABLE_INST(Int, I#)
> >
> > #define PRIM_COMP_INST(ty,con,le,ge) \
> > instance PrimitiveOrd ty where { \
> > minM' (con a#) (con b#) =\
> > IO (\s ->\
> > let r# = if le a# b# then a# else b# \
> > in case touch# r# s of s' -> (# s', (con r#) #));\
> > }
> >
> > PRIM_COMP_INST(Int, I#, (<=#), (>=#))
> 
> Dominic Steinitz
> domi...@steinitz.org
> http://idontgetoutmuch.wordpress.com
> 
> On 23 Dec 2014, at 15:06, Dominic Steinitz  wrote:
> 
> > Hi Erik,
> >
> > Thank you very much. With that clue the compilation now doesn’t fail at 
> > that particular point.
> >
> > The bad news is it now fails to compile this module
> >
> > https://hackage.haskell.org/package/yarr-1.3.2/docs/src/Data-Yarr-Utils-Primitive.html#clampM%27
> >
> > with a parse error(!). Not only do I not have much experience with TH but 
> > this has now exposed my ignorance of CPP.
> >
> >> Data/Yarr/Utils/Primitive.hs:119:126: Parse error in pattern: con
> >
> > If I comment out the last four lines
> >
> >> PRIM_COMP_INST(Int, I#, (<=#), (>=#))
> >> PRIM_COMP_INST(Char, C#, leChar#, geChar#)
> >> PRIM_COMP_INST(Word, W#, leWord#, geWord#)
> >> PRIM_COMP_INST(Double, D#, (<=##), (>=##))
> >> PRIM_COMP_INST(Float, F#, leFloat#, geFloat#)
> >
> > then the module compiles but of course then the whole package does *not* 
> > compile.
> >
> > Did something change in 7.8.3 with regard to CPP (this code has not been 
> > modified for at least two years)?
> >
> > Thanks once again.
> >
> > Dominic Steinitz
> > domi...@steinitz.org
> > http://idontgetoutmuch.wordpress.com
> >
> > On 23 Dec 2014, at 13:42, Erik Hesselink  wrote:
> >
> >> Hi Dominic,
> >>
> >> It looks like just a representation change: a TySynEqn is a data type
> >> containing a [Type] and a Type, and those were the original two
> >> arguments. So it looks like with a little bit of CPP, you could
> >> support both versions. Something like
> >>
> >> #if MIN_VERSION_template_haskell(2,9,0)
> >> ...
> >> #else
> >> ...
> >> #endif
> >>
> >> In general, I think each major release of template haskell has quite
> >> some bre

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Dominic Steinitz]

How very clever of you and thank you very much. Changing ‘ to 1 does fix the 
problem.

I would have thought this would work

> cabal install --with-gcc=gcc-4.9

But sadly I still got the same error.

Do I need a special version of cpphs?

Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuch.wordpress.com

On 23 Dec 2014, at 15:58, Brandon Allbery  wrote:

> On Tue, Dec 23, 2014 at 10:46 AM, Dominic Steinitz  
> wrote:
> To restate the problem: this is from code that has not been changed for 2 
> years. I get
> 
> > Examples.hs:42:42: Parse error in pattern: con
> > Failed, modules loaded: none.
> 
> I think I see the problem. Are you by any chance on a machine which has clang 
> as its default C compiler (OS X, FreeBSD 9.3?/10.x/STABLE/CURRENT, possibly 
> others)? cpp will in that case malfunction because it won't substitute macro 
> parameters after the single quote:
> 
> > minM' (con a#) (con b#) =\
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Brandon Allbery]

On Tue, Dec 23, 2014 at 10:46 AM, Dominic Steinitz 
wrote:

> To restate the problem: this is from code that has not been changed for 2
> years. I get
>
> > Examples.hs:42:42: Parse error in pattern: con
> > Failed, modules loaded: none.
>

I think I see the problem. Are you by any chance on a machine which has
clang as its default C compiler (OS X, FreeBSD 9.3?/10.x/STABLE/CURRENT,
possibly others)? cpp will in that case malfunction because it won't
substitute macro parameters after the single quote:

> minM' (con a#) (con b#) =\

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Carter Schonwald]

what version of cabal-install are you using?

On Tue, Dec 23, 2014 at 10:46 AM, Dominic Steinitz 
wrote:

> Ok I have a cut down version of the problem and am cross posting to
> glasgow-haskell-users.
>
> To restate the problem: this is from code that has not been changed for 2
> years. I get
>
> > Examples.hs:42:42: Parse error in pattern: con
> > Failed, modules loaded: none.
>
> Any help would be very gratefully received.
>
> > {-# LANGUAGE TypeFamilies, MultiParamTypeClasses,
> FunctionalDependencies #-}
> > {-# LANGUAGE FlexibleContexts #-}
> > {-# LANGUAGE EmptyDataDecls #-}
> > {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
> > {-# LANGUAGE UndecidableInstances, OverlappingInstances #-}
> > {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-}
> > {-# LANGUAGE RankNTypes, ScopedTypeVariables #-}
> > {-# LANGUAGE MagicHash, BangPatterns, UnboxedTuples #-}
> > {-# LANGUAGE TemplateHaskell, CPP #-}
> >
> > module Examples where
> >
> > import GHC.Prim
> > import GHC.Exts
> > import GHC.Types
> > import GHC.Word
> > import GHC.Int
> >
> > class Touchable a where
> > touch :: a -> IO ()
> >
> > instance Touchable Bool where
> > touch b = IO (\s -> case touch# b s of s' -> (# s', () #))
> > {-# INLINE touch #-}
> >
> > #define TOUCHABLE_INST(ty,con)  \
> > instance Touchable ty where {   \
> > touch (con x#) = IO (\s -> case touch# x# s of s' -> (# s', () #)); \
> > {-# INLINE touch #-};   \
> > }
> >
> > TOUCHABLE_INST(Int, I#)
> >
> > #define PRIM_COMP_INST(ty,con,le,ge) \
> > instance PrimitiveOrd ty where { \
> > minM' (con a#) (con b#) =\
> > IO (\s ->\
> > let r# = if le a# b# then a# else b# \
> > in case touch# r# s of s' -> (# s', (con r#) #));\
> > }
> >
> > PRIM_COMP_INST(Int, I#, (<=#), (>=#))
>
> Dominic Steinitz
> domi...@steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> On 23 Dec 2014, at 15:06, Dominic Steinitz  wrote:
>
> > Hi Erik,
> >
> > Thank you very much. With that clue the compilation now doesn’t fail at
> that particular point.
> >
> > The bad news is it now fails to compile this module
> >
> >
> https://hackage.haskell.org/package/yarr-1.3.2/docs/src/Data-Yarr-Utils-Primitive.html#clampM%27
> >
> > with a parse error(!). Not only do I not have much experience with TH
> but this has now exposed my ignorance of CPP.
> >
> >> Data/Yarr/Utils/Primitive.hs:119:126: Parse error in pattern: con
> >
> > If I comment out the last four lines
> >
> >> PRIM_COMP_INST(Int, I#, (<=#), (>=#))
> >> PRIM_COMP_INST(Char, C#, leChar#, geChar#)
> >> PRIM_COMP_INST(Word, W#, leWord#, geWord#)
> >> PRIM_COMP_INST(Double, D#, (<=##), (>=##))
> >> PRIM_COMP_INST(Float, F#, leFloat#, geFloat#)
> >
> > then the module compiles but of course then the whole package does *not*
> compile.
> >
> > Did something change in 7.8.3 with regard to CPP (this code has not been
> modified for at least two years)?
> >
> > Thanks once again.
> >
> > Dominic Steinitz
> > domi...@steinitz.org
> > http://idontgetoutmuch.wordpress.com
> >
> > On 23 Dec 2014, at 13:42, Erik Hesselink  wrote:
> >
> >> Hi Dominic,
> >>
> >> It looks like just a representation change: a TySynEqn is a data type
> >> containing a [Type] and a Type, and those were the original two
> >> arguments. So it looks like with a little bit of CPP, you could
> >> support both versions. Something like
> >>
> >> #if MIN_VERSION_template_haskell(2,9,0)
> >> ...
> >> #else
> >> ...
> >> #endif
> >>
> >> In general, I think each major release of template haskell has quite
> >> some breaking changes, but I don't know of any place where they're
> >> enumerated. The GHC changelog only has a couple of high level bullet
> >> points.
> >>
> >> Regards,
> >>
> >> Erik
> >>
> >> On Tue, Dec 23

CPP Help (was Re: Latest Template Haskell Breaks Package)

[Dominic Steinitz]

Ok I have a cut down version of the problem and am cross posting to 
glasgow-haskell-users.

To restate the problem: this is from code that has not been changed for 2 
years. I get

> Examples.hs:42:42: Parse error in pattern: con
> Failed, modules loaded: none.

Any help would be very gratefully received.

> {-# LANGUAGE TypeFamilies, MultiParamTypeClasses, 
> FunctionalDependencies #-}
> {-# LANGUAGE FlexibleContexts #-}
> {-# LANGUAGE EmptyDataDecls #-}
> {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
> {-# LANGUAGE UndecidableInstances, OverlappingInstances #-}
> {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-}
> {-# LANGUAGE RankNTypes, ScopedTypeVariables #-}
> {-# LANGUAGE MagicHash, BangPatterns, UnboxedTuples #-}
> {-# LANGUAGE TemplateHaskell, CPP #-}
> 
> module Examples where
> 
> import GHC.Prim
> import GHC.Exts
> import GHC.Types
> import GHC.Word
> import GHC.Int
> 
> class Touchable a where
> touch :: a -> IO ()
> 
> instance Touchable Bool where
> touch b = IO (\s -> case touch# b s of s' -> (# s', () #))
> {-# INLINE touch #-}
> 
> #define TOUCHABLE_INST(ty,con)  \
> instance Touchable ty where {   \
> touch (con x#) = IO (\s -> case touch# x# s of s' -> (# s', () #)); \
> {-# INLINE touch #-};   \
> }
> 
> TOUCHABLE_INST(Int, I#)
> 
> #define PRIM_COMP_INST(ty,con,le,ge) \
> instance PrimitiveOrd ty where { \
> minM' (con a#) (con b#) =\
> IO (\s ->\
> let r# = if le a# b# then a# else b# \
> in case touch# r# s of s' -> (# s', (con r#) #));\
> }
> 
> PRIM_COMP_INST(Int, I#, (<=#), (>=#))

Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuch.wordpress.com

On 23 Dec 2014, at 15:06, Dominic Steinitz  wrote:

> Hi Erik,
> 
> Thank you very much. With that clue the compilation now doesn’t fail at that 
> particular point.
> 
> The bad news is it now fails to compile this module
> 
> https://hackage.haskell.org/package/yarr-1.3.2/docs/src/Data-Yarr-Utils-Primitive.html#clampM%27
> 
> with a parse error(!). Not only do I not have much experience with TH but 
> this has now exposed my ignorance of CPP.
> 
>> Data/Yarr/Utils/Primitive.hs:119:126: Parse error in pattern: con
> 
> If I comment out the last four lines
> 
>> PRIM_COMP_INST(Int, I#, (<=#), (>=#))
>> PRIM_COMP_INST(Char, C#, leChar#, geChar#)
>> PRIM_COMP_INST(Word, W#, leWord#, geWord#)
>> PRIM_COMP_INST(Double, D#, (<=##), (>=##))
>> PRIM_COMP_INST(Float, F#, leFloat#, geFloat#)
> 
> then the module compiles but of course then the whole package does *not* 
> compile.
> 
> Did something change in 7.8.3 with regard to CPP (this code has not been 
> modified for at least two years)?
> 
> Thanks once again.
> 
> Dominic Steinitz
> domi...@steinitz.org
> http://idontgetoutmuch.wordpress.com
> 
> On 23 Dec 2014, at 13:42, Erik Hesselink  wrote:
> 
>> Hi Dominic,
>> 
>> It looks like just a representation change: a TySynEqn is a data type
>> containing a [Type] and a Type, and those were the original two
>> arguments. So it looks like with a little bit of CPP, you could
>> support both versions. Something like
>> 
>> #if MIN_VERSION_template_haskell(2,9,0)
>> ...
>> #else
>> ...
>> #endif
>> 
>> In general, I think each major release of template haskell has quite
>> some breaking changes, but I don't know of any place where they're
>> enumerated. The GHC changelog only has a couple of high level bullet
>> points.
>> 
>> Regards,
>> 
>> Erik
>> 
>> On Tue, Dec 23, 2014 at 2:20 PM, Dominic Steinitz  
>> wrote:
>>> I realise I should have sent this to the libraries list.
>>> 
>>> Dominic Steinitz
>>> domi...@steinitz.org
>>> http://idontgetoutmuch.wordpress.com
>>> 
>>> Begin forwarded message:
>>> 
>>> From: Dominic Steinitz 
>>> Subject: Latest Template Haskell Breaks Package
>>> Date: 23 December 2014 13:14:26 GMT
>>> To: Haskell-Cafe 
>>> 
>>> Hello Fellow Haskellers,
>>> 
>>> I have become a maintainer for yarr
>>> (https://hackage.haskell.o

Re: Irreducible predicates error in Template Haskell

[Richard Eisenberg]

This fix will not get merged into the 7.8.x development stream, but it is 
already available in HEAD and will be available in GHC 7.10.x. We try not to 
make breaking changes (and this is a breaking change) in the middle of a major 
version.

Richard

On Oct 29, 2014, at 11:27 AM, Sreenidhi Nair  wrote:

> Hello,
> 
> we were trying to reify a typeclass, which had a ConstraintKind and we hit 
> upon this error: "Can't represent irreducible predicates in Template 
> Haskell:".
> 
> It seems that there is already a ghc bug [ 
> https://ghc.haskell.org/trac/ghc/ticket/7021 ] filed and its status is set as 
> fixed, but there is a comment at the bottom in which the reviewer recommends 
> against merging immediately. Does anybody know when it would get merged in? 
> 
> -- 
> Yours truly,
> Sreenidhi Nair
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Irreducible predicates error in Template Haskell

[Sreenidhi Nair]

Hello,

we were trying to reify a typeclass, which had a ConstraintKind and we hit
upon this error: "Can't represent irreducible predicates in Template
Haskell:".

It seems that there is already a ghc bug [
https://ghc.haskell.org/trac/ghc/ticket/7021 ] filed and its status is set
as fixed, but there is a comment at the bottom in which the reviewer
recommends against merging immediately. Does anybody know when it would get
merged in?

-- 
Yours truly,
Sreenidhi Nair
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GADTs in implementation of Template Haskell

[Gershom B]

On October 20, 2014 at 2:35:27 PM, Richard Eisenberg (e...@cis.upenn.edu) wrote:
> Having done so, I'm not 100% convinced that this is the right thing to do. I 
> would love feedback  
> on my full, concrete proposal available at 
> https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs  
>  
> Is this a change for the better or worse? Feel free either to comment on the 
> wiki page or  
> to this email.
>  
> Thanks!
> Richard

As I understand it, the big downsides are that we don’t get `gunfold` for Dec 
and Pragma, and we may not get `Generic` instances for them at all.

At first this felt pretty bad, but then I reviewed how generics and TH tend to 
get used together, and now I’m not _quite_ as anxious. In my mind the main use 
case for them is in things like this: 
http://www.well-typed.com/blog/2014/10/quasi-quoting-dsls/ — skimming the code 
involved, and the way `dataToExpQ` and friends tend to work, the key bit is 
having the generic instances on what we’re inducting on, not what we’re 
building… By the time we hit concrete TH syntax, it feels a bit late to be 
doing further generic transformations on it, so I have a suspicion this won’t 
hit anyone. I certainly don’t think it’ll affect _my_ uses of TH at least :-)

Cheers,
Gershom
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GADTs in implementation of Template Haskell

[Richard Eisenberg]

I'm doing a bunch of bug-fixes / improvements to Template Haskell. Two of these 
are to fix GHC bugs #8100 (add standalone-deriving support) and #9064 (add 
`default` method type signature support), both of which introduce new 
constructors for `Dec`. This got me thinking about `Dec` and the fact that 
different declaration forms are allowable in different contexts. (For example, 
datatype declarations are allowable only at the top level, and fixity 
declarations are allowable anywhere except in instance declarations.) How to 
encode these restrictions? With types, of course! Thus, I redesigned `Dec` to 
be a GADT.

Having done so, I'm not 100% convinced that this is the right thing to do. I 
would love feedback on my full, concrete proposal available at 
https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs  

Is this a change for the better or worse? Feel free either to comment on the 
wiki page or to this email.

Thanks!
Richard___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Greg Weber]

I created a GHC patch that spits out the generated Template Haskell code to
a file with -dump-to-file -ddump-splices
https://ghc.haskell.org/trac/ghc/ticket/9126


On Sat, Jul 5, 2014 at 8:18 PM, adam vogt  wrote:

> Zeroth takes the first approach. It only supports a subset of TH
> (DecsQ splices) however.
>
> http://hackage.haskell.org/package/zeroth
>
> https://github.com/aavogt/zeroth is a fork that works with more recent
> haskell-src-exts and ghc
>
> On Sat, Jul 5, 2014 at 3:59 PM, John Meacham  wrote:
> > Actually, I was looking into it a little, and template haskell could
> > effectively be implemented by a pre-processor and a portable library
> > that is compiler independent. If one could get ghc to spit out the
> > template haskell source after it expands it then that can be fed to
> > jhc as a quick first pass, but ideally the pre-processor TH would
> > create programs that can be run under the target compiler. that would
> > bring TH to every haskell compiler.
> >
> > John
> >
> > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery 
> wrote:
> >> On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald
> >>  wrote:
> >>>
> >>> does JHC support template haskell?
> >>
> >>
> >> Pretty sure TH is too closely tied to ghc.
> >>
> >> --
> >> brandon s allbery kf8nh   sine nomine
> associates
> >> allber...@gmail.com
> ballb...@sinenomine.net
> >> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> >
> >
> >
> > --
> > John Meacham - http://notanumber.net/
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[adam vogt]

Zeroth takes the first approach. It only supports a subset of TH
(DecsQ splices) however.

http://hackage.haskell.org/package/zeroth

https://github.com/aavogt/zeroth is a fork that works with more recent
haskell-src-exts and ghc

On Sat, Jul 5, 2014 at 3:59 PM, John Meacham  wrote:
> Actually, I was looking into it a little, and template haskell could
> effectively be implemented by a pre-processor and a portable library
> that is compiler independent. If one could get ghc to spit out the
> template haskell source after it expands it then that can be fed to
> jhc as a quick first pass, but ideally the pre-processor TH would
> create programs that can be run under the target compiler. that would
> bring TH to every haskell compiler.
>
> John
>
> On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery  wrote:
>> On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald
>>  wrote:
>>>
>>> does JHC support template haskell?
>>
>>
>> Pretty sure TH is too closely tied to ghc.
>>
>> --
>> brandon s allbery kf8nh   sine nomine associates
>> allber...@gmail.com  ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
>
>
>
> --
> John Meacham - http://notanumber.net/
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Luite Stegeman]

I'm not sure I correctly understand your approach, but to have the template
haskell reification work without any runtime communication with the
compiler you'd have to include the entire typechecker state, at least for
all names reachable from the splice (see
http://hackage.haskell.org/package/template-haskell-2.9.0.0/docs/Language-Haskell-TH-Syntax.html
, the Quasi class for the required functionality). This would mean
serializing all names with types modules, annotations, instances. I briefly
looked into this for GHCJS but decided that just querying the compiler
would be better.


On Sat, Jul 5, 2014 at 10:39 PM, John Meacham  wrote:

> The target compiler would have the TH libraries, which could be made
> to be portable. The external program would just extract the TH bits
> and turn them into a program that spits the TH expanded output to a
> new file to compile, and repeat the process til no TH expansions exist
> and finally that is the result you pass to the compiler.
>
>  John
>
> On Sat, Jul 5, 2014 at 1:09 PM, Luite Stegeman  wrote:
> > How would you do reification with that approach?
> >
> >
> > On Sat, Jul 5, 2014 at 9:59 PM, John Meacham  wrote:
> >>
> >> Actually, I was looking into it a little, and template haskell could
> >> effectively be implemented by a pre-processor and a portable library
> >> that is compiler independent. If one could get ghc to spit out the
> >> template haskell source after it expands it then that can be fed to
> >> jhc as a quick first pass, but ideally the pre-processor TH would
> >> create programs that can be run under the target compiler. that would
> >> bring TH to every haskell compiler.
> >>
> >> John
> >>
> >> On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery 
> >> wrote:
> >> > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald
> >> >  wrote:
> >> >>
> >> >> does JHC support template haskell?
> >> >
> >> >
> >> > Pretty sure TH is too closely tied to ghc.
> >> >
> >> > --
> >> > brandon s allbery kf8nh   sine nomine
> >> > associates
> >> > allber...@gmail.com
> >> > ballb...@sinenomine.net
> >> > unix, openafs, kerberos, infrastructure, xmonad
> >> > http://sinenomine.net
> >>
> >>
> >>
> >> --
> >> John Meacham - http://notanumber.net/
> >> ___
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users@haskell.org
> >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> >
>
>
>
> --
> John Meacham - http://notanumber.net/
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[John Meacham]

The target compiler would have the TH libraries, which could be made
to be portable. The external program would just extract the TH bits
and turn them into a program that spits the TH expanded output to a
new file to compile, and repeat the process til no TH expansions exist
and finally that is the result you pass to the compiler.

 John

On Sat, Jul 5, 2014 at 1:09 PM, Luite Stegeman  wrote:
> How would you do reification with that approach?
>
>
> On Sat, Jul 5, 2014 at 9:59 PM, John Meacham  wrote:
>>
>> Actually, I was looking into it a little, and template haskell could
>> effectively be implemented by a pre-processor and a portable library
>> that is compiler independent. If one could get ghc to spit out the
>> template haskell source after it expands it then that can be fed to
>> jhc as a quick first pass, but ideally the pre-processor TH would
>> create programs that can be run under the target compiler. that would
>> bring TH to every haskell compiler.
>>
>> John
>>
>> On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery 
>> wrote:
>> > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald
>> >  wrote:
>> >>
>> >> does JHC support template haskell?
>> >
>> >
>> > Pretty sure TH is too closely tied to ghc.
>> >
>> > --
>> > brandon s allbery kf8nh   sine nomine
>> > associates
>> > allber...@gmail.com
>> > ballb...@sinenomine.net
>> > unix, openafs, kerberos, infrastructure, xmonad
>> > http://sinenomine.net
>>
>>
>>
>> --
>> John Meacham - http://notanumber.net/
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>



-- 
John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Luite Stegeman]

How would you do reification with that approach?


On Sat, Jul 5, 2014 at 9:59 PM, John Meacham  wrote:

> Actually, I was looking into it a little, and template haskell could
> effectively be implemented by a pre-processor and a portable library
> that is compiler independent. If one could get ghc to spit out the
> template haskell source after it expands it then that can be fed to
> jhc as a quick first pass, but ideally the pre-processor TH would
> create programs that can be run under the target compiler. that would
> bring TH to every haskell compiler.
>
> John
>
> On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery 
> wrote:
> > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald
> >  wrote:
> >>
> >> does JHC support template haskell?
> >
> >
> > Pretty sure TH is too closely tied to ghc.
> >
> > --
> > brandon s allbery kf8nh   sine nomine
> associates
> > allber...@gmail.com
> ballb...@sinenomine.net
> > unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
>
>
> --
> John Meacham - http://notanumber.net/
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[John Meacham]

Actually, I was looking into it a little, and template haskell could
effectively be implemented by a pre-processor and a portable library
that is compiler independent. If one could get ghc to spit out the
template haskell source after it expands it then that can be fed to
jhc as a quick first pass, but ideally the pre-processor TH would
create programs that can be run under the target compiler. that would
bring TH to every haskell compiler.

John

On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery  wrote:
> On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald
>  wrote:
>>
>> does JHC support template haskell?
>
>
> Pretty sure TH is too closely tied to ghc.
>
> --
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net



-- 
John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Brandon Allbery]

On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald  wrote:

> does JHC support template haskell?


Pretty sure TH is too closely tied to ghc.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Carter Schonwald]

does JHC support template haskell?


On Sat, Jul 5, 2014 at 12:02 PM, Scott Turner <2hask...@pkturner.org> wrote:

> It installed and worked on my Nexus 5.
>
> On 2014-07-04 00:43, Dominick Samperi wrote:
> > Hello John,
> > I tried to install the Haskell demo Cube on my Nexus 7
> > and got: Error: package file was not signed correctly.
> > D
> >
> > On Thu, Jul 3, 2014 at 4:47 PM, John Meacham  wrote:
> >> In case anyone wanted to start writing haskell android code now, jhc
> >> fully supports android as a target. here is an app made with it
> >>
> >>
> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube
> >>
> >> this was made with Kiwamu's ajhc branch but code has been merged back
> >> into the main tree.
> >>
> >> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald
> >>  wrote:
> >>> This would probably be a great boon for those trying to use haskell for
> >>> Android and IOS right? how might the emulation setup work for those?
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald
> >>>  wrote:
> >>>> wow, this is great work!
> >>>>
> >>>> If theres a clear path to getting the generic tooling into 7.10, i'm
> all
> >>>> for it :) (and willing to help on concrete mechanical subtasks)
> >>>>
> >>>>
> >>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
> >>>> wrote:
> >>>>> hi all,
> >>>>>
> >>>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
> >>>>> code on node.js, rather than using the GHC linker. GHCJS has
> supported TH
> >>>>> for a long time now, but so far always relied on native (host) code
> for it.
> >>>>> This is the main reason that GHCJS always builds native and
> JavaScript code
> >>>>> for everything (another is that Cabal Setup.hs scripts need to be
> compiled
> >>>>> to some host-runnable form, but that can also be JavaScript if you
> have
> >>>>> node.js)
> >>>>>
> >>>>> Now besides the compiler having to do twice the work, this has some
> other
> >>>>> disadvantages:
> >>>>>
> >>>>> - Our JavaScript code has the same dependencies (packages) as native
> >>>>> code, which means packages like unix or Win32 show up somewhere,
> depending
> >>>>> on the host environment. This also limits our options in choosing
> >>>>> JS-specific packages.
> >>>>> - The Template Haskell code runs on the host environment, which
> might be
> >>>>> slightly different from the target, for example in integer size or
> operating
> >>>>> system specific constants.
> >>>>>
> >>>>> Moreover, building native code made the GHCJS installation procedure
> more
> >>>>> tricky, making end users think about libgmp or libiconv locations,
> since it
> >>>>> basically required the same preparation as building GHC from source.
> This
> >>>>> change will make installing much easier and more reliable (we still
> have to
> >>>>> update the build scripts).
> >>>>>
> >>>>> How it works is pretty simple:
> >>>>>
> >>>>> - When any code needs to be run on the target (hscCompileCoreExpr,
> >>>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js
> process with
> >>>>> the thrunner.js [3] script,
> >>>>> - GHCJS sends its RTS and the Template Haskell server code [1] to
> >>>>> node.js, the script starts a Haskell thread running the server,
> >>>>> - for every splice, GHCJS compiles it to JavaScript and links it
> using
> >>>>> its incremental linking functionality. The code for the splice,
> including
> >>>>> dependencies that have not yet been sent to the runner (for earlier
> >>>>> splices), is then sent in a RunTH [4] message,
> >>>>> - the runner loads and runs the code in the Q monad, can send
> queries to
> >>>>> GHCJS for reification,
> >>>>> - the runner sends back the result as a serialized Template Haskell
> AST
> >>>>> (using GHC.Generics for the Binary instances).
> >

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Scott Turner]

It installed and worked on my Nexus 5.

On 2014-07-04 00:43, Dominick Samperi wrote:
> Hello John,
> I tried to install the Haskell demo Cube on my Nexus 7
> and got: Error: package file was not signed correctly.
> D
>
> On Thu, Jul 3, 2014 at 4:47 PM, John Meacham  wrote:
>> In case anyone wanted to start writing haskell android code now, jhc
>> fully supports android as a target. here is an app made with it
>>
>> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube
>>
>> this was made with Kiwamu's ajhc branch but code has been merged back
>> into the main tree.
>>
>> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald
>>  wrote:
>>> This would probably be a great boon for those trying to use haskell for
>>> Android and IOS right? how might the emulation setup work for those?
>>>
>>>
>>>
>>>
>>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald
>>>  wrote:
>>>> wow, this is great work!
>>>>
>>>> If theres a clear path to getting the generic tooling into 7.10, i'm all
>>>> for it :) (and willing to help on concrete mechanical subtasks)
>>>>
>>>>
>>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
>>>> wrote:
>>>>> hi all,
>>>>>
>>>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
>>>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH
>>>>> for a long time now, but so far always relied on native (host) code for 
>>>>> it.
>>>>> This is the main reason that GHCJS always builds native and JavaScript 
>>>>> code
>>>>> for everything (another is that Cabal Setup.hs scripts need to be compiled
>>>>> to some host-runnable form, but that can also be JavaScript if you have
>>>>> node.js)
>>>>>
>>>>> Now besides the compiler having to do twice the work, this has some other
>>>>> disadvantages:
>>>>>
>>>>> - Our JavaScript code has the same dependencies (packages) as native
>>>>> code, which means packages like unix or Win32 show up somewhere, depending
>>>>> on the host environment. This also limits our options in choosing
>>>>> JS-specific packages.
>>>>> - The Template Haskell code runs on the host environment, which might be
>>>>> slightly different from the target, for example in integer size or 
>>>>> operating
>>>>> system specific constants.
>>>>>
>>>>> Moreover, building native code made the GHCJS installation procedure more
>>>>> tricky, making end users think about libgmp or libiconv locations, since 
>>>>> it
>>>>> basically required the same preparation as building GHC from source. This
>>>>> change will make installing much easier and more reliable (we still have 
>>>>> to
>>>>> update the build scripts).
>>>>>
>>>>> How it works is pretty simple:
>>>>>
>>>>> - When any code needs to be run on the target (hscCompileCoreExpr,
>>>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with
>>>>> the thrunner.js [3] script,
>>>>> - GHCJS sends its RTS and the Template Haskell server code [1] to
>>>>> node.js, the script starts a Haskell thread running the server,
>>>>> - for every splice, GHCJS compiles it to JavaScript and links it using
>>>>> its incremental linking functionality. The code for the splice, including
>>>>> dependencies that have not yet been sent to the runner (for earlier
>>>>> splices), is then sent in a RunTH [4] message,
>>>>> - the runner loads and runs the code in the Q monad, can send queries to
>>>>> GHCJS for reification,
>>>>> - the runner sends back the result as a serialized Template Haskell AST
>>>>> (using GHC.Generics for the Binary instances).
>>>>>
>>>>> All Template Haskell functionality is supported, including recent
>>>>> additions for reifying modules and annotations. I still need to clean up 
>>>>> and
>>>>> push the patches for the directory and process packages, but after that, 
>>>>> the
>>>>> TH code can read/write files, run processes and interact with them and

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[John Meacham]

Hmm.. It works on my nexus 4. Kiwamu of the metasepi
http://ajhc.metasepi.org/ is the one that uploaded the demo. Perhaps
he needs to update the key or something.

On Thu, Jul 3, 2014 at 9:43 PM, Dominick Samperi  wrote:
> Hello John,
> I tried to install the Haskell demo Cube on my Nexus 7
> and got: Error: package file was not signed correctly.
> D
>
> On Thu, Jul 3, 2014 at 4:47 PM, John Meacham  wrote:
>> In case anyone wanted to start writing haskell android code now, jhc
>> fully supports android as a target. here is an app made with it
>>
>> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube
>>
>> this was made with Kiwamu's ajhc branch but code has been merged back
>> into the main tree.
>>
>> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald
>>  wrote:
>>> This would probably be a great boon for those trying to use haskell for
>>> Android and IOS right? how might the emulation setup work for those?
>>>
>>>
>>>
>>>
>>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald
>>>  wrote:
>>>>
>>>> wow, this is great work!
>>>>
>>>> If theres a clear path to getting the generic tooling into 7.10, i'm all
>>>> for it :) (and willing to help on concrete mechanical subtasks)
>>>>
>>>>
>>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
>>>> wrote:
>>>>>
>>>>> hi all,
>>>>>
>>>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
>>>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH
>>>>> for a long time now, but so far always relied on native (host) code for 
>>>>> it.
>>>>> This is the main reason that GHCJS always builds native and JavaScript 
>>>>> code
>>>>> for everything (another is that Cabal Setup.hs scripts need to be compiled
>>>>> to some host-runnable form, but that can also be JavaScript if you have
>>>>> node.js)
>>>>>
>>>>> Now besides the compiler having to do twice the work, this has some other
>>>>> disadvantages:
>>>>>
>>>>> - Our JavaScript code has the same dependencies (packages) as native
>>>>> code, which means packages like unix or Win32 show up somewhere, depending
>>>>> on the host environment. This also limits our options in choosing
>>>>> JS-specific packages.
>>>>> - The Template Haskell code runs on the host environment, which might be
>>>>> slightly different from the target, for example in integer size or 
>>>>> operating
>>>>> system specific constants.
>>>>>
>>>>> Moreover, building native code made the GHCJS installation procedure more
>>>>> tricky, making end users think about libgmp or libiconv locations, since 
>>>>> it
>>>>> basically required the same preparation as building GHC from source. This
>>>>> change will make installing much easier and more reliable (we still have 
>>>>> to
>>>>> update the build scripts).
>>>>>
>>>>> How it works is pretty simple:
>>>>>
>>>>> - When any code needs to be run on the target (hscCompileCoreExpr,
>>>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with
>>>>> the thrunner.js [3] script,
>>>>> - GHCJS sends its RTS and the Template Haskell server code [1] to
>>>>> node.js, the script starts a Haskell thread running the server,
>>>>> - for every splice, GHCJS compiles it to JavaScript and links it using
>>>>> its incremental linking functionality. The code for the splice, including
>>>>> dependencies that have not yet been sent to the runner (for earlier
>>>>> splices), is then sent in a RunTH [4] message,
>>>>> - the runner loads and runs the code in the Q monad, can send queries to
>>>>> GHCJS for reification,
>>>>> - the runner sends back the result as a serialized Template Haskell AST
>>>>> (using GHC.Generics for the Binary instances).
>>>>>
>>>>> All Template Haskell functionality is supported, including recent
>>>>> additions for reifying modules and annotations. I still need to clean up 
>>>>> and
>>>>> push the patches for the directory and process packages, but after that, 
>&

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Luite Stegeman]

On Thu, Jul 3, 2014 at 6:18 PM, Simon Peyton Jones 
wrote:

>  Luite
>
>
>
> I lack the bandwidth to respond at any technical depth, but I’d like to
> make encouraging noises.  If you can figure out a way to make GHC do these
> things without making the compiler terribly complicated and making
> maintaining it harder, then I’m open to your proposals.
>
>
>
I think most of the communication code could go into a separate executable
that can be built by the user for the target-specific communication. The
GHC API facing part of the implementation in GHCJS is under 300 lines and
that includes some non-exported code duplicated from GHC, so I'm reasonably
optimistic that it can be done without too much impact.

Unfortunately I won't have much time in the near future, since a GHCJS
release is well overdue (mostly because I keep adding features like
this...) and I want to focus on that first, but getting it ready before
7.10 should be doable (especially if other people want to help!)

luite
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Dominick Samperi]

Hello John,
I tried to install the Haskell demo Cube on my Nexus 7
and got: Error: package file was not signed correctly.
D

On Thu, Jul 3, 2014 at 4:47 PM, John Meacham  wrote:
> In case anyone wanted to start writing haskell android code now, jhc
> fully supports android as a target. here is an app made with it
>
> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube
>
> this was made with Kiwamu's ajhc branch but code has been merged back
> into the main tree.
>
> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald
>  wrote:
>> This would probably be a great boon for those trying to use haskell for
>> Android and IOS right? how might the emulation setup work for those?
>>
>>
>>
>>
>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald
>>  wrote:
>>>
>>> wow, this is great work!
>>>
>>> If theres a clear path to getting the generic tooling into 7.10, i'm all
>>> for it :) (and willing to help on concrete mechanical subtasks)
>>>
>>>
>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
>>> wrote:
>>>>
>>>> hi all,
>>>>
>>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
>>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH
>>>> for a long time now, but so far always relied on native (host) code for it.
>>>> This is the main reason that GHCJS always builds native and JavaScript code
>>>> for everything (another is that Cabal Setup.hs scripts need to be compiled
>>>> to some host-runnable form, but that can also be JavaScript if you have
>>>> node.js)
>>>>
>>>> Now besides the compiler having to do twice the work, this has some other
>>>> disadvantages:
>>>>
>>>> - Our JavaScript code has the same dependencies (packages) as native
>>>> code, which means packages like unix or Win32 show up somewhere, depending
>>>> on the host environment. This also limits our options in choosing
>>>> JS-specific packages.
>>>> - The Template Haskell code runs on the host environment, which might be
>>>> slightly different from the target, for example in integer size or 
>>>> operating
>>>> system specific constants.
>>>>
>>>> Moreover, building native code made the GHCJS installation procedure more
>>>> tricky, making end users think about libgmp or libiconv locations, since it
>>>> basically required the same preparation as building GHC from source. This
>>>> change will make installing much easier and more reliable (we still have to
>>>> update the build scripts).
>>>>
>>>> How it works is pretty simple:
>>>>
>>>> - When any code needs to be run on the target (hscCompileCoreExpr,
>>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with
>>>> the thrunner.js [3] script,
>>>> - GHCJS sends its RTS and the Template Haskell server code [1] to
>>>> node.js, the script starts a Haskell thread running the server,
>>>> - for every splice, GHCJS compiles it to JavaScript and links it using
>>>> its incremental linking functionality. The code for the splice, including
>>>> dependencies that have not yet been sent to the runner (for earlier
>>>> splices), is then sent in a RunTH [4] message,
>>>> - the runner loads and runs the code in the Q monad, can send queries to
>>>> GHCJS for reification,
>>>> - the runner sends back the result as a serialized Template Haskell AST
>>>> (using GHC.Generics for the Binary instances).
>>>>
>>>> All Template Haskell functionality is supported, including recent
>>>> additions for reifying modules and annotations. I still need to clean up 
>>>> and
>>>> push the patches for the directory and process packages, but after that, 
>>>> the
>>>> TH code can read/write files, run processes and interact with them and make
>>>> network connections, all through node.js.
>>>>
>>>> Now since this approach is in no way specific to JavaScript, I was
>>>> wondering if there's any interest in getting this functionality into GHC
>>>> 7.10 for general cross compilation. The runner would be a native (target)
>>>> program with dynamic libraries (or object files) being sent over to the
>>>> target machine (or emulator) for the splices.
>>>>
>>>>

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[John Meacham]

In case anyone wanted to start writing haskell android code now, jhc
fully supports android as a target. here is an app made with it

https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube

this was made with Kiwamu's ajhc branch but code has been merged back
into the main tree.

On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald
 wrote:
> This would probably be a great boon for those trying to use haskell for
> Android and IOS right? how might the emulation setup work for those?
>
>
>
>
> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald
>  wrote:
>>
>> wow, this is great work!
>>
>> If theres a clear path to getting the generic tooling into 7.10, i'm all
>> for it :) (and willing to help on concrete mechanical subtasks)
>>
>>
>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
>> wrote:
>>>
>>> hi all,
>>>
>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH
>>> for a long time now, but so far always relied on native (host) code for it.
>>> This is the main reason that GHCJS always builds native and JavaScript code
>>> for everything (another is that Cabal Setup.hs scripts need to be compiled
>>> to some host-runnable form, but that can also be JavaScript if you have
>>> node.js)
>>>
>>> Now besides the compiler having to do twice the work, this has some other
>>> disadvantages:
>>>
>>> - Our JavaScript code has the same dependencies (packages) as native
>>> code, which means packages like unix or Win32 show up somewhere, depending
>>> on the host environment. This also limits our options in choosing
>>> JS-specific packages.
>>> - The Template Haskell code runs on the host environment, which might be
>>> slightly different from the target, for example in integer size or operating
>>> system specific constants.
>>>
>>> Moreover, building native code made the GHCJS installation procedure more
>>> tricky, making end users think about libgmp or libiconv locations, since it
>>> basically required the same preparation as building GHC from source. This
>>> change will make installing much easier and more reliable (we still have to
>>> update the build scripts).
>>>
>>> How it works is pretty simple:
>>>
>>> - When any code needs to be run on the target (hscCompileCoreExpr,
>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with
>>> the thrunner.js [3] script,
>>> - GHCJS sends its RTS and the Template Haskell server code [1] to
>>> node.js, the script starts a Haskell thread running the server,
>>> - for every splice, GHCJS compiles it to JavaScript and links it using
>>> its incremental linking functionality. The code for the splice, including
>>> dependencies that have not yet been sent to the runner (for earlier
>>> splices), is then sent in a RunTH [4] message,
>>> - the runner loads and runs the code in the Q monad, can send queries to
>>> GHCJS for reification,
>>> - the runner sends back the result as a serialized Template Haskell AST
>>> (using GHC.Generics for the Binary instances).
>>>
>>> All Template Haskell functionality is supported, including recent
>>> additions for reifying modules and annotations. I still need to clean up and
>>> push the patches for the directory and process packages, but after that, the
>>> TH code can read/write files, run processes and interact with them and make
>>> network connections, all through node.js.
>>>
>>> Now since this approach is in no way specific to JavaScript, I was
>>> wondering if there's any interest in getting this functionality into GHC
>>> 7.10 for general cross compilation. The runner would be a native (target)
>>> program with dynamic libraries (or object files) being sent over to the
>>> target machine (or emulator) for the splices.
>>>
>>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of
>>> concept (without reification) at BudHac.
>>>
>>> cheers,
>>>
>>> Luite
>>>
>>> [1]
>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs
>>> [2]
>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs
>>> [3]
>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/e

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Luite Stegeman]

I think GHC could use more or less the same communication method as GHCJS
now does: Start some user-specifiied process and send messages through
pipes (GHCJS uses stdin/stderr of the node process), with the difference
that it would get dynamic libraries for the target rather than blobs of JS
code. That user process is then responsible for setting up the actual
communication with the runner on the emulator or development device.

A requirement for complete TH support is that more code can be loaded at
runtime, so that multiple splices can be run by the same runner (because of
the persistent map, qGetQ / qPutQ), I'm not sure if this is problematic on
iOS.



On Thu, Jul 3, 2014 at 2:54 AM, Carter Schonwald  wrote:

> This would probably be a great boon for those trying to use haskell for
> Android and IOS right? how might the emulation setup work for those?
>
>
>
>
> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> wow, this is great work!
>>
>> If theres a clear path to getting the generic tooling into 7.10, i'm all
>> for it :) (and willing to help on concrete mechanical subtasks)
>>
>>
>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
>> wrote:
>>
>>> hi all,
>>>
>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH
>>> for a long time now, but so far always relied on native (host) code for it.
>>> This is the main reason that GHCJS always builds native and JavaScript code
>>> for everything (another is that Cabal Setup.hs scripts need to be compiled
>>> to some host-runnable form, but that can also be JavaScript if you have
>>> node.js)
>>>
>>> Now besides the compiler having to do twice the work, this has some
>>> other disadvantages:
>>>
>>> - Our JavaScript code has the same dependencies (packages) as native
>>> code, which means packages like unix or Win32 show up somewhere, depending
>>> on the host environment. This also limits our options in choosing
>>> JS-specific packages.
>>> - The Template Haskell code runs on the host environment, which might be
>>> slightly different from the target, for example in integer size or
>>> operating system specific constants.
>>>
>>> Moreover, building native code made the GHCJS installation procedure
>>> more tricky, making end users think about libgmp or libiconv locations,
>>> since it basically required the same preparation as building GHC from
>>> source. This change will make installing much easier and more reliable (we
>>> still have to update the build scripts).
>>>
>>> How it works is pretty simple:
>>>
>>> - When any code needs to be run on the target (hscCompileCoreExpr,
>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with
>>> the thrunner.js [3] script,
>>> - GHCJS sends its RTS and the Template Haskell server code [1] to
>>> node.js, the script starts a Haskell thread running the server,
>>> - for every splice, GHCJS compiles it to JavaScript and links it using
>>> its incremental linking functionality. The code for the splice, including
>>> dependencies that have not yet been sent to the runner (for earlier
>>> splices), is then sent in a RunTH [4] message,
>>> - the runner loads and runs the code in the Q monad, can send queries to
>>> GHCJS for reification,
>>> - the runner sends back the result as a serialized Template Haskell AST
>>> (using GHC.Generics for the Binary instances).
>>>
>>> All Template Haskell functionality is supported, including recent
>>> additions for reifying modules and annotations. I still need to clean up
>>> and push the patches for the directory and process packages, but after
>>> that, the TH code can read/write files, run processes and interact with
>>> them and make network connections, all through node.js.
>>>
>>> Now since this approach is in no way specific to JavaScript, I was
>>> wondering if there's any interest in getting this functionality into GHC
>>> 7.10 for general cross compilation. The runner would be a native (target)
>>> program with dynamic libraries (or object files) being sent over to the
>>> target machine (or emulator) for the splices.
>>>
>>> Thanks to Andras Slemmer from Prezi who helped build the initial proof
>>> of concept (without reification) at BudHac.
>>>
>>> cheers,
>>>
>>&

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[CJ van den Berg]

Yes! This would definitely be of great interest to users of the
Android cross compilers. It should be quite feasible to drive a TH
runner process on a development device or emulator. Having genuine TH
support would be a huge improvement to the usefulness of GHC in a
cross compiling scenario.

I would love to start work on integrating TH runner support into
ghc-android.

On 2014-07-02 18:14, Luite Stegeman wrote:
> Now since this approach is in no way specific to JavaScript, I was
> wondering if there's any interest in getting this functionality into GHC
> 7.10 for general cross compilation. The runner would be a native
> (target) program with dynamic libraries (or object files) being sent
> over to the target machine (or emulator) for the splices.
> 


-- 
CJ van den Berg

mailto:c...@vdbonline.com
xmpp:neuroc...@gmail.com
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Carter Schonwald]

This would probably be a great boon for those trying to use haskell for
Android and IOS right? how might the emulation setup work for those?




On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald  wrote:

> wow, this is great work!
>
> If theres a clear path to getting the generic tooling into 7.10, i'm all
> for it :) (and willing to help on concrete mechanical subtasks)
>
>
> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
> wrote:
>
>> hi all,
>>
>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
>> code on node.js, rather than using the GHC linker. GHCJS has supported TH
>> for a long time now, but so far always relied on native (host) code for it.
>> This is the main reason that GHCJS always builds native and JavaScript code
>> for everything (another is that Cabal Setup.hs scripts need to be compiled
>> to some host-runnable form, but that can also be JavaScript if you have
>> node.js)
>>
>> Now besides the compiler having to do twice the work, this has some other
>> disadvantages:
>>
>> - Our JavaScript code has the same dependencies (packages) as native
>> code, which means packages like unix or Win32 show up somewhere, depending
>> on the host environment. This also limits our options in choosing
>> JS-specific packages.
>> - The Template Haskell code runs on the host environment, which might be
>> slightly different from the target, for example in integer size or
>> operating system specific constants.
>>
>> Moreover, building native code made the GHCJS installation procedure more
>> tricky, making end users think about libgmp or libiconv locations, since it
>> basically required the same preparation as building GHC from source. This
>> change will make installing much easier and more reliable (we still have to
>> update the build scripts).
>>
>> How it works is pretty simple:
>>
>> - When any code needs to be run on the target (hscCompileCoreExpr,
>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with
>> the thrunner.js [3] script,
>> - GHCJS sends its RTS and the Template Haskell server code [1] to
>> node.js, the script starts a Haskell thread running the server,
>> - for every splice, GHCJS compiles it to JavaScript and links it using
>> its incremental linking functionality. The code for the splice, including
>> dependencies that have not yet been sent to the runner (for earlier
>> splices), is then sent in a RunTH [4] message,
>> - the runner loads and runs the code in the Q monad, can send queries to
>> GHCJS for reification,
>> - the runner sends back the result as a serialized Template Haskell AST
>> (using GHC.Generics for the Binary instances).
>>
>> All Template Haskell functionality is supported, including recent
>> additions for reifying modules and annotations. I still need to clean up
>> and push the patches for the directory and process packages, but after
>> that, the TH code can read/write files, run processes and interact with
>> them and make network connections, all through node.js.
>>
>> Now since this approach is in no way specific to JavaScript, I was
>> wondering if there's any interest in getting this functionality into GHC
>> 7.10 for general cross compilation. The runner would be a native (target)
>> program with dynamic libraries (or object files) being sent over to the
>> target machine (or emulator) for the splices.
>>
>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of
>> concept (without reification) at BudHac.
>>
>> cheers,
>>
>> Luite
>>
>> [1]
>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs
>> [2]
>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs
>> [3]
>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js
>> [4]
>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Carter Schonwald]

wow, this is great work!

If theres a clear path to getting the generic tooling into 7.10, i'm all
for it :) (and willing to help on concrete mechanical subtasks)


On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman  wrote:

> hi all,
>
> I've added some code [1] [2] to GHCJS to make it run Template Haskell code
> on node.js, rather than using the GHC linker. GHCJS has supported TH for a
> long time now, but so far always relied on native (host) code for it. This
> is the main reason that GHCJS always builds native and JavaScript code for
> everything (another is that Cabal Setup.hs scripts need to be compiled to
> some host-runnable form, but that can also be JavaScript if you have
> node.js)
>
> Now besides the compiler having to do twice the work, this has some other
> disadvantages:
>
> - Our JavaScript code has the same dependencies (packages) as native code,
> which means packages like unix or Win32 show up somewhere, depending on the
> host environment. This also limits our options in choosing JS-specific
> packages.
> - The Template Haskell code runs on the host environment, which might be
> slightly different from the target, for example in integer size or
> operating system specific constants.
>
> Moreover, building native code made the GHCJS installation procedure more
> tricky, making end users think about libgmp or libiconv locations, since it
> basically required the same preparation as building GHC from source. This
> change will make installing much easier and more reliable (we still have to
> update the build scripts).
>
> How it works is pretty simple:
>
> - When any code needs to be run on the target (hscCompileCoreExpr, through
> the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the
> thrunner.js [3] script,
> - GHCJS sends its RTS and the Template Haskell server code [1] to node.js,
> the script starts a Haskell thread running the server,
> - for every splice, GHCJS compiles it to JavaScript and links it using its
> incremental linking functionality. The code for the splice, including
> dependencies that have not yet been sent to the runner (for earlier
> splices), is then sent in a RunTH [4] message,
> - the runner loads and runs the code in the Q monad, can send queries to
> GHCJS for reification,
> - the runner sends back the result as a serialized Template Haskell AST
> (using GHC.Generics for the Binary instances).
>
> All Template Haskell functionality is supported, including recent
> additions for reifying modules and annotations. I still need to clean up
> and push the patches for the directory and process packages, but after
> that, the TH code can read/write files, run processes and interact with
> them and make network connections, all through node.js.
>
> Now since this approach is in no way specific to JavaScript, I was
> wondering if there's any interest in getting this functionality into GHC
> 7.10 for general cross compilation. The runner would be a native (target)
> program with dynamic libraries (or object files) being sent over to the
> target machine (or emulator) for the splices.
>
> Thanks to Andras Slemmer from Prezi who helped build the initial proof of
> concept (without reification) at BudHac.
>
> cheers,
>
> Luite
>
> [1]
> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs
> [2]
> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs
> [3]
> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js
> [4]
> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Luite Stegeman]

hi all,

I've added some code [1] [2] to GHCJS to make it run Template Haskell code
on node.js, rather than using the GHC linker. GHCJS has supported TH for a
long time now, but so far always relied on native (host) code for it. This
is the main reason that GHCJS always builds native and JavaScript code for
everything (another is that Cabal Setup.hs scripts need to be compiled to
some host-runnable form, but that can also be JavaScript if you have
node.js)

Now besides the compiler having to do twice the work, this has some other
disadvantages:

- Our JavaScript code has the same dependencies (packages) as native code,
which means packages like unix or Win32 show up somewhere, depending on the
host environment. This also limits our options in choosing JS-specific
packages.
- The Template Haskell code runs on the host environment, which might be
slightly different from the target, for example in integer size or
operating system specific constants.

Moreover, building native code made the GHCJS installation procedure more
tricky, making end users think about libgmp or libiconv locations, since it
basically required the same preparation as building GHC from source. This
change will make installing much easier and more reliable (we still have to
update the build scripts).

How it works is pretty simple:

- When any code needs to be run on the target (hscCompileCoreExpr, through
the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the
thrunner.js [3] script,
- GHCJS sends its RTS and the Template Haskell server code [1] to node.js,
the script starts a Haskell thread running the server,
- for every splice, GHCJS compiles it to JavaScript and links it using its
incremental linking functionality. The code for the splice, including
dependencies that have not yet been sent to the runner (for earlier
splices), is then sent in a RunTH [4] message,
- the runner loads and runs the code in the Q monad, can send queries to
GHCJS for reification,
- the runner sends back the result as a serialized Template Haskell AST
(using GHC.Generics for the Binary instances).

All Template Haskell functionality is supported, including recent additions
for reifying modules and annotations. I still need to clean up and push the
patches for the directory and process packages, but after that, the TH code
can read/write files, run processes and interact with them and make network
connections, all through node.js.

Now since this approach is in no way specific to JavaScript, I was
wondering if there's any interest in getting this functionality into GHC
7.10 for general cross compilation. The runner would be a native (target)
program with dynamic libraries (or object files) being sent over to the
target machine (or emulator) for the splices.

Thanks to Andras Slemmer from Prezi who helped build the initial proof of
concept (without reification) at BudHac.

cheers,

Luite

[1]
https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs
[2]
https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs
[3]
https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js
[4]
https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Albert Y. C. Lai]

On 14-02-18 10:44 PM, Carter Schonwald wrote:

hey Albert, could you open a ticket on ghc Trac about the QuasiQuot thing?


It is now https://ghc.haskell.org/trac/ghc/ticket/8805
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Carter Schonwald]

hey Albert, could you open a ticket on ghc Trac about the QuasiQuot thing?


On Tue, Feb 18, 2014 at 9:48 PM, Albert Y. C. Lai  wrote:

> The new dynamism is pretty nice! I even used GHC 7.6.3 to build
> cabal-install 1.18, then played with PATH so that when I said "cabal
> install mtl" it saw GHC 7.8. It correctly added -dynamic-too and built both
> *.a and *.so in one go. This is very user-friendly.
>
> Still, I observed a few oddities.
>
> 1. Referring to the user guide section 2.3 "loading compiled code", it is
> now insufficient to "ghc -c D.hs". It has to be "ghc -c -dynamic D.hs".
>
> Perhaps more importantly, "ghc -c -dynamic-too D.hs" is also insufficient.
> Apparently, while TemplateHaskell considers both *.hi and *.dyn_hi, :load
> considers *.hi only.
>
> 2. My experiment began with just QuasiQuote. QuasiQuote needs as much
> dynamism as TemplateHaskell. Yet, QuasiQuote does not trigger a nice
> implicit -dynamic-too, unlike TemplateHaskell.
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Albert Y. C. Lai]

The new dynamism is pretty nice! I even used GHC 7.6.3 to build 
cabal-install 1.18, then played with PATH so that when I said "cabal 
install mtl" it saw GHC 7.8. It correctly added -dynamic-too and built 
both *.a and *.so in one go. This is very user-friendly.


Still, I observed a few oddities.

1. Referring to the user guide section 2.3 "loading compiled code", it 
is now insufficient to "ghc -c D.hs". It has to be "ghc -c -dynamic D.hs".


Perhaps more importantly, "ghc -c -dynamic-too D.hs" is also 
insufficient. Apparently, while TemplateHaskell considers both *.hi and 
*.dyn_hi, :load considers *.hi only.


2. My experiment began with just QuasiQuote. QuasiQuote needs as much 
dynamism as TemplateHaskell. Yet, QuasiQuote does not trigger a nice 
implicit -dynamic-too, unlike TemplateHaskell.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Simon Marlow]

I think you can summarise all that with "tl;dr the right thing will 
happen, you don't have to remember to give any new flags to GHC or Cabal".


Cheers,
Simon

On 09/02/2014 21:14, Austin Seipp wrote:

Actually, just to keep it even simpler, so nobody else is confused
further: Cabal will *also* properly turn on dynamic builds for regular
packages if GHC is dynamic, TemplateHaskell or not. So any library you
compile will still work in GHCi as expected.

So here's the breakdown:

   1) Cabal 1.18 will handle dynamical GHCi correctly, including
compiling things dynamically, however it must.
   2) Per #1, libraries are compiled dynamically. This means libraries
work in GHCi, just like they did.
   3) -Executables- are statically linked by default, still. (But
because of #1 and #2, it's very easy to turn on dynamic exes as well,
without needing to recompile a lot.)
   4) TemplateHaskell works as expected due to #1 and #2. But there is
one caveat for executables, noted separately below.

The caveat with TemplateHaskell is for executables: This is because if
you end up with an executable that needs TH and profiling, Cabal must
be aware of this. Why? Because GHCi cannot load *profiled* objects,
only normal ones. So we must compile twice: once without profiling,
and once with profiling. The second compilation will use the 'normal'
objects, even though the final executable will be profiled. Cabal
doesn't know to do this if it doesn't know TemplateHaskell is a
requirement.

Does this clear things up? My last message might give the impression
some things aren't compiled dynamically, because I merely ambiguously
referred to 'packages'.

On Sun, Feb 9, 2014 at 2:37 PM, Austin Seipp  wrote:

It is correct that Template Haskell now requires dynamic objects.
However, GHC can produce static and dynamic objects at the same time,
so you don't have to recompile a package twice (it's a big
optimization, basically).

Furthermore, if TemplateHaskell is enabled as a requirement for a
package, and GHC is built dynamically, Cabal will do The Right Thing
by building the shared objects for the dependencies as well. It will
save time by doing so using -dynamic-too, if possible. This is because
it queries GHC before compilation to figure this out (you can run 'ghc
--info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports
dynamic-too" fields.)

Finally, if you simply run 'ghc Foo.hs' on a file that requires
TemplateHaskell, it will also switch on -dynamic-too for the needed
objects in this simple case.

There is one caveat, if I remember correctly: if a package uses
TemplateHaskell, it must declare it as such in the Cabal file. This is
because Cabal does not parse the source to detect if TemplateHaskell
is needed in the dependency graph of the compiled modules. Only GHC
can do this reliably. If you don't specify TemplateHaskell as an
extension, Cabal might not do the right thing. This is noted in the
release notes:


Note that Cabal will correctly handle -dynamic-too for you automatically, 
especially when -XTemplateHaskell is needed - but you *must* tell Cabal you are 
using the TemplateHaskell extension.


However, based on the other suggestions in the thread and confusion
around this, a big "Incompatible changes" section with this listed as
the first thing with clear detail would be a good idea. I'll do so.

If something else is going on, please file a bug.

On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts
 wrote:

Yes, in general I think the doc needs a section: Incompatible changes. The
hope is that you can take the release and just work as usual but when (for
good reasons as in this release) it is not true is is important to have such
a section. Another case that needs to be there is how to compile so you can
load compile object files into ghci as what you did in 7.6.3 won't work in
this release.


On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald
 wrote:


Indeed. The problem is that many folks might have cabal config files that
explicitly disable shared.  (For the compile times!).  They might need clear
information about wiping that field.


On Sunday, February 9, 2014, Brandon Allbery  wrote:


On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn  wrote:


Is --enable-shared off by default?


It's supposed to be on by default in 7.8. That said, not sure how many
people have played with ~/.cabal/config

--
brandon s allbery kf8nh   sine nomine
associates
allber...@gmail.com
ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http

Re: 7.8.1, template haskell, and dynamic libraries

[Austin Seipp]

Actually, just to keep it even simpler, so nobody else is confused
further: Cabal will *also* properly turn on dynamic builds for regular
packages if GHC is dynamic, TemplateHaskell or not. So any library you
compile will still work in GHCi as expected.

So here's the breakdown:

  1) Cabal 1.18 will handle dynamical GHCi correctly, including
compiling things dynamically, however it must.
  2) Per #1, libraries are compiled dynamically. This means libraries
work in GHCi, just like they did.
  3) -Executables- are statically linked by default, still. (But
because of #1 and #2, it's very easy to turn on dynamic exes as well,
without needing to recompile a lot.)
  4) TemplateHaskell works as expected due to #1 and #2. But there is
one caveat for executables, noted separately below.

The caveat with TemplateHaskell is for executables: This is because if
you end up with an executable that needs TH and profiling, Cabal must
be aware of this. Why? Because GHCi cannot load *profiled* objects,
only normal ones. So we must compile twice: once without profiling,
and once with profiling. The second compilation will use the 'normal'
objects, even though the final executable will be profiled. Cabal
doesn't know to do this if it doesn't know TemplateHaskell is a
requirement.

Does this clear things up? My last message might give the impression
some things aren't compiled dynamically, because I merely ambiguously
referred to 'packages'.

On Sun, Feb 9, 2014 at 2:37 PM, Austin Seipp  wrote:
> It is correct that Template Haskell now requires dynamic objects.
> However, GHC can produce static and dynamic objects at the same time,
> so you don't have to recompile a package twice (it's a big
> optimization, basically).
>
> Furthermore, if TemplateHaskell is enabled as a requirement for a
> package, and GHC is built dynamically, Cabal will do The Right Thing
> by building the shared objects for the dependencies as well. It will
> save time by doing so using -dynamic-too, if possible. This is because
> it queries GHC before compilation to figure this out (you can run 'ghc
> --info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports
> dynamic-too" fields.)
>
> Finally, if you simply run 'ghc Foo.hs' on a file that requires
> TemplateHaskell, it will also switch on -dynamic-too for the needed
> objects in this simple case.
>
> There is one caveat, if I remember correctly: if a package uses
> TemplateHaskell, it must declare it as such in the Cabal file. This is
> because Cabal does not parse the source to detect if TemplateHaskell
> is needed in the dependency graph of the compiled modules. Only GHC
> can do this reliably. If you don't specify TemplateHaskell as an
> extension, Cabal might not do the right thing. This is noted in the
> release notes:
>
>> Note that Cabal will correctly handle -dynamic-too for you automatically, 
>> especially when -XTemplateHaskell is needed - but you *must* tell Cabal you 
>> are using the TemplateHaskell extension.
>
> However, based on the other suggestions in the thread and confusion
> around this, a big "Incompatible changes" section with this listed as
> the first thing with clear detail would be a good idea. I'll do so.
>
> If something else is going on, please file a bug.
>
> On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts
>  wrote:
>> Yes, in general I think the doc needs a section: Incompatible changes. The
>> hope is that you can take the release and just work as usual but when (for
>> good reasons as in this release) it is not true is is important to have such
>> a section. Another case that needs to be there is how to compile so you can
>> load compile object files into ghci as what you did in 7.6.3 won't work in
>> this release.
>>
>>
>> On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald
>>  wrote:
>>>
>>> Indeed. The problem is that many folks might have cabal config files that
>>> explicitly disable shared.  (For the compile times!).  They might need clear
>>> information about wiping that field.
>>>
>>>
>>> On Sunday, February 9, 2014, Brandon Allbery  wrote:
>>>>
>>>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn  wrote:
>>>>>
>>>>> Is --enable-shared off by default?
>>>>
>>>> It's supposed to be on by default in 7.8. That said, not sure how many
>>>> people have played with ~/.cabal/config
>>>>
>>>> --
>>>> brandon s allbery kf8nh   sine nomine
>>>> associates
>>>> allber...@gmail.com
>>>> ballb...@sinenomine.net
>>>>

Re: 7.8.1, template haskell, and dynamic libraries

[Joachim Breitner]

Hi,

Am Sonntag, den 09.02.2014, 14:37 -0600 schrieb Austin Seipp:
> There is one caveat, if I remember correctly: if a package uses
> TemplateHaskell, it must declare it as such in the Cabal file. This is
> because Cabal does not parse the source to detect if TemplateHaskell
> is needed in the dependency graph of the compiled modules. Only GHC
> can do this reliably. If you don't specify TemplateHaskell as an
> extension, Cabal might not do the right thing. This is noted in the
> release notes:
> 
> > Note that Cabal will correctly handle -dynamic-too for you automatically, 
> > especially when -XTemplateHaskell is needed - but you *must* tell Cabal you 
> > are using the TemplateHaskell extension.

we need -dynamic-too also for everything that a user ever might want to
load in GHCi, right? So doesn’t that already imply that Cabal should and
will build libHS*so files always anyways?

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nome...@debian.org


signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Austin Seipp]

It is correct that Template Haskell now requires dynamic objects.
However, GHC can produce static and dynamic objects at the same time,
so you don't have to recompile a package twice (it's a big
optimization, basically).

Furthermore, if TemplateHaskell is enabled as a requirement for a
package, and GHC is built dynamically, Cabal will do The Right Thing
by building the shared objects for the dependencies as well. It will
save time by doing so using -dynamic-too, if possible. This is because
it queries GHC before compilation to figure this out (you can run 'ghc
--info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports
dynamic-too" fields.)

Finally, if you simply run 'ghc Foo.hs' on a file that requires
TemplateHaskell, it will also switch on -dynamic-too for the needed
objects in this simple case.

There is one caveat, if I remember correctly: if a package uses
TemplateHaskell, it must declare it as such in the Cabal file. This is
because Cabal does not parse the source to detect if TemplateHaskell
is needed in the dependency graph of the compiled modules. Only GHC
can do this reliably. If you don't specify TemplateHaskell as an
extension, Cabal might not do the right thing. This is noted in the
release notes:

> Note that Cabal will correctly handle -dynamic-too for you automatically, 
> especially when -XTemplateHaskell is needed - but you *must* tell Cabal you 
> are using the TemplateHaskell extension.

However, based on the other suggestions in the thread and confusion
around this, a big "Incompatible changes" section with this listed as
the first thing with clear detail would be a good idea. I'll do so.

If something else is going on, please file a bug.

On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts
 wrote:
> Yes, in general I think the doc needs a section: Incompatible changes. The
> hope is that you can take the release and just work as usual but when (for
> good reasons as in this release) it is not true is is important to have such
> a section. Another case that needs to be there is how to compile so you can
> load compile object files into ghci as what you did in 7.6.3 won't work in
> this release.
>
>
> On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald
>  wrote:
>>
>> Indeed. The problem is that many folks might have cabal config files that
>> explicitly disable shared.  (For the compile times!).  They might need clear
>> information about wiping that field.
>>
>>
>> On Sunday, February 9, 2014, Brandon Allbery  wrote:
>>>
>>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn  wrote:
>>>>
>>>> Is --enable-shared off by default?
>>>
>>> It's supposed to be on by default in 7.8. That said, not sure how many
>>> people have played with ~/.cabal/config
>>>
>>> --
>>> brandon s allbery kf8nh   sine nomine
>>> associates
>>> allber...@gmail.com
>>> ballb...@sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[George Colpitts]

Yes, in general I think the doc needs a section: Incompatible changes. The
hope is that you can take the release and just work as usual but when (for
good reasons as in this release) it is not true is is important to have
such a section. Another case that needs to be there is how to compile so
you can load compile object files into ghci as what you did in 7.6.3 won't
work in this release.


On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald  wrote:

> Indeed. The problem is that many folks might have cabal config files that
> explicitly disable shared.  (For the compile times!).  They might need
> clear information about wiping that field.
>
>
> On Sunday, February 9, 2014, Brandon Allbery  wrote:
>
>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn  wrote:
>>
>>> Is --enable-shared off by default?
>>>
>> It's supposed to be on by default in 7.8. That said, not sure how many
>> people have played with ~/.cabal/config
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Carter Schonwald]

Indeed. The problem is that many folks might have cabal config files that
explicitly disable shared.  (For the compile times!).  They might need
clear information about wiping that field.

On Sunday, February 9, 2014, Brandon Allbery  wrote:

> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn 
> 
> > wrote:
>
>> Is --enable-shared off by default?
>>
> It's supposed to be on by default in 7.8. That said, not sure how many
> people have played with ~/.cabal/config
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com 
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Brandon Allbery]

On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn  wrote:

> Is --enable-shared off by default?
>
It's supposed to be on by default in 7.8. That said, not sure how many
people have played with ~/.cabal/config

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Greg Horn]

Is --enable-shared off by default?
On Feb 9, 2014 9:04 AM, "harry"  wrote:

> Michael Snoyman wrote
> > When upgrading to a new version of GHC, you'll have to reinstall all of
> > the
> > packages anyway. You can't simply use GHC 7.6 compiled packages with your
> > new GHC 7.8.
>
> This is probably the point at which it would be useful to know that all
> this
> recompilation will have to be done with dynamic libraries, to avoid having
> to do it all a second time when the user tries to use templates.
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743628.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[harry]

Michael Snoyman wrote
> When upgrading to a new version of GHC, you'll have to reinstall all of
> the
> packages anyway. You can't simply use GHC 7.6 compiled packages with your
> new GHC 7.8.

This is probably the point at which it would be useful to know that all this
recompilation will have to be done with dynamic libraries, to avoid having
to do it all a second time when the user tries to use templates.



--
View this message in context: 
http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743628.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at 
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Michael Snoyman]

On Sun, Feb 9, 2014 at 10:30 AM, harry  wrote:

> Carter Schonwald wrote
> > Yes.  (And thence ghc itself is then invoked with dynamic or dynamic-too)
> >
> >> The docs for 7.8.1 say "Template Haskell must now load dynamic object
> >> files,
> >> not static ones". Does this mean that, if I'm using Template Haskell,
> >> every
> >> package which the templates depend on have to be built with
> >> --enable-shared?
>
> Perhaps there should be a clear warning about this? If I've understood
> correctly, anything using Template Haskell will break when upgrading to
> 7.8,
> until all the dependencies are reinstalled with  --enable-shared.
>
>
>
When upgrading to a new version of GHC, you'll have to reinstall all of the
packages anyway. You can't simply use GHC 7.6 compiled packages with your
new GHC 7.8.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[harry]

Carter Schonwald wrote
> Yes.  (And thence ghc itself is then invoked with dynamic or dynamic-too)
> 
>> The docs for 7.8.1 say "Template Haskell must now load dynamic object
>> files,
>> not static ones". Does this mean that, if I'm using Template Haskell,
>> every
>> package which the templates depend on have to be built with
>> --enable-shared?

Perhaps there should be a clear warning about this? If I've understood
correctly, anything using Template Haskell will break when upgrading to 7.8,
until all the dependencies are reinstalled with  --enable-shared.



--
View this message in context: 
http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743624.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at 
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1, template haskell, and dynamic libraries

[Carter Schonwald]

Yes.  (And thence ghc itself is then invoked with dynamic or dynamic-too)

On Saturday, February 8, 2014, harry  wrote:

> The docs for 7.8.1 say "Template Haskell must now load dynamic object
> files,
> not static ones". Does this mean that, if I'm using Template Haskell, every
> package which the templates depend on have to be built with
> --enable-shared?
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org 
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

7.8.1, template haskell, and dynamic libraries

[harry]

The docs for 7.8.1 say "Template Haskell must now load dynamic object files,
not static ones". Does this mean that, if I'm using Template Haskell, every
package which the templates depend on have to be built with --enable-shared?



--
View this message in context: 
http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at 
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Proposal to extend FieldPat in Template Haskell

[Simon Peyton-Jones]

Fine with me!  We need people to update TH.

We plan to release 7.8 in mid Feb, and then have a TH upheaval shortly 
thereafter (I hope). So let’s put this in afterwards.

Simon

From: glasgow-haskell-users-boun...@haskell.org 
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Iavor Diatchki
Sent: 29 January 2013 21:25
To: GHC Users Mailing List; Eric Mertens
Subject: Proposal to extend FieldPat in Template Haskell

Hello,
(sorry for the repost, I forgot to add a subject.)

I was just doing some work with Template Haskell and I noticed that the AST 
does not have support for record puns and wild-cards.  I know that these could 
be desugared into ordinary record patterns but I think that it would be more 
convenient for users (and also more consistent with the rest of the AST) if we 
provided direct support for them.

So I propose to change:

type FieldPat = (Name, Pat)

to

data FieldPat = RecordFileldP Name Pat  -- x = P
  | RecordPunP Name -- x
  | RecordWildP -- ..

Would there be any objections to doing so?  If not, I'd be happy to have a go 
at making the change.

-Iavor

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Proposal to extend FieldPat in Template Haskell

[Iavor Diatchki]

Hello,
(sorry for the repost, I forgot to add a subject.)

I was just doing some work with Template Haskell and I noticed that the AST
does not have support for record puns and wild-cards.  I know that these
could be desugared into ordinary record patterns but I think that it would
be more convenient for users (and also more consistent with the rest of the
AST) if we provided direct support for them.

So I propose to change:

type FieldPat = (Name, Pat)

to

data FieldPat = RecordFileldP Name Pat  -- x = P
  | RecordPunP Name -- x
  | RecordWildP -- ..

Would there be any objections to doing so?  If not, I'd be happy to have a
go at making the change.

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Template Haskell

[Mikhail Vorozhtsov]

On 07/18/2012 07:25 PM, Simon Peyton-Jones wrote:

Folks

Mikhail has improved Template Haskell’s handling of INLINE pragmas,
SPECIALISE pragmas, and RULES.  I plan to commit his patch:

http://hackage.haskell.org/trac/ghc/ticket/7064
Will the patch make it to 7.6? I have 6 unpublished libraries that 
depend (transitively) on the RULES pragma support in TH. It would be 
nice to not have to wait for another 6 months to put them on hackage.



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Template Haskell

[Simon Marlow]

On 20/07/2012 03:33, Mikhail Vorozhtsov wrote:

Hi Simon.

On Wed, Jul 18, 2012 at 7:25 PM, Simon Peyton-Jones
 wrote:

Mikhail has improved Template Haskell’s handling of INLINE pragmas,
SPECIALISE pragmas, and RULES.  I plan to commit his patch

BTW, is there a reason why you use commit messages to attribute other
people's work instead of `git am` or `git commit --author=...`?


We normally use 'git am' to apply patches from tickets, and I have 
certainly used --author from time to time if I need to edit and recommit 
a patch for some reason (perhaps Simon isn't familiar with --author though).


Cheers,
Simon




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Template Haskell

[Mikhail Vorozhtsov]

Hi Simon.

On Wed, Jul 18, 2012 at 7:25 PM, Simon Peyton-Jones
 wrote:
> Mikhail has improved Template Haskell’s handling of INLINE pragmas,
> SPECIALISE pragmas, and RULES.  I plan to commit his patch
BTW, is there a reason why you use commit messages to attribute other
people's work instead of `git am` or `git commit --author=...`?

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: update to Template Haskell for rich kinds

[José Pedro Magalhães]

Hi Richard,

I've had a look at the updated proposal page; it looks fine to me. I don't
really have a preference between the "standard" and "alternative"
implementations right now.

You do mention parse errors with kinds and promoted constructors (which is
related to http://hackage.haskell.org/trac/ghc/ticket/5682) but I think we
want those things to be synonyms; the current behavior is just a bug.


Cheers,
Pedro

2012/3/20 Richard Eisenberg 

> Yes, we will, but this is already support through the use of ConT.
> The namespaces of defined types and of promoted types are also already
> kept distinct. The one update we would want here is an extension to the
> name quoting syntax. I've updated the Wiki page with my thoughts and
> plans here:
> http://hackage.haskell.org/trac/ghc/wiki/TemplateHaskellRichKinds
>
> In my continued experiments with this, I've realized that we will need
> even more constructors to make all the different kinds expressible. The
> Wiki page is updated for this also, and I've listed two alternative
> implementations. Comments very much appreciated!
>
> Thanks,
> Richard
>
> PS: I added ConstraintK as well.
>
> On 03/20/2012 03:43 AM, José Pedro Magalhães wrote:
> > Hi Richard,
> >
> > Thanks for taking this up! One question: won't we need syntax for
> > arbitrary promoted constructors (other than lists and tuples) in TH's
> > Type datatype?
> >
> > Also, is the Constraint kind already in TH? If not, this might be a good
> > time to add it too.
> >
> >
> > Cheers,
> > Pedro
> >
> > On Mon, Mar 19, 2012 at 03:09, Richard Eisenberg  > <mailto:e...@seas.upenn.edu>> wrote:
> >
> > Hi all,
> >
> > I'm working on bringing Template Haskell up to speed with the new
> > extensions for polymorphic kinds and promoted data kinds. This
> > requires a few small, non-breaking changes to TH datatypes. I've
> > made a (short) wiki page at
> >
> http://hackage.haskell.org/__trac/ghc/wiki/__TemplateHaskellRichKinds <
> http://hackage.haskell.org/trac/ghc/wiki/TemplateHaskellRichKinds>
> > and the official Trac feature request is
> > hackage.haskell.org/trac/ghc/__ticket/5612
> > <http://hackage.haskell.org/trac/ghc/ticket/5612>
> >
> > Does anyone have any suggestions to what I've written? Any other
> > comments?
> >
> > Thanks!
> > Richard
> >
> > _
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.__org
> > <mailto:Glasgow-haskell-users@haskell.org>
> > http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users
> > <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
> >
> >
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: update to Template Haskell for rich kinds

[Richard Eisenberg]

Yes, we will, but this is already support through the use of ConT.
The namespaces of defined types and of promoted types are also already
kept distinct. The one update we would want here is an extension to the
name quoting syntax. I've updated the Wiki page with my thoughts and
plans here:
http://hackage.haskell.org/trac/ghc/wiki/TemplateHaskellRichKinds

In my continued experiments with this, I've realized that we will need
even more constructors to make all the different kinds expressible. The
Wiki page is updated for this also, and I've listed two alternative
implementations. Comments very much appreciated!

Thanks,
Richard

PS: I added ConstraintK as well.

On 03/20/2012 03:43 AM, José Pedro Magalhães wrote:
> Hi Richard,
> 
> Thanks for taking this up! One question: won't we need syntax for
> arbitrary promoted constructors (other than lists and tuples) in TH's
> Type datatype?
> 
> Also, is the Constraint kind already in TH? If not, this might be a good
> time to add it too.
> 
> 
> Cheers,
> Pedro
> 
> On Mon, Mar 19, 2012 at 03:09, Richard Eisenberg  <mailto:e...@seas.upenn.edu>> wrote:
> 
> Hi all,
> 
> I'm working on bringing Template Haskell up to speed with the new
> extensions for polymorphic kinds and promoted data kinds. This
> requires a few small, non-breaking changes to TH datatypes. I've
> made a (short) wiki page at
> http://hackage.haskell.org/__trac/ghc/wiki/__TemplateHaskellRichKinds 
> <http://hackage.haskell.org/trac/ghc/wiki/TemplateHaskellRichKinds>
> and the official Trac feature request is
> hackage.haskell.org/trac/ghc/__ticket/5612
> <http://hackage.haskell.org/trac/ghc/ticket/5612>
> 
> Does anyone have any suggestions to what I've written? Any other
> comments?
> 
> Thanks!
> Richard
> 
> _
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.__org
> <mailto:Glasgow-haskell-users@haskell.org>
> http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users
> <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
> 
> 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: update to Template Haskell for rich kinds

[José Pedro Magalhães]

Hi Richard,

Thanks for taking this up! One question: won't we need syntax for arbitrary
promoted constructors (other than lists and tuples) in TH's Type datatype?

Also, is the Constraint kind already in TH? If not, this might be a good
time to add it too.


Cheers,
Pedro

On Mon, Mar 19, 2012 at 03:09, Richard Eisenberg  wrote:

> Hi all,
>
> I'm working on bringing Template Haskell up to speed with the new
> extensions for polymorphic kinds and promoted data kinds. This requires a
> few small, non-breaking changes to TH datatypes. I've made a (short) wiki
> page at http://hackage.haskell.org/**trac/ghc/wiki/**
> TemplateHaskellRichKinds<http://hackage.haskell.org/trac/ghc/wiki/TemplateHaskellRichKinds>and
>  the official Trac feature request is
> hackage.haskell.org/trac/ghc/**ticket/5612<http://hackage.haskell.org/trac/ghc/ticket/5612>
>
> Does anyone have any suggestions to what I've written? Any other comments?
>
> Thanks!
> Richard
>
> __**_
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.**org 
> http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users<http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

update to Template Haskell for rich kinds

[Richard Eisenberg]

Hi all,

I'm working on bringing Template Haskell up to speed with the new 
extensions for polymorphic kinds and promoted data kinds. This requires 
a few small, non-breaking changes to TH datatypes. I've made a (short) 
wiki page at 
http://hackage.haskell.org/trac/ghc/wiki/TemplateHaskellRichKinds and 
the official Trac feature request is 
hackage.haskell.org/trac/ghc/ticket/5612


Does anyone have any suggestions to what I've written? Any other comments?

Thanks!
Richard

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error when building cabal package with template haskell configured for profiling

[Bas van Dijk]

On 27 January 2012 15:14, Felipe Almeida Lessa  wrote:
> On Fri, Jan 27, 2012 at 12:06 PM, Bas van Dijk  wrote:
>> $ cabal configure --ghc-options="-O2 -prof -auto-all -caf-all"
>
> Why aren't you using the specific options for profiling?
>
> $ cabal configure --help | grep profiling
>  -p --enable-library-profiling     Enable Library profiling
>    --disable-library-profiling    Disable Library profiling
>    --enable-executable-profiling  Enable Executable profiling
>    --disable-executable-profiling Disable Executable profiling

This gives the following error:

$ cabal configure  --enable-executable-profiling
...
$ cabal build
...
cannot find normal object file `'
while linking an interpreted expression

However when I apply the same trick as before, first building normally
then building with profiling enabled, it works:

$ cabal configure
...
$ cabal build
...
$ cabal configure  --enable-executable-profiling
...
$ cabal build
...
success!

Thanks for the hint!

Bas

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error when building cabal package with template haskell configured for profiling

[Felipe Almeida Lessa]

On Fri, Jan 27, 2012 at 12:06 PM, Bas van Dijk  wrote:
> $ cabal configure --ghc-options="-O2 -prof -auto-all -caf-all"

Why aren't you using the specific options for profiling?

$ cabal configure --help | grep profiling
 -p --enable-library-profiling Enable Library profiling
--disable-library-profilingDisable Library profiling
--enable-executable-profiling  Enable Executable profiling
--disable-executable-profiling Disable Executable profiling

Cheers, =)

-- 
Felipe.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Error when building cabal package with template haskell configured for profiling

[Bas van Dijk]

Hello,

I would like to profile a cabal package that contains template haskell
code. However I get the following error:

$ cabal configure --ghc-options="-O2 -prof -auto-all -caf-all"
...

$ cabal build
...
  Dynamic linking required, but this is a non-standard build (eg. prof).
  You need to build the program twice: once the normal way, and then
  in the desired way using -osuf to set the object file suffix.

What's the best way to solve this?

Currently I do a cabal build -v and copy the ghc --make ... command
line. Then I first build the program normally (without -prof) and then
build it with -prof and -osuf p_o like the error messages suggests.
This is annoying however.

Is there a ticket for this bug?

Bas

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: accessing compilation parameters from template haskell

[Simon Peyton-Jones]

| Would making a template-haskell-ghc package make sense? Might be
| overkill just for my requirement but there could be other things like
| support for GHC-specific language extensions that might also logically
| belong there.

I don't know --  I don't know what it would look like. By all means have a go!

S
| 
| On 16/09/2011 08:21, Simon Peyton-Jones wrote:
| > The difficulty here is that the TH library, by design, doesn't depend on 
GHC.  So
| we can't have a TH function
| > getFlags :: Q DynFlags
| > or (as you suggest, more or less)
| > runTc :: TcM a -> Q a
| > because to write those type signatures in Language.Haskell.TH.Syntax you'd 
need to
| import GHC.
| >
| > There's no difficulty in *practice*!  Q more or less *is* TcM.
| >
| > Still I don't really know how to get around this in a beautiful way.
| >
| > Simon
| >
| > | -Original Message-
| > | From: glasgow-haskell-users-boun...@haskell.org 
[mailto:glasgow-haskell-users-
| > | boun...@haskell.org] On Behalf Of Ganesh Sittampalam
| > | Sent: 16 September 2011 06:42
| > | To: GHC users
| > | Subject: accessing compilation parameters from template haskell
| > |
| > | Hi,
| > |
| > | It would be useful to access the current compilation parameters or even
| > | an entire RunGhc monad from inside a Template Haskell splice. Is there
| > | any way to do this?
| > |
| > | The reason I want to do this is I'm using the ghc API at runtime to
| > | dynamically execute code, and I want both the dynamically loaded code
| > | and static code to use a shared runtime module that defines some types
| > | used for communication across the boundary. To guarantee the internal
| > | representations etc are the same, I store the object file of the runtime
| > | during compilation then load it dynamically at runtime - but to make
| > | this work I need to know where the object file is (-odir and -hidir) and
| > | I also need to know or be able to deduce the GHC DynFlags so I can
| > | replicate them at runtime.
| > |
| > | I could also achieve this goal by putting my runtime in a separate
| > | package and installing it first, but that's less self-contained and
| > | would be a pain during development.
| > |
| > | Cheers,
| > |
| > | Ganesh
| > |
| > | ___
| > | Glasgow-haskell-users mailing list
| > | Glasgow-haskell-users@haskell.org
| > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| >
| >
| 
| 
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: accessing compilation parameters from template haskell

[Ganesh Sittampalam]

Would making a template-haskell-ghc package make sense? Might be
overkill just for my requirement but there could be other things like
support for GHC-specific language extensions that might also logically
belong there.

On 16/09/2011 08:21, Simon Peyton-Jones wrote:
> The difficulty here is that the TH library, by design, doesn't depend on GHC. 
>  So we can't have a TH function
>   getFlags :: Q DynFlags
> or (as you suggest, more or less)
>   runTc :: TcM a -> Q a
> because to write those type signatures in Language.Haskell.TH.Syntax you'd 
> need to import GHC.
> 
> There's no difficulty in *practice*!  Q more or less *is* TcM.
> 
> Still I don't really know how to get around this in a beautiful way.
> 
> Simon
> 
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org 
> [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Ganesh Sittampalam
> | Sent: 16 September 2011 06:42
> | To: GHC users
> | Subject: accessing compilation parameters from template haskell
> | 
> | Hi,
> | 
> | It would be useful to access the current compilation parameters or even
> | an entire RunGhc monad from inside a Template Haskell splice. Is there
> | any way to do this?
> | 
> | The reason I want to do this is I'm using the ghc API at runtime to
> | dynamically execute code, and I want both the dynamically loaded code
> | and static code to use a shared runtime module that defines some types
> | used for communication across the boundary. To guarantee the internal
> | representations etc are the same, I store the object file of the runtime
> | during compilation then load it dynamically at runtime - but to make
> | this work I need to know where the object file is (-odir and -hidir) and
> | I also need to know or be able to deduce the GHC DynFlags so I can
> | replicate them at runtime.
> | 
> | I could also achieve this goal by putting my runtime in a separate
> | package and installing it first, but that's less self-contained and
> | would be a pain during development.
> | 
> | Cheers,
> | 
> | Ganesh
> | 
> | ___
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users@haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> 


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: accessing compilation parameters from template haskell

[Simon Peyton-Jones]

The difficulty here is that the TH library, by design, doesn't depend on GHC.  
So we can't have a TH function
getFlags :: Q DynFlags
or (as you suggest, more or less)
runTc :: TcM a -> Q a
because to write those type signatures in Language.Haskell.TH.Syntax you'd need 
to import GHC.

There's no difficulty in *practice*!  Q more or less *is* TcM.

Still I don't really know how to get around this in a beautiful way.

Simon

| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Ganesh Sittampalam
| Sent: 16 September 2011 06:42
| To: GHC users
| Subject: accessing compilation parameters from template haskell
| 
| Hi,
| 
| It would be useful to access the current compilation parameters or even
| an entire RunGhc monad from inside a Template Haskell splice. Is there
| any way to do this?
| 
| The reason I want to do this is I'm using the ghc API at runtime to
| dynamically execute code, and I want both the dynamically loaded code
| and static code to use a shared runtime module that defines some types
| used for communication across the boundary. To guarantee the internal
| representations etc are the same, I store the object file of the runtime
| during compilation then load it dynamically at runtime - but to make
| this work I need to know where the object file is (-odir and -hidir) and
| I also need to know or be able to deduce the GHC DynFlags so I can
| replicate them at runtime.
| 
| I could also achieve this goal by putting my runtime in a separate
| package and installing it first, but that's less self-contained and
| would be a pain during development.
| 
| Cheers,
| 
| Ganesh
| 
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

accessing compilation parameters from template haskell

[Ganesh Sittampalam]

Hi,

It would be useful to access the current compilation parameters or even
an entire RunGhc monad from inside a Template Haskell splice. Is there
any way to do this?

The reason I want to do this is I'm using the ghc API at runtime to
dynamically execute code, and I want both the dynamically loaded code
and static code to use a shared runtime module that defines some types
used for communication across the boundary. To guarantee the internal
representations etc are the same, I store the object file of the runtime
during compilation then load it dynamically at runtime - but to make
this work I need to know where the object file is (-odir and -hidir) and
I also need to know or be able to deduce the GHC DynFlags so I can
replicate them at runtime.

I could also achieve this goal by putting my runtime in a separate
package and installing it first, but that's less self-contained and
would be a pain during development.

Cheers,

Ganesh

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Template-haskell] change in [d| |] and creating instances in template-haskell 2.7

[Jeremy Shaw]

Ah cool.

I just patched the code so that it uses mkName explicitly for now  
since it is Happstack related code and I want it to work the most  
places possible.


Thanks!
- jeremy

On Sep 8, 2011, at 12:07 PM, Simon Peyton-Jones wrote:


| Yeah. I would expect this to work:
|
| inferBar2 :: Name -> Q [Dec]
| inferBar2 typeName =
|[d| instance Bar $(conT typeName) where
|  bar _ = "sucker"
|  |]
|
| But I get the same error:
|
|  inferBar2 'Bool
|==>
|  show-test.hs:4:3-18
|  instance Bar Bool where
|  { bar_aTK _ = "sucker" }

Yes that should work. And it does with HEAD.  I fixed a bunch of  
stuff in the ticket I cited.  Maybe try a snapshot distribution?


Simon



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: [Template-haskell] change in [d| |] and creating instances in template-haskell 2.7

[Simon Peyton-Jones]

| Yeah. I would expect this to work:
| 
| inferBar2 :: Name -> Q [Dec]
| inferBar2 typeName =
|[d| instance Bar $(conT typeName) where
|  bar _ = "sucker"
|  |]
| 
| But I get the same error:
| 
|  inferBar2 'Bool
|==>
|  show-test.hs:4:3-18
|  instance Bar Bool where
|  { bar_aTK _ = "sucker" }

Yes that should work. And it does with HEAD.  I fixed a bunch of stuff in the 
ticket I cited.  Maybe try a snapshot distribution?

Simon

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Template-haskell] change in [d| |] and creating instances in template-haskell 2.7

[Jeremy Shaw]

On Sep 8, 2011, at 4:00 AM, Simon Peyton-Jones wrote:

[Redireting to ghc users; the TH list is pretty dormant and I keep  
thinking I should close it down altogether.]


Jeremy

Actually this is by design.  See the long thread at 
http://hackage.haskell.org/trac/ghc/ticket/5375

When you say

| inferBar typeName =
|do s <- [d| bar _ = "sucker"
|  |]

you are asking for a *new* definition bar _ = "sucker".  But in an  
instance declaration you have to mention the *existing* method name.


Right. That makes sense.


To put it another way, do you expect this to work?

 do { bar_nm <- newName "bar"
; return (InstanceD []  [FunD bar_nm ]) }

where you make up a *fresh name* (whose string-name is "bar") and  
use it in an instance declaration binding.


no.

I suppose you could argue that for the odd case of instance decls,  
TH should ignore the exact identity of the method name, and just use  
its string name. It would be convenient; but another weirdness too.


Yeah. I would expect this to work:

inferBar2 :: Name -> Q [Dec]
inferBar2 typeName =
  [d| instance Bar $(conT typeName) where
bar _ = "sucker"
|]

But I get the same error:

inferBar2 'Bool
  ==>
show-test.hs:4:3-18
instance Bar Bool where
{ bar_aTK _ = "sucker" }

show-test.hs:4:3:
Warning: No explicit method nor default method for `bar'
In the instance declaration for `Bar Bool'

Presumably because bar is still being created as a *fresh name*. I  
think in that version, it is more surprising that it does not work  
because the whole instance declaration is inside the [d| |].  
Additionally, it is not obvious (to me) how to work around the issue  
and keep the code pretty / easily readable.


But, as you point out, making bar not be a fresh name there creates a  
'special case'. So, that is not great either..


When you saw inferBar2, did you find it somewhat 'surprising' that it  
didn't work ?


- jeremy


User advice welcome!

Simon


| -Original Message-
| From: template-haskell-boun...@haskell.org [mailto:template-haskell-
| boun...@haskell.org] On Behalf Of Jeremy Shaw
| Sent: 07 September 2011 20:50
| To: template-hask...@haskell.org
| Subject: [Template-haskell] change in [d| |] and creating  
instances in template-

| haskell 2.7
|
| Hello,
|
| I have some code that likes like this, which works in template- 
haskell

| 2.5 / GHC 7.0.3:
|
| ---
| {-# Language TemplateHaskell, TypeFamilies #-}
| module Show where
|
| import Language.Haskell.TH
|
| class Bar a where
|bar :: a -> String
|
| inferBar :: Name -> Q [Dec]
| inferBar typeName =
|do s <- [d| bar _ = "sucker"
|  |]
|   d <- instanceD (return []) (appT (conT ''Bar) (conT typeName))
| (map return s)
|   return [d]
|
| -
|
| $(inferBar ''Bool)
|
| But, in template-haskell 2.6 / GHC 7.2.1, I get an error,
|
| Warning: No explicit method nor default method for `bar'
|  In the instance declaration for `Bar Bool'
|
| Comparing the output of -ddump-splices we see in GHC 7.0.3/ TH  
2.5, we

| have:
|
| bar-test.hs:1:1: Splicing declarations
|  inferBar 'Bool
|==>
|  bar-test.hs:4:3-17
|  instance Bar Bool where
|  { bar _ = "sucker" }
|
| But in GHC 7.2.1 / TH 2.6 we have:
|
| bar-test.hs:1:1: Splicing declarations
|  inferBar 'Bool
|==>
|  bar-test.hs:4:3-17
|  instance Bar Bool where
|  { bar_acAU _ = "sucker" }
|
| The difference being that instead 'bar' we have 'bar_acAU'.  So  
maybe

| that is why it can't find the method 'bar' in the instance
| declaration? Though, I would kind of expect an error like,
|
| `bar_acAU' is not a (visible) method of class `Bar'.
|
| Am I doing something wrong? Should I file a bug ?
|
| Thanks!
|
| - jeremy
|
|
|
| ___
| template-haskell mailing list
| template-hask...@haskell.org
| http://www.haskell.org/mailman/listinfo/template-haskell




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: [Template-haskell] change in [d| |] and creating instances in template-haskell 2.7

[Simon Peyton-Jones]

[Redireting to ghc users; the TH list is pretty dormant and I keep thinking I 
should close it down altogether.]

Jeremy

Actually this is by design.  See the long thread at 
http://hackage.haskell.org/trac/ghc/ticket/5375

When you say

| inferBar typeName =
|do s <- [d| bar _ = "sucker"
|  |]

you are asking for a *new* definition bar _ = "sucker".  But in an instance 
declaration you have to mention the *existing* method name.  

To put it another way, do you expect this to work?

  do { bar_nm <- newName "bar"
 ; return (InstanceD []  [FunD bar_nm ]) }

where you make up a *fresh name* (whose string-name is "bar") and use it in an 
instance declaration binding.

I suppose you could argue that for the odd case of instance decls, TH should 
ignore the exact identity of the method name, and just use its string name. It 
would be convenient; but another weirdness too.

User advice welcome!

Simon


| -Original Message-
| From: template-haskell-boun...@haskell.org [mailto:template-haskell-
| boun...@haskell.org] On Behalf Of Jeremy Shaw
| Sent: 07 September 2011 20:50
| To: template-hask...@haskell.org
| Subject: [Template-haskell] change in [d| |] and creating instances in 
template-
| haskell 2.7
| 
| Hello,
| 
| I have some code that likes like this, which works in template-haskell
| 2.5 / GHC 7.0.3:
| 
| ---
| {-# Language TemplateHaskell, TypeFamilies #-}
| module Show where
| 
| import Language.Haskell.TH
| 
| class Bar a where
|bar :: a -> String
| 
| inferBar :: Name -> Q [Dec]
| inferBar typeName =
|do s <- [d| bar _ = "sucker"
|  |]
|   d <- instanceD (return []) (appT (conT ''Bar) (conT typeName))
| (map return s)
|   return [d]
| 
| -
| 
| $(inferBar ''Bool)
| 
| But, in template-haskell 2.6 / GHC 7.2.1, I get an error,
| 
| Warning: No explicit method nor default method for `bar'
|  In the instance declaration for `Bar Bool'
| 
| Comparing the output of -ddump-splices we see in GHC 7.0.3/ TH 2.5, we
| have:
| 
| bar-test.hs:1:1: Splicing declarations
|  inferBar 'Bool
|==>
|  bar-test.hs:4:3-17
|  instance Bar Bool where
|  { bar _ = "sucker" }
| 
| But in GHC 7.2.1 / TH 2.6 we have:
| 
| bar-test.hs:1:1: Splicing declarations
|  inferBar 'Bool
|==>
|  bar-test.hs:4:3-17
|  instance Bar Bool where
|  { bar_acAU _ = "sucker" }
| 
| The difference being that instead 'bar' we have 'bar_acAU'.  So maybe
| that is why it can't find the method 'bar' in the instance
| declaration? Though, I would kind of expect an error like,
| 
| `bar_acAU' is not a (visible) method of class `Bar'.
| 
| Am I doing something wrong? Should I file a bug ?
| 
| Thanks!
| 
| - jeremy
| 
| 
| 
| ___
| template-haskell mailing list
| template-hask...@haskell.org
| http://www.haskell.org/mailman/listinfo/template-haskell


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Template Haskell: onward and upward

[Simon Peyton-Jones]

Folks

Following lots of feedback from users, especially at ICFP, I've evolved some 
proposals for Template Haskell, that should make it both more expressive, and 
more secure.

http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal

Do let me know what you think.  Discussion by email is fine (cc me if it's on 
Haskell-cafe), or comments direct on the Trac.

(None of this will be in GHC 7.0; it's a proposed plan for post-release 
improvements.)

Thanks

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Template Haskell and linking

[Simon Peyton-Jones]

It probably is linked if you use  --make, but should not be if you use an 
explicit link command
ghc -o run-me A.o B.o C.o
Just omit LargeThModule.o

Hmm.  Maybe this won't work, because there is a module initialisation tree, in 
which each module calls the initialisation function of the modules it imports. 
So probably the module that imports LargeThModule will call LargeThModule's 
initialisation function, so omitting LargeThModule.o would give a link error.

I suppose you could hack around this by commenting out the body of 
LargeThModule and recompiling it to make  a small .o file for runtime linking, 
but it would be a gross hack.

Oh, here's a thought.  If you use -split-objs, the linker should drop all 
non-executed code, so that will probably do what you want.  

Simon

From: glasgow-haskell-users-boun...@haskell.org 
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Jonas Almström 
Duregård
Sent: 17 September 2010 21:48
To: glasgow-haskell-users@haskell.org
Subject: Template Haskell and linking

Hi GHC users!

Does anyone know if an import that is only used by Template Haskell (i.e. not 
in "actual" code) is reflected in the produced executable?

Example:

import LargeModule(thFunction)

$thfunction

...

Is LargeModule linked in the executable file? (Assume thFunction is not 
referenced by the code it generates or elsewhere in the example)

Best regards
Jonas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Template Haskell and linking

[Jonas Almström Duregård]

Hi GHC users!

Does anyone know if an import that is only used by Template Haskell (i.e.
not in "actual" code) is reflected in the produced executable?

Example:

import LargeModule(thFunction)

$thfunction

...

Is LargeModule linked in the executable file? (Assume thFunction is not
referenced by the code it generates or elsewhere in the example)

Best regards
Jonas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Template Haskell reification of instances

[Simon Peyton-Jones]

Dear TH users

In Template Haskell, it's not currently possible to say "give me all the 
instances of this class"; it's a long-standing feature request.

Sam Anklesaria has come up with a design and implemented it. Before committing 
to it, I want to check that other Template Haskell users are happy with the 
design. 

You can find the details here:
http://hackage.haskell.org/trac/ghc/ticket/1835

But a summary of the design appears below.  If you have a stake in Template 
Haskell, pls RSVP by adding a comment to the ticket.

Thanks

Simon



Proposed design

* Extending the Quasi monad to have

  class (Monad m, Functor m) => Quasi m where
...
qReify :: Name -> m Info
qIsClassInstance :: Name -> [Type] -> m Bool

  isClassInstance :: Name -> [Type] -> Q Bool
  isClassInstance n ts = Q (qIsClassInstance n ts)

* Extending the info you get back when reifying a Class, by adding its 
instances:

  data Dec = ...
| ClassI Dec [([TyVarBndr],Cxt,[Type])]

Some random thoughts

* In principle, I suppose that isClassInstance isn't really necessary: 
  you could reify the class and search the list yourself. 
  But I can see that it's convenient.

* Currently isClassInstance returns True if any instances match, 
  even if they overlap etc. Might you want to know more?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Annotations and Template Haskell

[Bertram Felgenhauer]

Hello Simon,

> I'm not sure what you intend here. Can you be more concrete?

A concrete example could look like this,

  {-# ANN T $(defaultValue [| T { foo = 1 } |]) #-}
  data T = T { foo :: Int, baz :: Int }

where defaultValue :: Q Exp -> Q Exp  would encode the value in a
suitable form. The intention is to specify default values for some
fields of the record.

Then, later, I want to generate a parser for T, that takes the default
value into consideration, in order to make the foo field optional and
the baz field mandatory.

  $(deriveParser ''T)

Inside deriveParser, I want to access the annotation of T. That
requires a function like

  getAnnotations :: (Typeable a, Binary a) => Name -> Q [a]

which does not exist. So the first question is,

Would adding this function be feasible? If yes, what sort of stage
restrictions would be required to make it work?

Continuing the example above, I can achieve the same effect by passing
the default value in some form as an argument to  deriveParser. But I'd
prefer using an annotation because then I only have to specify that
value once even if there are several chunks of generated code that rely
on a default value. A second advantage is that an unused annotation does
not add any clutter to the code at all -- it can be completely optional.
So in my eyes this feature would be ideal for specifying exceptional
handling of a few data types (or functions or constructors) from
Template Haskell code.

Of course there are disadvantages as well, foremost that it'd be yet
another ghc specific extension. So the second question is, is the idea
really useful enough to justify being implemented?

regards,

Bertram

[annotations] http://hackage.haskell.org/trac/ghc/wiki/Annotations
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Annotations and Template Haskell

[Simon Peyton-Jones]

I'm not sure what you intend here. Can you be more concrete?

Simon

| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Bertram Felgenhauer
| Sent: 08 March 2010 10:28
| To: glasgow-haskell-users@haskell.org
| Subject: Annotations and Template Haskell
| 
| Hello,
| 
| I'm wondering whether annotations [1] could be made available to
| Template Haskell users as a ghc specific extension.
| 
| Would that be feasible? Would it be useful?
| 
| An example use would be annotating a type with a representation of a
| default value that could be used in generating instances for various
| type classes (like parsers that take the default value into account).
| 
| The alternative would be to pass that representation explicitely to
| every single Template Haskell invocation that uses it.
| 
| Regards,
| 
| Bertram
| 
| [1] http://hackage.haskell.org/trac/ghc/wiki/Annotations
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Annotations and Template Haskell

[Bertram Felgenhauer]

Hello,

I'm wondering whether annotations [1] could be made available to
Template Haskell users as a ghc specific extension.

Would that be feasible? Would it be useful?

An example use would be annotating a type with a representation of a
default value that could be used in generating instances for various
type classes (like parsers that take the default value into account).

The alternative would be to pass that representation explicitely to
every single Template Haskell invocation that uses it.

Regards,

Bertram

[1] http://hackage.haskell.org/trac/ghc/wiki/Annotations
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Template Haskell pattern quotations

[Brad Larsen]

On Thu, Feb 4, 2010 at 5:47 AM, Sebastian Fischer
 wrote:
>
> On Feb 4, 2010, at 8:58 AM, Simon Peyton-Jones wrote:
>
>> Unless I have a sudden revelation I don't expect to implement pattern
>> splices anytime soon.
>>
>> On the other hand, pattern *quasiquotes* are fine; they are run by the
>> renamer before scope analysis is done.  So you can certainly say
>>        f [qq| ...blah.. |] = ...g...
>
> If I understand Brad correctly, then what he needs is what he called pattern
> quotation rather than splicing.
>
> He can write
>
>    [e|True|]  instead of  conE (mkName "True")
>
> to implement the  Exp  parser of his quasi quoter but he cannot write
>
>    [p|True|]  instead of  conP (mkName "True")
>
> to implement his  Pat  parser because GHC tells him that "Tempate Haskell
> pattern brackets are not supported yet".
>
> My impression is that the problems with pattern splicing are not affected by
> support for pattern brackets. We can define a quasi quoter  qq  to implement
>
>    id :: a -> a
>    id [$qq|x|] = x
>
> independently of whether we use pattern brackets in its definition or not.
> Or am I missing something?
>
> Is there a problem with adding support for pattern brackets on the
> right-hand side of function definitions in order to simplify the definition
> of quasi quoters?
>
> Sebastian
>
>
> --
> Underestimating the novelty of the future is a time-honored tradition.
> (D.G.)

Yes, I think you have nailed my problem, and described it better than
I did!  It would be convenient to be able to use the pattern quotation
in the right hand side of a definition, when implementing a
quasiquoter without relying on the Data.Generics technique.

Brad
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Template Haskell pattern quotations

[Simon Peyton-Jones]

| If I understand Brad correctly, then what he needs is what he called
| pattern quotation rather than splicing.
...
| 
| Is there a problem with adding support for pattern brackets on the
| right-hand side of function definitions in order to simplify the
| definition of quasi quoters?

Oh, thank you for clarifying. I'd totally missed that.

No, there's no problem at all with pattern quotes. (I've just done the work and 
it took 10 mins.) I'm already messing with the TH stuff in pursuit of the 
quasi-quote changes I advertised, so I'll commit it at the same time.  That is

TH pattern quotes will work
but TH pattern splices will continue not to exist

Thanks for sorting out my misunderstanding.

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Template Haskell pattern quotations

[Sebastian Fischer]

On Feb 4, 2010, at 8:58 AM, Simon Peyton-Jones wrote:

Unless I have a sudden revelation I don't expect to implement  
pattern splices anytime soon.


On the other hand, pattern *quasiquotes* are fine; they are run by  
the renamer before scope analysis is done.  So you can certainly say

f [qq| ...blah.. |] = ...g...


If I understand Brad correctly, then what he needs is what he called  
pattern quotation rather than splicing.


He can write

[e|True|]  instead of  conE (mkName "True")

to implement the  Exp  parser of his quasi quoter but he cannot write

[p|True|]  instead of  conP (mkName "True")

to implement his  Pat  parser because GHC tells him that "Tempate  
Haskell pattern brackets are not supported yet".


My impression is that the problems with pattern splicing are not  
affected by support for pattern brackets. We can define a quasi  
quoter  qq  to implement


id :: a -> a
id [$qq|x|] = x

independently of whether we use pattern brackets in its definition or  
not. Or am I missing something?


Is there a problem with adding support for pattern brackets on the  
right-hand side of function definitions in order to simplify the  
definition of quasi quoters?


Sebastian


--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Template Haskell pattern quotations

[Simon Peyton-Jones]

| My question:  Are Template Haskell pattern quotations (i.e., [p| ...
| |]) not implemented in GHC because they are rather tricky to
| implement, or because there has not been demand for them?

They are tricky!  The trouble is that patterns *bind variables*.  I don't know 
how to deal cleanly with this. For example
f $p = ...g...
g x = ...f...
Are these mutually recursive?  Not if $p expands to something that binds g!  
But we need to sort bindings into recursive groups before type checking.  But 
splices must be typechecked before being run, so TH splices are run by the 
typechecker.

Unless I have a sudden revelation I don't expect to implement pattern splices 
anytime soon.  

On the other hand, pattern *quasiquotes* are fine; they are run by the renamer 
before scope analysis is done.  So you can certainly say
f [qq| ...blah.. |] = ...g...

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Template Haskell pattern quotations

[Robert Greayer]

The *splicing* of patterns is considered tricky, see:
http://hackage.haskell.org/trac/ghc/ticket/1476

Implementing pattern quotations might be less tricky, but I would
imagine to make them useful, you'd have to allow splicing things
*into* them, which requires implementing pattern splicing.   That's my
non-expert take on the issue.


On Wed, Feb 3, 2010 at 7:32 PM, Brad Larsen  wrote:
> I'll put my question at the very front of this message, and then give
> the context.
>
> My question:  Are Template Haskell pattern quotations (i.e., [p| ...
> |]) not implemented in GHC because they are rather tricky to
> implement, or because there has not been demand for them?
>
> And now, the context.
>
> I am working on an embedded DSL/compiler in Haskell, and I want to
> make use of the recently-much-discussed quasiquoting mechanism to ease
> reading & writing various transformations.
>
> I read through the quasiquoting paper [1] again and played around with
> some simple examples.  In the paper, Data.Generics is used so that the
> same parser can be used for quasiquoting both expressions and
> patterns.  This requires adding constructors to the ASTs being
> quasiquoted for antiquotations to be possible.
>
> In my application, I don't anticipate using Data.Generics for parser
> reuse, for a few reasons:
>  * I haven't read the SYB papers, and don't understand how
> Data.Generics or Data.Data work.
>  * My ASTs in some cases involve GADTs with several phantom type
> parameters (is that the right terminology?), and DeriveDataTypeable
> does not work with them.
>  * I don't want to add the extra constructors necessary to support
> antiquotation with the Data.Generics approach.
>
> So, I'm stuck writing separate ExpQ / PatQ parsers.  (Actually, I can
> write the parser once, if it takes a dictionary of semantic actions as
> a parameter, in which case I only need to write the dictionary of ExpQ
> actions and the dictionary of PatQ actions.)  When writing the ExpQ
> parser, I can use Template Haskell expression quotations, [| ... |].
> When writing the PatQ parser, I have to resort to using the various
> pattern construction combinators, which is unfortunate!  I'd like to
> be able to use pattern quotations instead.
>
> So, my question once again:  How hard would it be to implement the
> pattern quotations from the Template Haskell paper in GHC?
>
> Sincerely,
> Brad
>
>
> References:
>
> [1]  Geoffrey B. Mainland.  Why It's Nice to be Quoted:  Quasiquoting
> for Haskell.  
> <http://www.eecs.harvard.edu/~mainland/ghc-quasiquoting/mainland07quasiquoting.pdf>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Template Haskell pattern quotations

[Brad Larsen]

I'll put my question at the very front of this message, and then give
the context.

My question:  Are Template Haskell pattern quotations (i.e., [p| ...
|]) not implemented in GHC because they are rather tricky to
implement, or because there has not been demand for them?

And now, the context.

I am working on an embedded DSL/compiler in Haskell, and I want to
make use of the recently-much-discussed quasiquoting mechanism to ease
reading & writing various transformations.

I read through the quasiquoting paper [1] again and played around with
some simple examples.  In the paper, Data.Generics is used so that the
same parser can be used for quasiquoting both expressions and
patterns.  This requires adding constructors to the ASTs being
quasiquoted for antiquotations to be possible.

In my application, I don't anticipate using Data.Generics for parser
reuse, for a few reasons:
  * I haven't read the SYB papers, and don't understand how
Data.Generics or Data.Data work.
  * My ASTs in some cases involve GADTs with several phantom type
parameters (is that the right terminology?), and DeriveDataTypeable
does not work with them.
  * I don't want to add the extra constructors necessary to support
antiquotation with the Data.Generics approach.

So, I'm stuck writing separate ExpQ / PatQ parsers.  (Actually, I can
write the parser once, if it takes a dictionary of semantic actions as
a parameter, in which case I only need to write the dictionary of ExpQ
actions and the dictionary of PatQ actions.)  When writing the ExpQ
parser, I can use Template Haskell expression quotations, [| ... |].
When writing the PatQ parser, I have to resort to using the various
pattern construction combinators, which is unfortunate!  I'd like to
be able to use pattern quotations instead.

So, my question once again:  How hard would it be to implement the
pattern quotations from the Template Haskell paper in GHC?

Sincerely,
Brad


References:

[1]  Geoffrey B. Mainland.  Why It's Nice to be Quoted:  Quasiquoting
for Haskell.  
<http://www.eecs.harvard.edu/~mainland/ghc-quasiquoting/mainland07quasiquoting.pdf>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: bug in template haskell (with recursion?)

[Jake Wheat]

Sorry for posting this on the wrong mailing list.

I added the bug to the tracker here:
http://hackage.haskell.org/trac/ghc/ticket/3845
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

bug in template haskell (with recursion?)

[Jake Wheat]

Hello All,

I'm trying to write a splice to make HList type signatures a bit more
concise, I don't know whether this is a good idea or not.

I wrote a small function to do '[(Type,Type)] -> Q Type' for this, and
got the following from GHC. Should I add this to the bug tracker?

Details:

THBug1.hs:
{-# LANGUAGE TemplateHaskell #-}

module THBug1 where

import Data.HList
import Language.Haskell.TH


mhlt :: [(Type,Type)] -> Q Type
mhlt x = [t| Record $(foldThing x)|]
  where
foldThing ((f,t):xs) = [t|HCons (LVPair (Proxy $f) $t) $(foldThing xs)|]
foldThing [] = [t|HNil|]



$ ghc -c THBug1.hs

THBug1.hs:12:61:
GHC internal error: `foldThing' is not in scope during type
checking, but it passed the renamer
tcg_type_env of environment: []
In the expression: foldThing xs
In the Template Haskell quotation
  [t| HCons (LVPair (Proxy $f) $t) $(foldThing xs) |]
In the expression:
[t| HCons (LVPair (Proxy $f) $t) $(foldThing xs) |]

I'm using GHC 6.12.1 from debian experimental:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1

$ ghc-pkg list |grep template
template-haskell-2.4.0.0

To get HList to install with GHC 6.12, I downloaded the latest version from
http://old-darcs.well-typed.com/HList/

and altered it slightly, updated package here:
http://launchpad.net/hssqlppp/prealpha/environment/+download/HList-0.2.tar.gz

the changes I made are:
diff -rN old-HList/Data/HList/GhcSyntax.hs new-HList/Data/HList/GhcSyntax.hs
2c2
< {-# LANGUAGE FlexibleContexts #-}
---
> {-# LANGUAGE FlexibleContexts, TypeOperators #-}
diff -rN old-HList/Data/HList/Label2.hs new-HList/Data/HList/Label2.hs
1c1,2
< {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses,
UndecidableInstances, EmptyDataDecls #-}
---
> {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, 
> EmptyDataDecls,
>   ExistentialQuantification #-}
36c37
< data HNat x => Label x ns desc  -- labels are exclusively type-level entities
---
> data Label x ns desc = HNat x => Label x ns desc  -- labels are exclusively 
> type-level entities
diff -rN old-HList/Data/HList/Label3.hs new-HList/Data/HList/Label3.hs
1c1,2
< {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses,
UndecidableInstances, EmptyDataDecls #-}
---
> {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, 
> EmptyDataDecls,
>   ExistentialQuantification #-}
37c38
< data HNat x => Label x ns desc  -- labels are exclusively type-level entities
---
> data Label x ns desc = HNat x => Label x ns desc  -- labels are exclusively 
> type-level entities

(If it's not obvious, I have no idea what I'm doing..., but my small
amount of code which uses HList worked fine with this altered
package.)

Thanks,
Jake Wheat
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: [Template-haskell] Querying the instances a data type implements

[Simon Peyton-Jones]

All: as Robert says, I keep meaning to close the template-haskell list 
altogether; but I am not sure how to do so.

Jonathan: where did you find a pointer to the mailing list?  I should remove 
those too.

Returning to the question, sadly there's no way to do what you want right now.  
There's an open feature request:
 http://hackage.haskell.org/trac/ghc/ticket/1835
Would anyone like to undertake it?  It's not hard.

Simon

From: template-haskell-boun...@haskell.org 
[mailto:template-haskell-boun...@haskell.org] On Behalf Of 
jonathangfisch...@gmail.com
Sent: 17 January 2010 23:42
To: template-hask...@haskell.org
Subject: [Template-haskell] Querying the instances a data type implements

Hi,

I am trying query the instances that a data type implements. Calling reify on 
the data type doesn't appear to return anything relating to type classes.

I am very new to Template Haskell, so I apologize if there is a easy way to do 
this that I missed.

-Jonathan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: [Template-haskell] How to extract name and type of exported functions in modules

[Simon Peyton-Jones]

| First I thought I would examine the source code of template-haskell
| (more specifically qLocation and qReify) to figure out how to do it
| but got stuck. Obviously I have still much to learn when it comes to
| Haskell.
| 
| Could someone explain how Quasi works?

Have you read the paper?  Referred to from here 
http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html, 
the particular bit you want is Section 10 of 
http://research.microsoft.com/~simonpj/papers/meta-haskell/notes2.ps

| The only way this can work (as fast as I can see) is if where is
| another instance of Quasi than Q and IO but I cannot find that
| instance in the source code.

Yes indeed there is -- the type checker monad!  See TcSplice line 819.

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: [Template-haskell] How to extract name and type of exported functions in modules

[Simon Peyton-Jones]

| -- If it exports any prelude indentifiers (not only the Prelude itself,
|but also for example Data.List), I have no idea how to get at
|their types --- lookupGlobalName does not find them.

Well, it claims that it should find them.   Would you like to make a 
reproducible test case and file a Trac bug report?

| -- I cannot find any re-exported instances. The ``package InstEnv''
|obtained from tcGetInstEnvs after loading a library module interface
|(via findAndReadIface) seems to contain only the module's own exported
|instances, which are the same instances I also find via mi_insts.
|(For source modules, where I use typeCheckModule,
| I've only been able to find the module's own exported instances via
| hptInstances).

Hmm.  GHC does not read every interface file for every module in every package 
that is transitively visible from the current module.  Instead it relies on the 
fact that before an instance (C T) is useful, you must have a hold of Class C 
and TyCon T.  So you'll have loaded *their* interfaces, and thereby loaded 
their instances. (Except for orphan instances, which *are* loaded eagerly.)

I can see that this is inconvenient; on the other hand, do you really want ALL 
the instances of Ord, say?  

Perhaps there should be an interface for
load instances that relate to the following Names
Indeed, there is: LoadIface.loadInterfaceForName.

Does that help?  What's the desired behaviour?


I really wish there was someone who took ownership for the GHC API, as seen by 
"customers" of the API.  At the moment it grows incrementally, without proper 
design.  Maybe no one feels able to, because they think GHC HQ will do it, but 
(a) we are too busy and (b) we represent the suppliers of the API, not the 
customers.

Any volunteeers?

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users