Subject: Include 04 export/import

From: Aaron Stone <[email-masked]>
Date: Wed, 14 Jun 2006 09:28:30 -0700

Hi Cyrus,

I remember the hangup for the include draft! It was the interaction with
variables ;-) Glad you've addressed it; I like the export/import idea.

Nits: there are two spelling errors in section 3.4.2, "intially" should
be "initially" and further down, "and error..." should be "an error".

Meat: has there been discussion on the list about what happens if an
undefined variable is used? I think it would be good to fall back on any
such definitions.

An included script could pull in more variables than were exported, and
simply find that some of them are not defined. For example, a :global
script might have some documented functionality like, "export ${this}
for some useful behavior, and ${that} for some other useful stuff." A
user might only set ${that}, but the script has imported both ${this}
and ${that}. I don't think it should cause an error.

On the other hand, it establishes a very strong contract with the
including-script, which must export all imported variables. Hmm.

Aaron

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 15 Jun 2006 00:12:33 +0200

good work, Cyrus, I really like import/export.

> undefined variable is used? I think it would be good to fall back on any

[VARIABLES] says:

    Unknown variables are replaced by the empty string.

it's not an error.

> and ${that}. I don't think it should cause an error.

I agree.

   If an "import" command lists a variable that has not been exported
   and set by any other script at that point during the SIEVE execution
   process, then an error MUST occur.

I suggest that "and set" is removed.  remember that changes made to the
imported variable will be visible in the parent.  this is how values are
returned from "calling" sub-scripts, and it would be strange to require
the parent to set it prior to the call.  this should probably made clear
in the draft.

another issue -- the examples say:

    |   require ["variables", "include"];
    |   export ${test}

further up it says the argument is a string list, so it would have to be

    export "${test}";

I would prefer that the variable name was used unadorned, however, as I
would expect ${test} to be expanded to the value, no matter how
nonsensical that is...  so:

    export "test";

it should also be made clear that the strings in the list need to be
constant strings, ie. without ${variable} references.

-- 
Kjetil T.

---

From: "Aaron Stone" <[email-masked]>
Date: Wed, 14 Jun 2006 23:13:01 -0000

>     Unknown variables are replaced by the empty string.

Thanks, I was looking for that reference. I grepped for "undefined" and
"undeclared" and "unset" -- "unknown" was not the word I expected :-P

> the parent to set it prior to the call.  this should probably made clear

Would a read-only modified be useful here? For example:

    export :readonly "testvar"

Also, would you still want to consider it an error to import a variable
that was not already exported? I'm on the fence about this.

Aaron

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 15 Jun 2006 01:19:16 +0200

>     export :readonly "testvar"

if the exporting script worries about this, it can make a copy in an
unexported variable.

> that was not already exported?

yes.
-- 
Kjetil T.

---

From: "Aaron Stone" <[email-masked]>
Date: Wed, 14 Jun 2006 23:26:28 -0000

> if the exporting script worries about this, it can make a copy in an

Heh, duh.

>> that was not already exported?

Ok, I can roll with that. Looking forward to hearing Cyrus' remarks on our
remarks :-) I'm glad to see the include draft revived!

Aaron

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 14 Jun 2006 20:32:26 -0400

Hi Kjetil,

> the parent to set it prior to the call.  this should probably made clear

OK, that makes sense and I will update the draft accordingly. However, one 
questions: what should happen if an "export" command references a variable 
not defined in the remainder of the script? I don't think I called out that 
case explicitly. Should that be an error, or should it be allowed?

> constant strings, ie. without ${variable} references.

OK, I will fix the examples as you suggest.

-- 
Cyrus Daboo

---

From: Aaron Stone <[email-masked]>
Date: Wed, 14 Jun 2006 18:39:11 -0700

> case explicitly. Should that be an error, or should it be allowed?

I don't see why should this be a problem. I definitely would not want to
have code in my implementation that goes through a script to see if
exported variables are ever set or used. Too much hassle for no gain.

Aaron

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 15 Jun 2006 09:24:21 +0200

I agree.
-- 
Kjetil T.