October 05, 2009
"Justin Johansson" <no@spam.com> wrote in message news:ha4qpi$189h$1@digitalmars.com...
> For the interest of newsgroups readers, I dropped in at the Cafe the other
> day and
> the barista had this to say
>
> http://cafe.elharo.com/programming/imagine-theres-no-null/
>
> Disclaimer: YMMV
>
> Cheers
>

This is gonna sound trivial (and probably is), but it's been bugging the hell out of me:

What is the meaning of the "+ Looney Tunes" added to the title of this sub-thread? I don't see a connection...?


October 05, 2009
Denis Koroskin:

>I don't see any reason why if (someComplexNumber) { ... } should be a
valid code, it hardly makes any sense for me.<

In general I think adding a boolean-evaluation standard method to D can be positive and handy and not that bug-prone.
But complex numbers are FP, so you usually test if they are close to zero (test of exactly zero can be useful to know if a value was not changed, etc). So I agree with you that for complex numbers such boolarn-eveluation method isn't very useful.
Once D has such operator, it can be defined for library complex numbers too, but probably it will not be used often.
It's useful if you want to write generic code, so if in a templated function you use if(x){... it will work with integers, double, complex values, etc, without special casing.

Bye,
bearophile
October 05, 2009
Nick Sabalausky:

> -- fig A -----------
> open(inFile ~ "out" ~ inFile.file ~ "log");
> // As many as 4 different errors that could be caught but currently aren't.
> // (But obviously all would be overridable, of course)
> // Without such checking, if inFile contained "/usr/home/joe/foo/bar.dat",
> // the result would be:
> //   "/usr/home/joe/foo/bar.datoutbar.datlog"
> 
> // Meant to do this:
> open(inFile.path ~ "out/" ~ inFile.name ~ ".log");
> // Result now: "/usr/home/joe/foo/out/bar.log"
> ---------------------
> 
> -- fig B -----------
> int add(int* a, int* b)
> {
>     return a + b; // Error currently caught
>     // Meant:
>     return *a + *b;
> }
> ---------------------
> 
> -- fig C -----------
> auto accel = velocity * time; // Error caught with that "dimensional
> analysis"
> // Meant this:
> auto accel = velocity / time;
> ---------------------

Scala has a powerful type system that allows to implement such things in a good enough way:

http://www.michaelnygard.com/blog/2009/05/units_of_measure_in_scala.html

Bye,
bearophile
October 05, 2009
>     ranged y = 1000; // Uh, bypasses the setter, no errors
>     writeln(y); // 0?

In the last version of DMD it gives an error:

ranged y = 1000;

temp.d(23): Error: cannot implicitly convert expression (1000) of type int to ranged

Better. And opCast may help here. No implicit cast.

Bye,
bearophile
October 05, 2009
bearophile wrote:
> Scala has a powerful type system that allows to implement such things in a good enough way:
> 
> http://www.michaelnygard.com/blog/2009/05/units_of_measure_in_scala.html

Either I'm missing something, or this system only checks units at runtime (which would make it both slow and unsafe).

Boost.Units (C++) checks units at compile time.  There is no reason why D could not use the same approach.


-- 
Rainer Deyke - rainerd@eldwood.com
October 05, 2009
Mon, 05 Oct 2009 05:29:20 -0600, Rainer Deyke thusly wrote:

> bearophile wrote:
>> Scala has a powerful type system that allows to implement such things in a good enough way:
>> 
>> http://www.michaelnygard.com/blog/2009/05/
units_of_measure_in_scala.html
> 
> Either I'm missing something, or this system only checks units at runtime (which would make it both slow and unsafe).
> 
> Boost.Units (C++) checks units at compile time.  There is no reason why D could not use the same approach.

There have been several existing implementations of SI unit libraries for D. By Oskar Linde et al. The checking can be built statically without any runtime performance penalty.
October 05, 2009
Mon, 05 Oct 2009 11:41:52 +0000, language_fan wrote:

> Mon, 05 Oct 2009 05:29:20 -0600, Rainer Deyke thusly wrote:
> 
>> bearophile wrote:
>>> Scala has a powerful type system that allows to implement such things in a good enough way:
>>> 
>>> http://www.michaelnygard.com/blog/2009/05/
> units_of_measure_in_scala.html
>> 
>> Either I'm missing something, or this system only checks units at runtime (which would make it both slow and unsafe).
>> 
>> Boost.Units (C++) checks units at compile time.  There is no reason why D could not use the same approach.
> 
> There have been several existing implementations of SI unit libraries for D. By Oskar Linde et al. The checking can be built statically without any runtime performance penalty.

The only problem with these was that there was no way to signal the location of the type error in the client code, it always reported the location of the (static) assert in the library, which is pretty much useless.
October 05, 2009
"Rainer Deyke" <rainerd@eldwood.com> wrote in message news:haclah$33m$1@digitalmars.com...
> bearophile wrote:
>> Scala has a powerful type system that allows to implement such things in a good enough way:
>>
>> http://www.michaelnygard.com/blog/2009/05/units_of_measure_in_scala.html
>
> Either I'm missing something, or this system only checks units at runtime (which would make it both slow and unsafe).
>
> Boost.Units (C++) checks units at compile time.  There is no reason why D could not use the same approach.
>

I've been thinking it might be nice to have both. Compile-time for obvious reasons but then also run-time ones that could do conversions:

double(inch) distance = 7;
double(minute) time = 1.5;
double(meter/second) velocity = distance / time; // Compile-time error
auto velocity = convert(meter/second)(distance / time); // Actual
runtime-conversion
auto velocity = convert(meter)(distance / time); // Compile-time error:
Incompatible

Although that would probably be far from trivial to design/implement.


October 05, 2009
Mon, 05 Oct 2009 08:03:11 -0400, Nick Sabalausky thusly wrote:

> "Rainer Deyke" <rainerd@eldwood.com> wrote in message

> I've been thinking it might be nice to have both. Compile-time for obvious reasons but then also run-time ones that could do conversions:

> Although that would probably be far from trivial to design/implement.

Why? Because of the NIH syndrome? Just grab the O. Linde's sources from the ng archives and build the conversion function you mentioned above. It's not that hard to do..
October 05, 2009
"language_fan" <foo@bar.com.invalid> wrote in message news:hacnq3$2en$3@digitalmars.com...
> Mon, 05 Oct 2009 08:03:11 -0400, Nick Sabalausky thusly wrote:
>
>> "Rainer Deyke" <rainerd@eldwood.com> wrote in message
>
>> I've been thinking it might be nice to have both. Compile-time for obvious reasons but then also run-time ones that could do conversions:
>
>> Although that would probably be far from trivial to design/implement.
>
> Why? Because of the NIH syndrome?

Because everything seems super-hard when I'm as tired as I am right now ;)