Earlier quoted context omitted.
> "Right now I see no difference between the good and bad" You're building a new query string each time you create a Query object, and concatenating the string onto that. With that approach, each time you build a Query object you have a fresh opportunity to mess up. So you're right that there's no difference between your to cases. Let's drop my off-the-cuff example and look at how a real library, postgresql-simple, h…
Sure, and Rails offers a similar syntax: User.select('x').where('name like ?', username) But if your language allows literal string interpolation (as Ruby does), what prevents you from doing this: query conn ("select x from users where name like #{username}") How do type-safe languages prevent this?
query conn ("select x from users where name like " ++ username)
++ is a function that expects two Strings. The "select..." stuff isn't a String, quotation marks not withstanding. When we try to hand a Query to ++, the compiler screams bloody murder.Longer explanation: I suspect the syntax is a bit confusing, since while I keep saying "select ..." is a Query, it looks an awful lot like a String. Here's what's going on. Haskell has a typeclass called IsString. Query is an instance of IsString, as is String.[^2]
Quoted text can represent any instance of IsString. So the compiler sees a function that expects a Query and an IsString of some sort, and through the magic of type inference, it decides that the IsString must be a Query.[^3] And when you try to use a function that concatenates Strings on that Query, it knows that Something's Not Right.
[1]: Haskell doesn't have string interpolation. But if it did, this is how it would work.
[2]: And other instances as well. postgresql-simple actually uses ByteStrings, not Strings, for performance.
[3]: I've fuzzed the evaluation order a bit, for simplicity. In practice the first error reported might be that you've passed 2 arguments to a function that expects 3.