[m-dev.] Here's an idea.

[Fergus Henderson]

Tyson Richard DOWD, you wrote:
> 
> % A cute use of heterogenous lists, dynamic type-checking (using
> % univ_to_type) and overloading of '.'.
> %
> % Instead of
> %
> % 	string__format("%d %d %f %s\n", [i(3), i(4), f(2.5), s("foo")], Str) 
> %
> % we can can do 
> %
> % 	sprintf("%d %d %f %s\n", [3, 4, 2.5, "foo"], Str) 
> %
> % In fact, there's no need for string__poly_type (although this code
> % just converts to it for simplicity).
> %
> % Unfortunately, overloading '.' like this causes problems - even
> % [1,2,3] has two possible types. So you should put the '.' function
> % in a module, then "use" it instead of "importing" it, and put a module
> % qualifier before the list, eg:
> %
> % 	sprintf("%d %d %f %s\n", modulename:[3, 4, 2.5, "foo"], Str) 

That won't quite work (try it).
The module qualifier only applies to the top-level functor.

To do it correctly, it would need to be

 	sprintf:sprintf("%d %d %f %s\n",
		sprintf:[3 | sprintf:[4 | sprintf:[2.5 | sprintf:["foo"]]]],
		Str) 

at which point you've lost all terseness.

It would work OK if you use import_module rather than use_module,
but then you have the problem that [1,2,3] is ambiguous.

Another alternative would be to overload some unary prefix operator, e.g. ~,
or perhaps +, to mean the same as univ/1 (which is the function version of
type_to_univ/2).  Then you could write

 	sprintf("%d %d %f %s\n", [~3, ~4, ~2.5, ~"foo"], Str) 

This avoids overloading `.', so it might be preferable.

However, this still doesn't solve one of the main problems of formatted
I/O, namely extensibility.  I think that if we are going to extend the
current formatted I/O support, we should look for a solution using type
classes that can provide formatted I/O for values of user-defined types.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.