That looks great - thanks!
Adam Chlipala <[email protected]> writes: > I've pushed a small changeset with a new error message, inspired by your > suggestion. > > By the way, I expect the error message you reported originally was > especially confusing because you must have configured an empty URI for > your application's main page handler. The "()" part of your message > would have said, e.g., "(main)" if some nonempty name were configured > for that handler. My error message tweak is also aimed at explaining > this part of the message better. > > On 06/14/2013 01:27 PM, Daniel Patterson wrote: >> I still think the message is misleading. Because seeing that message >> (and not having source information to track down what was causing it), >> I removed _all_ links from the application - ie, there were no calls >> to "url", and no "<a>" tags. So it isn't that I'm using a link when I >> should be using a form - it is that a page that is accessible via a >> url is causing effects. >> >> If the error was more along the lines of "A handler accessible via GET >> requests could cause side effects - try accessing it only via forms, >> or removing it from the list of exported handlers", I would have had a >> lot easier time figuring out what was wrong. Of course, being able to >> specify what handler (ie, the handler at 101:0, or even better, >> sourceloc and name) would be even better. >> >> On Fri, Jun 14, 2013 at 12:53 PM, Adam Chlipala<[email protected]> wrote: >> >>> I agree that it would be nice to get the proper source location information >>> propagated into that error message. However, I don't think the message >>> itself is so misleading. Presumably your 'onload' handler is on a page that >>> can be reached via a GET request to a link. The HTTP standard or some >>> related advice specifies that GET requests should not have side effects, and >>> Ur/Web is detecting that your [Js.init] function might actually cause a side >>> effect upon loading of the link. From a user's perspective, there is little >>> practical difference between "fetching URL causes a side effect" and >>> "fetching URL returns a page whose JavaScript immediately causes a side >>> effect." >>> >>> I hope the Ur/Web manual makes clear that 'benignEffectful' is for functions >>> with only page-local side effects, while 'effectful' is for functions that >>> may cause persistent side effects. Does your [Js.init] really belong in the >>> second category? If so, then the compiler seems to me to be making a >>> reasonable inference that you aren't following the rules about GET requests >>> not causing persistent side effects. >>> >>> >>> On 06/13/2013 08:14 PM, Daniel Patterson wrote: >>> >>>> I have an ffi function declared like: >>>> >>>> ffi js >>>> jsFunc Js.init=init >>>> effectful Js.init >>>> >>>> I have it in my body onload handler as: >>>> >>>> Js.init ... >>>> >>>> And the error that it produces is: >>>> >>>> :0:0: (to 0:0) A link () could cause side effects; try implementing it >>>> with a form instead >>>> make: *** [app] Error 1 >>>> >>>> >>>> Which is confusing because: >>>> >>>> a. it has no source location information, so I have no idea where the >>>> error is occuring and >>>> >>>> b. it is not caused by a link. >>>> >>>> The problem goes away if I either don't say that it is effectful, or >>>> say it is benignEffectful, but I'm not sure why this is - because it >>>> seems like onload handlers should be able to cause effects... >>>> > > _______________________________________________ > Ur mailing list > [email protected] > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
pgp9nfRUlyR57.pgp
Description: PGP signature
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
