[web-devel] Odd "Ambiguous type variable `a0' in the constraint:" error (with Yesod)

[Michael Snoyman]

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 <deteego at gmail.com> 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 <michael at snoyman.com>
> 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 <deteego at gmail.com>
>> 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 <michael at snoyman.com>
>> > 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|<p>I was added with addHtml|]
>> >>    addHamlet [$hamlet|<p>I was added with addHamlet|]
>> >>    addWidget [$whamlet|<p>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 <deteego at gmail.com>
>> >> 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|<p>I was added with addHtml|]
>> >> >     addHamlet [$hamlet|<p>I was added with addHamlet|]
>> >> >     addWidget [$hamlet|<p>I was added with addWidget|]
>> >> > and then to
>> >> > getRootR = defaultLayout $ do
>> >> >     setTitle "Polymorphic Hamlet"
>> >> >     addHtml [$hamlet|<p>I was added with addHtml|]
>> >> >     addHamlet [$hamlet|<p>I was added with addHamlet|]
>> >> >     addWidget [$hamlet|<p>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 at haskell.org
>> >> > http://www.haskell.org/mailman/listinfo/web-devel
>> >> >
>> >> >
>> >
>> >
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>