[gambit-list] Parameter objects performance Q

Adam adam.mlmb at gmail.com
Thu Mar 12 02:44:03 EDT 2020

On Wed, 11 Mar 2020 at 19:39, Jörg F. Wittenberger <
Joerg.Wittenberger at softeyes.net> wrote:

> On Tue, 10 Mar 2020 21:19:01 -0400
> Marc Feeley <feeley at iro.umontreal.ca> wrote:
> > > On Mar 10, 2020, at 6:41 PM, Jörg F. Wittenberger
> > > <Joerg.Wittenberger at 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-Class_Continuations
> ).
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20200312/0d566a00/attachment.htm>

More information about the Gambit-list mailing list