February 18, 2010
Steven Schveighoffer wrote:
> First, it would work under my rules.  j would be of type int.  Under my rules, negating an unsigned value equates to a signed version of that type.


I've tried to stick with the principle that C code compiled with D will either work the same, or will fail with a compiler error message. It's very important to avoid "compiles, but produces subtly different behavior" for integer numeric code.

The reason for this is there's a lot of debugged, working C code that contains rather complicated integer expressions. How/why it works may be long since lost information, and having it fail when translated to D will cause frustration and distaste for D.

Changing the signedness of a sub-expression will definitely fall into this category.
February 18, 2010
On Thu, 18 Feb 2010 14:22:06 -0500, Walter Bright <newshound1@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> First, it would work under my rules.  j would be of type int.  Under my rules, negating an unsigned value equates to a signed version of that type.
>
>
> I've tried to stick with the principle that C code compiled with D will either work the same, or will fail with a compiler error message. It's very important to avoid "compiles, but produces subtly different behavior" for integer numeric code.
>
> The reason for this is there's a lot of debugged, working C code that contains rather complicated integer expressions. How/why it works may be long since lost information, and having it fail when translated to D will cause frustration and distaste for D.
>
> Changing the signedness of a sub-expression will definitely fall into this category.

This is a much better argument than your previous one.  However, there is at least one (and probably more common) case where this is not true: statically sized arrays as parameters to functions.

But such changes need good justification for their inclusion.  It's clear to me that it's justified on the fact that there is no reasonable use to have the negation of an unsigned be unsigned, but it's not my language :)

I guess unary - for unsigned will only ever be a lint-worthy error.

-Steve
March 01, 2010
Andrei Alexandrescu wrote:
> I'm telling you that pre-monads there was an I/O paradigm that everybody FP swore by.

I looked this up out of curiosity. The Haskell 1.2 report, circa 1992, talks about "streams of messages" and also "continuation-based I/O" as an alternative to streams.

Monads were introduced as the standard for I/O in the 1.3 report, circa 1996.

http://haskell.org/haskellwiki/Definition#Historic_development_of_Haskell

-Jeff
March 02, 2010
Mon, 01 Mar 2010 16:10:33 -0500, Jeff Nowakowski wrote:

> Andrei Alexandrescu wrote:
>> I'm telling you that pre-monads there was an I/O paradigm that everybody FP swore by.
> 
> I looked this up out of curiosity. The Haskell 1.2 report, circa 1992, talks about "streams of messages" and also "continuation-based I/O" as an alternative to streams.
> 
> Monads were introduced as the standard for I/O in the 1.3 report, circa 1996.
> 
> http://haskell.org/haskellwiki/
Definition#Historic_development_of_Haskell
> 
> -Jeff

Btw, there has been some progress in the Haskell land lately:

 - a new llvm based backend which is a lot faster
 - a GA based optimization parameter finder for the new backend
 - a new fusion technique for optimizing functional code
 - a rather nice new benchmarking platform

http://www.haskell.org/pipermail/cvs-ghc/2010-February/052606.html http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using- ghcs-new-llvm-codegen/ http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs- now-with-llvm/ http://donsbot.wordpress.com/2010/02/26/fusion-makes-functional- programming-fun/ http://donsbot.wordpress.com/2010/02/23/modern-benchmarking-in-haskell/

Of course lots of other stuff is also happening, but I thought the language related stuff might interest you.
March 02, 2010
retard:
>  - a new llvm based backend which is a lot faster

I guess most people on Reddit has not read the original thesis. The LLVM Haskell back-end:
- Needs less code to be used by the front-end, this is quite positive for them.
- LLVM compiles better certain heavy numerical kernels. So if you want to use Haskell for number crunching LLVM is better. While most of other Haskell code becomes a little slower.

Bye,
bearophile
March 02, 2010
Tue, 02 Mar 2010 14:55:05 -0500, bearophile wrote:

> retard:
>>  - a new llvm based backend which is a lot faster
> 
> I guess most people on Reddit has not read the original thesis. The LLVM Haskell back-end: - Needs less code to be used by the front-end, this is quite positive for them. - LLVM compiles better certain heavy numerical kernels. So if you want to use Haskell for number crunching LLVM is better. While most of other Haskell code becomes a little slower.

Can you cite any sources? I'd like to know the cases where GCC is faster than the don's new approach.
March 02, 2010
retard:
> Can you cite any sources? I'd like to know the cases where GCC is faster than the don's new approach.

The thesis, page 52 (page 61 of the PDF):
http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf

Bye,
bearophile
March 02, 2010
Tue, 02 Mar 2010 15:33:58 -0500, bearophile wrote:

> retard:
>> Can you cite any sources? I'd like to know the cases where GCC is faster than the don's new approach.
> 
> The thesis, page 52 (page 61 of the PDF):
> http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf

Did you notice that he kept improving the backend interoperability after the thesis was done? The full potential hasn't been realized yet. Also the thesis doesn't mention Don's genetic algorithm stuff or the stream fusion optimization.
March 02, 2010
retard:
>The full potential hasn't been realized yet.<

I'm sure there's space for improvements. But I have yet to see benchmarks that show improvements compared to those shown in the thesis.


>Also the thesis doesn't mention Don's genetic algorithm stuff<

Genetic algorithms can be used with GCC too, this is a more mature software than the one you talk about that uses LLVM: http://www.coyotegulch.com/products/acovea/


>or the stream fusion optimization.<

I don't know about this. I am not sure.

Bye,
bearophile
1 2 3 4 5 6 7 8
Next ›   Last »