Hello! On Mon 25 Jul 2011 11:24, l...@gnu.org (Ludovic Courtès) writes:
> BT Templeton <b...@hcoop.net> skribis: > >> Andy Wingo <wi...@pobox.com> writes: > > [...] > >>> Here I disagree. From the perspective of semantics and security, it's >>> important to be able to make assertions as to the type of value returned >>> by a procedure -- that (current-input-port) returns a port. The same >>> goes for (current-language) and all the other dynamic parameters. >>> Parameters allow us to make guarantees like that. >> >> Why is it uniquely useful to be able to make these guarantees for >> dynamically-bound values? Static/soft typing would be more generally >> useful than parameters. > > I agree it’s not specific to dynamically-bound values. > > Andy mentioned that exporting, say, the fluid that underlies > ‘current-output-port’ would be a problem because you could ‘fluid-set!’ > it to anything, which would lead to an obscure wrong-type-arg error > sometime. > > OTOH it could be argued that this is no different with mutable global > variables. FWIW I think it's fine to export the fluid corresponding to current-output-port -- and indeed the `parameter-fluid' accessor would allow you to get at these values. But, if you would like to provide a minimal environment for untrusted code, you wouldn't provide parameter-fluid (or struct-ref) to that code. In Guile we have a tension between providing both hackability and reliability. We have many ways of resolving this tension -- modules, convention, and tools among them. In this case I would use all three -- expose the fluids you need to, but only if you need to; by convention, avoid direct fluid access to other modules' fluids; and such access should cause compile-time warnings (to give feedback to the user about our conventions). We should do the same for global variables, btw. Set! to a variable exported by another module should produce a warning. As you mention BT, typing (and contracts) can help too. We don't have them currently, but that's no reason to eschew the tools that we do have. >> Also, I'd prefer it if parameters used a type predicate or a type >> specifier object instead of a conversion procedure. ISTM that the >> current interface conflates type checking and coercion. > > Well, Andy’s proposal is similar to SRFI-39 and I find it convenient > this way. In addition, this step does not preclude type specifier objects, were Guile to get them at some point. They can be defined as wrappers to `make-parameter' et al. Racket is really leading the way here, I think; do read Findler's contracts work if you have an interest in such things. Andy -- http://wingolog.org/
