View mode: basic / threaded / horizontal-split · Log in · Help
February 18, 2010
Re: disabling unary "-" for unsigned types
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
Re: disabling unary "-" for unsigned types
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
Off-topic: Haskell I/O (was Re: disabling unary "-" for unsigned types)
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
Re: Off-topic: Haskell I/O (was Re: disabling unary "-" for unsigned types)
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
Re: Off-topic: Haskell I/O (was Re: disabling unary "-" for
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
Re: Off-topic: Haskell I/O (was Re: disabling unary "-" for
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
Re: Off-topic: Haskell I/O (was Re: disabling unary "-" for
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
Re: Off-topic: Haskell I/O (was Re: disabling unary "-" for
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
Re: Off-topic: Haskell I/O (was Re: disabling unary "-" for
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
Next ›   Last »
4 5 6 7 8
Top | Discussion index | About this forum | D home