On 19 July 2011 17:22, Adam Chlipala
http://www.impredicative.com/ur/demo/crud1.html The example involves a library component encapsulating functionality like that of Ruby on Rails's scaffolding: automatic generation of a standard web-based "admin interface" to an SQL database table. The Ur/Web version uses static typing to guarantee that any applications generated by this component are free of injection attacks and other generic problems. The guarantees apply both to app communication with server-side pieces (e.g., static type-checking of SQL) and client-side pieces (e.g., static type-checking of HTML). This is not done by type-checking individual invocations of the admin-interface component. Rather, the component is checked at a static type which guarantees correct operation for _any_specialization_parameters_.
So, the challenge is, can this functionality be implemented in Haskell (GHC extensions fair game, any web framework allowed)?
Is TemplateHaskell fair game? Because if so these problems are not hard. Yesod employs static typing for templates. HaskellDB achieves injectionless static type checking even without TemplateHaskell, and templatepg has type safe SQL queries based on parsing the SQL itself and inspecting the types involved by asking the PostgreSQL server directly at compile time. This doesn't protect you from runtime changes to the DB schema of course. I think there's a lot of interesting work to be done based on inspecting the data base schema by querying the database server and analyzing queries at compile time. Ferry, anyone? Statically avoiding SQL and HTML injection/type problems are trivial problems that have been solved since forever ago, I don't think those are Ur's best secret weapon (dependent types goes without saying). Of Ur I particularly like that you can write Ur that will be compiled to JS. That is something that is hard to do in Haskell right now (ghcjs is a great base, but it's alpha). I don't anyone will spend time to answer the crud challenge.
If so, how pretty is it? :)
Anything's gonna be prettier than what you've presented there. ;-)