[stringtemplate-interest] sequences and unique numbers

[Koerner, Ron]

A somewhat different approach would be a template-scoped builtin
"constant" which is unique for each invocation of the template.
If you think of templates as functions that could be the stack frame
pointer.

if(cond,block) ::= <<

<cond>
bne label<TemplateInstanceUID>
<block>
label<TemplateInstanceUID>:

>>

where TemplateInstanceUID is implicitely bound the the address of the
template instance. That would push it a little more into the direction
of the current time and does not have the bad taste of side effects.

Regards,
Ron

-----Original Message-----
From: stringtemplate-interest-bounces at antlr.org
[mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Terence
Parr
Sent: Wednesday, August 05, 2009 9:44 PM
To: Sam Barnett-Cormack
Cc: String Template
Subject: Re: [stringtemplate-interest] sequences and unique numbers


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.

> 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.

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...

I thought about doing something like

labels ::= {label<it>}

which presumably would give you a new label every time you reference  
<labels>.

Ter
_______________________________________________
stringtemplate-interest mailing list
stringtemplate-interest at antlr.org
http://www.antlr.org/mailman/listinfo/stringtemplate-interest

-- 
WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.