Haskell

[Jonathan M Davis]

On Thursday, August 25, 2011 03:35:05 Timon Gehr wrote:
> On 08/25/2011 03:07 AM, Jonathan M Davis wrote:
> > 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).
> 
> It could have a special case for BigInt.
> 
> 
> The DIP does not solve the whole issue imho. This _cries_ for a more
> general solution. The DIP says, 'composing strings is inefficient and
> puts too much pressure on the heap, that is why we have to replace a
> simple API with a more complex one'. Wrong. That is why we have to make
> the compiler generate good code for composing strings, if necessary
> through an ABI change.
> 
> writeTo looks like a neat solution if you want to Eg. output the thing
> without heap activity. But toString means: Convert this Object to
> string, and allocate a new string. I do not get why anyone would think
> that a hermaphrodite method with the name toString and the functionality
> of writeTo has any reason to exist. How do you simply convert a BigInt
> to a string using that tool? (I haven't found out, I always get "0") It
> really hurts generic code too, because it deviates from how things work
> for other types. Don should seriously reconsider.

The DIP works great if it's fully implemented. It complicates the 
implementations for classes and structs somewhat, but the code which uses them 
isn't generally affected much. It just uses to!string(a) instead of 
a.toString(). The problem is that the DIP hasn't been fully implemented. And 
in the meantime, the lack of a toString on BigInt is crippling.

- Jonathan M Davis