[stringtemplate-interest] sequences and unique numbers

[Sam Barnett-Cormack]

Sam Barnett-Cormack wrote:
> Now, I can see how all of this could be done with the curernt system, 
> from your initial description, but I can see that they'll need clear 
> documentation and some best practices. I can see a value in the 
> recommended course being setting of formal parameters to a default 
> value, which does some sort of immediate-invoke of a property of an 
> object that evolves its own state. That's great. However, there's an 
> issue of parameter scoping - doing this recursively could cause problems 
> unless the parameters have clearer scoping. As I understand it, and I 
> may be wrong, if a template has a formal parameter, and the invoking 
> template can "see" an attribute of that name, then it's implicitly 
> passed. Is this still the case if the parameters has a default? Say, 
> templaet A has an attribute, no default, call att1, and template B has a 
> formal parameter *with* default also called att1. A invokes B without 
> explicitly setting att1. What value of att1 does B see? Should it be 
> possible to define B so that you choose whether to implicitly receive a 
> parameter or not?

Continuing my habit of replying to myself... I know that, currently, ST 
formal parameters hide the invoking template's parameters, although the 
caller can override this with <template(...)>. As I was suggesting 
expanding the template parameter definition syntax, it might be nice 
(from a documentation point of view) to specify parameters that *don't* 
hide the caller's values. In face, one thing that would be nice in the 
kind of use-cases I can imagine is a variant of default specification 
that allows you to say "this parameter will have the value it has in the 
caller, unless it's empty (unset) in the caller, in which case it will 
have this default". Also nice to say "this parameter can be set 
implicitly or explicitly, but it's an error if it's not set at all".

On another note, I guess one thing is that I'm uncomfortable with a 
syntax that means "the value of this template evaluated right now", as 
that violates the functional feel of ST. It means that 
order-of-evaluation *does* matter, otherwise there'd be no concept of 
"now". I'd prefer to only allow in parameter defaults, and then only on 
things that are marked as "yes-I-can-change", as discussed in my last email.

-- 
Sam Barnett-Cormack