2011/10/4 Gábor Lehel <illiss...@gmail.com>: > On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale <g...@sefer.org> wrote: >> George Giorgidze wrote: >>> My second proposal is to introduce the >>> OverloadedLists extension that overloads >>> list literals... >> >> I am opposed to this proposal as stated. >> >> But I think that with a modification, >> it can not only be improved, but also solve >> the problems with the current OverloadedStrings >> extension. >> >> OverloadedStrings - and George's unmodified >> proposal - change compile time errors into run >> time errors. Literals with hard-to-find problems >> are accepted by the compiler and become >> _|_ at run time. >> >> An example of the problem: the xml-types >> package has an IsString instance for >> Name. The fromString method parses >> XML namespaces from XML names and >> calls error if the parse fails. Without the >> extension, one would specify the parts using >> constructors; that is wordy and awkward but >> checked at compile time. A quasi-quoter >> could be defined, but that syntax would still >> be far less convenient in practice than >> string literals. >> >> I agree that we need a way of allowing literals >> to have some flexibility in their types. But there >> should be a way for overloading to work >> at compile time, i.e. more like a quasi-quoter, >> when needed. >> >> Of course, "quasi-quoter" overloading can also >> just create an expression that applies a coercion function >> at run time. So in that sense, "quasi-quoter" overloading >> is more general than ad-hoc-polymorphism overloading. >> >> In all of George's examples fromList happens to be total, >> so there isn't an issue having it happen at run time. But if we >> make this generally available, you can be certain that >> it will cause problems later on. Just as with IsString, >> people will not be able to resist the nice syntax, and >> they will define fromList implementations that are partial. >> >> Here is a tentative modification of George's proposal: >> >> class IsList l where >> type Item l >> fromList :: [Item l] -> l >> listExpQ :: [ExpQ] -> ExpQ >> >> -- Minimal complete definition: fromList >> listExpQ = appE (varE (mkName "fromList")) . listE > > listExpQ doesn't actually use the class's type variable here. You'd > have to add a dummy parameter ('l' or preferably 'Proxy l'). > > That said, this seems like what the Lift class[1] was made for. Maybe: > > class Lift l => IsList l where > fromList :: [Item l] -> l > > and then have GHC apply the function at compile time, during the > Template Haskell phase, and then lift and splice the result. That > would resolve both your complaint about partial instances (an > exception at compile time is a compile error) and Roman's about > performance (if it results in a performance hit with some data > structures, it'll only be at compile time). I don't know if it would > work out mechanically (i.e. whether GHC's internals allow this kind of > thing). > > In the spirit of "don't let the perfect be the enemy of the good" > though, I'm solidly in favor of the original proposal as it is. My > only quibble is whether it might not be better called FromList (or > FromListLiteral or ...), given that a Map Is not really a List. Since > IsString is named the same way, the question is whether consistency or > accuracy is more important.
(Of course I mean that if we can get something better, great, but the original proposal is a lot better than nothing - not that I would actually prefer the original to something better than it.) > > [1] > http://hackage.haskell.org/packages/archive/template-haskell/2.4.0.0/doc/html/Language-Haskell-TH-Syntax.html > >> >> If the type of a list literal determines a specific instance >> of IsList at compile time, use the listExpQ from that >> instance to interpret the list literal. Otherwise, use the >> default listExpQ, which is just George's original proposal. >> >> An alternative would be to put listExpQ in a separate type >> class with an IsList constraint. >> >> IsString can similarly be extended in a backward compatible >> way to allow syntax checking at compile time. Here the >> type could be stringExpQ :: String -> ExpQ >> >> Numeric literals with Num and Integral can also be extended, >> though I think the problem is less common for those. >> >> Thanks, >> Yitz >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > > -- > Work is punishment for failing to procrastinate effectively. > -- Work is punishment for failing to procrastinate effectively. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users