digitalmars.D - why D matters for Bioinformatics

george (3/3) May 22 2012 An interesting post and case for using D in bioinformatics by

bearophile (5/8) May 22 2012 This article is a strong advertisement for D. I agree D will be

deadalnix (2/10) May 22 2012 I spreaded the word. This article is great and I 100% agree with it :D

bearophile (20/28) May 22 2012 The author of that article has missed that D lacks something much

travert phare.normalesup.org (Christophe Travert) (8/43) May 23 2012 This little example raises a question if tuples becomes part of the

bearophile (29/42) May 23 2012 Why not? Fixed-sized arrays are similar to tuples with uniform

Dmitry Olshansky (39/43) May 23 2012 I'd rather see common structure/static array expansion. Then returning

Dmitry Olshansky (9/40) May 23 2012 In short:

Gor Gyolchanyan (5/66) May 23 2012 This is awesome! I really like it!

travert phare.normalesup.org (Christophe Travert) (6/11) May 23 2012 foreach (immutable sx, sy; unpack(s)) {...}

Andrei Alexandrescu (4/10) May 22 2012 On reddit:

bioinfornatics (4/7) May 24 2012 I have created dsciene for develop a bioinformatics library

"george" <georgkam gmail.com> writes:

An interesting post and case for using D in bioinformatics by
Pjotr Prins
http://blog.thebird.nl/?p=93

May 22 2012

"bearophile" <bearophileHUGS lycos.com> writes:

On Tuesday, 22 May 2012 at 16:01:25 UTC, george wrote:
 An interesting post and case for using D in bioinformatics by
 Pjotr Prins
 http://blog.thebird.nl/?p=93

This article is a strong advertisement for D. I agree D will be 
good for bioinformatics.

Bye,
bearophile

May 22 2012

deadalnix <deadalnix gmail.com> writes:

Le 22/05/2012 19:40, bearophile a écrit :
 On Tuesday, 22 May 2012 at 16:01:25 UTC, george wrote:
 An interesting post and case for using D in bioinformatics by
 Pjotr Prins
 http://blog.thebird.nl/?p=93

 This article is a strong advertisement for D. I agree D will be good for
 bioinformatics.

 Bye,
 bearophile

I spreaded the word. This article is great and I 100% agree with it :D

May 22 2012

"bearophile" <bearophileHUGS lycos.com> writes:

deadalnix:
 http://blog.thebird.nl/?p=93

...

 I spreaded the word. This article is great and I 100% agree 
 with it :D

The article says:

There are a few things I miss in D. For example pattern 
recognition on unpacking data, which is great in Haskell, 
Erlang, and Scala (see example 
[http://www.scala-lang.org/node/120 ]).<

The author of that article has missed that D lacks something much 
simpler than pattern matching, and even more commonly useful. 
Currently in D you have to write something like:

int[2][] directions = [[-1, 0], [1, 0], [0, -1], [0, 1]];
foreach (sx_sy; directions) {
     immutable sx = sx_sy[0];
     immutable sy = sx_sy[1];
     // code that uses sx and sy


While a less clunky language allows you to unpack them better, 
something like:

auto directions = [tuple(-1, 0), tuple(1, 0), tuple(0, -1), 
tuple(0, 1)];
foreach (immutable (sx, sy); directions) {
     // code that uses sx and sy


If you use tuples, you want to unpack them often, it's a basic 
operation on tuples.

Bye,
bearophile

May 22 2012

travert phare.normalesup.org (Christophe Travert) writes:

"bearophile" , dans le message (digitalmars.D:168160), a écrit :
 deadalnix:
 http://blog.thebird.nl/?p=93

...

 I spreaded the word. This article is great and I 100% agree 
 with it :D

 
 The article says:
 
There are a few things I miss in D. For example pattern 
recognition on unpacking data, which is great in Haskell, 
Erlang, and Scala (see example 
[http://www.scala-lang.org/node/120 ]).<

 
 The author of that article has missed that D lacks something much 
 simpler than pattern matching, and even more commonly useful. 
 Currently in D you have to write something like:
 
 int[2][] directions = [[-1, 0], [1, 0], [0, -1], [0, 1]];
 foreach (sx_sy; directions) {
      immutable sx = sx_sy[0];
      immutable sy = sx_sy[1];
      // code that uses sx and sy
 
 
 While a less clunky language allows you to unpack them better, 
 something like:
 
 auto directions = [tuple(-1, 0), tuple(1, 0), tuple(0, -1), 
 tuple(0, 1)];
 foreach (immutable (sx, sy); directions) {
      // code that uses sx and sy
 
 
 If you use tuples, you want to unpack them often, it's a basic 
 operation on tuples.

This little example raises a question if tuples becomes part of the 
langage. Should static array have tuple capabilities ?

Besides that, it is easy to emulate your example with a little 
library solution. Maybe something like that should be added to 
std.range.

-- 
Christophe

May 23 2012

"bearophile" <bearophileHUGS lycos.com> writes:

Christophe Travert:

 This little example raises a question if tuples becomes part of 
 the langage. Should static array have tuple capabilities ?

Why not? Fixed-sized arrays are similar to tuples with uniform 
types. Unpacking short arrays in the same way you unpack tuples 
*very handy* and it's commonly done in both Python and Haskell 
(and probably in other languages too):

In Python:

 t = (10, 20)
 a, b = t
 a



10
 b



20
 l = [3, 5]
 x, y = l
 x



3
 y



5


In Haskell:

Prelude> let t = (10, 20)
Prelude> let (a, b) = t
Prelude> a
10
Prelude> b
20
Prelude> let l = [3, 5]
Prelude> let [x, y] = l
Prelude> x
3
Prelude> y
5


 Besides that, it is easy to emulate your example with a little
 library solution. Maybe something like that should be added to
 std.range.

What syntax do you suggest?
(Generally tuple unpacking/small array unpacking is a so commonly 
done operation that it needs a clean and very nice syntax, so you 
often want it as built-in feature).

Bye,
bearophile

May 23 2012

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 23.05.2012 14:10, bearophile wrote:

 Why not? Fixed-sized arrays are similar to tuples with uniform types.
 Unpacking short arrays in the same way you unpack tuples *very handy*
 and it's commonly done in both Python and Haskell (and probably in other
 languages too):

I'd rather see common structure/static array expansion. Then returning 
struct will be as powerful as multiple value return. The latter can be 
added sometime later, since tuple is just a plain struct.

I expect some form of pattern matching a-la Ecma Script 6 (yeah, I know 
but idea itself is good).

My proposal the is following using a.{ ... } syntax to unpack:

Record r = ...;
auto a, b, c = r.{ first, third, some_other_field };//a=r.first, 
b=r.third, c = r.some_other_field

With tuples:
auto a, b, c = r.{};//a = r[0], b = r[1], c = r[2]
auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4]

With arrays, exactly the same as tuples:
auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4]

Tuples with named fields can work in both named and indexed "modes". 
Indexes must be a valid CT-constant.

More over we then have nested unpacking syntax:

auto x, i = r.{ something, nested_thing.{ precious_secret} };
//x = r.something, i = r.nested_thing.precious_secret

The same with just about any expression:

auto point = (a+b()).{ x, y };
//even better - point is now Tuple!(<type of x>, "x", <type of y>, "y")


Summarizing it all.

For single left-side variable the rewrite of expression is:
auto __tmp = <expr>, tuple(__tmp.<spec_1>, __tmp.<spec_2>);

For multiple left-side the rewrite of the whole statement is:
auto __tmp = <expr>, __1st = __tmp.<spec_1>, __2nd = __tmp.<spec_2> ...;


Where spec_x is constructed from:

root_0.{ ... root_1.{ .. root_n.{ var_x ... } ... } ... }

as
root_0.<...>.root_n.var_x

If some var_k/root_k happens to be CT index the rewrite is 
...[root_k]... or ...[var_k]..


So far I think it's the closest thing to multiple value return with 
natural syntax. It also brings concise syntax for a common general 
propose task.

-- 
Dmitry Olshansky

May 23 2012

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

 My proposal the is following using a.{ ... } syntax to unpack:

In short:
I think the original proposal of
  https://github.com/D-Programming-Language/dmd/pull/341
could be enhanced with introduction  <expr>.{ <spec> } selectors 
allowing to cherry pick fields and array elements easily.

If we go with Kenji's proposal, this can be treated as cool way to 
construct tuple by applying selector to an expression.

 Record r = ...;
 auto a, b, c = r.{ first, third, some_other_field };//a=r.first,
 b=r.third, c = r.some_other_field

 With tuples:
 auto a, b, c = r.{};//a = r[0], b = r[1], c = r[2]
 auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4]

 With arrays, exactly the same as tuples:
 auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4]

 Tuples with named fields can work in both named and indexed "modes".
 Indexes must be a valid CT-constant.

 More over we then have nested unpacking syntax:

 auto x, i = r.{ something, nested_thing.{ precious_secret} };
 //x = r.something, i = r.nested_thing.precious_secret

 The same with just about any expression:

 auto point = (a+b()).{ x, y };
 //even better - point is now Tuple!(<type of x>, "x", <type of y>, "y")


 Summarizing it all.

 For single left-side variable the rewrite of expression is:
 auto __tmp = <expr>, tuple(__tmp.<spec_1>, __tmp.<spec_2>);

 For multiple left-side the rewrite of the whole statement is:
 auto __tmp = <expr>, __1st = __tmp.<spec_1>, __2nd = __tmp.<spec_2> ...;


 Where spec_x is constructed from:

 root_0.{ ... root_1.{ .. root_n.{ var_x ... } ... } ... }

 as
 root_0.<...>.root_n.var_x

 If some var_k/root_k happens to be CT index the rewrite is
 ...[root_k]... or ...[var_k]..


 So far I think it's the closest thing to multiple value return with
 natural syntax. It also brings concise syntax for a common general
 propose task.




-- 
Dmitry Olshansky

May 23 2012

Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:

On Wed, May 23, 2012 at 3:00 PM, Dmitry Olshansky <dmitry.olsh gmail.com>wrote:

 My proposal the is following using a.{ ... } syntax to unpack:

 In short:
 I think the original proposal of
  https://github.com/D-**Programming-Language/dmd/pull/**341<https://github.com/D-Programming-Language/dmd/pull/341>
 could be enhanced with introduction  <expr>.{ <spec> } selectors allowing
 to cherry pick fields and array elements easily.

 If we go with Kenji's proposal, this can be treated as cool way to
 construct tuple by applying selector to an expression.


 Record r = ...;
 auto a, b, c = r.{ first, third, some_other_field };//a=r.first,
 b=r.third, c = r.some_other_field

 With tuples:
 auto a, b, c = r.{};//a = r[0], b = r[1], c = r[2]
 auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4]

 With arrays, exactly the same as tuples:
 auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4]

 Tuples with named fields can work in both named and indexed "modes".
 Indexes must be a valid CT-constant.

 More over we then have nested unpacking syntax:

 auto x, i = r.{ something, nested_thing.{ precious_secret} };
 //x = r.something, i = r.nested_thing.precious_secret

 The same with just about any expression:

 auto point = (a+b()).{ x, y };
 //even better - point is now Tuple!(<type of x>, "x", <type of y>, "y")


 Summarizing it all.

 For single left-side variable the rewrite of expression is:
 auto __tmp = <expr>, tuple(__tmp.<spec_1>, __tmp.<spec_2>);

 For multiple left-side the rewrite of the whole statement is:
 auto __tmp = <expr>, __1st = __tmp.<spec_1>, __2nd = __tmp.<spec_2> ...;


 Where spec_x is constructed from:

 root_0.{ ... root_1.{ .. root_n.{ var_x ... } ... } ... }

 as
 root_0.<...>.root_n.var_x

 If some var_k/root_k happens to be CT index the rewrite is
 ...[root_k]... or ...[var_k]..


 So far I think it's the closest thing to multiple value return with
 natural syntax. It also brings concise syntax for a common general
 propose task.



 --
 Dmitry Olshansky

This is awesome! I really like it!

-- 
Bye,
Gor Gyolchanyan.

May 23 2012

travert phare.normalesup.org (Christophe Travert) writes:

"bearophile" , dans le message (digitalmars.D:168206), a écrit :
 Besides that, it is easy to emulate your example with a little
 library solution. Maybe something like that should be added to
 std.range.

 
 What syntax do you suggest?

foreach (immutable sx, sy; unpack(s)) {...}

doing something like (but more optimised than):

foreach (immutable sx, sy; lockstep(s.map!"a[0]", s.map!"a[1]")) {...}

You have to be careful with types, I don't think the result of map here 
can be cast to immutable (but I didn't check).

May 23 2012

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 5/22/12 12:40 PM, bearophile wrote:
 On Tuesday, 22 May 2012 at 16:01:25 UTC, george wrote:
 An interesting post and case for using D in bioinformatics by
 Pjotr Prins
 http://blog.thebird.nl/?p=93

 This article is a strong advertisement for D. I agree D will be good for
 bioinformatics.

On reddit:

http://www.reddit.com/r/programming/comments/tzpdh/d_is_a_dragon_or_why_d_matters_for_bioinformatics/


Andrei

May 22 2012

bioinfornatics <bioinfornatics fedoraproject.org> writes:

Le mardi 22 mai 2012 =C3=A0 18:01 +0200, george a =C3=A9crit :
 An interesting post and case for using D in bioinformatics by
 Pjotr Prins
 http://blog.thebird.nl/?p=3D93

I have created dsciene for develop a bioinformatics library
https://github.com/dscience-developers/dscience
everyone are welcome to contribute

May 24 2012

D Programming

C/C++ Programming

Other

digitalmars.D - why D matters for Bioinformatics