On 9/21/11 5:22 PM, bearophile wrote:
This is why I have asked for functions like amap/afilter in Phobos,
because in many situations in D you need an array instead of a lazy
range.
I don't think that was being asked.
Of course, if every function that accepts a range becomes a
template then you have the practical problem of managing the number
of template instantiations. Code bloat is still a real problem with
heavy template usage.
Haskell has used typeclasses to avoid this :-)
At the conference I discussed typeclasses at length with a Haskell
connoisseur and he had to agree that D's template constraints are a
suitable replacement, and also that template constraints can express
requirements that type classes have difficulties with. This is because
D's template constraints can involve several types simultaneously and
can do arbitrary computations. (That's also what makes them less
structured than typeclasses.)
Finally, map in Haskell just makes sense. You have a list of a's,
a function of 'a to b' and you get a list of b's out the other end.
It's simple, it's exactly what you want, and it just works. You
can't say the same in D.
I agree. That has two good consequences: - It makes sense for the
Haskell compiler too, so it is able to perform very complex
optimizations that no D compiler today performs. - Being map so easy
to write, to use and to understand, the programmer is able to write
far more complex things. If writing a map requires a tens lines of
complex D code, normal programmers usually don't want to write things
much more complex (type-wise too) than a map.
I'm not sure how that assumption works. Implementing a regex engine is
quite an endeavor, but that doesn't stop people from using it casually,
and for higher-level things.
On the Haskell compiler being "... able to perform very complex
optimizations that no D compiler today performs" I call bullshit. The
two languages have very different approaches to computation and choose
right off the bat very different corners of the PL design space.
Consequently, the challenges met by the two languages are very different
and the approaches to overcome those challenges are also very different.
Haskell starts with a computational model far removed from the reality
of the computing fabric it works on. Therefore, it gains some in certain
areas, but it loses some when it comes to efficiency. Naturally, it
needs more sophisticated optimizations to overcome that handicap. That
doesn't mean much in comparing Haskell to D or the quality of a Haskell
compiler with that of a D compiler.
Python lazy iterators syntax wins over both languages:
collection = xrange(20) [2 * x for x in collection if x< 5] #
eager
[0, 2, 4, 6, 8]
newcol = (2 * x for x in collection if x< 5) # lazy
list(newcol)
[0, 2, 4, 6, 8]
I guess I must act impressed.
We should probably add a specialized lambda syntax.
Do you mean something like C# lambdas?
Per Walter's enumeration of syntax in various languages.
I wonder what Scala/Haskell idioms we should borrow for D.
Haskell has several nice ideas, but I think it's not easy to copy
them without changing D a lot. Still, being open toward this idea is
an improvement for D designers :-)
Feel free to spare the patronizing part, it won't be missed.
You want Haskell capability with D performance. You can't have
that.
We live in a world where JavaScript is sometimes only 3-4 times
slower than D code, and where LuaJIT compiles dynamically typed Lua
floating-point-heavy programs and runs them in a total amount of time
lower than just running a binary produced by DMD. So be careful when
you say something is impossible :-)
In the works there is a dialect of Haskell meant for faster
programs: http://www.haskell.org/haskellwiki/DDC
That wasn't my point.
D's map is superior to Haskell's. There is no contest.
Some aspects of D map are superior, and some aspects of Haskell map
are superior to D ones.
(In addition, Hakell's map forces ONE higher-order function
representation, whereas D works with a function alias, function,
or delegate.)
I think this is an advantage of Haskell. I think Haskell doesn't need
those things, it's more uniform.
It's also slower. Per the other half of your other posts, efficiency is
a huge concern to you.
D also allows things that are essentially impossible in Haskell,
such as quicksort.
The point of this discussion is to look for ways to improve D.
bashing Haskell is off topic and bad.
Nobody's bashing Haskell. But we can't work from the assumption that
everything in Haskell is non-critically good and has no downsides.
Andrei
