Clay language

[spir]

On Tue, 28 Dec 2010 14:38:56 +0300
Stanislav Blinov <stanislav.blinov at gmail.com> wrote:

> Taking an example from std.algorithm documentation:
> 
> 1)
> int[] arr1 = [ 1, 2, 3, 4 ];
> int[] arr2 = [ 5, 6 ];
> auto squares = map!("a * a")(chain(arr1, arr2));
> assert(equal(squares, [ 1, 4, 9, 16, 25, 36 ]));
> // 146 characters
> 
> 2)
> int[] arr1 = [ 1, 2, 3, 4 ];
> int[] arr2 = [ 5, 6 ];
> auto squares = std.algorithm.map!("a * a")(std.range.chain(arr1, arr2));
> assert(std.algorithm.equal(squares, [ 1, 4, 9, 16, 25, 36 ]));
> // 184 characters
> 
> How is 2) is better/safer than 1)? I took a pretty short example, but I 
> easily imagine as real code would blow up to 25-40% more characters just 
> for the sake of explicit qualification, especially when using 
> third-party (or own) libraries with nested structure (like, e.g., in 
> Tango).

It seems you don't get the point (or rather what I think is the actual point). "Safe" import (as the OP defines and names it; I would rather call it "explicite import") perfectly allows aliasing imported symbols, as D presently does it:
	import mod	: func = somefunc; // or simply func=func
But the current default / least resistance way of importing blindly imports all symbols from the module in a local namespace and --even more importantly for me:
1. at import place, does not tell the reader which symbols are actually used
2. at use place, does not tell the reader where a given symbol is imported from
These are imo essential documentation needs unfulfilled. (I'm constantly bumping in this wall when reading other people's code; esp. phobos source; even more when it uses C stdlib funcs that everybody but me seems to know where they are defined, what they actually do, and how ;-)

Keeping the module name instead of aliasing in numerous cases makes the code far easier to read. For instance, I commonly use this scheme:
	static import file = std.file;
	...
	auto config = file.readText("config");

There should be a way to carelessly import everything --for instance into a parser module using (most) pattern types, constants, and more, from a parsing lib. This is correct in particular cases, and secure thank to the fact that in D symbols are not implicitely re-exported. But this should not be the default case; then the plain fact of using a dedicated syntax (eg like proposed "import parseLib : *;") would deal as a kind of documentation about a non-standard practice.

Maybe it's only me (and a few other martian programmers) expecting code to be commonly clearer...


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com