Subject: Re: I-D ACTION:draft-daboo-sieve-include-04.txt (fwd)

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 12 Jul 2006 00:02:02 +0200

On Mon, 2006-06-26 at 19:37 -0400, Mark E. Mallett wrote:
> In preparing some comments (so far left on the floor), I had come up
> with some twisted examples to illustrate questions about how import and
> export interact, specifically contrasted with simple global variables.
> The best I can make out is that import and export coordinate through
> some sort of import/export namespace (as contrasted with global
> namespace, which it really isn't):
> 
>    - import pre-initializes a variable's value from the same-named
>      variable in the import/export namespace, requiring that at some
>      other point in script execution, some code has set up that variable
>      in the import/export namespace;
> and
>    - export says that whenever a script context changes (i.e. it
>      'return's to its includer, or it 'include's another script), the
>      exported variable's value is published into that of the same-named
>      variable in the import/export pool.
> 
> If this is correct, then it just makes me wonder:  wouldn't it be just
> as useful to make "import" and "export" be action commands, allowing a
> script to push and pull variables out of the import/export namespace
> without being subject to unintended side-effects (i.e. of not being able
> to predict what, exactly, included scripts export into your nicely
> imported variables)?

one option here is to get rid of export, and instead do it as an option
to the "include" action.

   include :export ["foo", "bar"] "myscript";

(the specified variable names should be constant strings, ie. without
variable expansions, to reduce the number of exploding head incidents.)

> And that in turn makes me wonder, why not just use
> a reserved namespace (like "include.")  and use "set" to do those
> manipulations?  (Which is similar to what you said re 'global' only more
> in line with what I read into what import/export is trying to do.)

do you get any control over access then?

it's probably better to think of import/export as the parameter list
supplied to the sub-script, rather than as a scoping thing.  a variable
which is exported, will only be available to the directly included
script.  in fact, the sub-script is prohibited from re-exporting the
variable to its sub-sub-scripts, it has to make a copy with a different
name if it needs to do such a thing (aside, I don't think we need that
restriction, I can't see what we gain from it).

so when you call (actually include) a procedure (actually sub-script),
your exported variables are the named parameters for that procedure, and
the procedure may return values to the caller by modifying these
exported variables.

switching to an :export keyword may make this more intuitive.
-- 
Kjetil T.

---

From: Aaron Stone <[email-masked]>
Date: Thu, 13 Jul 2006 07:32:34 -0700

> > namespace, which it really isn't):

This is my understanding as well.

> variable expansions, to reduce the number of exploding head incidents.)

Yes, constant strings are better here.

> > in line with what I read into what import/export is trying to do.)

You'd have to start calculating namespaces in the variable names... I'm
not a great fan of the namespace idea.

Kjetil's idea is an interesting, funky subroutine system. Would the
included script still need to explicitly import the exported variables,
or would we simply drop the import keyword entirely?

The proposal seems workable; I could go for this, too. Toss a coin?

Aaron