Ludovic Courtès <[email protected]> writes: > The goal from day 1 has always been to allow for declarative package > specifications that “look” obvious and have as little boilerplate as > possible. All the decisions were guided by this, including the removal > of input labels:
this is a worthwhile goal, but i think while the new variables do make things look nice, it's only at the surface level, and it that surface sheen creates ugly warts at a more fundamental level. the main problem is that i can't know when they're going to be applied. i don't know what a thunk is. i shouldn't have to know what a thunk is. you've made it /look/ like i can just use a variable “inputs”, but when it comes to recreating it myself for other fields, i find i cannot. i have been bamboozled! turns out the word “inputs” is special, and i had no way of knowing that. and if i now need to know what “thunked” means in order to use this package management system, then it's no longer obvious, but esoteric: it requires obscure domain knowledge. on top of that, there's no documentation about which fields are thunked (that i can tell, anyway), and by now requiring that i know the difference between these field types, the fact that they wrap up to the same syntax (ie, lacking the enclosing parens to make something an application) becomes a misfeature. i also dislike this change, even if i admire its accomplishment. -bjc
