headers
Simon Peyton-Jones | 20 Aug 2004 17:37
Picon
Favicon
Gravatar

FW: RE: calling fail in Q monad gives uninformativeerror message, anderror causes panic

Dear Template Haskell colleagues

I sent three messages to the TH list a month ago.  Here's one of them:
the others concerned the conversions TH.Syntax <-> HsSyn; I'll fwd them
in the next two messages

I didn't get a single reply to any of the three.  Either the TH mailing
list is broken, or else you are all busy with other stuff.  (After all,
all three did ask for volunteers, in one form or another.)

Does anyone care? I'm busy implementing GADTs at the moment, so TH has a
somewhat back seat.  It'll probably stay that way unless there are some
signs of life in the TH ranks.

Simon

-----Original Message-----
From: template-haskell-bounces <at> haskell.org
[mailto:template-haskell-bounces <at> haskell.org] On Behalf Of Simon
Peyton-Jones
Sent: 20 July 2004 12:19
To: Duncan Coutts; Template Haskell List
Subject: [Template-haskell] RE: calling fail in Q monad gives
uninformativeerror message, anderror causes panic

Tim and I want to tidy up the error-reporting interface in Template
Haskell.   The goal is that a TH user should be able to control the
error messages that appear.  Here's a proposal

  qReport  :: Severity -> String -> Q ()	-- Report an error or
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Peyton-Jones | 20 Aug 2004 17:37
Picon
Favicon
Gravatar

FW: FW: [ ghc-Bugs-992199 ] Template crash onexistential types

Second message referred to in my last post...

-----Original Message-----
From: template-haskell-bounces <at> haskell.org
[mailto:template-haskell-bounces <at> haskell.org] On Behalf Of Simon
Peyton-Jones
Sent: 19 July 2004 17:51
To: template-haskell <at> haskell.org
Subject: [Template-haskell] FW: [ ghc-Bugs-992199 ] Template crash
onexistential types

My previous message was about robust-ifying the conversion from:
	TH.Syntax -> HsSyn
but the other direction has very similar problems.  The functions in
DsMeta convert:
	HsSyn -> TH.Syntax
Unfortunately, of course TH does not implement all of GHC's extensions,
so the desugaring can fall over badly.

The right thing to do is presumably to make the desugarer monad support
failure and errors, like the type checker monad does, and fail more
gracefully.

Again, is there anyone who'd be prepared to take this on?

Simon 

-----Original Message-----
From: glasgow-haskell-bugs-bounces <at> haskell.org
[mailto:glasgow-haskell-bugs-bounces <at> haskell.org] On Behalf Of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Peyton-Jones | 20 Aug 2004 17:37
Picon
Favicon
Gravatar

FW: FW: [ ghc-Bugs-992200 ] Template crash onconstructing existential datatype

...and the third one...

-----Original Message-----
From: template-haskell-bounces <at> haskell.org
[mailto:template-haskell-bounces <at> haskell.org] On Behalf Of Simon
Peyton-Jones
Sent: 19 July 2004 17:35
To: template-haskell <at> haskell.org
Subject: [Template-haskell] FW: [ ghc-Bugs-992200 ] Template crash
onconstructing existential datatype

Dear Template Haskell folk

This SourceForge bug is another example of the bad things that happen
when:

- a TH program constructs a syntactically invalid program
- and then splices it in

The trouble is that Convert.convertToHsExpr :: TH.Exp -> LHsExpr RdrName
is a pure function, and fails "hard" with a panic, whereas it should
really be in the TcM monad, and fail in the way any other type error
fails.  It's a user error, and should not show up as a panic.

Would anyone like to fix hsSyn/Convert.lhs so that it lives in the Tc
monad?  The call (in TcSplice) is easily changed.  It'd probably make
sense to move it from hsSyn/ to typecheck/

I'm thinking about putting types in the syntax tree, so if others can
help out with tidying up like this, it'd be great.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Thomas | 23 Aug 2004 14:07
Picon

Re: FW: RE: calling fail in Q monad gives uninformativeerror message, anderror causes panic

Hi Simon.

I think you deserve a reply on these questions as at their heart is an 
important point which I believe remains unanswered.

Simon Peyton-Jones wrote:
> Dear Template Haskell colleagues
> 
> I sent three messages to the TH list a month ago.  Here's one of them:
> the others concerned the conversions TH.Syntax <-> HsSyn; I'll fwd them
> in the next two messages
> 
> I didn't get a single reply to any of the three.  Either the TH mailing
> list is broken, or else you are all busy with other stuff.  (After all,
> all three did ask for volunteers, in one form or another.)
> 
> Does anyone care?

I am not using TH personally due to lack of time (as with most of my 
"free time" projects for the past year or two - job, family etc, etc).

Never-the-less, I think TH is important because it explores, in the 
context of the SML family of languages and particularly non-strict 
Haskell, the equivalent of one of the more powerful features available 
in Lisp - macros.

Despite all the work you and your collaborators have done I believe that 
it remains to be seen in a large, mature project whether the methodology 
of TH is of such practical benefit to Haskell as macros have been to 
Lisp and even templates to C++.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eelco Visser | 25 Aug 2004 18:03
Picon

Call for participation: GPCE'04 -- Generative Programming and Component Engineering


                         CALL FOR PARTICIPATION

----------------------------------------------------------------------
                   Third International Conference on
       Generative Programming and Component Engineering (GPCE'04)

                     Vancouver, October 24-28, 2004
                co-located with OOPSLA 2004 and ISMM 2004

                          http://gpce04.gpce.org
----------------------------------------------------------------------
                           Online Registration
                http://www.regmaster.com/oopsla2004.html
         early registration with reduced rates closes September 16
----------------------------------------------------------------------

Generative and component approaches have the potential to
revolutionize software development in a similar way as automation and
components revolutionized manufacturing. Generative Programming
(developing programs that synthesize other programs), Component
Engineering (raising the level of modularization and analysis in
application design), and Domain-Specific Languages (elevating program
specifications to compact domain-specific notations that are easier to
write and maintain) are key technologies for automating program
development.

GPCE arose as a joint conference, merging the prior conference on
Generative and Component-Based Software Engineering (GCSE) and the
Workshop on Semantics, Applications, and Implementation of Program
(Continue reading)

Permalink | Reply | 0 comments |

Gmane