On Wed, 11 Mar 2020 at 19:39, Jörg F. Wittenberger < Joerg.Wittenberger@softeyes.net> wrote:
On Tue, 10 Mar 2020 21:19:01 -0400 Marc Feeley feeley@iro.umontreal.ca wrote:
On Mar 10, 2020, at 6:41 PM, Jörg F. Wittenberger Joerg.Wittenberger@softeyes.net wrote:
;; YMMV, but I find this not exactly intuitive.
On the contrary I find it very intuitive!> I give an example of why this semantics is what you want in the paper “A Better API for First-Class Continuations” section 1.3 (
https://www.researchgate.net/publication/2405339_A_Better_API_for_First-Clas... ).
Note. I'm not saying that it would be wrong by any means.
[...]
In practice I'm much easier confused understanding code with dynamic
scope applies than code where lexical scope rules.
As for me I find the parameter objects highly intuitive.
Detail discussion:
With that said, if you need to solve a primary language problem than parameter objects were designer for, e.g. normal function value arguments, then of course parameters are not needed.
The teleport example I included in my third post in this thread, reflects what I use parameter objects for. Again:
(define (a)
; Teleport from hr (b)) (define (b) (c)) (define (c) ; Teleport to hr #!void)
This is the same usecase as Marc uses them for in the runtime. That is, you have a chain of procedure calls where including a hundred arguments would be too verbose (or calls go through "someone else's code" where you can't even add arguments), and for this reason you use parameter objects, which you assign at the beginning of the call chain (by |parameterize|) and then use at the end of the call chain (by calling the respective parameter object), and the utility is that none of the intermediary procedures need to define those values as arguments (e.g. in the example above, the |b| procedure does not need to define as arguments the values teleported from |a| to |c|).
The |doit!| example you provided does not illustrate this particular utility, but some other utility. On a quick read cannot immediately comprehend what your |magic| procedure does so can't comment on it. I do see call/cc calls inside |magic|'s definition however and I agree that the combination of parameter objects and call/cc would need additional consideration (unclear of details in this moment). call/c is not so frequently used though and its use does mean that particular considerations need to be made for all associated code anyhow though so I don't find it to steal from the teleport utility per above. If you need parameter objects that work some other way than the ordinary Gambit/Scheme parameter objects, just by all means implement that functionality yourself.
Adam