Less coding + possible module bug

[bearophile]

Jarrod:

> I like your collection of higher order functions, perhaps you can get
> them added to the core library in the future, or even better, Walter can
> build them into the language (ha).

Thank you. I think most of that stuff doesn't need to become built-in (I think among them only two things may enjoy being supported by the compiler: an *exact* copy of Python list comps and generators. Partial or approximate copies are not worth). What I'd like to see in the compiler isn't more HOFs, but better basic tools to *build* and use such high-order things. AST macros may help. Other useful tools:
- Built-in (or in phobos, if it can be used in a transparent way) ability to iterate on two generators in parallel.
- Better type inference, to allow shorter anonymous function syntax and allow more automatic specialization: for example having defined many different foo() templated functions, I'd like to use it as &foo, instead of &foo!(uint, long).
- A more logically sound module system (*).


> std.algorithm is packed full of HOP functions, and a foreach range.

D 2.x allows foreach(i; 1..10) too, but I am using D 1.x, and most (95%?) of my stuff isn't present in that std.algorithm. It's nothing revolutionary, but they seem to work well enough, and I have kept the usage very easy because they can be useful (almost) only if they are easy to remember :-)

===============================================

(*) beside the other bugs/problems shown in the past by me regarding the module system, I may have found another problem in it. The following ones are 3 modules, the first is the main one:


module main_module;
import foo1;
import foo2;
void main() { str(1); }

------------------

module foo1;
private import std.string: str = toString;

------------------

module foo2;
string str(TyArgs...)(TyArgs args) {
  return "";
}

------------------

If compiled it produces:
main_module.d(4): Error: foo1.str at foo1.d(2) conflicts with foo2.str(TyArgs...) at foo2.d(2)

The "private" in foo1 must be unnecessary in a usable module system, but even adding it the "str" name in the "foo1" namespace becomes imported anyway in the "main_module" namespace, and it gives conflict.

Bye,
bearophile