[stringtemplate-interest] sequences and unique numbers

[Sam Barnett-Cormack]

Terence Parr wrote:
> 
> On Aug 4, 2009, at 4:16 AM, Sam Barnett-Cormack wrote:
> 
>> Terence Parr wrote:
>>> I'm running this up the flagpole to see what people think.  Is this
>>> good, bad, or indifferent?
>>
>> I'm not really a ST afficianado yet, but I like the whole ST concept,
>> and I think that this fits okay with it... but it means there should be
>> a change in the explanation of side-effects and the expectation of there
>> not being any. Call it perhaps "dynamic models" with "static models"
>> (predictable results) being easier, but dynamic models being valid.
> 
> Yeah, that's a good point. perhaps dynamic versus static is the way to 
> say it rather than side effect. but, by no side effects, do I mean 
> repeatability? Hmm... I wonder what pure functional languages due to get 
> the current time? does anybody know? Weird, I see some things on the web 
> about getting the current working directory and changing the current 
> directory, clear side effects. perhaps you have to do in one of those 
> weird monad things.

The way I see it, a "dynamic model" is one that changes in clear, 
pre-defined ways, perhaps defined by a set of best practices, perhaps by 
some sort of framework for classes being used as models. I'd hate that 
complexity... monads are pretty complicated, but "uniquess types" might 
be a model that can be followed, and allows "side effects without side 
effects". Basically, as far as I can tell, the idea is that, when you 
increment the counter (or whatever), the actual underlying object of the 
counter is passed to the caller, and the counter replaces itself with an 
entirely new counter. This is much like the way Java does String 
concatenation (the original isn't modified, it's replaced) with the 
additional constraint that one ensure that only one thing has a 
reference to the uniqueness type at any time. Now, we can't easily force 
application programmers to obey that, but we can offer them the chance 
to implement bits of their model that StringTemplate promises to work 
with in that way.

Say we have a class Counter, as an example, and it wraps an underlying 
counter such that a special call (that's where we'd add in an interface 
or something) to, say, Counter.value() returns a CounterValue of the 
next value - the one it was holding. At the same time, it replaces its 
own internal reference with a *new* CounterValue representing the next 
value desired afterwards. Make Counter.value() atomic (synchronized in 
Java, I think) and it's even pretty threadsafe. To fit the pattern of 
the uniqueness type, there'd have to be *no* other way to get the value 
of the Counter other than one that increments it. CounterValue types 
would also have to be immutable. Hard to enforce, but document it as the 
way it's supposed to be done.

How useful this is, I'm less sure, but it preserves (to some extent) the 
pure functionality I feel is sought by StringTemplate. I'd suggest 
implementing it using interfaces, maybe some convenience (abstract) 
classes to help people use it. One could also use a similar strategy to 
require classes in a model to not be changed by outside influence during 
the rendering, to help prevent confusing misuses with non-synchronized 
models that are changing *during* the rendering process, but that's 
another kettle of fish.

>> There are potentially all sorts of issues with concurrency,
>> repeatability, etc etc, and you need to be sure that developers know
>> that those are *their* problem. Otherwise, I don't see the problem with
>> dynamic models - it's potentially very useful, if subtle.
> 
> Yeah, makes me nervous, but I could put in the advanced features 
> "beware" type stuff. Also it's not like it's built into the language so 
> people who make tostring return a different value each time know they 
> are making a nonrepeatable thing.

Well, with the strategy I spitball above, you can make it "built in" for 
people who are using the framework/interfaces.

> In your next e-mail you suggest sugar to make it easier. Part of me 
> wants to leave it as "do it only few know what you're doing" and syntax 
> would make people use it. On the other hand, if it has a known bit of 
> syntactic sugar with known semantics, we discourage people from doing 
> all sorts of weird things manually in the model and passing them in. Hmm...

This also fits what I just wrote about helping with it when people are 
using the "right way"... make syntactic sugar require it be done in the 
expected way.

> I thought about doing something like
> 
> labels ::= {label<it>}
> 
> which presumably would give you a new label every time you reference 
> <labels>.

I'm not sure what the sugar would look like, but it could be something 
like that... ideally you'd have two special templates/syntaxes that 
requires its argument to use the framework (if following my suggestion) 
and can increment (or whatever). Like being able to define a special 
template that can be called in two ways...

counter ::= <evolving(foo)>

which will check that foo claims to be an implementation of the pattern 
I described above, and then if you call <counter> you get the last thing 
returned by foo, and if you call, say <|counter|> (just as an example), 
it updates the value and outputs it.

This would *not* require that only stringtemplate, and only one 
instance, use foo. The Uniqueness structuer ensures that everyone's free 
to get values from it, and the practice would require some insurance 
that a Counter always returns a completely fresh value.

Well, that was a bit of an incoherent rant, and half of it was me 
writing it literally as I thought it... but hey, it's a break from 
modelling ASN.1 and mapping it to Java... I hate deadlines. Anyway, 
hopefully you got something from it.

-- 
Sam Barnett-Cormack