> We have enabled side effects already. Without caring about evaluation > order. I mean "trace" builtin. It has 2 main properties, though: it > never changes what derivations are constructed and it only gives > end-user a bit more information that can be filtered out if not helpful. > > tryCatch lacks the first property, and because of that I consider it > harmful. tryRethrow is just like trace, and I am not sure that IO purity > is worth preserving (if it doesn't affect actual build purity).
As you say, trace is a somewhat special case. Nix is a special-purpose language, and the results we're interested in are the derivations, not the screen output. So having some slight impurity that affects only screen output and nothing else is acceptable IMHO. Regarding tryCatch: as far as I understood it, it doesn't introduce any impurity, so I don't find it particularly problematic to add. But I doubt its usefulness given the lazy nature of the language and the escaping issues. Plus, I think it sends the wrong message, because it encourages the use of exceptions (throw), which are impure already, and I don't like that very much. I think we should strive for ways to be able to program with as few as possible uses of throw. On the other hand, I'm willing to admit that while we're using throw anyway, it might be better to at least provide helpful error messages. Cheers, Andres _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
