Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

Mathew de Detrich

30 Apr 2011 30 Apr '11

11:50 p.m.

Ok so I have a problem that was described here ( http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a "Ambiguous type variable `a0' in the constraint error" when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally thought that it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The problem is, that when I use the above example code in my WebServer, I get this Ambigious type error when compiling (even though I have set up the route the exact same way). Unfortunatley I can't provide the code for my webserver, since its commercially owned (and it would be pointless because its just renamed variables, but otherwise its the same), so does anyone have any ideas what could possibly cause such an error (such as a missing/extra import or some package or something), or possibly some missing instances? Also sorry for creating another mailing list, but its a different issue then what I thought it was originally (and I also wanted to put it on haskell-cafe since its a more general issue)

Attachments:

attachment.html (text/html — 2.6 KB)

Show replies by date

Michael Snoyman

1 May 1 May

9 a.m.

New subject: Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR. As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like: getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$html|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$whamlet|I was added with addWidget|] And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then. Michael On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich wrote:

...

Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a "Ambiguous type variable `a0' in the constraint error" when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally thought that it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The problem is, that when I use the above example code in my WebServer, I get this Ambigious type error when compiling (even though I have set up the route the exact same way). Unfortunatley I can't provide the code for my webserver, since its commercially owned (and it would be pointless because its just renamed variables, but otherwise its the same), so does anyone have any ideas what could possibly cause such an error (such as a missing/extra import or some package or something), or possibly some missing instances? Also sorry for creating another mailing list, but its a different issue then what I thought it was originally (and I also wanted to put it on haskell-cafe since its a more general issue) _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Mathew de Detrich

2 May 2 May

9:14 a.m.

New subject: Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/post****R) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *****) however, the mkYesod requires the handlers (of the form get/post****R) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ****** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman wrote:

...

Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR.

As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like:

getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$html|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$whamlet|I was added with addWidget|]

And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then.

Michael

...
Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a "Ambiguous type variable `a0' in the constraint error" when compiling. Originally I thought it was due to the way I was coding that

...
of the code (or to be more accurate the code specifically for creating

...
so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally thought

...
it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The

...
is, that when I use the above example code in my WebServer, I get this Ambigious type error when compiling (even though I have set up the route

...
exact same way). Unfortunatley I can't provide the code for my webserver, since its commercially owned (and it would be pointless because its just renamed variables, but otherwise its the same), so does anyone have any ideas what could possibly cause such an error (such as a missing/extra import or some package or something), or possibly some missing instances? Also sorry for creating another mailing list, but its a different issue

On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich wrote: part the that problem the then

...
what I thought it was originally (and I also wanted to put it on haskell-cafe since its a more general issue) _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Michael Snoyman

9:18 a.m.

New subject: Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch. HTH, Michael On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich wrote:

...

Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/post****R) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *****) however, the mkYesod requires the handlers (of the form get/post****R) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ****** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman wrote:

...
Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR.

As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like:

getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$html|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$whamlet|I was added with addWidget|]

And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then.

Michael

On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich wrote:

...
Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a "Ambiguous type variable `a0' in the constraint error" when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally thought that it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The problem is, that when I use the above example code in my WebServer, I get this Ambigious type error when compiling (even though I have set up the route the exact same way). Unfortunatley I can't provide the code for my webserver, since its commercially owned (and it would be pointless because its just renamed variables, but otherwise its the same), so does anyone have any ideas what could possibly cause such an error (such as a missing/extra import or some package or something), or possibly some missing instances? Also sorry for creating another mailing list, but its a different issue then what I thought it was originally (and I also wanted to put it on haskell-cafe since its a more general issue) _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Mathew de Detrich

9:28 a.m.

New subject: Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

...... You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman wrote:

...

Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch.

HTH, Michael

...
Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/post****R) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *****) however, the mkYesod requires the handlers (of the form get/post****R) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ****** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman wrote:

...
Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR.

As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like:

getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$html|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$whamlet|I was added with addWidget|]

And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then.

Michael

On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich wrote:

...
Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in

regards

...
...
to returning a "Ambiguous type variable `a0' in the constraint error" when compiling. Originally I thought it was due to the way I was coding

...
...
...
part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets ). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally

On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich wrote: that thought

...
...
...
that it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The problem is, that when I use the above example code in my WebServer, I get this Ambigious type error when compiling (even though I have set up the route the exact same way). Unfortunatley I can't provide the code for my webserver, since its commercially owned (and it would be pointless because its just renamed variables, but otherwise its the same), so does anyone have any ideas what could possibly cause such an error (such as a missing/extra import or some package or something), or possibly some missing instances? Also sorry for creating another mailing list, but its a different issue then what I thought it was originally (and I also wanted to put it on haskell-cafe since its a more general issue) _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Michael Snoyman

9:30 a.m.

New subject: Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case. Michael On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich wrote:

...

...... You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman wrote:

...
Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch.

HTH, Michael

On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich wrote:

...
Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/post****R) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *****) however, the mkYesod requires the handlers (of the form get/post****R) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ****** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman wrote:

...
Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR.

As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like:

getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$html|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$whamlet|I was added with addWidget|]

And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then.

Michael

On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich wrote:

...
Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a "Ambiguous type variable `a0' in the constraint error" when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally thought that it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The problem is, that when I use the above example code in my WebServer, I get this Ambigious type error when compiling (even though I have set up the route the exact same way). Unfortunatley I can't provide the code for my webserver, since its commercially owned (and it would be pointless because its just renamed variables, but otherwise its the same), so does anyone have any ideas what could possibly cause such an error (such as a missing/extra import or some package or something), or possibly some missing instances? Also sorry for creating another mailing list, but its a different issue then what I thought it was originally (and I also wanted to put it on haskell-cafe since its a more general issue) _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Mathew de Detrich

9:40 a.m.

New subject: Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

Im not sure what you mean exactly by "run the scaffolder", (just to be clear, I am not exactly sure what technically scaffolding is apart from it being referenced once or twice in your documentation) I assume you are talking about setting up the handlers for a specific route, and then creating that single route on its own (instead of all at once with mkYesod)? On Mon, May 2, 2011 at 11:30 PM, Michael Snoyman wrote:

...

My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case.

Michael

...
...... You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in

...
Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman wrote:

...
Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch.

HTH, Michael

On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich wrote:

...
Ok I have found the source issue, in my case it was an issue that

ended

...
...
up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/post****R) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *****) however,

...
...
...
mkYesod requires the handlers (of the form get/post****R) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ****** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman
...
...
wrote:

...
Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR.

As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and

will

...
be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like:

getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$html|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$whamlet|I was added with addWidget|]

And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then.

Michael

On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich
...
...
...
wrote:

...
Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a "Ambiguous type variable `a0' in the constraint error" when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied

On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich wrote: the the the

...
...
...
...
...
example code given here exactly (http://www.yesodweb.com/book/example-widgets). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$hamlet|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$hamlet|I was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally thought that it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The problem is, that when I use the above example code in my WebServer, I get this Ambigious type error when compiling (even though I have set up the route the exact same way). Unfortunatley I can't provide the code for my webserver, since its commercially owned (and it would be pointless because its just renamed variables, but otherwise its the same), so does anyone have any ideas what could possibly cause such an error (such as a missing/extra import or some package or something), or possibly some missing instances? Also sorry for creating another mailing list, but its a different issue then what I thought it was originally (and I also wanted to put it on haskell-cafe since its a more general issue) _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Michael Snoyman

9:53 a.m.

New subject: Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

Type: yesod init It will ask you some questions and then generate a bootstrap site. Michael On Mon, May 2, 2011 at 4:40 PM, Mathew de Detrich wrote:

...

Im not sure what you mean exactly by "run the scaffolder", (just to be clear, I am not exactly sure what technically scaffolding is apart from it being referenced once or twice in your documentation) I assume you are talking about setting up the handlers for a specific route, and then creating that single route on its own (instead of all at once with mkYesod)?

On Mon, May 2, 2011 at 11:30 PM, Michael Snoyman wrote:

...
My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case.

Michael

On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich wrote:

...
...... You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman wrote:

...
Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch.

HTH, Michael

On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich wrote:

...
Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/post****R) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *****) however, the mkYesod requires the handlers (of the form get/post****R) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ****** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman wrote:

...
Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR.

As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like:

getRootR = defaultLayout $ do setTitle "Polymorphic Hamlet" addHtml [$html|I was added with addHtml|] addHamlet [$hamlet|I was added with addHamlet|] addWidget [$whamlet|I was added with addWidget|]

And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then.

Michael

On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich wrote: > Ok so I have a problem that was described here > (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in > regards > to > returning a "Ambiguous type variable `a0' in the constraint > error" > when > compiling. Originally I thought it was due to the way I was coding > that > part > of the code (or to be more accurate the code specifically for > creating > the > so called widgets with addHTML/addWidget,addHamlet). So I copied > the > example > code given here exactly > (http://www.yesodweb.com/book/example-widgets). > Compiling this worked fine, so at the next point I changed the > definition > of getRootR to > getRootR = defaultLayout $ wrapper $ do > setTitle "Polymorphic Hamlet" > addHtml [$hamlet|I was added with addHtml|] > addHamlet [$hamlet|I was added with addHamlet|] > addWidget [$hamlet|I was added with addWidget|] > and then to > getRootR = defaultLayout $ do > setTitle "Polymorphic Hamlet" > addHtml [$hamlet|I was added with addHtml|] > addHamlet [$hamlet|I was added with addHamlet|] > addWidget [$hamlet|I was added with addWidget|] > Both times compiled fine, so the issue wasn't what I originally > thought > that > it was (as described > in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). > The > problem > is, that when I use the above example code in my WebServer, I get > this > Ambigious type error when compiling (even though I have set up the > route > the > exact same way). Unfortunatley I can't provide the code for my > webserver, > since its commercially owned (and it would be pointless because > its > just > renamed variables, but otherwise its the same), so does anyone > have > any > ideas what could possibly cause such an error (such as a > missing/extra > import or some package or something), or possibly some missing > instances? > Also sorry for creating another mailing list, but its a different > issue > then > what I thought it was originally (and I also wanted to put it on > haskell-cafe since its a more general issue) > _______________________________________________ > web-devel mailing list > web-devel@haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > >

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Mathew de Detrich

9:58 a.m.

New subject: Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

Ok thanks, that helped On Mon, May 2, 2011 at 11:53 PM, Michael Snoyman wrote:

...

Type:

yesod init

It will ask you some questions and then generate a bootstrap site.

Michael

...
Im not sure what you mean exactly by "run the scaffolder", (just to be clear, I am not exactly sure what technically scaffolding is apart from it being referenced once or twice in your documentation) I assume you are talking about setting up the handlers for a specific route, and then creating that single route on its own (instead of all at once with mkYesod)?

On Mon, May 2, 2011 at 11:30 PM, Michael Snoyman wrote:

...
My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case.

Michael

On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich wrote:

...
...... You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it

in

...
...
the Yesod book is not completed yet ( http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman
...
...
wrote:

...
Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch.

HTH, Michael

On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich
...
...
...
wrote:

...
Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and

...
...
...
...
...
compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/post****R) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *****) however, the mkYesod requires the handlers (of the form get/post****R) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ****** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman wrote: > > Without seeing the actual code that's causing the breakage,

...
...
...
...
...
> not much I can tell you. (If you'd like me to take a look off-list, > feel free to send me a private email.) My best recommendation is to > try putting a type signature on getRootR. > > As a general issue: polymorphic Hamlet is a very convenient feature, > but I think it leads to too much complexity in the type system. I've > added some code for non-polymorphic Hamlet to the Github repo and > will > be releasing it as its own module (Text.Hamlet.NonPoly) in the next > release. Assuming all goes well, it will be replacing the current > Hamlet. That essentially means that you'll need to replace your code > with something like: > > getRootR = defaultLayout $ do > setTitle "Polymorphic Hamlet" > addHtml [$html|I was added with addHtml|] > addHamlet [$hamlet|I was added with addHamlet|] > addWidget [$whamlet|I was added with addWidget|] > > And just to make everyone curious: I've also added i18n support to > non-poly Hamlet. I've got a long train ride on Tuesday, and I'm > planning on documenting it then. > > Michael > > On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich > > wrote: > > Ok so I have a problem that was described here > > (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in > > regards > > to > > returning a "Ambiguous type variable `a0' in the constraint > > error" > > when > > compiling. Originally I thought it was due to the way I was coding > > that > > part > > of the code (or to be more accurate the code specifically for > > creating > > the > > so called widgets with addHTML/addWidget,addHamlet). So I copied > > the > > example > > code given here exactly > > (http://www.yesodweb.com/book/example-widgets). > > Compiling this worked fine, so at the next point I changed the > > definition > > of getRootR to > > getRootR = defaultLayout $ wrapper $ do > > setTitle "Polymorphic Hamlet" > > addHtml [$hamlet|I was added with addHtml|] > > addHamlet [$hamlet|I was added with addHamlet|] > > addWidget [$hamlet|I was added with addWidget|] > > and then to > > getRootR = defaultLayout $ do > > setTitle "Polymorphic Hamlet" > > addHtml [$hamlet|I was added with addHtml|] > > addHamlet [$hamlet|I was added with addHamlet|] > > addWidget [$hamlet|I was added with addWidget|] > > Both times compiled fine, so the issue wasn't what I originally > > thought > > that > > it was (as described > > in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431 ). > > The > > problem > > is, that when I use the above example code in my WebServer, I get > > this > > Ambigious type error when compiling (even though I have set up

On Mon, May 2, 2011 at 4:40 PM, Mathew de Detrich wrote: that there's the

...
...
...
...
...
> > route > > the > > exact same way). Unfortunatley I can't provide the code for my > > webserver, > > since its commercially owned (and it would be pointless because > > its > > just > > renamed variables, but otherwise its the same), so does anyone > > have > > any > > ideas what could possibly cause such an error (such as a > > missing/extra > > import or some package or something), or possibly some missing > > instances? > > Also sorry for creating another mailing list, but its a different > > issue > > then > > what I thought it was originally (and I also wanted to put it on > > haskell-cafe since its a more general issue) > > _______________________________________________ > > web-devel mailing list > > web-devel@haskell.org > > http://www.haskell.org/mailman/listinfo/web-devel > > > >

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

5132

Age (days ago)

5133

Last active (days ago)

List overview

Download

8 comments

2 participants

participants (2)

Mathew de Detrich
Michael Snoyman

Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

tags

participants (2)