Haskell

[Jonathan M Davis]

On Wednesday, August 24, 2011 17:52 Timon Gehr wrote:
> On 08/25/2011 02:34 AM, Jonathan M Davis wrote:
> > On Wednesday, August 24, 2011 17:17 Timon Gehr wrote:
> >> On 08/25/2011 01:15 AM, Timon Gehr wrote:
> >>> On 08/24/2011 11:55 PM, bearophile wrote:
> >>>> Timon Gehr:
> >>>>> If anyone is interested:
> >>>>> http://pastebin.com/2rEdx0RD
> >>>> 
> >>>> I suggest you to usually compile your D code with -w, I see some
> >>>> missing overrides. At line 40 it gives me a "Warning: statement is not
> >>>> reachable".
> >>> 
> >>> There is only one missing override, but it is reported for every
> >>> instantiation of the template. Statement at line 40 is necessary to
> >>> make the /type inference/ work out, and such things are the reason I
> >>> don't usually turn warnings on. Another example where warnings are a
> >>> pita:
> >>> 
> >>> case "bla","blu","blo": // Warning: fallthrough
> >>> case "xxx","yyy","zzz":
> >>> 
> >>> What the code expresses is: There are two cases, one occurs if the
> >>> input is bla blu or blo, and the other one if it is xxx or yyy or zzz.
> >>> Those cases should be handled the same way. (At least for now).
> >>> goto case; is both unnecessary and ugly in that case.
> >>> 
> >>> So basically, for me there are too many false positives to make the -w
> >>> switch really practical, which is a pity, as they would have catched
> >>> the missing override in this case.
> >>> 
> >>>> Are you able to use it to translate the Haskell version of this task?
> >>>> http://rosettacode.org/wiki/Hamming_numbers#Haskell
> >>> 
> >>> Challenge accepted.
> >> 
> >> ASDF. I got it working quite fast, and then I started a fight with
> >> std.bigint.BigInt.toString until I accidentally cp'd over my source
> >> code. That will be reported soon, it makes BigInt UNUSABLE.
> >> 
> >> I am going to code it again...
> > 
> > Don refuses to implement it, because it always creates a new string. He
> > wants something like the DIP for writeFrom (or whatever the exact
> > function name was) which allows for writing to a pre-existing buffer. I
> > think that there's already a bug on the issue, but I'd have to search
> > for it.
> > 
> > - Jonathan M Davis
> 
> We must just add _*RVO for arrays*_ to the compiler and then users can
> use the built-in array concatenation syntax for the efficient thing.
> Everything else would just waste the precious grammar rules.
> How it is now is just painful and it does not fit well into the rest of
> Phobos. Not even std.conv.to can convert a BigInt to a string. This is a
> trivial issue that renders std.bigint unusable for these kinds of little
> scripts, where they actually would be of use. I don't care if I get a
> newly allocated string, because I only convert it once to output it. The
> current design just hurts me everywhere, and wasted a lot of my time.
> Premature optimization is the root of all evil.

The DIP actually solves the problem quite well, but it hasn't gone anywhere 
yet. I'd argue that BigInt should have a toString in the interim, but Don is 
against it (and std.conv.to requires toString, alias this to a string, or a 
cast to a string for a struct or class to work with it, and BigInt has none of 
those).

- Jonathan M Davis