Parameterised modules

[Sean Hinde]

On Monday, September 1, 2003, at 02:46  pm, Mikael Pettersson wrote:

> Sean Hinde writes:
>> Hi,
>>
>> some convention that if the registered name was say '$undefined' then
>> the register step would be explicitly skipped.
>
> Either using a convention with an out-of-band value denoting "don't"
> or adding a second boolean DoReg parameter will work. (But see below.)

But then we are getting pretty ugly, with new case specific code 
required in the guts of the module of similar complexity of that which 
we hope to remove.

>
>> The second example is of providing a user defined log function at
>> module instantiation. Every time I have wanted to provide for a user
>> definable log function I have also wanted to have a built in default
>> logger, and provide the caller the option to provide their own if
>> desired. I do not see any way to provide a default value for a
>> parameter in the proposal for parameterised modules.
>
> 1. Whoever does the instantiation gets to choose. This works
>    perfectly in Standard ML, whose parametrized module system
>    was the original inspiration for HiPE's work on the same.
>
> 2. Something like
>
>    -module(foo, [{Label,Default},...])
>
>    and change foo:new() calls to pass the values by Label
>
>    foo:new([{'Log', sean_logger}])
>
>    and any omitted Label would get its default value.

So you are proposing that new() should always have a single parameter 
which is a list of tagged tuples with magic properties? This would work 
I think, though it is getting away from the reason to provide the 
feature (Clearer code).

If this was taken further so that a call to foo:new() was a wrapper for 
foo:new([]) this would be quite clean. Maybe even then using a 
parameterised module without ever calling new() would give the default 
behaviour - thus removing the burden of additional understanding 
required before a module could be used at all. This is not as pretty as 
Richards version though..

>
>    This would be a fairly simple change I think.
>
>    This could also solve your maybe-register problem. Omitting the
>    RegisteredName parameter lets it take on a default value, whose
>    encoding is private to the module. Clean, no?

I'm still not really convinced that the benefit in normal everyday code 
is enough to justify the additional cost of maintenance of systems 
which use this feature - I envision many hours of searching for the 
place where some magic imperative style variable got it's value when 
reading someone elses code, especially when it is probably nowhere to 
be seen in the backtrace of some crashdump from a live system. Hmmmm

Sean