Remove capture-lookup in favour of global identifier property lookup procedure #183

dpk commented 2023年11月02日 14:55:18 +01:00

As suggested in comment to issue 138

As suggested in [comment to issue 138](https://codeberg.org/scheme/r7rs/issues/138#issuecomment-1316814)

dpk commented 2023年11月20日 21:54:51 +01:00

@mnw: Do you have any objections to merging this?

@mnw: Do you have any objections to merging this?

mnw commented 2023年11月23日 17:00:41 +01:00

If you want to go this route, make identifier-property a pure procedure and define a dynamic parameter expand-environment so that looking up a property would be done by (identifier-property (expand-environment) KEY VALUE). This at least clearly separates the impure from the pure part and, moreover, allows future additions in the form of further static procedures acting on the "expand environment."

Keeping future extensions in mind, in this model, identifier-property should probably be renamed ref-property (think of set-property!). The prefix "identifier-" is too much in any case; the corresponding definition is just called define-property.

If you want to go this route, make `identifier-property` a pure procedure and define a dynamic parameter `expand-environment` so that looking up a property would be done by `(identifier-property (expand-environment) KEY VALUE)`. This at least clearly separates the impure from the pure part and, moreover, allows future additions in the form of further static procedures acting on the "expand environment." Keeping future extensions in mind, in this model, `identifier-property` should probably be renamed `ref-property` (think of `set-property!`). The prefix "identifier-" is too much in any case; the corresponding definition is just called `define-property`.

dpk commented 2023年11月24日 11:19:29 +01:00

If you want to go this route, make identifier-property a pure procedure and define a dynamic parameter expand-environment so that looking up a property would be done by (identifier-property (expand-environment) KEY VALUE). This at least clearly separates the impure from the pure part and, moreover, allows future additions in the form of further static procedures acting on the "expand environment."

What would be the concrete benefit of this, other than the theoretical benefit of separating dynamic state from pure operations? (If we have other future procedures which depend on the expand environment, the same question applies to them — they could equally just use the dynamic environment directly.) When would someone, in practice, want to use identifier-property (or whatever we call it) with an argument other than a direct call to (expand-environment)? You could, in theory, save the expand environment in a variable; I don’t see any benefit in doing this other than perhaps a mild (non-asymptotic) performance improvement.

Moreover, this proposal implies too much to me about the implementation strategy for identifier properties. It is, under both the SRFI 213 and current identifier-property proposal models, possible to store identifier properties on the wrap of a syntax object. (This is perhaps not advisable, for reasons I think we’ve previously discussed, but at least it’s possible in theory.) In this case, in the SRFI 213 system, capture-lookup always passes the same static lookup procedure in; in this PR as currently stands, identifier-property is itself such a static procedure. An expander-environment parameter becomes a useless dummy in such an implementation — a sign, to me, that this is an implementation detail which we should hide.

(Moreover moreover, what if someone parameterizes expander-environment to some nonsense? This can be guarded against by making expander-environment a trivial wrapper procedure around an actual internal %expander-environment parameter object, among other possibilities, but this is just silly.)

> If you want to go this route, make `identifier-property` a pure procedure and define a dynamic parameter `expand-environment` so that looking up a property would be done by `(identifier-property (expand-environment) KEY VALUE)`. This at least clearly separates the impure from the pure part and, moreover, allows future additions in the form of further static procedures acting on the "expand environment." What would be the concrete benefit of this, other than the theoretical benefit of separating dynamic state from pure operations? (If we have other future procedures which depend on the expand environment, the same question applies to them — they could equally just use the dynamic environment directly.) When would someone, in practice, want to use `identifier-property` (or whatever we call it) with an argument other than a direct call to `(expand-environment)`? You could, in theory, save the expand environment in a variable; I don’t see any benefit in doing this other than perhaps a mild (non-asymptotic) performance improvement. Moreover, this proposal implies too much to me about the implementation strategy for identifier properties. It is, under both the SRFI 213 and current `identifier-property` proposal models, possible to store identifier properties on the wrap of a syntax object. (This is perhaps not advisable, for reasons I think we’ve previously discussed, but at least it’s possible in theory.) In this case, in the SRFI 213 system, `capture-lookup` always passes the same static lookup procedure in; in this PR as currently stands, `identifier-property` is itself such a static procedure. An `expander-environment` parameter becomes a useless dummy in such an implementation — a sign, to me, that this is an implementation detail which we should hide. (Moreover moreover, what if someone parameterizes `expander-environment` to some nonsense? This can be guarded against by making `expander-environment` a trivial wrapper procedure around an actual internal `%expander-environment` parameter object, among other possibilities, but this is just silly.)

mnw commented 2023年11月24日 12:18:52 +01:00

If you want to go this route, make identifier-property a pure procedure and define a dynamic parameter expand-environment so that looking up a property would be done by (identifier-property (expand-environment) KEY VALUE). This at least clearly separates the impure from the pure part and, moreover, allows future additions in the form of further static procedures acting on the "expand environment."

What would be the concrete benefit of this, other than the theoretical benefit of separating dynamic state from pure operations?

This, in itself, is an important benefit.

Moreover, this proposal implies too much to me about the implementation strategy for identifier properties. It is, under both the SRFI 213 and current identifier-property proposal models, possible to store identifier properties on the wrap of a syntax object. (This is perhaps not advisable, for reasons I think we’ve previously discussed, but at least it’s possible in theory.) In this case, in the SRFI 213 system, capture-lookup always passes the same static lookup procedure in; in this PR as currently stands, identifier-property is itself such a static procedure.

As you just have shown, it does not imply anything about the implementation strategy. By the way, even a model where the property is directly stored on the wrap can benefit from an extra parameter to determine whether the information in the wrap is stale (or inaccessible in the given environment).

An expander-environment parameter becomes a useless dummy in such an implementation — a sign, to me, that this is an implementation detail which we should hide.

Quite the contrary. expander-environment is not an implementation detail but the reification of a semantic entity. The fact that some implementations can do with a trivially expander-environment is an implementation-detail, on the other hand.

(Moreover moreover, what if someone parameterizes expander-environment to some nonsense? This can be guarded against by making expander-environment a trivial wrapper procedure around an actual internal %expander-environment parameter object, among other possibilities, but this is just silly.)

Sorry for the confusion here. By dynamic parameter, I didn't mean a parameter in the sense of SRFI 39, just a thunk whose value depends on the dynamical state of the expander.

> > If you want to go this route, make `identifier-property` a pure procedure and define a dynamic parameter `expand-environment` so that looking up a property would be done by `(identifier-property (expand-environment) KEY VALUE)`. This at least clearly separates the impure from the pure part and, moreover, allows future additions in the form of further static procedures acting on the "expand environment." > > What would be the concrete benefit of this, other than the theoretical benefit of separating dynamic state from pure operations? This, in itself, is an important benefit. > Moreover, this proposal implies too much to me about the implementation strategy for identifier properties. It is, under both the SRFI 213 and current `identifier-property` proposal models, possible to store identifier properties on the wrap of a syntax object. (This is perhaps not advisable, for reasons I think we’ve previously discussed, but at least it’s possible in theory.) In this case, in the SRFI 213 system, `capture-lookup` always passes the same static lookup procedure in; in this PR as currently stands, `identifier-property` is itself such a static procedure. As you just have shown, it does not imply anything about the implementation strategy. By the way, even a model where the property is directly stored on the wrap can benefit from an extra parameter to determine whether the information in the wrap is stale (or inaccessible in the given environment). > An `expander-environment` parameter becomes a useless dummy in such an implementation — a sign, to me, that this is an implementation detail which we should hide. Quite the contrary. `expander-environment` is not an implementation detail but the reification of a semantic entity. The fact that some implementations can do with a trivially `expander-environment` is an implementation-detail, on the other hand. > (Moreover moreover, what if someone parameterizes `expander-environment` to some nonsense? This can be guarded against by making `expander-environment` a trivial wrapper procedure around an actual internal `%expander-environment` parameter object, among other possibilities, but this is just silly.) Sorry for the confusion here. By dynamic parameter, I didn't mean a parameter in the sense of SRFI 39, just a thunk whose value depends on the dynamical state of the expander.

dpk commented 2024年07月25日 23:51:43 +02:00

I’m not convinced by the argument for (expander-environment). If a future RnRS thinks it worthwhile and has a use case for reifying the expander environment, I suggest they add it as an optional argument to identifier-property, in the same way the I/O procedures default to the dynamic values of current-{input,output}-port if no explicit port argument is given.

Racket’s expand-time values and Guile’s expand-time identifier introspection both use the dynamic environment of the expander.

I’m not convinced by the argument for `(expander-environment)`. If a future RnRS thinks it worthwhile and has a use case for reifying the expander environment, I suggest they add it as an optional argument to `identifier-property`, in the same way the I/O procedures default to the dynamic values of `current-{input,output}-port` if no explicit port argument is given. Racket’s expand-time values and Guile’s expand-time identifier introspection both use the dynamic environment of the expander.