There's really not much I can say about Wednesday. The programming competition is consuming an increasing portion of my work time, but obviously I can't tell you what I'm doing. I think Thursday or Friday there may be some news to announce, but I really don't even know whether that'll come to pass or not. So I guess the only thing I'll say is that I spent about 30 minutes and added a feature to the speed-daters web site after realizing that the deadline by which it needed to be in live use was, um, tomorrow. It was no big deal, but still it was annoying.
I'm growing less and less enamored of Scheme's untypedness. Even contracts can't help you in some situations, because values don't have principal types: I was in a situation where I wanted to extract an element from a list using Scheme's assoc function. assoc, if it had a type, would have type α * (listof (cons α β)) -> (union (cons α β) #f). It takes a value and a list of pairs and returns the pair in that list whose first element is the given value, or #f if there is none. You'd imagine that you could write a contract that would enforce the same behavior, but you can't: if someone gives you a string and a list of pairs whose first elements are all symbols, how do you know the set the programmer was thinking of wasn't the union of the set of strings and the set of symbols? Or that particular string and those particular symbols? Or maybe the set of all those particular symbols except one, in which case the contract should alert you that it's been violated? The solution is just not to use this kind of polymorphism in contracts, and if you know more about a particular call-site then make a specialized function with the contract there. But that's obviously a pain.
I think I may be coming around to the opinion that my ideal language would have a static type system with an explicit mechanism for allowing you to turn it off, or allow you to run code even if there's a type error somewhere. Basically the way you used to be able to do with MrSpidey in DrScheme; write some code, typecheck, fix every error it finds or come up with a justification for why it's not actually an error, repeat.
I'm growing less and less enamored of Scheme's untypedness. Even contracts can't help you in some situations, because values don't have principal types: I was in a situation where I wanted to extract an element from a list using Scheme's assoc function. assoc, if it had a type, would have type α * (listof (cons α β)) -> (union (cons α β) #f). It takes a value and a list of pairs and returns the pair in that list whose first element is the given value, or #f if there is none. You'd imagine that you could write a contract that would enforce the same behavior, but you can't: if someone gives you a string and a list of pairs whose first elements are all symbols, how do you know the set the programmer was thinking of wasn't the union of the set of strings and the set of symbols? Or that particular string and those particular symbols? Or maybe the set of all those particular symbols except one, in which case the contract should alert you that it's been violated? The solution is just not to use this kind of polymorphism in contracts, and if you know more about a particular call-site then make a specialized function with the contract there. But that's obviously a pain.
I think I may be coming around to the opinion that my ideal language would have a static type system with an explicit mechanism for allowing you to turn it off, or allow you to run code even if there's a type error somewhere. Basically the way you used to be able to do with MrSpidey in DrScheme; write some code, typecheck, fix every error it finds or come up with a justification for why it's not actually an error, repeat.
posted by Jacob Matthews at
22:26
0 Comments:
Post a Comment
<< Home