Haskell

[Timon Gehr]

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.