headers
Alfonso Acosta | 1 Oct 2007 14:51
Picon

Any chances of having TH included in Haskell II?

Hi,

I recently developed an embedded DSL compiler making use of TH (and my
plan is to continue with its development). However, my employers are
naturally concerned about the long-term support of Template Haskell.

I've been trying to gather some information about it, but I don't seem
to find any opened tickets in haskell-prime.

Can anyone confirm if there are any plans of including Template
Haskell in the next standard and/or any information regarding
long-term support?

Best Regards,

Alfonso Acosta
Permalink | Reply | 3 comments |
headers
Simon Peyton-Jones | 2 Oct 2007 07:40
Picon
Favicon
Gravatar

RE: Any chances of having TH included in Haskell II?

Hi Alfonso

GHC is an open-source project, so anyone can enhance or maintain it.  It's used by thousands of people, so I
think it'll continue to attract developers who are prepared to help support it.  For myself, I certainly to
expect to continue doing so for the foreseeable future.

Template Haskell is part of GHC -- it's not a separate program.   I always wonder how many people use TH.  The TH
mailing list is quite quiet.  There aren't many bug reports, but that could always be because it just works. 
A couple of talks here at the Haskell Workshop have mentioned they use TH, which I didn't know about.

So TH is one of the less-heavily-used parts of GHC, although I think there are a bunch of users who rely on it.
Nevertheless, I'd expect it to continue working as long as GHC does.

Does that help?

Simon

| -----Original Message-----
| From: template-haskell-bounces <at> haskell.org [mailto:template-haskell-
| bounces <at> haskell.org] On Behalf Of Alfonso Acosta
| Sent: 01 October 2007 13:51
| To: template-haskell <at> haskell.org
| Subject: [Template-haskell] Any chances of having TH included in Haskell II?
|
| Hi,
|
| I recently developed an embedded DSL compiler making use of TH (and my
| plan is to continue with its development). However, my employers are
| naturally concerned about the long-term support of Template Haskell.
|
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andy Gill | 2 Oct 2007 09:17
Favicon

Re: Any chances of having TH included in Haskell II?

The Haskell Equational Reasoning Assistant (HERA) system makes
extensive use of Template Haskell, without it there would be no HERA.
But Template Haskell just works, and works well for our needs.

Andy Gill

On Oct 2, 2007, at 7:40 AM, Simon Peyton-Jones wrote:

> Hi Alfonso
>
> GHC is an open-source project, so anyone can enhance or maintain  
> it.  It's used by thousands of people, so I think it'll continue to  
> attract developers who are prepared to help support it.  For  
> myself, I certainly to expect to continue doing so for the  
> foreseeable future.
>
> Template Haskell is part of GHC -- it's not a separate program.   I  
> always wonder how many people use TH.  The TH mailing list is quite  
> quiet.  There aren't many bug reports, but that could always be  
> because it just works.  A couple of talks here at the Haskell  
> Workshop have mentioned they use TH, which I didn't know about.
>
> So TH is one of the less-heavily-used parts of GHC, although I  
> think there are a bunch of users who rely on it. Nevertheless, I'd  
> expect it to continue working as long as GHC does.
>
> Does that help?
>
> Simon
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alfonso Acosta | 4 Oct 2007 02:12
Picon

Re: Any chances of having TH included in Haskell II?

On 10/2/07, Simon Peyton-Jones <simonpj <at> microsoft.com> wrote:
> Nevertheless, I'd expect it to continue working as long as GHC does.

That's pretty much what I wanted to know.

> Does that help?

Considering your role in GHC and Template Haskell, yes, it really does help :)
Permalink | Reply | 0 comments |
headers
Alfonso Acosta | 23 Oct 2007 03:51
Picon

Defining a function and using it in a splice within the same module

Hi,

The user guide from latest GHC release makes clear that doing what I
wrote in the subject of this message is not possible:

>From 7.6:

"You can only run a function at compile time if it is imported from
another module. That is, you can't define a function in a module, and
call it from within a splice in the same module."

Unfortunately I have encountered this problem more times than I'd like
while using TH to implement a DSL. My usual solution is to generate a
function to process the extra arguments which cannot be passed to the
splice (i.e. push the arguments out of the splice so that I can use
functions defined in the same module).

Nevertheless, I'd like to know if there are any chances of seeing this
problem solved anytime soon.

Thanks,

Alfonso
Permalink | Reply | 502 comments |
headers
Simon Peyton-Jones | 24 Oct 2007 14:01
Picon
Favicon
Gravatar

RE: Defining a function and using it in a splice within the same module


| "You can only run a function at compile time if it is imported from
| another module. That is, you can't define a function in a module, and
| call it from within a splice in the same module."
|
| Unfortunately I have encountered this problem more times than I'd like
| while using TH to implement a DSL. My usual solution is to generate a
| function to process the extra arguments which cannot be passed to the
| splice (i.e. push the arguments out of the splice so that I can use
| functions defined in the same module).

I don't quite understand your workaround.  Can you describe it a bit more?

| Nevertheless, I'd like to know if there are any chances of seeing this
| problem solved anytime soon.

Here's why it's hard.  It involves compiling the functions *before* the splice to bytecode, so that they can
be run.  But we don't always want to do that!  Usually we do not run any of these functions, and we want to
compile them to object code.  I don't think it's acceptable to *always* compile *everything* to bytecode,
just in case.

So the trickiness is simply the plumbing required to notice that f is called from inside a splice, so we'd
better compile it to bytecode early.   Oh, and the transitive closure of things called by f.

A possible approximation is: see if *anything* defined in this module is called from within a splice, and if
so compile *everything* to bytecode, just in case.

I doubt I'll get to this soon.  Is anyone else interested in working on it?

I've created a ticket for it though: http://hackage.haskell.org/trac/ghc/ticket/1800
(Continue reading)

Permalink | Reply | 502 comments |
headers
Alfonso Acosta | 24 Oct 2007 15:49
Picon

Re: Defining a function and using it in a splice within the same module

On 10/24/07, Simon Peyton-Jones <simonpj <at> microsoft.com> wrote:
>
> | "You can only run a function at compile time if it is imported from
> | another module. That is, you can't define a function in a module, and
> | call it from within a splice in the same module."
> |
> | Unfortunately I have encountered this problem more times than I'd like
> | while using TH to implement a DSL. My usual solution is to generate a
> | function to process the extra arguments which cannot be passed to the
> | splice (i.e. push the arguments out of the splice so that I can use
> | functions defined in the same module).
>
> I don't quite understand your workaround.  Can you describe it a bit more?

Well, it doesn't solve the issue of executing things at compile-time,
it simply delays their execution until proper runtime.

As a (simplified) example, in my System Modelling DSL I have to create
system definition. That is done by providing the function Name
together with the identifiers of its inputs and outputs.

inputs = ["in1", "in2"]

outputs = ["out1", "out2"]

f :: Signal Int -> Signal Int -> (Signal Int, Signal Int)
f = ...

Since it is not possible to do
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alfonso Acosta | 24 Oct 2007 23:46
Picon

What happened to currentLoc ?

Hi,

I've been trying to improve error reporting in my TH-based embedded
compiler. I sometimes build data structures using splices. Those
structures can later cause an error at runtime which, to be more
informative, should give the line and module in which the splice was
executed (i.e. tell to what structure the error refering by telling
where it was exactly created)

I have just read about currentLoc in the "Notes on Template Haskell 2"
document.

currentLoc :: Q (FilePath, Int)

  -- Returns the location of the top-level splice being executed.

Was it ever implemented? Are there any plans to do it?

The path to the module is not really important (it should be enough
with currentModule) but the line information can be really helpful.

Thanks,

Fons
Permalink | Reply | 3 comments |
headers
Simon Peyton-Jones | 25 Oct 2007 10:02
Picon
Favicon
Gravatar

RE: What happened to currentLoc ?

There's nothing difficult about this, but it's sadly not implemented. This exists:
        currentModule :: Q String exists
but not currentLoc.

To add currentLoc would mean changing the definition of the Q monad; not hard, but an API change.  Then
currentLoc would report the location of the splice -- I assume that's what you want.

Would you like to make a Trac feature request for this?  No reason it should not go in 6.10.

Simon

| -----Original Message-----
| From: template-haskell-bounces <at> haskell.org [mailto:template-haskell-bounces <at> haskell.org] On
Behalf Of
| Alfonso Acosta
| Sent: 24 October 2007 22:46
| To: template-haskell <at> haskell.org
| Subject: [Template-haskell] What happened to currentLoc ?
|
| Hi,
|
| I've been trying to improve error reporting in my TH-based embedded
| compiler. I sometimes build data structures using splices. Those
| structures can later cause an error at runtime which, to be more
| informative, should give the line and module in which the splice was
| executed (i.e. tell to what structure the error refering by telling
| where it was exactly created)
|
| I have just read about currentLoc in the "Notes on Template Haskell 2"
| document.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Peyton-Jones | 25 Oct 2007 11:37
Picon
Favicon
Gravatar

RE: Defining a function and using it in a splice within the same module

| As a (simplified) example, in my System Modelling DSL I have to create
| system definition. That is done by providing the function Name
| together with the identifiers of its inputs and outputs.
|
| inputs = ["in1", "in2"]
|
| outputs = ["out1", "out2"]
|
| f :: Signal Int -> Signal Int -> (Signal Int, Signal Int)
| f = ...
|
| Since it is not possible to do
|
| system :: SysDef
| system = $(mkSysDef 'f inputs outputs)
|
| due to the limitation we mentioned
|
| I simply do
|
| system = $(mkSysDef 'f) inputs outputs
|
| where mkSysDef :: Name -> [String] -> [String] -> SysDef

Ah I see.  Although you presumably meant
        mkSysDef :: Name -> Q ([String] -> [String] -> SysDef)
else it'd be ill-typed.

| Excuse my ignorance (I'm not familiar with the internals of GHC) but,
| wouldn't it be possible to compute a dependency graph for each splice
(Continue reading)

Permalink | Reply | 2 comments |

Gmane