[prev in list] [next in list] [prev in thread] [next in thread] 

List:       stringtemplate-interest
Subject:    [stringtemplate-interest] formal arg checking
From:       parrt () cs ! usfca ! edu (Terence Parr)
Date:       2007-05-10 22:23:34
Message-ID: 272EAEBE-5D59-423A-A782-C21A7CA45B71 () cs ! usfca ! edu
[Download RAW message or body]


On Apr 30, 2007, at 8:16 PM, Nate wrote:
>> Is error message defined anywhere in the surrounding context? that
>> is, in an enclosing template? If not, you cannot reference an
>> undefined attribute just like in a programming language. If I were
>> you, I would just add errorMessage to the template that invokes table
>> and you problem disappears.
> No, errorMessage is only defined in the surrounding context when  
> there is an error message. I am pretty sure that ST out of the box  
> allows this to work...
>
> $table(emptyMessage=errorMessage)$
>
> But not this...
>
> $table(emptyMessage={$errorMessage$})$
>
> In the latter, ST explodes with an exception saying that  
> "errorMessage" is not a formal argument to "table". While this is  
> true, it is not consistent behavior with the former.
>
> That is what doesn't make sense to me.

If that is the way it is currently working, then yes that does not  
make sense.

> I have removed formal argument checking from my local copy of ST.  
> I'm posting this because I think ST formal argument checking should  
> be fixed in the official distribution.
>
> This should fail with "table doesn't have a formal argument named  
> nate" exception...
>
> $table(nate="moo")$

agreed. so it does not fail on this now?

> This should NOT fail even if "cow" is undefined ("rows" is a valid  
> formal arg)...
>
> $table(rows={$cow$})$

If cow is not defined anywhere up the chain and that chain has formal  
arguments, then it is an error.

> I'd like to tack on a couple unrelated items since I'm here typing  
> anyway...
>
> A. Why does this fail?... $first(tests).name$
> Seems like that should be valid.
> $first(tests):{$it.name$}$ is quite an ugly workaround.

True.  Syntax just doesn't allow it at the moment.  Sorry.

> B. Would index access to lists break separation? Eg...
> $tests[0].name$
> $tests[1].name$

yep because it is like calling a function with an argument from the  
template, not that there aren't similar things.  Even referencing an  
attribute requires that I invoke toString, the difference is that  
there are no attributes or arguments going in.

> [0] can be done with first(), but getting the nth element is  
> impossible otherwise.

  on purpose I am afraid.

>
> C. Imagine this code...
> $tests:{test|
>  $test.values:{value|
>    $value$,
>  }$
> }
> Output might be...
>      value1, value2
> test1 123, 456
> test2 321, 654
> test3 789, 987

[ actually there would be commas on the as well] ;)

> Now I want to output the table differently, rotated 90 degrees like  
> this...
>       test1, test2, test3
> value1 123, 321, 789
> value2 456, 654, 987

What you want is to do parallel iteration, but ST can only do this  
for named arrays:

$names,phones:{n,p | ...}$

Here, you need names,phones to be tests[0], test[1], ...  right?  If  
you know how many there are, you could do the following hideous version:

$first(tests), first(rest(tests)), ...$

Well, I must be honest that I thought more in terms of objects not  
lots of different arrays, which is the problem you're having.  I  
think that if you had lists of objects instead of two-dimensional  
arrays this would be easier.


Ter

[prev in list] [next in list] [prev in thread] [next in thread]