>implementation of parameters as procedures (even global ones) necessarily prohibits them from working with call/cc.
It appears I didn't write clearly: the fact that they are procedures doesn't make them not work with call/cc. As I understand it, the procedures mechanism actually makes it easier to make work, which is why Feely wrote the SRFI that way, as opposed to earlier mechanisms like fluid-let, which did use variables.
The procedures are really just a way to control access to the variables. If you use normal global variables, people can treat them like lexical variables which breaks the semantics of dynamic scope. With the procedures, updates are forced to go through the dynamic-wind mechanism and forced to "pop" on exit from the dynamic extent. It's just a way to leverage the call stack to implement the semantics, but I agree it's much nicer (and cleaner) to do it the "real way" handing the fluid environment to `apply`.
I think the use of procedures is fine, but not ideal. At the very least, I think the parameters should be abstracted to hide the fact that they're procedures. This is trivial to do now that there's a real record facility, and the extra abstraction would leave the door open for implementors to use an alternative implementation strategy. A carefully-designed API could even make it so that implementors could use procedures+records or the "real way" with clients being none the wiser.
One thing I do like is that parameters are lexically distinct from regular variables, so it's always obvious whether some particular variable is lexical or fluid.
>This is trivial to do now that there's a real record facility
Last I heard, there's still no way for a function to masquerade as a variable. Has this changed?
>One thing I do like is that parameters are lexically distinct from regular variables, so it's always obvious whether some particular variable is lexical or fluid.
See one of my other replies for a usecase of dynamically bound functions (intercepting calls to a function within a certain dynamic extent) that makes me wish otherwise.
It appears I didn't write clearly: the fact that they are procedures doesn't make them not work with call/cc. As I understand it, the procedures mechanism actually makes it easier to make work, which is why Feely wrote the SRFI that way, as opposed to earlier mechanisms like fluid-let, which did use variables.