Few things II

[Jari-Matti Mäkelä]

bearophile wrote:

> 12) I have seen D allows to pass anonymous functions like:
> (int x){return x*x;}
> 
> C# V.3.0 uses a more synthetic syntax:
> x => x*x
> 
> That syntax isn't bad, but I don't know how the compiler automatically
> manages the types in such situations, it can be a bit complex.

It does a bit more type inference than D at the moment. Currently you either
get return type or parameter type inference, but not both:

  (int x){return x*x;}

  int mul(T)(T x) { return x*x; }


> 17) I am following this newsgroup for some weeks, I have seen now and then
> it pops out some DMD problems regarding type inferencing (I too have found
> a 'bug' related to that, I have shown it on the learn newsgroup). I am
> helping the development of "ShedSkin" it's a compiler for an implicitly
> static subset of Python to C++. This program contains a really powerful
> type inferencer able to find fully by itself the types of all the
> variables used inside a 3000-lines long Python program (that contains no
> explicit type annotations). ShedSkin is rather slow and I think D will
> never need all its type inferencing capabilities, but I think its main
> point is to show that you can produce very fast code even if you start
> with code that's written with a very easy hi-level syntax. This
> 'discovery' may be useful to D too in the future.

At least the compile times are quite fast currently so there's much
potential for this.

> 19) I have created many very general function templates like map, imap,
> map, zip, sum, max, min, filter, ifilter, all, any, etc, that accept
> arrays, AAs and iterable classes. It may be useful to add a bit of
> functional-style programming to D, inside a Phobos module. Such functions
> may be fit for the 90% of the code where max running speed isn't
> necessary. They shorten the code, reduce bugs, speed up programming, make
> the program simpler to read, etc, and being hi-level they may even end
> helping the compiler produce efficient code (as foreach sometimes does).

It's hard to predict how much generic D code will still change in the near
future, but a functional library sounds useful. I've also written both
compile and runtime versions of generic map, fold, min, max, ... functions.
Probably some dsource project already implements them too, but it's faster
to write a simple algorithm from scratch than search the whole dsource and
worry about possible IP issues. But in overall I assume a lot of developer
time is wasted on reinventing the wheel :-/

> 21) In this newsgroup I've seen that people like a lot the ability of
> doing: txt.split()
> But I don't like it much because it's a syntactical sugar that masks the
> fact that those split are functions (that pollute the namespace) and they
> aren't true methods (object functions). That namespace pollution may cause
> problems, if you have already defined elsewhere a function with the same
> name and similar signature.

There was discussion about this some time ago. For example Scala has an
interesting language construct we could use in D.

> 
> 
> I think that's all, my successive post will probably be much smaller and
> mostly comments to specific posts :-)
> 
> Bear hugs,
> bearophile

--