alternatives to keyword parameters (was: Re: [Developers] Double quotes around keyword parameter values)

[Jonathan Thornburg]

I wrote:
>> That said...  If keyword parameter checks really are a performance
>> problem, why not just pre-decode them outside the inner loop?

Erik wrote:
> I do that, you do that, but most people who use keyword parameters don't
> do that.  I'm not saying that it is complicated to do so.  I just find
> that, when I look at random code written by at least halfway competent
> people, it tends to not pre-decode keyword parameters.

Ok, I see your point.  I suppose putting a warning into the Cactus Users'
Guide might be a Good Thing To Do, but realistically most Cactus programmers
probably won't see/read/honor it. :(


> Keyword parameters are semantically identical to enums, but performance
> wise orders of magnitude worse.  That is a surprise to people, and
> surprises are bad.  Thus my idea to invent something -- be it macros,
> or a perl preprocessor stage, or whatever -- to make them more
> efficient.  Just how this should be done is open, but I think that
> representing them as strings is a dead end for that.

Ok, what about your scheme, call them "identifier parameters":

# param.ccl
identifier commute_method "how should I commute to work?"
{
work_at_home	:: "real geeks have DSL and work at home ==> no need to commute"
walk		:: "low-tech but works fine"
S_bahn		:: "not that cheap, but works well"
bicycle		:: "medium-tech, works great if you're in decent health"
car		:: "useful for speeding up global warming"
} "walk"

// MyThorn/mycode.c
void MyThorn_commute(CCTK_ARGUMENTS)
{
DECLARE_CCTK_ARGUMENTS
DECLARE_CCTK_PARAMETERS

int i,j,k;

 	for (int k = 0 ; k < cctk_lsh[2] ; ++k)
 	{
 	for (int j = 0 ; j < cctk_lsh[1] ; ++j)
 	{
 	for (int i = 0 ; i < cctk_lsh[0] ; ++i)
 	{
 	switch	(commute_method)
 		{
 	case work_at_home:
 		/* ... */
 		break;
 	case walk:
 		/* ... */
 		break;
 	case S_bahn:
 		/* ... */
 		break;
 	case bicycle:
 		/* ... */
 		break;
 	case car:
 		pollute(INT_MAX);
 		break;
 	default:
 		CCTK_WARN(CCTK_WARN_ABORT, ...);		/*NOTREACHED*/
 		}
 	}
 	}
 	}
}

The one problem I can see with this is that C enumerators have to be
GLOBALLY unique, i.e. the "identifiers" would have to be unique across
sets-of-thorns-sharing-parameters.  Possible solutions:
* Live with it, i.e. let users worry about finding globally-unique
   identifiers in sets-of-thorns-which-share-parameters, just like
   parameter names themselves must already be globally unique.
* Have the CST prefix the user-specified identifiers with the
   implementation names.  The trouble is, C limits identifiers
   to 31 letters, and Implementation_Identifier could easily
   exceed this.
* Have a perl preprocessor prefix the user-specified identifiers
   with short CST-generated unique strings, eg 2 A-Z letters is
   already enough for up to 26^2 thorns, which should be enough
   for just about any use I can think of.  This probably works,
   unless the programmer does something fancy with the # (stringify)
   operator in fancy macros...

comments?

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam