On Tue, Apr 24, 2012 at 1:08 PM, Erik Hesselink <hessel...@gmail.com> wrote: > On Tue, Apr 24, 2012 at 10:55, Michael Snoyman <mich...@snoyman.com> wrote: >> On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink <hessel...@gmail.com> wrote: >>> On Tue, Apr 24, 2012 at 08:32, Michael Snoyman <mich...@snoyman.com> wrote: >>>> Here's a theoretically simple solution to the problem. How about >>>> adding a new method to the IsString typeclass: >>>> >>>> isValidString :: String -> Bool >>> >>> If you're going with this approach, why not evaluate the conversion >>> from String immediately? For either case you have to know the >>> monomorphic type, and converting at compile time is more efficient as >>> well. But we're getting pretty close to Template Haskell here. >> >> I could be mistaken, but I think that would be much harder to >> implement at the GHC level. GHC would then be responsible for taking a >> compile-time value and having it available at runtime (i.e., lifting >> in TH parlance). Of course, I'm no expert on GHC at all, so if someone >> who actually knows what they're talking about says that this concern >> is baseless, I agree that your approach is better. > > But GHC already has all the infrastructure for this, right? You can do > exactly this with TH. > > Erik
Yes, absolutely. The issue is that TH can be too heavy for both the library author and user: * For the author, you now have to deal with generating some `Q Exp` instead of just producing your data with normal Haskell code. * For the user, you need to replace "foo" with [qqname|foo|]. There's also quite a bit of TH hatred out there, but I'm definitely not in that camp. Nonetheless, I *do* think it would be nice to avoid TH in this case if possible. Michael _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users