On 09/22/2011 02:29 PM, Christophe wrote:
"Nick Sabalausky" , dans le message (digitalmars.D:145002), a écrit :
For example, in Haskell, map (correctly) has the signature:
map :: (a -> b) -> [a] -> [b]
but in D, std.map has the signature (expressed in some Haskell/D
pseudocode)
map :: (a -> b) -> [a] -> Map!((a -> b), [a])
except that [a] should be a D Range, and that Map is a D Range too.
So I'd go for:
map :: (a -> b) -> Range!A -> Range!B
oh, that's quite close to Haskell's map...
Let me try the other game: what is Haskell's signature ?
I need to introduce Haskell's type to D, so:
// all types are lazy pure:
template Haskell(T)
{
alias pure T function() Haskell;
}
// Haskell's list:
template HaskellR(T)
{
alias pure Tuple!(Haskell!A, HaskellR!T) function() HaskellR;
}
// Then the signature of map is:
HaskellR!B map(A,B)(Haskell!B function(Haskell!A), HaskellR!A);
Experienced Haskell's users may correct me.
All functions must be pure, and those pure function, and a lot of
optimization comes from the memoization of those functions.
Haskell!T could be rewritten to take into account this memoization.
I wonder what efficiency would we get compared to Haskell with a library
based on this kind of stuff in D. We would probably miss many
optimization opportunities that Haskell is tuned to find out, but it
must be fun to try that out.
I did: http://pastebin.com/2rEdx0RD
port of some haskell code from RosettaCode (run it ~20 min to get
results, haskell runs in less than 2s)
http://pastebin.com/Vx4hXvaT
Output of the second example is screwed up with the latest release
though, I don't know why, but converting BigNums to string is a PITA
anyways... Has there been a regression in the std.bigint.BigInt.toString
code?
The main performance issue is the garbage collector. Turning it off will
help performance a lot if you have enough RAM. Furthermore, DMD does not
do any advanced optimizations
