Re: variables: open issue a) date variables

On Sunday 04 May 2003 00:15, Kjetil Torgrim Homme wrote:
<snip>
> if you want a prefix character, use "_".  it's part of the identifier
> grammar, and has seen similar use in other contexts.
"_" is as good as "#". I've chosen "#" b/c of the #namespace convention 
of IMAP and #... would be a kind of system namespace, like std:: in 
c++.

I don't see why variable names have to match the identifier production. 
num-variable certainly doesn't, either.

> >   The reasons against magic/system variables Kjetil mentioned were:
> >
> >   1. Year, month, etc. are not really magic, you can write them via
> > set and they only spring into life on setdate.
> >
> >   I think we agree that writing to those variables is not a good
> >   idea, since it's not needed, makes program flow analysis more
> >   complex
> really?
Come one. I thought we agreed that writing to system variables is a bad 
idea...

> I think an explicit action to set them is easier to handle 
> than a multitude of variables which can change as side-effects.
But they _do_ change as side effects. You can't go and pretend they 
don't.

> we've already seen that this is a tricky issue with the match back
> references.  there the gain for easy access seems great enough to be
> worth it.  SETDATE can be seen as a macro for
>
>   SET "hour" "${_internal_startup_hour}";
>   SET "minute" "${_internal_startup_minute}";
>   SET "second" "${_internal_startup_second}";
>   ...
>
> pretty straightforward to analyse, IMO.
So what should ${_internal_startup_hour} be other than a system 
variable? Also, how do the equivalent set commands look like for
  setdate "CEST";
? ;-)

> what actions can influence ${_imapflags}?  how will its value change?
<snip>

${#imapflags} is (if resolved) a space-separated list of imap flags. The 
order of flags in ${#imapflags} is undefined (it's conceptually a set).

addflag
- adds the flags given as arg to #imapflags then
- removes all duplicates.

removeflag
- removes all flags given as arg from #imapflags

setflag
- clears #imapflags
- executes addflag <args>

mark
- equivalent to addflag "\\Flagged"

unmark
- equivalent to removeflag "\\Flagged"

> >   Furthermore, that they spring into life as a side-effect of a
> >   command is proof, not disproof, of their magicness.
> see macro comment.
The macro comment only shifts the problem from ${year} to 
${_internal_startup_year}. Instead of ${year}, you make 
${_internal_startup_year} magic.

> >   3. We'd need a registry for them, since extensions could
> > conflict.
> >
> >   They can still conflict if we don't make system variables
> > explicit in the variables extension. Prefixing them at least avoids
> > conflicts with user variables.
> no, there can be no conflict, two extensions can use the same
> variable name and co-exist peacefully. e.g., you could have two 
> actions putting its return value in ${result}.  the user would just
> have to do a SET to save it in another variable before doing the next
> action, and he only has to do that if he needs to use the two actions
> in the same Sieve run.  with your truly magic variables, this can't
> be done.
<snip>

Granted, but where's the usefulness in allowing that in the first place? 
I don't see why such behaviour is needed, the more so as it's very 
inconvenient for the user (oh - and GUI editors!) to have to save away 
${result} themselves.

Summary:
There are two issues, let's separate them:
1. Should set be allowed to act on system variables?
   I hope to have made it clear that that's a bad idea.
2. Should system variables be prefixed?
   Well, why _not_? If it makes set's job easier to determine if
   something is read-only or not? If it makes system variable references
   more explicit?

Marc

-- 
I am Bush of USA. You will be pacified. Resistance is futile.

pgpp1Gtxlf0kp.pgp
Description: signature